上QQ阅读APP看书，第一时间看更新

Game flow

Flow charts and diagrams are a very powerful tool that every designer has to learn to utilize. They can be used for anything from explaining the ins and outs of your game economy and gameplay mechanics, to portraying technology and skill trees.

Unless your game is trivially simple (or a near-direct copy of something existing), you'll need to create a flowchart of sorts to explain where various options and features fit in and how they are connected. Even a simple game of Rock-Paper-Scissors could have its flow represented by a chart:

Flowchart for a game of Rock-Paper-Scissors with multiple rounds.

In the preceding example, we can see the structure of play as well as some of the rules that decide the outcome of a round. For those not familiar with the symbology:

Rounded squares represent terminal blocks (beginnings and ends of processes)
A parallelogram is used for user input/output
Diamonds portray decisions. Use these for simple yes/no or true/false forks
Rectangles are used for processes and operations
Arrow connectors are used to join parts of the diagram and portray the direction of transitions
On-page connectors (the circles with letters inside) allow us to avoid long and confusing arrows by connecting two remote parts of the flow

It may be a lot to take in, but for experienced people, reading such diagrams is much easier than reading paper rulesets.

Nevertheless, do not overthink the flow diagrams—we're not creating blueprints of factory processes, we're making games! It doesn't matter how many different shapes and connectors you use. As long as you do not confuse people, you can opt for a set of simple arrows and boxes.

Going to the lengths of putting a rhomboid decision box with forking outcomes for every single thing will likely end up as a waste of your time and potentially overwhelm the rest of your team (no one wants to read a flow with hundreds of nodes).

Ultimately, the game flow will evolve and change over time; the purpose of the initial diagrams is to help you visualize the structure of the game—do it by whatever means necessary. You can inject screenshots from reference games or earlier prototypes, comments, wireframes (rough sketches of the user interface and content)—everything flies as long as it helps you communicate effectively. If you really need a diamond decision box with forking paths—use it! But, if you're going to write up a detailed explanation of that part of the game anyway (with potentially its very own flow chart), opt for simplicity and put it all in a simple box.

These days, you rarely need to install specialist software such as Microsoft Visio or Inkscape. There are countless online solutions such as draw.io or Lucidchart, and you can always fall back on something even simpler; unless you're doing something large and complex, Google Slides and Powerpoint can easily satisfy most of your needs. Some people even use pictures of whiteboards or post-it notes.