Attack of Excalius

I wanted to make a game. There was no problem statement, no user, and no requirement beyond that — which, at eight, is exactly the right amount of specification.

Sprites drawn in the built-in editor. Jump physics arrived at by changing numbers until the jump felt right, which is a legitimate method I have never fully abandoned. Collision detection that worked in most cases and produced memorable failures in the rest.

And a boss fight I could not balance. Every adjustment made it either trivial or impossible, and I never found the middle. That was my first encounter with a problem that does not yield to more effort of the same kind.

Event-driven by construction, because Scratch gives you nothing else: sprites receiving messages, each running its own scripts, all state global and shared.

I did not know that "every variable is global" was a design constraint rather than how programs are. I found out by breaking the game — a variable one sprite depended on, quietly modified by another, producing a bug I could not reason about because I had no concept of scope to reason with. Meeting shared mutable state at eight, without the word for it, is a good way to learn why the word exists.

A finished game that other children played. Given how many projects at that age reach 80% and stop, finishing is the whole result.

• Finishing is a separate skill from building, and it is the rarer one.
• The title screen is not the game. I rewrote it more times than the boss fight, because it was the part I knew how to improve. Working on what is comfortable instead of what is hard is a habit I still catch myself in.
• Some problems do not yield to more of the same effort. The boss fight needed a different model of difficulty, not more tuning. I did not have that idea for years.