GameMechanics: Turning Real-World Constraints Into Code

Greetings once again, true believers! Joey here, coming to you live from the UXL at Full Sail University. Last week I talked to some length about the relationship that exists between real world problems and problem solving for fun and practice (i.e. playing games). This week I'm going discuss in more detail the fine points of real world constraints and how they are translated into modern video games as game mechanics.

As you'll recall from last week's post Formal Design Theory III, now known as Solving Problems Just for Fun, human beings are relatively limited in our capacity to accomplish what we want in the real world. Life comonly presents us with difficulties - with problems that need solving - either for pleasure, for the sake of convenience, or to ensure our very survival. Each of these problems can be broken down into four primary characteristics: a current state (where you are now); your end goal (where you would like to be); constraints (impediments that prevent you from reaching your goal); and assets (things that you have at your disposal that, when utilized properly, may help you achieve your goal).

Presumably the biollogical impetus for engaging in fun problem solving activities (playing games) is to make us better at solving real life problems through practice. From this perspective, the childrens' game of tag takes on new meaning - not only is it an entertaining way to pass the time, it also teaches children how to run away from things that are out to get them. I don't mean that statement to be particular dark, but you can imagine how such a skillset can be incredibly helpful. Perhaps less so in developed countries today today, but Hollywood at the very least insists that problem solving skills passed along via games like tag and hide-and-seek remain relevant.

When it comes right down to it, there really isn't a whole lot of difference between games played physically and games played remotely in a digital medium. The only real delineation lies in the way that the game's actions and constraints are represented:

Sticking with the tag example, the game itself and the problem that it represents is relatively simple:

Current state: not "it"

End goal: remain not "it"

Constraints: physical limitations, player who is "it," actions prevented by rules (turn and fight, get on an airplane, etc.), time allotted, size of the play area...

Assets: physical advantages, ingenuity, actions allowed by rules... (run, jump, hide, etc.)

The trick, as always, is to leverage your assets against your constraints in such a way as to surmount them and achieve your goal.

When playing a game of tag in the backyard, many of the rules built into the game are ones that we don't think about - how often do you think children curse gravity and human physical limitations when playing their games? Probably not all that often, and honestly if they did it would be pretty creepy.

However, when developing a video game, all of these aspects of the primary problem must be built into the game system and represented by code, effectively simulating a game of tag in which you begin as one of the players who is not "it." This includes everything from defining the beginning and ending states of the game to creating a system that emulates real world constraints (including, but not limited to, physics, actions, time, space, etc.), assets, and relevant rules of the game.

Now I know what you're thinking. You're thinking "Um... duh. We're all game developers or at least game enthusiasts here. We know how games and game engines work." Well, from what I can tell there's still a lot of debate over what game mechanics are and how we define them. To me, a game mechanic is either a constraint on player action or an asset that the player can use that has been built into the system of a video game. Things like time, space, allowed actions, physics, objects, and attributes are all examples of game mechanics that, when combined, make up the experience of playing the game. Game features, then, are groups of game mechanics that have been combined to form more complex gameplay functionalities.

Returning to an electronic version of the game of tag, the game feature of tagging another player is made up of several component game mechanics: physics, attributes, and time determine how fast you and the other player can run, actions and collision determine when your hand and the back of the other player come into contact, and rules determine that, upon collision, your "it" status is transferred to the other player.

Game features, when combined together in fun and interesting ways, make video games.

What I'm trying to do here is to hammer home this idea of games as little microcosms of possible real-world scenarios. All games are really various "what if" scenarios. What if you were being chased by something and had to run away and hide until it was gone? What if your princess lady love was stolen by a bad guy and spirited away to another castle? What if aliens landed on Earth with the intent of beginning a religious rite that would, unbeknownst to them, result pen-galactic genocide? All of this problem solving, no matter how far-fetched the premise, makes us better at achieving our goals in adverse situations.

So now that I've laid some basic theoretical groundwork, it's time for the big reveal: Games and stories, while in many ways dissimilar, share a great many common characteristics and, at the end of the the day, serve the same purpose. This, of course, is why games and stories work so well together. But THAT discussion is going to have to wait for next time.

Thanks for stopping in, and keep the faith.

Peace!