Defining the Prototype Boundary

Problem

What is the smallest version of Orbital Ignition that can answer whether its core puzzle idea is worth pursuing?

The first prototype needs to create useful evidence without quietly turning into a production build. That means separating the central interaction from progression systems, polished art, audio, and all the other work that can make an idea feel complete before it is actually proven.

Exploration

I considered starting with a broader vertical slice: a polished level, finished visual language, basic menus, and enough progression to communicate the intended experience. That would be easier to show, but slower to change and much more likely to hide a weak mechanic behind presentation.

The opposite approach is a disposable mechanics sandbox. It is faster and more honest, but only if it still captures the timing, feedback, and constraints that make the puzzle legible.

The useful middle ground is a deliberately narrow prototype with enough feedback to evaluate the loop, but no systems that do not help answer the current design question.

Decision

The Core Puzzle Prototype is the only active milestone.

The build should prove three things:

1. The central interaction is understandable without a tutorial wall.
2. A player can form a plan, act, and read the result.
3. The mechanic creates enough variation to support more than one obvious solution.

Anything that does not help test those claims stays outside the milestone.

Media

Screenshots, GIFs, and short MP4 captures will live here as the prototype becomes visual. Markdown images work directly, and videos can be embedded with a standard HTML video element:

<video controls preload="metadata" src="/journal-media/orbital-ignition/example.mp4"></video>

Next Steps

• Build the smallest playable interaction loop.
• Establish temporary visual feedback for valid and invalid actions.
• Write down the first playtest questions before testing the build.
• Capture the earliest prototype, even if it is ugly.

---

✅ Locked

• The first milestone is the Core Puzzle Prototype.
• Prototype work is evaluated by the questions it answers, not by presentation quality.
• Early builds and failed directions belong in this journal.

🤔 Exploring

• The minimum feedback needed to make the core interaction readable.
• How much variation the first test environment needs.
• Which metrics and observations will make playtests useful.

❌ Rejected

• Building a polished vertical slice before validating the core mechanic.
• Adding progression, final art, or production UI to the first milestone.