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.

Show Full Story

Asian Game Markets and Game Development

This is an excerpt from the Article

Asian Game Markets and Game Development – Mass Market for MMP Games
by Adi Gaash

The Main Players – Who Does What

First of all we have the game developers: small, medium and large-scale companies that design both graphics and story and that program the games as well. The games are usually based on an existing game engines and communication technology. The companies support the game product throughout its full life cycle: from the early stage of the game's development and up to its final implementation, support (patches, etc.) and development of future versions.

Most of the successful developers are local companies. This is not surprising, since they cater to the preferences and tastes of the local end users much better than foreign companies. The aesthetic differences are evident when you examine content and graphic design, for example Manga titles vs. Walt Disney titles or Shrek. Games in China are based on local mythology and historical events (such as The Three Kingdoms) which have great appeal to the local gamer. There are a few hundred local companies that develop exclusively for this MMP industry. Some of them try to export their games, but most of them are meant to be sold inside the Asia market.

The central place for game studios is Korea. Some of the Korean studios also have branches in other Asian countries, but generally most of the content comes from Korea. Some of the prominent companies in the local industry are NCsoft, Nexon and Webzen...


Next, we have the service providers. Unlike the standard developer-publisher food chain, here the Internet service provider takes the place of the traditional publisher. Business-wise this makes a lot of sense, as promotion for new content can be easily carried out by online platforms. For example, Chinese companies SINA and NETEASE provide e-mail and web hosting services, but by looking at their web sites, one can see that those companies' main business is massively multiplayer role-playing games (MMP RPGs).

The companies buying the local rights handle most of the service and support issues, and of course get most of the revenues. For funding, check NASDAQ for updates on some of the service providers. If this business is new to you, you will be surprised by the numbers and by the dramatic change this online Asian market has brought to the global market.

Last but not least, we have the Internet cafés. Unlike the common use of Internet café in the West, in the East an Internet café functions most of the time as a "gaming café," with most of the activities being focused on games. One can say that they have replaced the 80s' and the 90s' arcades with regard to computer gaming.

As this option for online gaming use became easier to implement, chains of Internet – gaming café quickly gained in popularity. You can find a franchise as easily as you can find a fast food joint. In some cases, Internet café chains function as service providers with regard to publishing new games; my previous development firm negotiated directly with them for the rights to the game we have been developing. One of the major Internet café chains may be equivalent to a major service provider in helping a game become popular and achieve market penetration.

Communication Infrastructure to Support Your Game!

The fast Internet infrastructure situation is promising, as most of the houses in the main cities are already connected to broadband Internet – and those that are not yet connected will most probably be connected in the near future. Funny as it may sound; a room in a cheap hotel in Seoul might not be equipped with towels and a bar of soap but will have a PC and a broadband connection. Taiwan for example published a plan last year to build the infrastructure to provide full broadband access to the whole island.

As you know there are other communication services that become increasingly popular, such as video on demand and videoconference calling. The demand for these services speeds up the building of the infrastructure. Thus infrastructure and telecommunication firms like China Telecom, China Networks and others promote this idea to provide their customers an attractively priced communication package consisting of telephone, TV and Internet. Service providers have already contacted telecommunications companies to include online gaming services in their content packages.

According to a DFC Intelligence report, "the rate of broadband penetration has grown even more rapidly in certain Asian markets, most notably China, Korea, Taiwan and Japan". Their relatively optimistic estimate of 30.6 million households in Asia with broadband connection by the end of 2003 was exceeded by almost 18%. Since they also state that "the countries with the highest broadband penetration are some of the hottest markets for online games", we can conclude that the potential for online games in the Asian market is very high.

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

Show Full Story