Designs, documentation and flowcharts
While I’m working on a few things in the project that aren’t…ready to show yet…I figured I might do a write up about how I’m organizing the project, design documentation and more.
Much has been written about design documentation by other folks, and this isn’t meant to be the comprehensive ‘be all, end all’ of how you should structure your own, but thought it might be useful to go through the tools, systems and basic workflows that I’ve come up with to help me organize Dystopia Punk.
The Monolithic Design Document
One thing that you will NOT see here is what a lot of people (and schools) seem to emphasize – the concept of the single monolithic design document that rules them all.
Quite frankly, these don’t exist, and I’ve never seen anything like that work in a realistic production environment.
The Feature Brief
In my day job, what we emphasize is the concept of Feature Briefs. This article has a good breakdown of the difference between a game design document and a feature brief.
The short version is that instead of a single gigantic 300 page design document that takes forever to write and no one will read, instead you create smaller 1-2 page ‘briefs’ on a given feature that is designed to help yourself and others working on the project understand a specific feature area in the game.
For example: most games have a player character that you can control. So you might have a feature brief that describes how the player moves, how the input for the character works, that type of thing.
The best way to imagine a feature brief is that you want them to be as ‘single purpose’ as you can make them. So for the above player character example, you might create multiple feature briefs for the character covering:
Input
Animation
Customization?
And so on. Each feature brief should include a change history to indicate if the document was updated, when it was updated and why – in case someone on the team has read the brief previously they can easily scan the brief and get up to speed on the latest iteration.
These briefs will inevitably get attached to a task tracking system that the rest of the team can use to reference when they start working on the actual feature itself.
Just in Time Design
Your job as the game designer is to produce documentation for the rest of your team before they require it. If you are working on a project with more than one person, you will rapidly discover the idea of the ‘dependency chain’. If you have a programmer, a UI Artist, an Animator, a level designer all waiting for you to finish your masterpiece monolithic design document before they can start their work, then you are wasting everyone’s time.
This is where the concept of the ‘Living Design Document’ comes into play. You should never consider your design ‘done’, ever. You will create a first draft, the team will do an implementation of it, you give it a playtest, inevitably something doesn’t feel write, tweak the design (or throw it away), rinse repeat.
For a larger / more complex project, something that you will also likely want to do is prioritization of elements of a feature design as well. Prioritization is critical to understand how far the team should take a given feature for it’s initial implementation before considering it complete.
So for the character animation brief that I mentioned above, you might want to prioritize the basic player movement (idle / walk run) animations as a P1 (priority 1) task that must be completed in order to get the basic character movement system functional.
More sophisticated animations (say for melee combat) could be the second priority, but at least you can get a character into the game and running around before then!
Tools of the Trade
If you came here looking for some master insight as to what the best tools to use for your design documentation, unfortunately I’m going to disappoint you. When it comes to what tools you should use for the feature briefs, it honestly does not matter.
Google Docs, Confluence, a wiki, wordpress site, you name it – these all work perfectly fine and can all become a nightmare to use if you aren’t organized equally fast. Use what is the most productive for you and gets out of the way so you can be productive.
What I’ve used in the past fairly well is an excel sheet that links to a variety of google docs. The excel sheet is updated whenever a design is ready to review and/or implement.
The benefit of having the master spreadsheet is that there only one central spot for the team to look for the designs. I find that relying on a folder structure in google drive or confluence ends up rapidly becoming a gong show once you get beyond a dozen or so pages, and you inevitably need to create a master index no matter what that links to the important / most relevant documentation that the team will be looking for anyways.
Anyways back to how I’m working for Dystopia Punk.
Throw out the Rulebooks
Everything that I’ve written above is how I’ve worked for many (many) years running production teams from 3-150+ people. The larger the team, the more organized you need to be.
With Dystopia Punk, as you may recall, it’s a one-person show.
Does this mean that I don’t need to write down the design? Keep track of what I’m working on? Absolutely not.
However, what I am NOT doing is writing dozens of feature briefs and documentation outlining the specifics of every single feature.
A ton of the design is literally ‘in my head’ – I have a vague idea of what I’m looking to build and how I want to build it. However, this does NOT meant that there isn’t any design documentation – far from it.
There are 3 main tools that I’m using for the documentation:
Simply put, Milanote is where I organize design ideas, Lucid Chart is where I build flowcharts, and Codecks is where I organize my todo list.
Milanote
Milanote is a fantastic free-form tool that combines note taking, mood boards and flow charts into a single app.
Here’s the home page of the Dystopia Punk Milanote board for example:
As you can see, there’s a lot going on there. I’ve broken different areas of the game into different sub-boards to organize things – and there is a ton of other boards that are basically placeholder for now – and will be fleshed out when I get to those areas (UI & SFX for example).
Each board can contain it’s own layout, and you can simply drag and drop images, youtube links and more into a board and structure them how you’d like.
For example, here’s a sub board for an initial mission that I’m working on currently:
As you can see, you can create basic flow charts, add simple to-do lists and incorporate sub-boards with reference images and more. The notes in the flow are tips / notes to myself to describe what should happen at the various stages in the mission. I’ve created a ‘template’ board that serves as the starting point for when I’ll design other missions in the game that includes the same notes.
Lucidchart
Which brings me to Lucidchart. Anyone that’s worked with me know that I’m a flowchart person. Given have a chance I’ll grab a whiteboard and start doodling ideas in any random meeting ;P
For flow charts, it’s hard to beat Lucidchart. I know there is a trend to move to tools like Miro or others, but Lucidchart is a nice, clean, simple flowcharting tool that I use heavily, mapping out code workflows, UI wireframes and flows and more.
For example, here’s the lucid flow that describes the Lobby game flow that I wrote about last time:
Lucidchart also allows you to link different flowcharts together to keep things organized. The ‘Enter Lobby Flow’ and ‘To Mission’ nodes are links to other flowcharts in the document for example. This lets me literally click through the entire app from start to finish, following the various flows to ensure that I have everything covered.
For example, here’s what the ‘Mission Flow’ looks like that is linked from the Lobby. It describes the basic systems and behaviour that will take place during a mission. Note that this is different than the Mission Flow I linked above, which is more ‘design-ey’ – the Lucid flow is much more ‘implementation’ detail specific. I’ll reference the Mila note flow for things like the actual dialog and in-game descriptions, whereas the Lucid flow helps me organize the systems that I need to build in order to actually bring the feature to life.
Codecks
Which finally brings me to Codecks, a fantastic task tracking tool that I’ve been using for a while to help organize myself.
One challenge that I have as a one-person shop is focus. There’s always ‘something’ that I could be doing for the game, but in order to try and drive towards the current milestone / objective, writing down to do lists is a fantastic way to stay on track.
Codecks organizes tasks into ‘decks’ (hence the co-decks name) – each task is a ‘card’ in the deck, that you can move into your ‘hand’ (current working to do list). The ‘co’ part is that it’s also a great collaboration tool if you’re working on a project with other folks!
I have one of the cards ‘Game Controller’ selected in the image above, and you can see that there are a number of sub-cards / tasks that make up this task. The green one indicates that it is complete, and the others are ‘in progress / tbd’ still.
If I’m working on a task and something comes up that I want to remember for later, I’ll jump into Codecks and add a task so that I don’t forget.
Same thing goes for any bugs or ‘known issues’ – I’ll add myself notes that I need to address later. Often I don’t want to distract myself from the specific thing that I’m working on at a given moment, but I DO want to make sure that I don’t forget it.
On each task you can mark whether you are working on it currently, which moves the card into your ‘hand’, shown like so:
This lets me focus on these specific tasks and not get distracted (or overwhelmed) by the sheer number of other tasks that are on the list.
Well that about covers it for the basic workflow that I’m using for Dystopia Punk. Hope this is helpful! Next time I’m hoping to have the Lobby Screen updated and a chunk of the mission flow working!
Until next time! Hit me up on Mastodon if you want to chat game design, Unity dev or anything #indiedev related! Cheers!
