GAME DEV MAPS: VISUALIZING YOUR DEVELOPMENT JOURNEY

I used to run my entire game project out of a Google Doc. One document. Thirty thousand words. Design notes, bug reports, todo lists, art direction, random shower thoughts from 2am, all stuffed into one scrolling brick of unformatted text. I knew where everything was in the sense that I knew it was somewhere. I did not know where anything was in the sense that actually mattered, which is being able to open the project on a Tuesday morning and know what to do next.

That is the whole problem with invisible work. If you cannot see the shape of what you are building, you cannot tell whether you are moving through it or just moving around inside it. A video game developer map is not a cute productivity gimmick. For solo devs especially, it is the thing that tells you, at a glance, whether last week mattered.

This is a post about game dev maps. Trello boards, Notion databases, whiteboards, sticky note walls, Gantt charts, and the weird hybrids people invent when the tidy options stop fitting. I have tried most of these. Some of them were disasters. One of them is the reason my current project is still moving.

Why visualizing progress is not optional for solo devs

A team of ten people has emergent visibility. Someone walks past your desk, sees you staring at a bug, asks what is up, and now two people understand that bug. A standup forces you to describe what you did yesterday and what you will do today, out loud, to humans. You cannot hide from your backlog because someone else has it open on their second monitor.

Solo dev has none of that. No standup. No drive-bys. No one asking what you did yesterday because no one was there. The only record of what you have actually built is the project itself, which is also the thing you are in the middle of changing, which means you cannot use it as a reference point. You open Unity on Monday and you are already lost.

The purpose of a map is to be the external memory that a team would normally provide. It is not about being organized in the aesthetic sense. It is about having somewhere to look that is not the code, where you can see the difference between "a lot of things are happening" and "the game is actually getting closer to done." Those are not the same thing. You can be extremely busy and also going in circles, and without a map you will not catch yourself.

The other reason visualization matters is motivational. Game dev is a slog. Most days you do not feel progress. The feedback loop of "I moved a card from In Progress to Done" is stupid and small and also, genuinely, one of the few reliable sources of dopamine in a project that takes years. Ship enough tiny wins, collected in one visible place, and you can keep going when the actual game is still a mess.

Trello, or why I keep coming back to kanban

My first real map was a Trello board. Lists across the top. Cards underneath. Drag right to show progress. This is the kanban pattern and it has been around since Toyota was making station wagons, and there is a reason it keeps turning up in every software project ever written.

The columns I settled on, after a lot of fiddling, are these. Backlog. Next Up. In Progress. Blocked. Playtest. Done. Six columns. Everything I want to do goes in Backlog. Things I want to do soon go in Next Up. The thing I am actively working on right now, and ideally only one thing, goes in In Progress. Blocked is for things waiting on something else, a tool update, a friend playing a build, an asset I ordered. Playtest is for features that are technically done but have not been validated yet. Done is Done.

The Blocked column is the one I almost skipped and the one that saved me. Before I had it, blocked tasks would sit in In Progress forever, making the board look busy while nothing was actually moving. Seeing four cards stuck in Blocked is a different feeling from seeing four cards stuck in In Progress. It tells you the problem is not you, the problem is that you are waiting on stuff and should either unblock it or start something else.

The trap with Trello, and with any digital board, is that it becomes write-only. You add cards faster than you move them. The Backlog swells to two hundred items. You stop looking at it because opening it makes you feel bad. I have crashed a Trello board this way twice. The fix, and this feels counterintuitive, is that the Backlog should not be a wishlist. If something has been sitting in Backlog for three months and you have not touched it, delete it. If it matters it will come back. Ninety percent of the time it does not come back, because it did not matter.

Notion, or when a board is not enough

Trello is great for flat lists. Kanban works when the work is roughly the same shape and you just need to track state. It starts to fall apart when you need to track relationships. A card for "implement enemy AI" is related to a card for "build enemy sprite" is related to a design doc for "enemy behavior" is related to a bug that came up in last week's playtest. Trello cannot represent this. You end up with a lot of checklists inside cards, and the structure gets lost.

Notion solves this differently. Instead of one board, you build a small database. Every task is a row. Every row has properties. Status, priority, area (audio, code, art, UI, marketing), estimated hours, related features, playtest feedback. Then you view that same database in different ways. Kanban view for daily work. Calendar view for deadlines. Gallery view grouped by area for "what is the state of my audio work right now." Same data, different lenses.

This is powerful and it is also where a lot of solo devs lose six weeks. Notion invites you to build the perfect system before you do any real work. You will spend a Saturday setting up a beautiful wiki with linked databases and rollup formulas and toggles that open into sub-pages that contain more databases. Monday comes. You open Unity. You do not touch the Notion wiki again for a month. The system collapses under its own weight because you built too much of it before you knew what you actually needed.

If you use Notion, start dumb. One database. Title, status, area, notes. Use it for two weeks. Only add a property when you have three real moments where you wished you had that property. Do not copy someone else's template off YouTube. Those templates were built by people making different games with different workflows, and the complexity is hiding a bunch of assumptions you do not share.

Whiteboards and sticky note walls

This is where I actually live most days. Behind my monitor is a four foot by three foot whiteboard covered in sticky notes. Yellow for features. Pink for bugs. Blue for polish. Green for marketing tasks. The wall is divided into the same six columns as my digital board, because the system is the same, just physical.

Why bother, when I already have the digital version. Two reasons. First, the physical wall is always on. I do not have to open a tab to see it. It is in my peripheral vision every second I am at my desk. When I finish a task and go to grab a coffee, I rip the sticky note off the wall and throw it in the trash on my way out of the room. That little ritual is disproportionately satisfying. Digital done columns do not feel the same.

Second, sticky notes have physical constraints that enforce scope. You can fit maybe forty notes on a wall before it looks chaotic. That ceiling is a feature. If you cannot fit your next phase of work on the wall, the phase is too big and needs to be broken up. Trello will let you have a thousand cards. The wall will not. The wall is honest with you in a way the software is not.

The downside of a whiteboard is that it does not travel. If you leave your desk for a week, the wall stops being a map. If your power goes out, you lose your backups. So I treat the wall as my "this month" view and Trello as the system of record. The wall gets the next two weeks of work. Trello holds everything else. When I finish the wall, I pull the next batch from Trello and set up the wall again. This is basically a sprint, which is another word I hate but the pattern works.

Gantt charts and why I mostly ignore them

Gantt charts are the grown-up version of project tracking. Tasks on the vertical axis, time on the horizontal axis, bars showing start and end dates, dependency arrows connecting related tasks. If you have ever worked at a studio with a producer, you have seen one. They are the standard artifact of serious production planning.

For solo dev, most of the time, I think they are a waste. Gantt charts work when you have reliable estimates. Solo game dev estimates are not reliable. They are barely even guesses. You think a feature will take three days. It takes two weeks. You think a feature will take two weeks. It takes two days because you stumble onto a plugin that already does it. The variance is so wide that drawing a precise timeline for anything more than a couple of weeks out is basically fiction. Pretty fiction, colorful fiction, but fiction.

Where Gantt charts do earn their keep is around hard external deadlines. A festival submission. A publisher milestone. A conference demo slot. When there is a real date you cannot move, working backward from it in a Gantt-like layout helps you see whether your plan is physically possible or whether you are about to lie to yourself. For those specific cases I will open a Gantt tool, sketch it out, usually realize I have overcommitted, and cut features. Then I close the Gantt tool and go back to the sticky note wall.

What a good public dev roadmap actually looks like

A separate question is what your map should look like when other people see it. Some studios publish their roadmaps. Factorio had a famously detailed one. Stardew Valley did not, and it was fine. Hollow Knight Silksong has had essentially no public roadmap for years and the fanbase has turned roadmap speculation into a minor sport.

If you choose to publish a roadmap, the mistake most solo devs make is putting dates on it. Do not do that. You will miss the dates. The community will notice. Someone will turn your missed date into a meme. Then every future update is haunted by the missed date even if it was a reasonable slip. Instead, publish phases. "Combat rework." "New biome." "Full release." People can live with "coming up next" in a way they cannot live with "coming March 2026" when it arrives in August.

The good public roadmaps I have seen share three traits. They are honest about what is uncertain. They separate locked-in features from aspirational ones. And they get updated when plans change, not left to rot so players find the old version and hold you to promises you quietly dropped. An out-of-date public roadmap is worse than no roadmap at all, because it actively misinforms people who trusted it.

The only rule I would actually insist on

Use something. It does not matter which thing. Trello, Notion, a wall of index cards, a legal pad you keep on your desk and rewrite every Monday morning. The specific tool matters far less than the act of keeping the work visible to you, every day, in a form that is not the project itself.

The trap people fall into, and I fell into for a long time, is thinking that choosing the right tool is the same as doing the work. It is not. I have met devs who spent more time optimizing their Notion dashboards than making the game. The tool is scaffolding. It supports the work. It is not the work. If you catch yourself watching a second YouTube video about someone's productivity system, close the tab and go open your project.

The way I think about it now is this. Every week I should be able to point at my map and say "this moved." If nothing moved, either the tasks were too big and need breaking down, or the week was bad for non-project reasons and that is fine but I need to notice it. If I cannot tell whether things moved because my map is too chaotic to read, the map is broken and I need to fix the map before I do anything else.

For more on how maps connect to the broader structure of a project, my notes on the game development roadmap go deeper into how I sequence phases across a multi-year solo build, and it pairs naturally with the tactical stuff in this post.

What I use right now, for the record

Current setup, as of this week. Trello board as the system of record, six columns, maybe sixty active cards across all of them. Whiteboard next to my desk with sticky notes for the current two-week block, never more than thirty notes on it. A single text file called NEXT.txt in the project folder, pinned open in my editor, with exactly three lines on it at any time. That file is the short list of what I am actually working on today, pulled off the wall that morning. When all three lines are crossed out, the day is done and I am allowed to stop.

No Notion. No Gantt. No fancy dependency graphs. I tried all of those and they did not survive contact with how I actually work. The boring stack won because the boring stack is the one I still use when I am tired, and tired is most days on a solo project.

If you are starting out, copy this or copy something simpler. Make it yours within a week. Then stop tweaking it and go make the game.