A HOLE PLANET

I wanted A Hole Planet to work as a quick arcade game rather than a long simulation. Five minutes creates enough room to build a planet while keeping every decision immediate: there isn’t enough time to patiently wait for ideal conditions, so the player is encouraged to interfere.

A successful run can finish considerably faster. Once the player understands the system, the challenge shifts from simply surviving to finding a more efficient route through it—building mass first, identifying water-rich planets, collecting atmosphere at the right time, minimizing damage, and reaching a stable orbit as quickly as possible.

That naturally turned completion time into the score.

I didn’t want the surrounding planets to function as static checkpoints or collectibles. They exist in the same orbital environment as the player and can be physically disrupted.

Hit a planet at lower speed and you can change its trajectory. Hit it with enough mass and velocity and you can drive through it completely. That destruction creates debris which remains in orbit, turning the player’s previous aggression into a new navigational hazard.

Other celestial bodies can collide with one another as well. An object you’ve knocked off course can come back around later, collide with something else—or hit you from behind.

Make a mess. Drive through the mess.

Visually, I resisted turning the planets into cartoon characters. The celestial bodies remain textured, atmospheric, and relatively serious because the absurdity works better when the world itself doesn’t seem to know it’s a joke.

Personality instead comes from behavior. Planets react when the player gets too close, remember repeated collisions, and complain through short speech bubbles while continuing along their orbit.

A Hole Planet was never intended to be an astrophysics simulator. Real planets don’t accelerate on command, deliberately change orbital radius, or spin faster because someone is holding a keyboard key. But I also didn’t want the solar system to feel arbitrary.

Mass affects what the player can destroy. Momentum makes changes in speed take time. Temperature depends on orbital position. Damage affects the planet’s ability to retain resources. Collisions alter trajectories. Water freezes farther from the star and evaporates when conditions become too extreme.

That created the central interaction problem behind the entire prototype: if the player is driving something with planetary mass, the controls can’t feel like they’re driving a car.

The delay between input and response became one of the most important parts of the game. Increasing speed doesn’t instantly launch the player forward. Changing radius doesn’t teleport the planet onto another orbital path. The player has to anticipate where a target will be, begin changing trajectory early, and account for the momentum of the body they’re controlling.

As the player’s mass increases, that sense of inertia becomes increasingly important. What initially feels like a slightly sluggish control scheme becomes the core skill: learning to drive ahead of the planet rather than reacting at the last second.

Orbital movement can be difficult to read from a camera that remains centered on the player. If everything else is moving around you, changing speed or radius doesn’t necessarily feel like movement.

I added physical responses to the planet itself so the controls became visible. Moving between orbital paths changes its apparent tilt. Accelerating and decelerating pitches the axis forward and backward. Increasing spin destabilizes the planet and introduces a visible wobble. At higher speeds, background stars stretch into streaks.

The HUD tells you what you changed. The planet shows you what it feels like.

Spin originally belonged to the physical fantasy of controlling a planet, but it became more useful once I connected it to damage recovery. A planet slowly repairs itself at its normal rotation. Increasing spin accelerates that process, giving the player a way to recover quickly after collisions.

The tradeoff is control. High spin destabilizes the planet’s orientation and creates a wobblier orbital path. A short burst can repair meaningful damage, but leaving it elevated makes precision driving much harder.

Early collision behavior broke the illusion. Planets reacted at rigid angles, making impacts feel more like objects bouncing around a simple game board than massive bodies exchanging momentum.

I reworked collisions so an impact could redirect both bodies. A lower-energy hit can shove another planet into a different trajectory and speed while disturbing the player’s own orbit. With enough mass and velocity, that same collision crosses a threshold and becomes destructive.

That made ramming useful beyond simply collecting resources. A player can deliberately alter another body’s path—but whatever trajectory they create continues through the system.

The earliest prototype already allowed changes in orbital radius and speed, but the game didn’t feel convincing until the camera behaved correctly.

The player needed to remain visually grounded to their own planet while still reading movement relative to the solar system around them. Once that relationship worked, the unusual control model became much easier to understand: the planet felt like the vehicle, and the rest of the system became the road.

Before

After

The player begins as a small, damaged planetary body with only a fraction of the mass required to support life. Early in a run, asteroids provide relatively safe opportunities to grow.

As mass increases, the player’s relationship with the rest of the solar system changes. Smaller collisions become less threatening, larger celestial bodies become viable targets, and sufficient mass combined with enough velocity allows the player to stop merely knocking planets around and start driving straight through them.

Water can’t simply be collected by touching another planet. The player has to pull alongside a water-rich body, close the gap, and match its orbital speed closely enough to establish a stable siphon.

Maintain that relationship and water begins transferring between the two planets: the target visibly dries out while oceans gradually appear across the player’s own surface. Break the speed match or drift too far away and the siphon stops.

Water retention depends on the condition of the planet itself. Repeated impacts create location-specific craters, and sufficiently severe damage can expose the core. Once that happens, water begins escaping from the damaged surface.

Temperature creates another constraint. Move too close to the star and oceans evaporate. Move far enough away and the planet visibly freezes, covering the surface in ice until it returns to warmer conditions.

You have to build a planet capable of holding what you steal.

Collect water

Atmosphere introduces another dependency. A planet can’t retain one until it has accumulated enough mass, forcing the player to prioritize growth before atmospheric collection becomes efficient.

Once that threshold is reached, the player can intercept atmospheric clouds distributed throughout the system and ride through them to build the resource. But the same conditions that threaten water threaten atmosphere as well.

Damage is spatial rather than purely numerical. Impacts leave visible craters where the collision occurred, and repeated hits to the same area can eventually expose the planet’s core.

That makes damage part of the resource system rather than simply a fail state. A badly damaged planet becomes less capable of retaining the water and atmosphere required to finish the game. Repair therefore becomes another strategic decision.

Entering the star’s inner heat zone triggers annealing, rapidly repairing planetary damage. That can rescue a run after a destructive collision or prepare the surface to retain water again.

But the same heat that repairs the planet also strips atmosphere and boils away its ocean. Staying longer means healing faster while destroying more of the progress you’ve already made.

Not every interaction rewards aggression. Moons function as optional time bonuses for players trying to improve leaderboard runs.

Like siphoning, capturing one requires pulling alongside its parent planet and holding position long enough to complete the transfer. Larger moons take longer to steal, forcing the player to decide whether the potential time bonus is worth interrupting a faster route toward habitability.

They aren’t required to create life. They’re there for players who have started optimizing the system rather than simply surviving it.

After spending most of the run changing orbit, stealing resources, smashing objects, repairing damage, and generally destabilizing the solar system, the final challenge asks the player to do something completely different: settle down.

To create life, the planet must enter a temperate orbital zone with the required mass, water, atmosphere, and surface condition—and maintain those conditions for ten seconds.

It’s deliberately fragile. Debris is still orbiting. Other planets are still moving. Asteroids can still hit. The player has to hold a stable environment inside the mess they created getting there.

The primary HUD is organized around the five conditions required to create life: mass, water, atmosphere, temperature, and damage.

Rather than functioning as passive progress bars, each panel changes with the state of the planet. Atmosphere explains when the player is too small to retain it. Temperature shifts between frozen, temperate, and scorched conditions. Damage surfaces repair behavior.

Five systems. One finish line.

The solar system contains far more information than can remain on screen permanently. Instead of giving every celestial body a persistent interface, nearby planets reveal contextual information only when they become relevant to the player.

Approach another planet and a panel exposes the information needed to interact with it: available water, mass, moons, distance, and relative speed. The closer the player gets to an actionable state, the more specific the feedback becomes.

Don’t show everything about the planet. Show what the player can do with it.

Some of the most important mechanics depend on relationships the player can’t judge precisely from the 3D scene alone. Two planets can appear close together while moving at very different velocities.

GAP and MATCH translate that invisible relationship into something actionable. Once both enter the required range, the interface changes state and a siphoning progress bar confirms that the player has successfully established the maneuver.

Close the gap · match velocity

Not every state needed another panel. Damage appears physically where the planet was hit. Repeated impacts deepen the same area until the core becomes visible. Water gradually covers the surface as it’s collected. Move into colder orbit and that surface freezes.

Those effects aren’t only visual polish. They reduce the amount of abstract information the HUD has to communicate.

Keeping the camera close enough to make the planet feel controllable creates another problem: the player loses a global view of the solar system.

I added the orbital map as a navigation layer rather than forcing players to constantly zoom out and search the 3D environment. It shows the player’s position relative to other celestial bodies and atmospheric resources, allowing someone to identify a target and plan the next orbital move without abandoning the driving view.

Because several resources can increase or decrease for different reasons, a changing number alone isn’t sufficient feedback.

Warning states explain the cause of the change whenever possible: the planet is too small to hold atmosphere, the star is boiling away water, damage is allowing resources to escape, or the current orbit is outside a temperate range. That turns failure into information the player can immediately act on.

The neighboring planets provided another feedback channel—just one that didn’t need to sound like a system message. Get too close and they become uncomfortable. Hit one and it complains. Hit the same planet again and it remembers you.

Designing A Hole Planet challenged one of my own tendencies: when a system becomes more sophisticated, it’s tempting to expose that sophistication in the interface. The opposite usually made the game better.

Controls became easier to understand when they were reduced to three inputs. Planet information became clearer when it appeared contextually. Physical changes replaced abstract indicators where possible. Feedback became more useful when it explained consequences instead of exposing mechanics.

An impressive system isn’t useful if the person playing it is the only one who doesn’t understand what’s happening.

I designed the game as an interconnected set of rules rather than a sequence of scripted events. Celestial bodies have orbital position, speed, and mass. Collisions can alter trajectories. Damage is stored spatially rather than as a purely cosmetic effect. Destroyed planets become persistent debris.

That separation allowed the visual layer to communicate what the underlying simulation was already doing rather than inventing effects solely for appearance.

126

Celestial Bodies

128 × 32

Localized Damage Grid

20

Code Modules

5,817

Lines

0

Application Servers

I used Claude extensively to implement the code while I focused on designing the game itself: the premise, mechanics, interaction rules, control behavior, risk/reward relationships, UI structure, visual direction, and continual playtesting and tuning.

The workflow was highly iterative. I’d define how a mechanic should behave, test the implementation in the browser, identify where the interaction stopped feeling intuitive or fun, and revise the rules until it clicked.

AI dramatically compressed the distance between “what if this worked?” and “let me play it.” It didn’t eliminate the design decisions required once the thing existed.

A Hole Planet isn’t a scripted demonstration with a predetermined successful path. The same interacting systems that create the intended experience can also produce unexpected situations: planets collide without the player’s involvement, altered trajectories create later encounters, destroyed worlds fill useful orbital lanes with debris, and badly timed damage can undo several minutes of resource collection.

That unpredictability became part of the appeal. Once the rules worked together, the game started producing situations I hadn’t explicitly designed.

Because A Hole Planet is designed around short repeatable runs, completion time naturally became the competitive layer. The browser submits finished runs directly to Firestore, where validation rules reject impossible scores before they’re added to the leaderboard.

There is no custom application server behind it—the playable prototype remains essentially a browser game with a lightweight persistence layer.

The weekend build proved the mechanic, not the final game. I’m continuing to refine the interface, environmental behavior, and physical interactions—including stronger gravitational effects near the star and the ability to push celestial bodies completely out of orbit.

But those are extensions of a loop that already works. By Sunday night, the question had changed from “Can this be a game?” to “How far can I push it?”

Some of the mechanics I initially treated as limitations became the things that made A Hole Planet feel distinctive.

The planet couldn’t respond instantly without feeling weightless, so inertia became part of the challenge. Repair needed a purpose, so spin became a risk/reward mechanic. Destruction needed consequences, so shattered planets became persistent debris. Resource collection needed more than progress bars, so water, atmosphere, damage, mass, and temperature became dependent on one another.

The game became more interesting when I stopped trying to make everything convenient for the player.

Building the system made me want to expose more of it. Playing the system made me want to remove things.

I simplified controls, made information contextual, pushed feedback into the environment, and focused the interface on immediate decisions rather than underlying mechanics.

If the creator has to explain how impressive the system is, the experience isn’t doing enough of the work.

AI-assisted development let me test ideas at a speed that would have been unrealistic for me otherwise. More importantly, it changed what I could prototype. Instead of stopping at a storyboard or interaction concept, I could put the actual mechanic in my hands, discover why it didn’t work, and make another decision.

The prototype became part of the design process—not just the artifact at the end of it.

A Hole Planet is still an active experiment, not a commercial product. I’m continuing to polish the playable prototype because the core interaction is fun and there are still ideas worth testing.

I’m deliberately not attaching a larger business story to it. The project already answered the question that justified building it: can a ridiculous idea survive contact with an actual player?

In this case, yes.