Game Design: Game Mechanics, and Game Narrative

In a traditional game development team, the game designer is primarily responsible for creating the roadmap or blueprint that will drive the development of the game. This is done by developing the game mechanics and game narrative documentation for the game. In educational game development, the game designer must focus on these two areas and also work with the Subject Matter Expect (SME) and Instructional Designer (ID) for the team to develop a game design document that also addresses the educational needs for the game. In other words, the game designer must create an experience that is not only fun and challenging for the player, but also teaches the learning objectives identified by the instructional designer and subject matter expert on the team.

Game Mechanics define the actions the player can take within the game and the results of those actions. They establish the rules for the game. The programmers use the game mechanics to program the game. Thus, it is critical that the game mechanics be exhaustive for the game.

The game mechanics should be relatively easy to learn and limited to a manageable number. Let’s consider the number of actions that are allowed in typical first person shooter and in the puzzle game, Tetris (see Table 1 and Table 2).

The development of the game mechanics should not be consfused with the development of the user interface, which is done during the production portion of the game development process.

As we begin to settle on the game mechanics for our game, we should rely on existing conventions, our expert knowledge of games, and our ability to prototype. Video games have been around for a fairly long time and our audience has learned what to expect out of certain game genres. Let’s consider FEAR and DOOM. These are different games, but the mechanics for navigating the environment are the same. The player moves with the ASWD keys and aims with the mouse. Anyone who has played a first person shooter on the PC has been trained to navigate in this manner. If we were designing a first person shooter on the PC, it would be a good idea to follow this convention.

Following preexisting conventions does not mean that we need to create games that are clones of one another. FEAR and DOOM are very different games. But as game designers we need to be cognizant of preexisting conventions and when we deviate from those conventions it should be for a purpose.

As game designers, we are in a position to create game mechanics or game actions that have never been implemented. This can be good and bad. It is good because it lets us truly invent new ways of playing games. But it can also be bad because the game mechanics that we settle on will then be passed on to a group of programmers who will build it. If our game design includes a set of game mechanics that are poorly thought out or just not fun, it will result in a lot of wasted time and resources. Often these poorly designed game mechanics will not be discovered until the game gets into the testing stages.

One way that we reduce this risk is through the production of game mechanic prototypes during the design stage. If we are contemplating the implementation of a set of actions that we do not feel confident about, we can create a very rough mock up of the activity in question and then try it out. Bad ideas can be identified and tossed out quickly with minimum loss in time and good ideas can be integrated into the game design.

While prototyping can mitigate some of the risk of implementing new game mechanics, there are also some dangers that we need to avoid. First, we need to make sure that we rely on our expert knowledge as game players and designers as a way to validate ideas. Not every single idea needs to be prototyped. If we prototype everything that we are considering, not only will our progress be tremendously slow, which will cause us to go over schedule and budget, but our process will have become nothing more than trial and error. Another danger of prototyping is that we could end up tossing out good ideas because our prototypes do not contain finished art assets or finished code. If a prototype fails to perform as we anticipated, we need to ask ourselves why it failed.

Game Narrative Documentation: In addition to the game mechanic documentation, some games will require us to also create design documents to address the narrative portions of the game. This is particularly true with action-adventure games. With these games, we typically have to establish a story for the game, individual back stories for the characters, a stylisitc feel for the settings within the game, etc. This documentation is used by the the artists to create models, textures, the graphical user interface for the game, etc.

It is important to realize that not all games require this type of narrative documentation. This is particularly true for puzzle games. In those games there is no need to establish a back-story for the setting or characters. Consider Tetris again. In this game there is no need to have anything other than the rules that define how the player's actions affect the game pieces and how the game pieces interact with other. The game mechnaics are sufficient here.

Educational Documentation: The design documentation created by the game designer will go directly to the programmers and artists responsible for creating the game. These artists and programmers traditionally do not a have a background in education. So sending them the instructional documentation created by the SME and ID is not usually effective. It is morre effective to assimilate the instructional documentation into the design documentation. In other words, the game designers, SME, and ID work together to create a single prescriptive game design documents that addresses the game-play and instructional aspects of the game.