How to Scope Your First Indie Game
Scope is the most important decision you make on any project, and it is the decision most developers get wrong. The natural instinct is to include everything that would make the game better. More levels, more enemy types, more weapons, more story, more polish, more features. Each addition seems small in isolation, but together they multiply into a project that requires ten times the work of the original vision. A platformer with 10 levels, 3 enemy types, and a jump mechanic is a one-month project. The same platformer with 50 levels, 15 enemy types, 4 power-ups, a shop system, boss fights, and cutscenes is a one-year project. The design on paper looks only slightly more ambitious. The development reality is an order of magnitude different.
Step 1: Define the Core Mechanic
Every game has one mechanic that makes it interesting. In Celeste, it is the dash. In Baba Is You, it is pushing word blocks to change the rules. In Vampire Survivors, it is automatic attacking while the player focuses on positioning and build choices. In your game, there should be one mechanic that you can describe in a single sentence. "The player swings between buildings using a grappling hook." "The player solves puzzles by rotating the level." "The player builds towers to defend against waves of enemies." That single sentence is your scope anchor. Everything in the game exists to support that mechanic. Everything that does not support it is a candidate for cutting.
Testing the core mechanic is the first thing you should do, before any other development. Build the simplest possible version of the mechanic, colored rectangles, no levels, no enemies, no score, and play with it for fifteen minutes. Is it fun to just do the thing? Does the grappling hook feel satisfying to swing? Does rotating the level create interesting spatial puzzles? Does the tower placement create meaningful strategic decisions? If the raw mechanic is not enjoyable, no amount of content, art, or polish will save the game. If it is enjoyable, you have a foundation worth building on.
Resist the urge to add a second core mechanic. One well-developed mechanic with interesting interactions is deeper than two half-developed mechanics that do not interact. Super Meat Boy is just running and jumping. The depth comes from the level design, not from mechanic count. Adding a second mechanic doubles the development work (two systems to build, balance, and test), doubles the design work (every level must account for both mechanics), and often dilutes the identity of the game. If your first mechanic is strong, double down on it. If it is weak, adding a second mechanic will not save it.
Step 2: Write the One-Page Design Document
A one-page design document forces you to prioritize ruthlessly. If the entire game cannot fit on a single page of text (roughly 500 words), the scope is too large for a first project. The document should include: a one-sentence description of the game, the core mechanic, the player's goal, how the game starts, how the game ends, how many levels or how much content, what the player sees on screen, and what makes the game interesting. That is everything. No lore document, no world-building bible, no detailed level-by-level breakdown. One page.
The discipline of the one-page document serves a psychological function as well as a practical one. A short document feels achievable. You can read the entire scope in two minutes and feel confident that you can build it. A twenty-page design document feels like a commitment that is already out of control, even before any code is written. When development gets difficult (and it always does), the one-page document serves as a reminder that the goal is close and manageable, not distant and overwhelming.
Here is an example one-page design document for a realistic first game: "Gravity Flip is a single-screen platformer where the player flips gravity to navigate through obstacles. The player presses spacebar to flip between falling down and falling up. The goal is to reach the exit door on each level. There are 10 levels that progressively introduce new obstacle types: static platforms, moving platforms, and spikes. The game has a start screen with a Play button, a level select screen that unlocks levels sequentially, and a congratulations screen after level 10. Art is simple geometric shapes. One background music track loops during gameplay. Sound effects for jumping, dying, and completing a level. Estimated development time: 2-3 weeks."
Step 3: List Every Feature, Then Cut Half
After writing your one-page design, make a comprehensive list of every feature, system, and piece of content the game needs. Include everything, no matter how small: title screen, level transitions, score display, sound effects, pause menu, settings, tutorial text, analytics, credits screen, social media sharing. Be thorough. The list will be longer than you expect, which is the point. Most developers underestimate scope because they only think about the big features and forget the dozens of small tasks that collectively take more time than the features themselves.
Now rank every item on the list by importance to the core experience. The top half of the list is your actual scope. The bottom half goes into a "nice to have" document that you look at only after the top half is complete. In practice, you will almost never finish the bottom half, and that is fine because the game works without it. A platformer without a pause menu is still a platformer. A platformer without a settings screen is still a platformer. A platformer without a credits screen is still a platformer. None of these are as important as having good levels and a satisfying jump.
The features you cut are not lost forever. They go into a list for potential post-release updates or for your next game. Cutting a feature from version 1.0 does not mean it will never exist. It means it will not prevent you from shipping. This mindset shift, from "the game needs everything" to "the game needs the core experience and everything else is a bonus," is the most important scope management skill a developer can learn.
Step 4: Estimate Time, Then Triple It
Time estimation in game development is notoriously inaccurate, and it is always inaccurate in the same direction: everything takes longer than expected. Experienced developers use a multiplier to account for this. The standard advice is to take your honest estimate and multiply it by three. If you think a feature will take two hours, budget six. If you think the game will take three weeks, budget nine. This is not pessimism. It is realism based on decades of collective experience across the game industry.
The triple multiplier accounts for several categories of hidden work. First, implementation always involves unexpected complications: edge cases, browser compatibility issues, physics interactions you did not predict, and bugs that take longer to fix than the feature took to build. Second, integration is its own task. A feature that works in isolation often breaks other features when combined. Third, polish takes longer than implementation. Getting a jump to feel "right" takes ten iterations of adjusting gravity, acceleration, coyote time, and animation timing, and each iteration takes time. Fourth, non-development tasks eat more time than expected: testing on different devices, writing descriptions for store pages, capturing screenshots, creating a trailer, and responding to feedback.
For a first game, estimate the total development time and check it against a realistic calendar. If you work on games for one hour per weekday evening, that is five hours per week, roughly twenty hours per month. A game scoped for 60 hours of development will take three months at that pace. If three months feels too long for your first project, reduce the scope until the time estimate fits a timeframe that feels sustainable. One month is an excellent target for a first game. Two months is acceptable. Anything longer risks losing motivation before you ship.
Step 5: Define Done Before You Start
Write a concrete, checkable "definition of done" before you write any code. This is a list of specific conditions that, when all are met, mean the game is ready to release. Not "the game feels polished" (subjective and impossible to measure) but "the game has 8 playable levels, a title screen, a game-over screen, no crash bugs, and works on Chrome, Firefox, and Safari" (concrete and checkable). When every box is checked, you ship. No exceptions, no "just one more thing," no "I want to add one more level." Done is done.
A good definition of done for a first web game might look like this: all levels are playable from start to finish without bugs. The game has a start screen with a Play button. The game has a game-over or victory screen with a Restart button. At least two sound effects exist (one for a core action, one for failure or success). The game loads and runs on desktop Chrome, Firefox, and Safari. The game loads and runs on mobile Safari and Chrome. Touch controls work if the game supports mobile play. The game is uploaded to itch.io with a description and at least one screenshot.
The definition of done prevents the most dangerous form of scope creep: moving the finish line. Without a concrete definition, "done" becomes a receding target. You finish the levels but decide the art needs improvement. You improve the art but realize you should add a leaderboard. You add the leaderboard but notice the menu could use animation. Each addition is small, but together they extend development indefinitely. The definition of done is a contractual agreement with yourself: when these conditions are met, I ship.
Step 6: Freeze the Scope After Week One
New ideas will arrive during development. They always do. The act of building a game generates more ideas than you can implement, and many of those ideas are genuinely good. The temptation to add them is powerful because they feel like improvements rather than additions. "This is not scope creep, this is just making the game better." But every addition delays the release, and delayed releases are the primary cause of abandoned indie projects.
The solution is a scope freeze. After the first week of development, lock the feature list. Any new idea, no matter how good, goes into a separate document labeled "Next Game" or "Post-Release." You do not evaluate whether the idea is worth adding. You do not debate it internally. You write it down and move on. The discipline of the scope freeze is uncomfortable at first, but it is the single most effective tool for ensuring that games actually ship.
The "Next Game" document serves two purposes. First, it gives your ideas somewhere to go so they do not nag at you during development. Second, it provides a head start on your next project. By the time you finish your current game, you will have a document full of tested, refined ideas that emerged from real development experience rather than abstract brainstorming. Many of the best features in successful indie games were ideas that were cut from a previous project and refined over time.
Common Scope Traps for First-Time Developers
Certain types of scope expansion are so common among first-time developers that they deserve specific warnings. Multiplayer is the most dangerous scope trap. Adding multiplayer to a game is not a feature, it is a fundamental architecture change that affects every system in the game. Networking, synchronization, latency compensation, matchmaking, server infrastructure, and testing all multiply the development effort by three to ten times. A single-player game that takes one month becomes a multiplayer game that takes six months. Save multiplayer for your third or fourth game.
Procedural generation is the second most common trap. It sounds like a shortcut: instead of designing 20 levels by hand, generate infinite levels with an algorithm. In practice, procedural generation requires extensive tuning to produce levels that are actually fun. Random is not fun by default. Interesting procedural generation requires constraints, rules, and validation systems that ensure generated content meets quality standards. This is a sophisticated engineering challenge that takes longer than hand-designing the levels would have.
Story and dialogue expand scope invisibly. A game with "just a few lines of dialogue" quickly becomes a game with NPCs, dialogue boxes, text rendering systems, dialogue branching logic, character portraits, and writing that needs editing and testing. If your game needs story, convey it through environmental design and short text screens between levels rather than through interactive dialogue systems.
Custom game engines are the ultimate scope trap. Building your own engine instead of using an existing one feels like a learning opportunity, and it is, but the learning it provides is about engine architecture, not about game development. You can spend six months building an engine that handles sprites, input, physics, and audio, and at the end you have a worse version of Phaser with zero games made. Use an existing engine and focus your time on the thing that matters: making a game.
The right scope for a first indie game is one core mechanic, one page of design, a concrete definition of done, and a timeline of one to two months. Cut everything that does not directly support the core experience, freeze the scope early, and ship when the checklist is complete. Small finished games teach more than large unfinished ones.