Alien Invasion

Context matters for this one. Alien Invasion isn't an indie game someone shipped and moved on from — it's the worked example bundled with the first three chapters of an actual published book on mobile HTML5 game development, written in 2011, back when getting a <canvas> element to respond correctly to a finger rather than a mouse was a genuinely open technical question. Judged as what it actually is — a teaching artifact — the touch implementation holds up remarkably well. Judged as a game worth adding to a curated shelf on its own merits, it's too thin to clear that bar.

The touch controls earn their place in the history books

engine.js's TouchControls class draws three squares directly onto the game canvas — a left arrow, a right arrow, and a fire button labelled "A" — and binds touchstart, touchmove, and touchend on the canvas to read finger position against those zones, writing straight into the same Game.keys object the keyboard handler uses. That's not a mouse-event fallback dressed up as touch support; it's a dedicated implementation, and it was confirmed working rather than assumed: on a simulated 390×844 touch phone, holding the left button dragged the ship steadily across the screen, and tapping the fire button launched a missile that travelled independently up-screen while the score counter incremented. For code written in 2011, before touchGamepad patterns were common and years before most mobile web games got this right, that's a genuinely notable piece of craft.

Two small fixes were needed to get here

As committed, the page requested its title-screen font — a bold, comic-style face called Bangers — from a plain http://fonts.googleapis.com URL. Every modern browser treats an insecure sub-resource request from an HTTPS page as mixed content and blocks it outright, so as shipped, this page would have silently lost its display font on any browser built in the last decade. Switching the link to https:// was a one-character fix and the font now loads and renders correctly.

The second issue is smaller and wasn't worth a source change: on a phone-width canvas, the "ALIEN INVASION" title and the "You lose!" game-over text run off both edges of the screen. The title screen draws its text with a fixed bold 40px bangers, and the mobile scaling path in Game.setupMobile() halves the canvas's internal resolution on wider screens to keep sprites crisp — a reasonable design decision in 2011 that just doesn't leave enough width at that fixed font size on a modern phone viewport. It's readable in fragments, not a functional blocker, but it's a real rough edge on exactly the device category this shelf is built around.

Twenty-five seconds, on a loop

Here's the part that keeps this off the shelf: reading level1 in game.js shows the entire game content as a single scripted sequence — a wave of enemies flying straight down, a wave moving left-to-right, a wave circling in, spanning about 25 seconds — after which winGame() fires and shows "You win! Press fire to play again," which restarts the identical sequence. There's no second level, no increasing difficulty, no new enemy type introduced later, and dying partway through just resets you to the same beginning. Play it once, and you've seen everything the game does. That's exactly appropriate for a book's chapter-three checkpoint, where the point is teaching sprite collision and wave scripting, not building a complete arcade experience — but it means there's nothing here that rewards a second visit on its own terms.

Where that leaves it

A 6.0 reflects real, well-earned credit for controls that were doing the right thing over a decade before this shelf existed to demand it, set against a game that is, honestly, a single short demo level rather than something with enough of its own substance to send a friend. Worth a look for what it represents; not worth bookmarking for what it plays like.