Game of Planets – Development Breakdown
For Recruiters, Hiring Managers, and Technical Leads
Game of Planets is a large-scale online 4X real-time strategy game originally built as a solo project on custom C++/C# technology and later folded into Indie Games Startup LLC. This page is a curated breakdown of what the game is, what I personally owned, and how I approached the technical and production challenges behind it.
High-Level Overview
- Genre & scope: Online 4X RTS with a persistent galaxy of ~1,600 star systems and 10,000+ planets, focused on long-running campaigns rather than short matches.
- Tech stack: Custom engine written primarily in C++/C#, with bespoke simulation, rendering, and tools tailored to the game’s large data sets and persistent state.
- Development timeline: First playable delivered in 9 months, followed by ~15 months of continuous iteration with a 200+ player closed beta community.
- Current status: Now a flagship title under Indie Games Startup LLC, being advanced toward a Steam edition with a core team of experienced, AAA-veteran developers.
My Role on the Project
I created Game of Planets and served as designer, lead programmer, and producer for the early life of the project. That meant owning the architecture and simulation, core game systems, UX, build/release pipeline, and player community.
As the project matured, it also became the nucleus for a remote studio. The practices developed here—instrumentation, release cadence, documentation, and community-facing changelogs—later scaled into the pipelines used at Indie Games Startup LLC.
Architecture & Key Systems
The goal was to support a persistent, data-heavy galaxy with fast iteration on balance and systems. Some of the core pieces:
- Galaxy simulation: Custom simulation layer managing thousands of celestial bodies, fleets, and long-running processes (production, research, logistics) with careful control over tick rates and update budgets.
- Procedural generation: Systems to create star systems, planets, and initial conditions procedurally, while still allowing handcrafted scenarios and debug setups.
- Economy & infrastructure: Resource extraction, production queues, trade routes, and planetary development, designed to create interesting macro-level decisions without overwhelming the player with micromanagement.
- AI & factions: Faction behavior for expansion, diplomacy, and warfare, with tunable aggression and personality settings used heavily during balance passes.
- Combat & ship design: Heavily inspired by MechWarrior-style loadouts, with a detailed ship-design screen that balances power, mass, heat, and cost, and a combat model tuned to reward good fleet composition and positioning.
- Tools & debugging: In-game debug overlays, logging, and test harnesses for stress-testing the simulation and quickly reproducing edge cases reported by testers.
Production & Process
Even as a solo developer for much of the project, I treated Game of Planets like a studio title with real production discipline:
- Milestones: Planned and delivered a first playable in 9 months, then moved to a cadence of frequent, playable builds with clear release notes.
- Closed beta: Recruited and managed a 200+ player tester community on Discord, using their feedback and telemetry to guide balance and UX improvements.
- Issue tracking: Maintained a lightweight but consistent bug/feature board, triaging issues based on impact and risk and grouping changes into low-risk, incremental releases.
- Playtest structure: Ran focused playtest cycles on specific systems (economy, AI, ship design), gathering both qualitative feedback and quantitative data where possible.
- Documentation: Kept concise internal docs on systems, modifiers, and progression curves so future collaborators could understand and extend the design.
Selected Technical & Design Challenges
A few of the more interesting problems and how I approached them:
- Scaling a persistent galaxy: Naïvely updating everything every frame quickly became infeasible. I moved to staged, batched updates with different tick cadences for “fast” vs “slow” systems, plus on-demand recalculation for UI-only views.
- Performance on modest hardware: Profiling showed bottlenecks in pathfinding and resource calculations. I rewrote hot paths, reduced allocations, and introduced simple caching layers to keep long campaigns stable over many hours of play.
- Making complex systems legible: Early UIs exposed too much raw data. I iterated towards clearer summaries, context-sensitive tooltips, and color-coded indicators so players could make decisions without reading spreadsheets.
- Balancing depth vs. pace: Testers enjoyed the depth but some stalled out on early turns. I tuned early-game economies, adjusted tech costs, and added more guided objectives so players hit “interesting decisions” faster.
- Solo development at this scale: To avoid being the bottleneck, I invested heavily in automation (builds, packaging, basic regression checks) and documentation so that when collaborators joined later, they could ramp quickly.
Lessons Carried into Later Work
Game of Planets directly informed how I now build games and run teams:
- Start with tools and observability: Good debug views and logs pay for themselves many times over in both solo and team contexts.
- Scope the first version hard: Deliver a tight core loop early, then layer complexity on top of a stable, well-understood foundation.
- Design for collaboration: Even if starting solo, structure code and data so that future engineers, designers, and artists can safely extend the game without having to reverse-engineer everything.
- Community as a design partner: A structured tester community is one of the fastest ways to surface blind spots and discover what really matters to players.
Further Links & Context
