Flowing Charts

I was working on my gameplay and writing my game’s design “doc”, and was planning to code some parts of the gameplay. I had some tasks listed in front of me, but I somehow couldn’t keep all the balls in the air simultaneously. So to speak.

I thought it was slightly difficult to proceed further with just these notes of mine.

So I did what I often do: drew a flow chart describing the main gameplay. I don’t know if I’ve mentioned this but I use flow charts (with my own customish syntax) to describe some aspects of the game. I feel that these charts are good in capturing the idea of certain issues.

So, I took my precious pen and draw a chart. It describes how the gameplay works: what happens first, how location is selected, how game progresses, and how game is won. It doesn’t explain everything, for example “resolving challenges” is not explained here – it’s a job for another flow chart or textual description, but this pic gives a pretty good overall view on how things work.

Using both my notes and this chart, I can continue coding.

Flow charts for very beginners
Basically, flow charts explain states. You may draw boxes/diamonds and write things like “Is leader?” and then have two arrows (one with word “no” and another with word “yes”) pointing to two different boxes which describe what happens in certain conditions.

A drawing makes things so much easier, so here’s an example flow chart describing the process of how reading this blog works.

Pretty slick, eh?

5 thoughts on “Flowing Charts

  1. When you write a bit bigger software, then flowcharts will get a mess and you have no overview anymore.
    With NSDs you can always make modular drawings, and although at the very first look you need to learn how they are read, they get very natural and easy to read on the 2nd look.
    You can visually see immediately where you have loops and branches in your program.

  2. Ugh, at first glance that Nassi-Shneiderman diagram is very hard to follow.

    I’ve always used and seen bog standard flowcharts in real world development (i.e. not university and my own indie projects).

    At the end of the day it’s what suits you best I think.

  3. That’s weird. We always used flowcharts for software documentation at university, and now I use it for some parts like when describing general game interface – all those option screens, save/load, new/quit etc.

  4. It’s forbidden in universities to use flowcharts for software documentation. Nassi-Shneiderman diagram is the right tool for software documentation. It also prevents endless loops and illogical jumps.

  5. What if you get stuck in a loop hole when reading your blog? Then you won’t be able to break out of the site; you are trapped inside forever!