Describing Game Behavior with Use Cases

This is an excerpt from the Article

Describing Game Behavior with Use Cases
by Matthew Walker

Modern MMP development projects are very large, involving many participants with different skill sets. It is rare for the same person to handle both game design and programming tasks. A new challenge arises from this need for specialization: communication of game requirements from designer to programmer. Games involve complex interactions between entities, requiring sophisticated state management and event handling. The creative vision of the game design must be systematically mapped into a technical design model so that the final implementation represents the initial intent. Use cases provide an effective means for doing this.

What Are Use Cases?

Use cases define a model of system behavior that uses natural language within a simple structure that designers and programmers can use as their common frame of reference. One of the primary functions of use cases is to decompose a large, unwieldy system specification into manageable parts. These smaller parts are easily described and consequently, more easily implemented.

Each use case represents a discrete unit of behavior with a clearly defined scope, distinct steps, and unambiguous preconditions and postconditions. The clarity of each use case's scope aids in developing a modular, robust system design by defining where specific responsibilities lie. Using distinct steps to describe a behavior illustrates what should be done to achieve the goal of the use case and ultimately maps into program code. Stipulating preconditions and postconditions for each use case ensures that the state of the system is known both entering and exiting the use case, and exposes dependencies between use cases.

Why Use Them for MMP Development?

On the large teams typical of today’s MMP projects, designers, artists, and programmers must communicate regularly and clearly to coordinate on the product's creation. Much of this communication is between people of varying levels of technical expertise. The approach of using simple, but structured, natural language in use cases reduces ambiguity without making too many assumptions about each party's degree of understanding of technical details. Designers and programmers can collaborate to build a fairly robust picture of the game they are creating without becoming mired in jargon or implementation details. Later, programmers can take the picture formed by the use cases and transform it into code more easily and with a greater understanding of the designer's requirements than if they were trying to do so directly from a textual game design document.


How to Write a Use Case

Use cases have been used in software development outside the game industry since their introduction by Ivar Jacobson in the early 1990s. Since then, many authors have written about use cases, presenting many different approaches to writing them. These range from intensely formal, cross-referenced, document hierarchies to little more than short, but consistent, modular descriptions of functionality.

The goal of this article is to present an acceptably consistent and clear approach, one that has been used in real game development projects, to illustrate how thinking in terms of use cases can aid MMP game development. Our technique will be to use a simple and repeatable structure, concise terminology using everyday vocabulary, and unambiguous English sentences.

Identifying Use Cases

Behavior that constitutes a use case is sometimes hard to identify. What starts a use case, and when does it end, are questions we must explore at the outset. The identification of actors and events helps us do this.

Actors

Actors are entities that exhibit behavior and initiate interactions with, and within, the system being developed. Actors cause use cases to happen. Identifying actors helps us to identify where a use case begins. A simple list of actors with descriptions should suffice to encourage completeness and expose duplicates:

• Player Character (PC) - In-game representation of the player.
• Non-player Character (NPC) - Computer-controlled entity that shares many characteristics of the player character, including the ability to chat, trade, fight, and join a party with a PC.
• Monster - A computer-controlled entity that can only fight with a PC or NPC.

Often, actors are external to the system. Common examples include human users and other software programs. This point of view is useful when developing user interfaces and other non-immersive aspects of a game, and it is the most common point of view in traditional software engineering projects.

In game development, however, an extremely important concept is that of an actor being an entity within the game environment itself. Many games are open-ended simulations of some aspect of reality, and within such simulations, entities often interact in complex ways. In such immersive situations, it is more useful to model the player's character as an actor, rather than the player himself. At this level, it becomes clear that individual computer-controlled entities such as monsters, NPCs, and vehicles benefit from being treated as actors. When we use this approach, we are able to break complex chains of activity involving multiple entities into discrete interactions between pairs of actors.


Events

At the highest level, use cases derive from events initiated by actors. An effective way to start identifying use cases is by listing and describing these events. Simply listing all the events that can occur in a game is a great way to brainstorm our set of use cases.

We do this by identifying the actor that generated the event, and providing a one-sentence description of the event. There are a couple of reasons for using a single sentence for the description. First, one sentence is short enough to include in a list while remaining readable. This aids in remembering and referring to events by name when discussing development with team members. The second reason is to introduce a discipline that is easy to follow: an event is a single occurrence; one can easily describe a single event in one sentence. If it takes two or more sentences to describe what is happening, it is likely that we are describing more than one event. Combining multiple events in such a manner is likely to confuse one's understanding of what is really happening.

A sample list of events from our role-playing game, with descriptions:

• PC Attacks Monster - PC targets monster and engages in combat using the currently equipped weapon.
• PC Casts Spell on Monster- PC targets monster and casts a damaging spell on it.
• PC Trades with NPC - PC purchases an item from an NPC.
• PC Heals PC - PC casts a healing spell on another PC.
• Monster Attacks PC - Monster targets PC and engages in combat using the currently equipped weapon.
• PC Equips Weapon - PC retrieves a weapon from inventory and inserts it into the weapon slot.

The Basic Course

The core of the use case is its list of steps. These describe the details of the behavior we want to implement. We use them to show the order in which actions are to occur, any repetition, and the existence of conditional logic. The first step should be consistent with the start of the use case description, and the last should reflect the final concept mentioned in the description. This ensures that the set of steps remains within the scope established in the description statement. If we find that a step appears to fall outside the scope of the use case, we need to either remove the step, possibly to another use case, or redefine the scope of the use case.

An example set of steps that fall within the scope of our earlier description might be:

Basic Course:
1) Player character targets monster.
2) Player character attacks monster with current weapon.
3) Compute chance of successful attack.
4) Compute amount of damage.
5) Apply damage to monster.

Now, our use case is starting to take form. It is still very simple, having only five steps. This initial set of steps, according to Jacobson, is called the Basic Course. Yet, we have discovered additional details about our use case. In order to attack a monster, we actually have to identify it as a target first. And, to allow for more interesting gameplay, we probably want to introduce some probability of failure for the attack. Finally, the amount of damage dealt to the monster may be dependent on many variables, so we introduce a step to compute this value. Here, we are hinting at the existence of other behaviors that may have additional complexity to be explored.

If you found this post interesting you should checkout the full article in the book MMP Game Development.