Introduction to Game Design, Prototyping, and Development (2015)

Part II: Digital Prototyping

Chapter 15. Thinking in Digital Systems

If you’ve never programmed before, this chapter will be your introduction to a new world: one where you have the ability and skills to make digital prototypes of the games you imagine.

This chapter describes the mindset you need to have when approaching programming projects. It gives you exercises to explore that mindset and helps you think about the world in terms of systems of interconnected relationships and meaning.

At the conclusion of this chapter, you will be in the right mindset to explore the challenges of the “Digital Prototyping” part of this book.

Systems Thinking in Board Games

In the first part of the book, you learned that games are created from interconnected systems. In games, these systems are encoded into the rules of the game and the players themselves; all players bring certain expectations, abilities, knowledge, and social norms to the games that they play. For example, when you think about a standard pair of six-sided dice, there are specific expected and unexpected behaviors that the dice carry with them in most board games:

Common expected behaviors of 2d6 (two six-sided dice) in board games

1. Each die is rolled to generate a random number between 1 and 6 (inclusive).

2. The dice are often rolled together, especially if they are the same color and size.

3. When rolled together, the dice are usually summed. For example, a 3 on one die and a 4 on the other would sum to a total of 7.

4. If “doubles” are rolled (that is, both dice show the same value), there is sometimes a special benefit for the player.

Common unexpected behaviors of 2d6 in board games

1. A player will not just place the dice on the values that she would prefer to have.

2. The dice must stay on the table and must land completely flat on a side to be considered a valid roll. Otherwise, they are rerolled.

3. Once rolled, the dice are generally not touched for the rest of that player’s turn.

4. Dice are generally not thrown at other players.

While it may seem somewhat pedantic to explore such simple, often unwritten, rules in detail, it serves to show how many of the rules of board games are not actually written in the rule book, rather they are based on the shared understanding of fair play among the players. This idea is incumbent in the concept of the magic circle, and it’s a large part of what makes it so easy for a group of children to make up a game that they all intuitively understand how to play. Most human players carry within them massive preconceptions about how games are played.

Computer games, however, rely on specific instructions to do absolutely everything. At their core, regardless of how powerful they have become over the past several decades, computers are mindless machines that follow very specific instructions several million times per second. It is up to you, the programmer, to provide the computer with a semblance of intelligence by encoding your ideas into very simple instructions for it to follow.

An Exercise in Simple Instructions

One classic exercise for budding computer science students to help them understand how to think in terms of very simple instructions involves telling another person how to stand up from a prone position. You’ll need a friend for this.

Ask your friend to lie on his back on the floor, and once he is there, tell him to only follow your exact instructions to the letter. Your goal is to give your friend instructions that will move him into a standing position, however, you cannot use any complex commands like “stand up.” Instead, you must only use the kind of simple commands that you might imagine giving to a robot. For example:

Bend your left elbow closed 90 degrees.

Extend your right leg halfway.

Place your left hand on the ground with your palm facing downward.

Point your right arm at the television.

In reality, even these simple instructions are drastically more complex than anything that could be sent to most robots, and they’re pretty open to interpretation. However, for the sake of this exercise, this level of simplicity will suffice.

Give it a try.

How long did it take you to give your friend the right instructions to stand up? If you and your friend try to follow both the rules and the spirit of the exercise, it will take quite a while. If you try it with different people, you’ll find that it takes much, much longer if your friend doesn’t know ahead of time that you are trying to get him to stand up.

How old were you the first time you were asked by a member of your family to set the table for a meal? I think I was only about four when my parents decided that I could handle that complex task with my only instruction being “please set the table for dinner.” Based on the exercise that you just completed, imagine how many simple instructions you would have to give to a person to recreate the complex task of setting the table, yet many children are able to do this before they start elementary school.

What This Means to Digital Programming

Now, of course, I didn’t give you that exercise to discourage you. In fact, the following two chapters are meant to be really inspirational! Rather, it was given to help you understand the mentality of computers and to set up several metaphors for aspects of computer programming. Let’s take a look.

Computer Language

When I gave you the list of four example commands that you could give, I was outlining the parameters of the language that you could use to talk to your friend. Obviously, this was a pretty loose language definition. Throughout this book, we will be using the programming language C# (pronounced “see sharp”), and luckily, its language definition is far more specific. We explore C# much more later in this part of the book, but suffice to say that I have taught hundreds of students several different programming languages over more than a decade, and my experience has shown me that C# is one of the best languages for someone to learn as their first programming language. Though it requires slightly more diligence than simpler languages like Processing or JavaScript, it gives learners a far better understanding of core development concepts that will help them throughout their game prototyping and development careers, and it enforces good coding practices that eventually make code development faster and easier.

Code Libraries

In the previous exercise, you can see that it would have been much easier to have been able to tell your friend to “stand up” rather than going through the trouble of having to give so many low-level commands. In that case, “stand up” would have been a multipurpose high-level instruction that could be used to tell your friend what you wanted regardless of the starting position that he was in. Similarly, “please set the table” is a common, high-level instruction that generates the desired outcome regardless of what meal is bring prepared, how many people will be eating, or even what household you are in. In C#, collections of high-level instructions for common behaviors are called code libraries, and there are hundreds of them available to you as a C# and Unity developer.

The most common code library that you will use is the collection of code that tailors C# to work properly with the Unity development environment. In your code, this extremely powerful library will be imported under the name UnityEngine. The UnityEngine library includes code for the following:

Awesome lighting effects like fog and reflections

Physics simulations that cover gravity, collisions, and even cloth simulation

Input from mouse, keyboard, gamepad, and touch-based tablets

Thousands of other things

In addition, there are hundreds of thousands of free (and paid) code libraries out there to help make your coding easier. If the thing you want to do is pretty common (e.g., moving an object across the screen smoothly over the course of one second), there’s a good chance that someone has already written a great code library to do so (in this case, the free library iTween by Bob Berkebile, http://itween.pixelplacement.com/index.php).

The prevalence of great code libraries for Unity and C# means that you can concentrate on writing code for the new, unique aspects of your games rather than reinventing the wheel every time you start a new game project. In time, you will also start collecting commonly used bits of your own code into libraries that you will use across multiple projects. In this book, we will start doing so by creating a code library called ProtoTools that will grow in capability across several projects in this book.

Development Environment

The Unity game development environment is an essential part of your development experience. The Unity application can best be thought of as an environment in which to collect and compose all of the assets that you create for a game. In Unity, you will bring together 3D models, music and audio clips, 2D graphics and textures, and the C# scripts that you author. None of these assets are created directly within Unity, rather it is through Unity that they are all brought together into a cohesive computer game. Unity will also be used to position game objects in three-dimensional space, handle user input, set up a virtual camera in your scene, and finally compile all of these assets together into a working, executable game. The capabilities of Unity are discussed extensively in Chapter 16, “Introducing Our Development Environment: Unity.”

Breaking Down Complex Problems into Simpler Ones

One of the key things you must have noticed in the exercise is that the exclusion from giving complex commands like “stand up” meant that you needed to think about breaking complex commands down into smaller, more discrete commands. Although this activity was difficult in the exercise, in your programming, you will find the skill of breaking complex tasks into simpler ones to be one of the greatest tools that you have for tackling the challenges that you face and helping you make the games you want one small piece at a time. This is a skill that I use every day in the development of my games, and I promise that it will serve you well. As an example, let’s break down the Apple Picker game that you will make in Chapter 28, “Prototype 1: Apple Picker” into simple commands.

Game Analysis: Apple Picker

Apple Picker is the first prototype that you will make in this book (built in Chapter 28. It is based on the game play of the classic Activision game Kaboom!, which was designed by Larry Kaplan and was published by Activision in 1981.¹ Many clones of Kaboom! have been made through the years, and ours is a somewhat less violent version. In the original game, the player moved buckets back and forth in an attempt to catch bombs being dropped by a “Mad Bomber.” In our version, the player uses a basket to collect apples that are falling from a tree (see Figure 15.1).

¹ http://en.wikipedia.org/wiki/Kaboom!_(video_game)

Figure 15.1 The Apple Picker game made in Chapter 28

In this analysis, we will look at each of the GameObjects in Apple Picker, analyze each of their behaviors, and break those behaviors down to simple commands in flowchart form. This will demonstrate how simple commands can lead to complex behavior and fun gameplay. I recommend searching for “play Kaboom!” online to see whether you can find an online version of the game to play before digging into this analysis, but the game is simple enough that doing so is not necessary. You can also find a version of the Apple Picker game prototype on thehttp://book.prototools.net website under Chapter 15, though the Apple Picker game is only a single endless level, whereas Kaboom! had eight difficulty levels.

Apple Picker Basic Gameplay

The player controls the three baskets at the bottom of the screen and is able to move them left and right using the mouse. The apple tree moves back and forth rapidly while dropping apples, and the player must catch the apples using her baskets before they hit the ground. For each apple that the player catches, she earns points, but if even a single apple hits the ground, it and all other remaining apples will disappear, and the player will lose a basket. When the player loses all three baskets, the game is over. (There are a few other rules in the original Kaboom! game about the number of points earned per bomb [apple] and how the various levels progress, but those are unimportant for this analysis.)

Apple Picker GameObjects

In Unity terminology, any object in the game—usually meaning anything that you see on screen—is a GameObject. We can also use this term in discussing the elements seen in Figure 15.2. For later consistency with our Unity projects, I will capitalize the name of all GameObjects (e.g., Apples, Baskets, and AppleTree) in the following list.

A. Baskets: Controlled by the player, the Baskets move left and right following the player’s mouse movements. When a Basket hits an Apple, the Apple is caught, and the player gains points.

B. Apples: The Apples are dropped by the AppleTree and fall straight down. If an Apple collides with any of the three Baskets, it is caught and disappears from the screen (granting the player some points). If an Apple hits the bottom of the play window, it disappears, and it causes all other Apples on screen to disappear as well. This destroys one of the Baskets (starting at the bottom), and then the AppleTree starts dropping Apples again.

C. AppleTree: The AppleTree moves left and right randomly while dropping Apples. The Apples are dropped at a regular interval, so the only randomness in the behavior is the left and right movement.

Figure 15.2 Apple Picker with GameObjects labeled

Apple Picker GameObject Action Lists

In this analysis, we’re not going to consider the difficulty level or the round structure that are present in the original Kaboom! game. Instead we will focus on the moment-to-moment actions taken by each GameObject.

Basket Actions

Basket actions include the following:

Move left and right following the player’s mouse.

If any Basket collides with an Apple, catch the Apple.²

² It would also be possible to make this reaction to collisions part of the Apple actions, but I have chosen to make it part of Basket.

That’s it! The Baskets are very simple.

Apple Actions

Apple actions include the following:

Fall down.

If an Apple hits the ground, it disappears and causes other Apples to disappear.

The Apples are also very simple.

AppleTree Actions

AppleTree actions include the following:

Move left and right randomly.

Drop an Apple every 0.5 seconds.

The AppleTree is pretty simple too.

Apple Picker GameObject Flowcharts

A flowchart is often a good way to think about how the flow of actions and decisions works in your game. Let’s look at some for Apple Picker. Though the following flowcharts refer to things like adding points and ending the game, right now, we’re just looking at the actions that take place in a single round, so we’re not worrying about how those kinds of scoring and round actions actually work.

Basket Flowchart

In Figure 15.3 the behavior of the Basket has been outlined in a flowchart. The game loops through this flowchart every frame (which is at least 30 times every second). This is shown by the oval that is at the top left of the chart. Actions are shown in boxes (e.g., Match Left/Right Mouse Movement), and decisions are shown as diamonds. See the sidebar “Frames in Computer Games” to learn more about what constitutes a frame.

Figure 15.3 Basket flowchart