The Triggers

Six Defect Triggers span the four game operating regions . These triggers describe ways to cause distinct categories of game defects to show up during testing. Together, these triggers account for all of the possible defects that can occur.

The Configuration Trigger

Some game configuration takes place in the Pre-Game region, prior to running the game. This includes device or environment settings that are established before running the game, such as game platform software versions. Date and time, screen resolution, system audio volume, operating system version, patches, and language settings are all examples of Configuration triggers.

Configuration also involves external devices that are associated with the game platform. Game controllers, keyboards, mice, speakers , monitors , network connections, headsets, and so on are also part of the test configuration. As shown in Figure 15.2, such devices are attached to various external connectors on the Sega Dreamcast or any other modern game hardware platform.

Figure 15.2: Sega Dreamcast block diagram.

The nature of these external devices is that they each have their own settings, properties (for example, version), and physical connection. Some of these devices can even have additional devices attached to them, such as the Nyko ‚ Xbox game controller shown in Figure 15.3, which can have lights, fans, vibration , memory, and microphone and/or speaker capabilities depending on the models and add-ons that are used.

Figure 15.3: Nyko ‚ multifunction Xbox game controller configuration.

Disconnecting one or more devices during gameplay is a type of configuration change. Unfortunately for developers, the game software is unable to do anything to prevent the user from connecting or disconnecting external devices during gameplay, or from changing settings or software versions on the game platform. Configuration changes can occur in any of the game software operating regions.

Connecting a device could be done to correct an accidental disconnection ("The dog kicked the phone cable out of the wall!"), change out a faulty device, or add a new capability, such as a headset for voice control. This too should be anticipated by the game design and incorporated into the game tests.

These possibilities shouldn't be excluded from testing just because your initial response might be "Why would anyone ever do that?" Recognize when you have this kind of reaction that you should test that area vigorously. It is likely that other people would have had reacted similarly and didn't bother to find out what would happen in that case.

Configuration failures might show up immediately as a result of the configuration operation or at some later time when a game operation relies on the new configuration. Seemingly unrelated capabilities might also fail as a side-effect of a configuration change.

The Startup Trigger

The Startup trigger is utilized by attempting operations while some game function is in the process of starting up or immediately after that while code values and states are in their initial conditions. This could be a highly noticeable activity, such as a "Loading please wait ‚ " screen or something that's behind the scenes such as loading data for a room you've just entered.

Particular code vulnerabilities exist during the startup period. These do not present themselves at any other time in the game. Code variables are being initialized . Graphics information is being loaded, buffered, and rendered. Information is read from and/or written to disk.

As an example, here is a summary of the events that take place in the Unreal engine in order to start up a new level:

1. The GameInfo's InitGame() event is called

2. The GameInfo's SetGrammar() event is called

3. All Actors' PreBeginPlay() events are called

4. All Actors' BeginPlay() events are called

5. All Actors' zones are set

6. All Actors' volumes are set

7. All Actors' PostBeginPlay() events are called

8. All Actors' PostNetBeginPlay() events are called

9. All Actors' SetInitialState() events are called

10. All Actors either with bShouldBaseAtStartup = True and Physics set to PHYS_None or PHYS_Rotating or with an Attach Tag get their base set

Startup defects are triggered by operations that take place during the Game Start period. These operations can be user-initiated or caused by the game platform. Interrupting any part of this sequence could mean that some essential operation will not complete its work or may not get to run at all. The Startup trigger accounts for bugs that will only show up as a result of the initial conditions that result from the game's initialization and startup processes. That means that defects that occur the very first time you use a game capability ‚a new map, item, powerup, or spell, for example ‚should also be classified as Startup defects.

The Exception Trigger

Special portions of the game code are exercised by the Exception trigger. Exception handling in a game is normally recognized by the player. Audio "bonks" or alert boxes are common ways in which an in-game problem is communicated. Some exceptions are under the control of the game, such as restricting user input choices. Other exceptions are caused by external conditions that are not under the control of the game software, such as network connection problems. Figure 15.4 shows the special alert you get when trying to play Dawn of War in multiplayer online mode when your game PC is not connected to the Internet. Exceptions can occur in any of the game operating regions.

Figure 15.4: Dawn of War online game mode connection exception alert.

The Stress Trigger

The Stress trigger tests the game under extreme conditions. These could be conditions imposed on either hardware or software resources. Memory, screen resolution, disk space, file size , and network speed are all examples of game conditions that could be stressed by users or through testing. Simply reaching a limit does not constitute a stress condition. Once stressed, the resource must be used or operated in some way for the stress behavior to reveal itself.

The Normal Trigger

Normal game operation takes place in the In-Game operating region. This refers to using the game apart from any stress, configuration, or exception conditions, kind of like the way you would script a demo or show how the game should be played in the user manual. The "normal" code is distinct from the code that handles the exceptions, the code that processes configuration changes and the code that takes over under stressful conditions.

Most of the testing that is done uses Normal triggers. That is okay because that is how the game will be used the vast majority of the time and testing is not just about finding defects; it also demonstrates that the game functions the way it is supposed to.

However, testing that almost exclusively uses Normal triggers is only training the code to follow a script. It will not detect many user faults that will occur in real-life situations.

The Restart Trigger

The Restart trigger classifies a failure that occurs as a result of quitting, ending the game, turning off the game device, ejecting the game disk, or terminating the game's operation in any other way. Some games are nice about this and prompt you to save vital information before allowing you to exit a game scenario, mission, or battle in progress. When ending the game, some information needs to be remembered and some forgotten. If either is done incorrectly, the player can gain an advantage or lose precious progress.

Sometimes you can notice the effects of a Restart defect during the End Game period, or you may have to wait until the next time you use the game. For example, there is a bug in All Star Baseball 2004 where you can Quit and Save a game while you are pitching, restart the game system, and then reload your saved game to fully recover your pitcher's energy. This kind of defect goes unnoticed if your test doesn't go back into the game after saving, so remember to do that whenever you apply a Restart trigger.