Skip to content

Auto Warz — Risk Register

Document Type: Project Management Version: 0.1 (Draft) Status: Living Document — review monthly Last Updated: 2026-02-22 Vault destination: 04_Project Management Author: Solo Developer Parent Document: [01_Master GDD](<../01_Design Documents/01_Master GDD.md>) Related Documents: [02_Scope & MVP Document](<../01_Design Documents/02_Scope & MVP Document.md>) · [01_Development Roadmap](<./01_Development Roadmap.md>) · [01_Technical Architecture Document](<../02_Technical Documents/01_Technical Architecture Document.md>)


Table of Contents


Purpose of This Document

This document identifies every known risk to Auto Warz — technical, design, project, and personal — and defines a mitigation strategy for each.

A risk that is identified and planned for is a problem. A risk that is ignored is a crisis.

Review this document monthly and after every major milestone. Update it when new risks emerge or when existing risks are resolved.


How to Use This Register

  • Review monthly — risks change as development progresses
  • Add new risks as they emerge — don't wait for a scheduled review
  • Move resolved risks to the #Resolved Risks section with a note on how they were resolved
  • Act on High likelihood + High impact risks immediately — these are the ones that kill projects

Risk Rating System

Likelihood

Rating Meaning
🔴 High Very likely to occur — has happened before or is a known pattern
🟡 Medium May occur — dependent on decisions or external factors
🟢 Low Unlikely — possible but would require unusual circumstances

Impact

Rating Meaning
🔴 High Could kill or severely delay the project
🟡 Medium Significant rework or delay but recoverable
🟢 Low Minor inconvenience, easily handled

Priority = Likelihood + Impact

Likelihood Impact Priority
🔴 High 🔴 High 🚨 Critical — act now
🔴 High 🟡 Medium ⚠️ Serious — have a plan ready
🟡 Medium 🔴 High ⚠️ Serious — have a plan ready
🟡 Medium 🟡 Medium 📋 Monitor — review monthly
Any 🟢 Low 📋 Monitor — low priority
🟢 Low 🔴 High 📋 Monitor — unlikely but plan ahead

Technical Risks

T1 — Factory Simulation Performance at Scale

Likelihood 🟡 Medium
Impact 🔴 High
Priority ⚠️ Serious
Description The factory simulation running 500+ entities at 60fps may cause performance issues, especially with belts, pipes, drones, and trains all active simultaneously.
Mitigation Build a performance test harness in M1.4. Establish baseline FPS metrics monthly. Use tick-based simulation (20 ticks/sec) to decouple sim from render. Profile before optimising — don't guess.
Early Warning Signs FPS dropping below 55 with fewer than 200 entities during prototype phase.
Contingency Reduce simulation tick rate. Implement entity LOD (distant buildings simulate less frequently). Cap maximum entity count per planet.

T2 — Multiplayer Desync in Factory Simulation

Likelihood 🔴 High
Impact 🔴 High
Priority 🚨 Critical
Description Factory simulation state diverging between host and clients is the single hardest problem in multiplayer factory games. Belt item positions, inventory counts, and research state must be perfectly synced.
Mitigation Authoritative host model — clients never simulate, only render. Full state broadcast every 5 seconds as desync recovery. Delta updates every simulation tick. Design simulation to be deterministic from day one.
Early Warning Signs Any visible difference between host and client view during M4.2 testing.
Contingency Increase full state broadcast frequency. Implement client-side rollback for minor desyncs. In worst case, force client resync from host on any detected divergence.

T3 — Godot 4 Engine Limitations

Likelihood 🟢 Low
Impact 🔴 High
Priority 📋 Monitor
Description Godot 4 may have undiscovered limitations for factory simulation at scale — particularly around large numbers of physics-adjacent entities, GDScript performance ceiling, or multiplayer API constraints.
Mitigation Build the performance test harness early (M1.4). If GDScript becomes a bottleneck, migrate hot paths to GDExtension (C++). Pin Godot version and update deliberately.
Early Warning Signs GDScript simulation tick taking > 5ms with fewer than 200 entities.
Contingency Profile and move simulation to a separate thread. Migrate critical systems to GDExtension if needed. In extreme case, evaluate engine switch (expensive — avoid).

T4 — NAT Traversal / Port Forwarding for Multiplayer

Likelihood 🔴 High
Impact 🟡 Medium
Priority ⚠️ Serious
Description Many home routers block incoming connections. Players wanting to host a session may need to configure port forwarding — a step many casual players won't complete. This directly limits the multiplayer audience in Phase 1.
Mitigation Document port forwarding clearly in-game and on Steam page. Provide a connection test tool in the lobby screen. Explore ENet relay options for Phase 1. Implement Steam Sockets (which handles NAT automatically) in Phase 3.
Early Warning Signs More than 30% of playtester feedback mentions difficulty connecting.
Contingency Implement a basic relay server option. Partner with a free relay service (e.g. Godot Relay) for Phase 1.

T5 — Save File Corruption

Likelihood 🟢 Low
Impact 🔴 High
Priority 📋 Monitor
Description A corrupted save file can destroy hours of player progress and generate very negative reviews. Most common cause: crash during save write.
Mitigation Write save to a temporary file first, then rename to replace the actual save (atomic write pattern). Keep a rolling backup of the last 3 saves. Validate save file on load — detect and report corruption before attempting to load.
Early Warning Signs Any save/load failure during M3.6 testing.
Contingency Auto-restore from most recent backup. Display clear error message with backup restoration option. Never silently fail a save.

T6 — Cel-Shader Inconsistency Across AI-Generated Assets

Likelihood 🟡 Medium
Impact 🟡 Medium
Priority 📋 Monitor
Description Hand-modelled assets from Blender may have inconsistent geometry that causes the cel-shader to behave differently across assets — some assets looking great, others having broken outlines or incorrect shading.
Mitigation Lock and test the cel-shader before importing any final assets (M5.2). Run all assets through the same Blender cleanup process. Maintain a shader test scene with all asset types visible simultaneously.
Early Warning Signs More than 20% of imported test assets have visible shader issues.
Contingency Manual shader override per-asset. Rebuild problematic assets. In worst case, simplify shader to improve consistency at the cost of visual quality.

T7 — GodotSteam Plugin Compatibility

Likelihood 🟢 Low
Impact 🟡 Medium
Priority 📋 Monitor
Description Godot engine updates may break compatibility with the GodotSteam plugin, requiring plugin updates or workarounds before Steam features work.
Mitigation Pin Godot version during active development. Only update Godot at milestone boundaries. Monitor GodotSteam GitHub for compatibility notes before updating.
Early Warning Signs GodotSteam repository showing unresolved compatibility issues with pinned Godot version.
Contingency Delay Godot update until GodotSteam compatibility is confirmed. Implement Steam features without the plugin as a fallback (limited but possible).

Design Risks

D1 — Scope Creep

Likelihood 🔴 High
Impact 🔴 High
Priority 🚨 Critical
Description The single most common cause of indie game project death. Adding features outside the current phase scope delays Early Access and exhausts developer motivation. This game has a particularly rich design space — the temptation to add "just one more thing" will be constant.
Mitigation The [02_Scope & MVP Document](<../01_Design Documents/02_Scope & MVP Document.md>) and this roadmap exist specifically to combat this. Every new feature idea goes to 00_Ideas first. Nothing gets built until it is formally added to the scope document. Review scope document at the start of every development session.
Early Warning Signs Working on a feature not listed in the current phase milestone. Ideas folder has 20+ items. Feeling like Phase 1 "needs" space or war content.
Contingency Stop. Open the Scope & MVP Document. If the feature isn't there, it doesn't get built. No exceptions.

D2 — Factory Loop Not Fun Enough at Early Access

Likelihood 🟡 Medium
Impact 🔴 High
Priority ⚠️ Serious
Description Phase 1 ships as a factory-only game. If the factory loop isn't compelling enough to stand alone — without space or war — the Early Access launch will underperform and damage long-term prospects.
Mitigation Achieve M1.7 (Prototype Complete) and play it for 10+ hours before building anything else. Get 5+ external playtesters through 2-hour sessions before M5.5. Treat external feedback as a design priority, not an optional extra.
Early Warning Signs Developer doesn't want to keep playing after completing the prototype. Playtesters stop before the 1-hour mark without external prompting.
Contingency Delay Early Access launch. Identify and fix the most-cited friction points from playtest feedback. Do not launch until the core loop is genuinely fun.

D3 — Multiplayer Balance — One Player Dominates

Likelihood 🟡 Medium
Impact 🟡 Medium
Priority 📋 Monitor
Description In co-op factory sessions, one player who understands the systems well could end up doing everything while others feel useless. This kills the multiplayer experience.
Mitigation Design the factory scale to genuinely require multiple players to manage simultaneously. Test multiplayer sessions with players of mixed experience. Natural role specialisation (Planet/Space/War) is the primary solution.
Early Warning Signs Multiplayer playtests where one player reports feeling like a spectator.
Contingency Add explicit role tools — player can "claim" a section of the factory or a planet. Introduce mechanics that physically require multiple players (two-player building assembly, etc.).

D4 — Alien Difficulty Curve Feels Unfair

Likelihood 🟡 Medium
Impact 🟡 Medium
Priority 📋 Monitor
Description Expansion-triggered alien attacks could feel punishing rather than challenging — especially for new players who don't know the attack will come. Players may feel ambushed rather than fairly challenged.
Mitigation Give clear advance warning before alien attacks (Radar Tower reveals alien movement, HUD alert when expansion crosses territory boundary). Teach the mechanic clearly in early game with low-aggression enemies before the player can trigger serious threats.
Early Warning Signs Playtesters expressing frustration rather than challenge when attacked. Multiple reports of "I didn't know that would happen."
Contingency Add a grace period after territory crossing before attack begins. Add more visible alien territory markers. Tune down early alien aggression.

Project Risks

P1 — Developer Burnout

Likelihood 🟡 Medium
Impact 🔴 High
Priority ⚠️ Serious
Description Auto Warz is a 3–5 year project. Solo development over that timeline without breaks or community support leads to burnout — the leading cause of hobby game project abandonment.
Mitigation Celebrate every milestone completion. Build in the open (devlog, Discord, Reddit) — community engagement provides external motivation. Take intentional breaks between major phases. Keep sessions to 15–20hrs/week — do not crunch. Revisit the World Bible and play the current build when motivation dips.
Early Warning Signs Dreading development sessions. Going 2+ weeks without working on the project. Feeling like the project is "too big."
Contingency Take a 1–2 week complete break. Return with a smaller, achievable task (fix one bug, polish one building). Do not make permanent decisions about the project while burned out.

P2 — Early Access Underperformance

Likelihood 🟡 Medium
Impact 🟡 Medium
Priority 📋 Monitor
Description Phase 1 Early Access sales may not meet expectations, reducing financial motivation to continue development and limiting budget for Phase 2 and 3 tools and services.
Mitigation Build community before launch — devlog, Reddit (r/gamedev, r/factorio, r/indiegaming), Discord. Steam wishlist campaign 3–6 months before launch. Set realistic sales expectations (1,000–5,000 units is a success for a first hobby game). Remember: the game is a labour of love first, revenue second.
Early Warning Signs Steam wishlist count below 500 at launch. Little to no community engagement pre-launch.
Contingency Do not reduce scope to chase sales. Focus on community building post-launch. A small dedicated community is more valuable than chasing a broad audience.

P3 — Key Tool Discontinuation or Pricing Change

Likelihood 🟢 Low
Impact 🟡 Medium
Priority 📋 Monitor
Description AI tools (Recraft, Leonardo AI, Artistly.ai, Suno, ElevenLabs) may change pricing, terms of service, or shut down. Losing a key tool mid-development causes pipeline disruption.
Mitigation Never rely on a single tool for any discipline — always have a documented backup. Save all generated assets locally immediately. Prompt library in [03_Prompt Library](<../03_Art & Audio/03_Prompt Library.md>) ensures prompts are not lost if a tool changes.
Early Warning Signs Any announcement of major pricing changes or ToS updates from key tools.
Contingency Switch to documented backup tool. Regenerate affected assets using backup tool and master style prompt.

P4 — Licensing Issue with AI-Generated Assets

Likelihood 🟢 Low
Impact 🔴 High
Priority 📋 Monitor
Description AI tool licensing terms for commercial use may change, or legal precedent may shift, creating uncertainty about the right to sell a game using AI-generated assets.
Mitigation Review licensing terms of all AI tools at project start, at Early Access launch, and at v1.0 launch (checklist in [03_AI Toolchain](<../01_Design Documents/03_AI Toolchain.md>)). Use tools with clear commercial licensing. Keep records of which tool generated each asset and under what terms.
Early Warning Signs Major legal rulings against commercial use of AI-generated art. Key tools removing commercial licensing from their plans.
Contingency Commission replacement assets from human artists for affected content. Budget reserve for this scenario.

Personal Risks

PR1 — Life Events Interrupting Development

Likelihood 🟡 Medium
Impact 🟡 Medium
Priority 📋 Monitor
Description Work, family, health, or other life events may reduce or eliminate available development time for extended periods. This is normal for a hobby project over a multi-year timeline.
Mitigation The project is designed for hobby pace — it can scale down to 5hrs/week without dying. Feature-based milestones mean no artificial deadlines. All documentation is thorough enough to resume after a long break without losing context.
Early Warning Signs N/A — life happens.
Contingency Pause development without guilt. Do a 1-hour "re-orientation session" (read Master GDD, Development Roadmap, last milestone status) when returning. Resume at whatever pace is sustainable.

PR2 — Skill Gap in Required Development Areas

Likelihood 🟡 Medium
Impact 🟡 Medium
Priority 📋 Monitor
Description Certain systems — multiplayer networking, shader development, procedural generation — may exceed current skill level and require significant learning investment before implementation.
Mitigation AI assistance (Claude, Codex) significantly reduces the skill gap for implementation. Godot 4 has strong documentation and community tutorials. The roadmap sequences hard systems (multiplayer) after easier ones (factory simulation) — skill builds naturally.
Early Warning Signs Blocked on the same technical problem for more than 3 days despite AI assistance and documentation research.
Contingency Simplify the system. Build the minimum viable version first. Hire a freelancer for specific hard problems if budget allows. Post to Godot Discord for community help.

Resolved Risks

Move risks here when they are no longer active, with a note on resolution.

Risk Resolution Date
Engine choice (Godot 4 vs UE5) Decided: Godot 4 + GDScript. Documented in [01_Technical Architecture Document](<../02_Technical Documents/01_Technical Architecture Document.md>) 2026-02-22
Multiplayer scope (Phase 1 vs Phase 3) Decided: Full online multiplayer in Phase 1. Documented in [01_Technical Architecture Document](<../02_Technical Documents/01_Technical Architecture Document.md>) 2026-02-22
Research system design Decided: Hybrid A+D (Science Drives + Field Data). Documented in [[08_Economy & Progression Design]] 2026-02-22
Art style Decided: Chunky cartoon voxel, cel-shaded, VoxelMade reference. Documented in [01_Art Direction Document](<../03_Art & Audio/01_Art Direction Document.md>) 2026-02-22

Revision History

Version Date Changes
0.1 2026-02-22 Initial draft — 13 risks identified across technical, design, project, and personal categories

Review this document monthly. A risk register that isn't updated is a false sense of security.