The Sky Is Falling

Purpose

First game project. Control a little Earth with a shield, tap incoming stars to destroy them before they reach you, collect the stardust they leave behind. Built in Flutter Flame as a way to learn 2D game development. It was not good. It was first.

Stack

What I Learned

• Flame's game loop (update + render running at 60fps) was the first time I worked outside of the widget-rebuild paradigm that Flutter normally uses. Widgets rebuild when state changes. Games rebuild every frame regardless. The mental shift from "update when something happens" to "update everything, 60 times per second, always" is the transition from app developer to game developer.
• Tap-to-destroy is one of the simplest input patterns in mobile games — detect which game object is under the tap coordinate, destroy it, spawn particles. But even this simple interaction requires: a collision detection system (is the tap point inside any star's hitbox?), an object lifecycle (spawned → active → destroyed → cleaned up), and visual feedback (explosion effect, stardust particle, score increment). The "simple" interaction has four systems underneath it.
• The stardust collection mechanic (destroy a star, its remains drift down, collect them for score) adds a secondary decision: do you focus on destroying incoming threats or do you move to collect the stardust from previous kills? This tension — defense vs. collection — is emergent from two simple systems interacting. The best game design creates decisions from intersecting mechanics, not from complex rules.
• The game somewhat works but is not polished. The star spawning is too random (sometimes nothing, sometimes overwhelming), the shield mechanic is unclear (what does it actually do?), and the difficulty curve is flat. These are all tuning problems, not architecture problems. The code works. The game design needs iteration. This distinction — working code vs. fun game — is the lesson that every game developer learns on their first project.

Key Insights

• First games should be bad. Not intentionally bad — earnestly attempted and genuinely not good. The value of a bad first game is that it calibrates your expectations: you learn how much work "fun" actually requires, how far "somewhat works" is from "people want to play this," and how many invisible systems (spawning, difficulty curves, feedback, juice) sit between a prototype and a product.
• Every game in the Hot Potato Games catalog — Burlap Sacker, Potato Pounder, Tater Dash, Grid Commander, Hot Potato, Tenlach — traces its lineage back to The Sky Is Falling. This was the project where Flame was first learned, where the game loop was first understood, where tap-based interaction was first implemented. The first game is never the best game. It is the game that makes all the other games possible.
• The order of this blog being "last updated" rather than "created" is actually revealing — it shows which projects I kept returning to. Older projects that were recently updated (like Intervalition, Tenlach) are the persistent ones. Projects listed early with old dates are the ones that were built and left. The update timestamp is a measure of emotional attachment as much as technical activity.