Space Strats Devlog 06: A Prototype We Can Build On
The evidence behind the current prototype, how the team keeps systems understandable, and what the next milestone needs to prove.
The tactical test scene at the current checkpoint. Units, cover and the action bar are functional prototype elements; the visual identity is still being developed. Captured in Unreal Engine, September 27, 2026.
Project overview · Phase 06 / 06
What we can show today
Space Strats now has enough connected systems to demonstrate a design process: construct an arena, build reusable pieces, tune its atmosphere and inspect tactical decisions in the combat prototype. Getting these parts to agree is a production milestone for a three-person team.
Our September 27 checkpoint recorded 182 automated checks: 179 clean, three with known asset warnings, and zero failures. A complete Editor build succeeded, and a visual check covered startup, hotbar paging, the radial menu, lighting tools and developer controls.
Those are results from that checkpoint. They establish a useful baseline for further changes, rather than certifying final balance, a packaged release or a particular frame rate. The captures in this series document the prototype itself.
Keeping a growing project understandable
The code separates the saved map, the editing session, the runtime’s spatial queries and the combat rules. Rendering consumes that state. A prettier wall should not accidentally become a different cover rule.
Text-based map and object formats make designs inspectable outside Unreal. Dedicated test maps isolate heights, cover, interactions, spawns, layers, modes, fluids and lighting. This gives a teammate a focused place to reproduce a problem instead of assembling a new arena every time.
Each system also has a human-readable guide and an agent handoff. Our AI-assisted workflow keeps architecture and final review with the senior, while bounded implementation tasks can be delegated with explicit file ownership and checks. The documentation gate detects missing updates; the team still has to write and review the explanation. This helps a later session recover the decisions behind a feature.
The next milestone should answer three questions
| Question | Useful evidence |
|---|---|
| Can a new creator build a satisfying arena? | Observe first-time users creating, revising and saving a small level. Find the points where they need help. |
| Does its decoration preserve tactical clarity? | Compare the complete arena with its gameplay-only view, then test movement and attacks through ambiguous spaces. |
| Does the arena lead to interesting encounters? | Integrate a clearly defined objective, play repeated encounters and revise routes, cover and starting positions. |
These are proposed review criteria, not a dated release promise. A more coherent art pass, encounter design and the full game loop remain ahead of the current prototype.
A few practical questions
Is this a finished game or a public demo?
It is a development prototype. This portfolio does not announce a release date or a public download. The editor and combat test scene demonstrate current systems; they do not represent a finished campaign or a complete commercial build.
What is implemented in the different game modes?
The editor can store multiple mode configurations on one shared arena and offer the corresponding authoring elements. King of the Hill and Capture the Flag illustrate that structure. Their complete scoring and victory rules still need gameplay implementation.
What would be useful in a publisher conversation?
A walkthrough of construction, the reusable-object workshop and tactical testing, followed by a discussion of the next playable milestone. This series documents what exists today; it does not claim sales, retention figures or a validated market.