Game Flow Charts

That got me thinking... what if there was a way to display all of the game mechanics and how they relate on one sheet of paper? What about a Game Flow Chart???

I have started sketching out a flow chart with some rough ideas. Maybe a standard format for games could be established. For example, the underlying mechanic could be shown in a rectangle, a diamond could indicate a decision point, and a circle could indicate results from a decision.

If a standard format is used, I see other potential applications for flow charts for games (submissions to publishers, addendum to written rules, and easier explanations for visual learners).

I am sure somewhere along the line, someone else had this idea. Does anyone know of some real games that have used flow charts with their instructions?

Any other comments or suggestions?

Great idea. I have actually used hi level flow charting to design the basic flow of a couple of my games. My problem was trying to figure out how much detail to actually include in the flow chart. That combined with my rustiness with flow charts in general, caused me to give up on them for the moment. I have no doubt that a good flow charting program would make the process all that much easier. Anyone have any suggestions? I know flow charting must come second nature to some of you old school programmers (Do they even teach that anymore in school?). There's got to be a good freeware or cheapware software program that could make flow charting easier. Visio's learning curve is too steep (not to mention way too costly) and the drawing tools in Word are too 'dumb'. There's got to be a good wizard driven app out there somewhere.

-Darke

Another type of diagram that can be useful in game design, is the feedback diagram. This diagram is used to discover how elements of a program affect others.

The diagram has each element listed in a circle. Each element has a line with an arrow and a symbol to indicate weather it is a positive or negitive influence on the target element.

An example (not of a game, but it a good example of the concept):
There are 2 elements to this:
Rabbits
Foxes

Foxes have a negitive effect on rabits (they eat them)
Rabits have a positive effect on Foxes (provide food for the foxes).

If you count the number of negitive influences in any loop (here it is Fox, Rabit, Fox...). it can indicate wether this loop is self limiting (a negitive feedback loop) or self perpetuating (a positive feedback loop).

The positive feedback loop is usually displayed in a game as a runnaway leader situation. As in Monopoly: If I buy a house for my properties then I can make more money, which I can spend on more houses...

This positive effect can sometimes be useful as it can build tension and excitement, but does need to be carefully balanced (usually by a loosely coupled negitive feedback loop) as it can cause problems.

The negitive feedback will tend to stabilise games and make it harder to get ahead. An example of negitive feedback in a game is, Aquire, where the more hotels in a chain are placed then the more expensive the shares for it are, making it harder to gain or keep control of the chain which feeds back into your available money which lets you buy shares...

~Josh

Yeah that's exactly what I was doing as well. Sometimes timing of various events is very important to make sure all the loose ends get tied.

-Darke

I think Flow Charts for games is a great idea; I was thinking about this last week when writing up the rules for a game, and instead of working it out in english, I drew a flow chart. This is actually how I was taught Munchkin, by using a flow-chart player-aid (under the Munchkin page at http://www.boardgamegeek.com/game/1927 the file is Munchkin.ppt)

Coming from a computer programming background, it makes perfect sense to me that the general structure of a game is a huge "do-while loop" (go until victory condition) with some variation on a "for loop" inside to determine turn order. The rules for a game are an implicit flow chart, with their if/then structured language and logical decision points. With the rules in a graphical format, it is much easier to see the connections and find out how much time each part takes, as well as get a feel for how complicated a particular piece or decision is for the players to grasp.

With a standard flow-chart style for games, I think it would be helpful to have a good notation to illustrate the trade-offs of each decision point for the players. I'd be happy to help work on a good set of squares, cirles, and diamonds and get things going. A good place to start would be to make flow-charts for some very well-known games, like Settlers, Carcassonne, or Ticket to Ride, and then post and discuss them to see what the standard pieces are.

Bobby beat me to the Grammar of Gameplay reference. The ideas there aren't bad... I recommend reading through it before trying to re-do what he's done, just in case it works for you.

-- Matthew

Hi

I hate to kill an idea, but I want to give my (negative) comments to this. Before I start, I want to say that this is partly what I'm working with (for over 18 years).

In this case no flow cart can help you. If your game is so complex that you as a designer can't see the consequences of a design change, then how do you expect the players to get an overview of the game when they play it?
I think that you should consider reducing the complexity and streamlining the game.

Actually a Flow Chart does not solve the problem. A flowchart does not show states, objects, and events. It only shows a work or action flow.
There are other describing methods (example UML) but if you don't know how those methods works, don’t try to use them.
At my previous job they tried to describe the order and development process with a flow chart. The overview flowchart was 1 x 5 meters big (covered a wall) (they got a special printer so they could print this chart) and all small boxes had new detail flowcharts) (I was not involved in the main work that time and I'm glad for that).

If you still are going to use these: Start with some established standard format for flowcharts. Don’t invent the wheel again.

... your main problem will be that it is not any standard way to describe those things (you will end up with "Send the submission" -> IF (Fantasy Flight) "Send a prototype" and so on. You will end up in all small exceptions and those take 95 % of the times.
When I write computer programs (I only do that professionally), if I do a program where the standard function has 500 lines, all exceptions will probably take 10.000 lines.

Finally, I have used flowcharts to describe complex things in games or when I try to understand a mechanism, but that is for smaller details
One thing I remembers was mortar rules in ASL that I needed to understand and the rules was spread all over the rulebook).

// Johan

The goal is to make a game, not a flow chart.

This is so true. I used a flowchart to map out the complex interactions of a game of mine a few years back,. and checking and double checking the chart for accuracy became a project in and of itself. Beware!

My advice would be to chart the broad overview of the game, and then have recursive sub-charts for more detail if you wanted or needed it.