How We Plan 30 Games: The Spreadsheet That Kept Us on Track

Planning 30 games at once is a nightmare. We used one spreadsheet to track concepts, dev status, content, specs, and deployment. Boring? Yes. Essential? Absolutely. Here's the system we built.

The 3-Pass Pipeline

Every game goes through three stages: Concept (idea, mechanics, feasibility), Code (prototype to polish), Content (wrapper page, strategy article, metadata). At any given time we have games in all three stages.

Surprising truth: writing the content takes longer than coding the game. A solid strategy guide runs 2-3 hours. The actual game code? Maybe 1-4 hours. Most people would never guess that. We found that starting content while coding was in progress kept both workflows efficient.

Prioritizing Game Features

Every game on Gerk Games begins with a feature list that is roughly three times longer than what ships. Our prioritization framework ranks features by three criteria: player impact (how many players will notice and benefit), development cost (engineering hours required), and maintenance burden (ongoing support cost). Features that score high on impact and low on cost ship first. Features that score low on impact regardless of cost are cut entirely.

Testing Strategy for Game Bugs

Game testing follows a different pattern than web application testing because the code runs in a continuous 60fps loop. Game bugs often manifest as visual glitches that only appear under specific timing conditions. Our testing protocol: run the game for 30 minutes with the developer playing (covers 70% of bugs), run automated input sequences for 2 hours (covers 20% of edge cases), and deploy with a feedback mechanism for the remaining 10% that only real players discover.

Responsive Design Planning

Designing a game that works on both 5-inch phones and 32-inch monitors requires planning responsive layout from day one. The game canvas must scale proportionally while maintaining aspect ratio. UI elements (score, buttons, menus) should be positioned relative to the canvas edges rather than in fixed pixel coordinates. We use a viewport-based scaling system where the game renders at a fixed resolution and the browser CSS scales it to fit.

Cost Estimation and Timeline Management

Game development timelines are notoriously unpredictable because gameplay quality cannot be estimated from feature checklists. Our solution: estimate the minimum viable version (core mechanic working at 60fps on one device), then multiply by three for the production version. The first version takes roughly one week for a simple arcade game. The production version — with menus, settings, mobile optimization, accessibility, and SEO metadata — takes three weeks. Budgeting for this 3x multiplier prevents the common mistake of underestimating the gap between a prototype and a shippable product.

Post-Launch Maintenance Planning

The most commonly underestimated phase of game development is post-launch maintenance. Users report bugs, request features, and encounter compatibility issues with new browser versions. Our maintenance budget allocates 10% of total development time per month for the first three months after launch. During this period, we fix reported bugs within 48 hours and release patches immediately (no batching). After three months, maintenance drops to 2% of monthly development time as the game stabilizes. This aggressive early maintenance strategy ensures high review scores and user retention — a game with responsive bug fixes retains 40% more users over its first year than one with monthly patch cycles.

Risk Management in Game Development

Every game project faces risks that can derail the timeline. We categorize risks into three types: technical unknowns (will the physics engine work on mobile?), design risks (is the core mechanic actually fun?), and schedule risks (how long will polishing take?). Technical unknowns are mitigated through prototyping — build a single level with all planned mechanics before committing to the full game. Design risks are mitigated through player testing — if the first five testers do not report fun within the first 30 seconds, the game goes back to the drawing board. Schedule risks are mitigated by the 3x estimation rule: whatever timeline the developer estimates, multiply by three.

What Got Cut and Why

Of the 45 game concepts we considered, 15 made it to production. The other 30 were cut at various stages. Some were cut for technical reasons (required WebGL shaders that didn't work on budget phones). Some were cut for content reasons (the gameplay loop wasn't satisfying after 30 seconds). And some were cut for market reasons (too similar to existing games in our catalog).

One specific concept that was painful to cut: a 2D platformer with procedural level generation. The technology worked — the algorithm generated interesting levels reliably. The problem was that the generated levels, while technically varied, all felt the same. The player couldn't tell the difference between level 5 and level 50. Manual level design creates intentional variety that procedural generation cannot replicate without AI-level sophistication. We decided that a game with repetitive levels was worse than no game at all, so we shelved it.

Another concept that made it far but ultimately failed: a rhythm game using Web Audio API to generate music procedurally. The music generation was impressive — it produced listenable, structured songs with bass, melody, and percussion. But the latency between user input and audio feedback on Bluetooth headphones (200-400ms) made the rhythmic accuracy impossible to calibrate. We could have forced wired headphones, but that's not a good user experience for browser games played on the couch. So it got cut.

The Columns That Actually Mattered

Our planning spreadsheet went through several versions before we found the columns that earned their place. The ones we kept: a one-line core mechanic, an estimated build time, a "fun risk" rating from one to five, and a dependency note. The columns we deleted were the ones that felt productive but never changed a decision — elaborate priority scores, detailed feature lists, projected play counts. A planning artifact is only useful if it changes what you do next; columns that look organized but never alter a decision are just decoration.

The Fun-Risk Rating

The most valuable column turned out to be the subjective "fun risk" rating — our honest guess about whether a concept would actually be fun once built. Games with high fun-risk got a quick throwaway prototype before any real work, because the spreadsheet flagged them as gambles. This saved us from fully building several concepts that looked great on paper and felt flat in practice. A number that captures gut uncertainty, used to trigger cheap experiments, prevented more wasted weeks than any precise estimate ever did.

Why We Stopped at Thirty Rows

A planning document that lists two hundred game ideas is a wish list, not a plan. We deliberately capped the active spreadsheet at the games we genuinely intended to build in the near term, and kept a separate, ignored "someday" list for everything else. Mixing aspirational ideas with committed work makes the committed work feel optional and the aspirational work feel obligatory. Keeping the real plan small and the dream list out of sight kept us shipping instead of endlessly re-prioritizing.