Okay, so a while back (longer than I care to think about), a friend of mine asked “how do I make a flowchart?!” the easiest answer to that question is “damned if I know, I just wing it every time”.

It’s actually true. I’ve made about a million flowcharts while working with game interfaces, but I have yet to come across a book about “game flowcharts for dummies”, or “game flowcharts in five easy steps” or anything like that. Most of what I have found has to do with programming and databases and states. It’s probably very good stuff, but it doesn’t exactly set a standard for game interfaces.

I also wish I had five easy steps to share, but my process is closer to “think of everything at once and pray to deity or non-deity of choice that you can make sense of it”. It also involves post-its and whiteboards or large empty walls (to put post-its on).

Write a spec. No seriously. Write a spec.
The idea of a flowchart – the way I use them – is to map out the full set of interactions on paper, including messages and notifications. In order to do this there are a few things you need to know or be able to decide. First off – what are the functions you need in this feature set or screen? What are you hoping to accomplish? What is the player supposed to be able to do?

Writing a feature specification is the basis for all future work, and for designers it is really important. A feature specification, brief or whatever you choose to call it, is a list of functional statements that the player can answer yes or no to.

For example:
Player is able to open menu from game pressing the “options” button.
Menu contains Map, Journal, Mission Log, Settings and Character Sheet
Player can navigate to each of the listed areas above using LB / RB buttons
Each area opens a new screen

The idea is to keep it simple enough that it is easy to say yes or no to the statement. Can I open the menu by pressing the options button? Great, then we’re all set. The reason you want this set of features before you start the flowchart is because flowcharts are messy to make, at least in my experience. Add a feature or a screen and you’ll have a cascade of interactions that need
updating. That said, there are no flowcharts (except the really simple ones) that won’t need updating once you’ve started. That’s why I always begin by using a whiteboard or post-it notes.

Both have the perks of being easy to change and update and with post-its you can even have larger post-its represent a screen and smaller ones a message or notification, or a database callback or whatever you need. This way you can add functions or screens easily and re-arrange them in a simple way.

Follow each interaction
One of the most important things to do is to follow each interaction from start to finish. Begin with the entry of the menu. When you call the screen on screen what options do you have? Let’s take a simple example. Start menus. You’ve pressed the options key on your controller and the start menu with the typical choices of a start menu appear on screen. If you want to start a game, what do you need to do? Press New Game. When you’ve pressed New Game, what happens? Does your game have save games? In that case do you get to select the save game slot? Let’s say you do. Select save game slot to save in, and then the game starts. At this point you can leave that particular interaction, but hold on! We’re not done yet. Is this the first time you play the game? In that case, the start menu might not be the first thing you see, but a request to sign up for the publishers’ game id service. What if the game can’t contact the game server? What implications will that have on the game experience?

Here’s a flowchart that kinda shows what a hypothetical Main Menu would look like.

My point is this – when you start looking at a game interface, you have to think systematically and often in edge cases. Yes, most likely the player will only have to go through the sign up process once. And yes, the server will be online most of the time. The save games won’t be corrupted and the player can hit resume and be on their way in the game without a problem. Flowcharts help with that. But for the instances when the game doesn’t act as expected, it’s important for the user experience that the game will tell the player what is actually wrong, and if the player can do something about it, to allow them to correct the error.

Follow each interaction from start to end and make sure that you’ve accounted for every edge case.

To recap…
1. Find out what you need from the interaction
2. Start with the top level interactions
3. Follow each interaction from the start to the finish
4. Include all messages and notifications
5. Make sure you take the edge cases into account

I think the basic idea is to think in systems rather than single instances of what you want to show. In a set of HUD notifications, think about all kinds of notifications the HUD could potentially show and categorize them accordingly. When would warnings show up for example? And what kind of warnings are there? What else do they trigger apart from a text message? Would there be VFX vignettes or voice overs to signify a warning? These instances can also be included depending on the level of detail in the flowchart. Basically it’s a blueprint for how the game should behave in any given situation.

The best part about figuring out the flow of a UI is that it can be used to structure the design document as well.

Tools? What tools do I use?! Halp!
If you’re working on a Windows PC, the best flowchart tool out there is Visio, no doubt about it. Visio is my poison of choice, because it is very versatile. That said, Visio is expensive. If you need a flowchart tool just to try things out, there’s an excellent app called YEd that is free and works very well. The drawback with YEd, to my mind, is that it isn’t as versatile, and if you redo parts of the flowchart you really have to redo all of them. It’s not as easy to rearrange. For most needs YEd works just fine though.

For Mac users I definitely recommend shopping around. There are a lot of apps that you can use. My favorite is Omnigraffle, but I suspect it’s because I’ve used it for so long that I know it like the back of my hand.

In closing
I don’t know if this blog post has been useful at all, but I hope so. If nothing else it has been a way for me to structure my thoughts, and perhaps help you organize yours.