What is a roadmap, and why do you need one?
A roadmap is a plan that breaks the path to a finished game into stages. It is a map you decide on in advance: what you will build, in what order, and over how long.
When you make a game on your own, it is easy to start building whichever feature comes to mind first without seeing the way to the finish. The result is often a growing list of features and no end in sight, until the project stalls. With a roadmap, you know which stage you are in and what to do next, so you are less likely to lose your way.
A roadmap is not something you must never change once it is set. You use it while reviewing it against your progress. Start by writing down the path to the end, even if it is rough.
Three things to decide before you plan
Before you think about detailed steps, decide the following three things. They give your roadmap its shape.
1. What game are you making?
Try writing the core of your game's play in a single sentence. For example, “Jump over obstacles to reach the goal.” Ideally it is short enough to say in one breath. If you cannot write it in one sentence, that is a sign you are not yet clear about what you want to make.
Also decide whether it is 2D or 3D, what genre it is, and which game engine you will use. If you have not chosen an engine yet, see Game Engines Compared: Unity, Godot, Unreal Engine, and RPG Maker Explained.
2. Who is making it?
Working alone or with teammates changes how you proceed. Alone, a list of your own tasks done in order is enough. With teammates, you need to decide at the start how to divide roles and how to share and merge data.
3. How much time can you spend?
The time to finish changes a lot depending on whether you can spend a few hours a week or large blocks of time almost every day. Base the durations in your roadmap on the time you can actually set aside. The trick is to plan around the time you realistically have, not the time you wish you had.
These three match the questions in our Game Development Roadmap tool. If you are unsure, you can organize your thinking by answering the tool’s questions.
For beginners: how to split the work into stages
If you are new to game development, do not jump straight into the game you most want to make. It is better to build up small successes as you go. Splitting the work into stages like the following lets you progress without strain.
| Stage | What to do | Purpose |
|---|---|---|
| 1. Preparation | Install the engine, find an official tutorial, and decide on a working folder and how to back it up. | Get to a state where you can start working. |
| 2. Basics | Learn how to read the screen and how to place and move objects. Work through an official tutorial to the end. | Learn the basics of the engine. |
| 3. Finish one small game | Make a small game that can be played from the title screen to the end. | Gain the experience of finishing something. |
| 4. Prototype | Build only the core of the gameplay with placeholder assets and have other people play it. | Check that it is fun before polishing. |
| 5. Main production | Add features little by little, centered on the gameplay you confirmed in the prototype. | Build the game you are aiming for. |
| 6. Effects and finishing | Add sound effects and visual effects, review the controls, and fix bugs. | Raise the quality. |
| 7. Release | Choose where to publish, prepare a description and images, and publish. | Let people play it. |
If you care more about simply finishing than about quality, you can skip the prototype and effects stages and go from the small game straight to main production. Add or remove stages to match your goal.
Make your first game very small
Keep your first game small enough that you can say, “That is all there is to it.” For example:
- A game where you simply jump over obstacles (2D)
- A short linear story with only three choices
- A game where you roll a ball to the goal (3D)
- An escape game where you walk around a room, search, and find a key to get out (3D)
Even if it is small, it matters that it can be played from the title screen to the end. The experience of finishing builds confidence for your next, bigger project.
For experienced developers: define “done” as you go
If you already have some experience, deciding a done condition for each stage makes the path clearer. The following flow is one example.
| Stage | What to do | Example done condition |
|---|---|---|
| 1. Concept and specification | Write the core loop in one sentence. Decide the target play time and volume. Sort features into must-have, nice-to-have, and will-not-do. | You can explain it to someone else with a one-page spec. |
| 2. Prototype | Implement only the core loop with placeholder assets. Decide the foundation: input, camera, basic state transitions, and so on. | You can judge whether it is fun after playing for five minutes. |
| 3. Vertical slice | Build one stage (or chapter) with final-quality art, sound, and UI. Re-estimate the total production cost based on results so far. | One stage is playable at release quality. |
| 4. Full implementation | Implement starting with the must-have features and produce a playable build every week. | All must-have features work and the game can be played from start to finish. |
| 5. Testing and tuning | Have several people playtest, and record and fix where they quit or get stuck. Adjust difficulty, balance, and performance load. | There are no known critical bugs and the game can be finished in the intended time. |
| 6. Release preparation and launch | Prepare the materials for the store page, and check the platform’s rules and review conditions and your asset licenses. Set up a way to receive feedback and bug reports. | You meet the platform’s conditions and can publish. |
The idea behind a vertical slice
A vertical slice is one part of the game, such as a single stage, built all the way to final quality. Building one shows you how long a stage takes once art, sound, and UI are included. You can use that result to re-estimate the cost of the whole game, so you find estimation errors early.
Items worth putting in a spec
- The core loop (what the player repeats)
- Controls and supported input devices
- Screen and scene structure (title, main game, results, and so on)
- Difficulty and how progress works
- Whether there is saving, and what is saved
How to estimate time
Estimate the time for each stage and add them up. Keep these points in mind:
- Plan around the time you can actually spend: For example, if you can only spend a few hours a week, expect about twice the duration you would need if you could work almost every day.
- Main production takes the longest: It makes up the largest share of the total. Think of it as the stage to expand, even at the expense of the others.
- Caring about quality adds stages and time: Adding the prototype, effects, and testing stages makes the total longer.
- Estimates will be off: Your first estimate is only a guide. Revise it using what you learn from your finished small game or your vertical slice.
Our Game Development Roadmap tool automatically calculates a guide to the duration of each stage based on your choices. It calculates one month as about 4.3 weeks, and the figures are only estimates.
Tips to keep your roadmap from falling apart
- Set a done condition for each stage: Deciding when something counts as finished helps you move forward without going back and forth between stages.
- Do not add features beyond the scope you set at the start: When a new idea comes up, note it down for your next game instead of adding it to this one. If you must add it, cut something else.
- Keep a working version every week: Do not build too much at once; save in a working state. If something breaks, you have somewhere to go back to.
- Check that everything works each time you add something: If you check everything at once, you lose track of what caused a bug.
- Have other people play it: They find places where players get stuck, or where the fun does not come across, that you would not notice yourself.
- Make backups and version control a habit: Use Git or similar, or at least copy your working folder regularly.
- Review once a week: Check your progress and the remaining work, and adjust the roadmap if needed.
Common mistakes and how to deal with them
| Mistake | What to do |
|---|---|
| Scope grows out of greed | Build one stage to finished quality and estimate the total from that result. |
| You keep adding new features before finishing | Freeze the spec partway and save new ideas for the next game. |
| You aim for a masterpiece from the start and stall | Finish one small game first, then start on the one you really want to make. |
| Making assets takes too much time | Use placeholder assets in the prototype, and make the real assets after you have confirmed it is fun. |
| You are caught off guard by conditions just before release | Check the platform’s rules and your asset licenses early. |
Build your roadmap with our tool
Our Game Development Roadmap asks about your experience, engine, 2D or 3D, genre, team size, goal, and available time. From your answers, it puts together a roadmap with a recommended engine and a guide to the duration of each stage. For experienced developers, it also shows design suggestions based on your viewpoint and the features in your game. You can copy the result as text or print it, so use it as a starting point for your project. Your answers are never sent anywhere.
The way of splitting stages and the approach to durations in this article are only examples. The right approach varies with your game and your team. Adjust them to your own situation.