Game Testing All in One (Game Development Series)

The first TFD example is based on the ability to pick up a weapon and its ammo while the game properly keeps track of your ammo count and performs the correct audible and visual effects. This is an ability required in first-person shooters, role playing games, action/adventure games, arcade games, and even some racing games . It may seem like a trivial thing to test, but the first four patches for Unreal Tournament 2004 fixed five ammo-related defects and fourteen other weapon- related bugs that were in the original release.

All TFDs start with an IN box, followed by a flow to the first state of the game that you want to observe or that you need to reach in order to begin testing. Don't begin every test with the startup screen unless that's what you are trying to test with the TFD. Jump right to the point in the game where you want to start doing things (events) with the game that you want the tester to check (actions, states).

In this TFD, the first state represents the situation where the player has no weapon and no ammo. Draw a flow to connect the IN box to the NoGunNoAmmo state. Per the process described earlier in this chapter, provide the event name "Enter" on the flow but don't provide an ID number yet. Figure 11.5 shows how the TFD looks at this point.

Figure 11.5: Starting the Ammo TFD.

The next step is to model what happens when the player does something in this situation. One likely response is to find a gun and pick it up. Having a gun creates observable differences from not having a gun. A gun appears in your inventory, your character is shown holding the gun, and a crosshair now appears at the center of the screen. These are reasons to create a separate state for this situation. Keep the naming simple and call the new state HaveGun . Also, in the process of getting the gun, the game may produce some temporary effects such as playing the sound of a weapon being picked up and identifying the weapon the display. The temporary effects are represented by an action on the flow. Name the flow's event GetGun and name the action GunEffects . The TFD with the gun flow and new state is shown in Figure 11.6.

Figure 11.6: TFD after picking up a weapon.

Because it's possible that the player could find and pick up ammo before getting the weapon, add another flow from NoGunNoAmmo to get ammo and check for the ammo sound and visual effects. A new destination state should also be added. Call it HaveAmmo to be consistent with the HaveGun state name format. Your TFD should look like Figure 11.7 at this point.

Figure 11.7: TFD with HaveGun and HaveAmmo states.

Now that there are a few states on the diagram, check if there are any flows you can add that go back from each state to a previous one. You got to the HaveGun state by picking up a weapon. It may also be possible to go back to the NoGunNoAmmo state by dropping the weapon. Likewise, there should be a flow from HaveAmmo going back to NoGunNoAmmo when the player somehow drops his ammo. If there are multiple ways to do this, each should appear on your TFD. One way might be to remove the ammo from your inventory and another might be to perform a reload function. For this example, just add the generic DropAmmo event and its companion DropSound action. To illustrate how actions might be reused within a TFD, the diagram reflects that the same sound is played for dropping either a weapon or ammo. That means the DropGun event will also cause the DropSound action. The return flows from HaveGun and HaveAmmo are shown in Figure 11.8.

Figure 11.8: Return flows added from HaveGun and HaveAmmo .

Now that the test represents gun-only and ammo-only states, tie the two concepts together by grabbing ammo once you have the gun. Call the resulting state HaveGunHaveAmmo .You should recognize that picking up the gun once you have the ammo will also take you to this very same state. Figure 11.9 shows the new flows and the HaveGunHaveAmmo state added to the TFD.

Figure 11.9: Flows added to get both gun and ammo.

You may have noticed that when new states are added it's good to leave some room on the diagram for flows or states that you might decide to add when you get further into the design process. Use up some of that empty space now by doing the same thing for HaveGunHaveAmmo that you did with the HaveAmmo and HaveGun states: create return flows to represent what happens when the gun or the ammo is dropped. One question that arises is whether the ammo stays in your inventory or is lost when the gun is dropped. This test is based on the ammo automatically loading when you have the matching weapon, so the DropGun event will take you all the way from HaveGunHaveAmmo to NoGunNoAmmo . Be careful not to get caught up in the symmetry that sometimes arises from the diagram. Flows coming out of states don't always return to the previous state. The TFD with these additional flows is shown in Figure 11.10.

Figure 11.10: Return flows added from HaveGunHaveAmmo .

At this point, evaluate whether there's anything else that could be added that remains consistent with the purpose of this test. That is, are there any ways to manipulate the ammo or the gun that would require new flows and/or states on the TFD? Start from the furthest downstream state and work your way up. If you have the gun and ammo, is there any other way to end up with the gun and no ammo besides dropping the ammo? Well, shooting the gun uses ammo, so you could keep shooting until all of the ammo is used up and then end up back at HaveGun . Since both of the states involved in this transition are already on the diagram, you only need to add a new flow from HaveGunHaveAmmo to HaveGun . Likewise, besides picking up an empty gun, you might get lucky and get one with some ammo in it. This creates a new flow from NoGunNoAmmo to HaveGunHaveAmmo . Figure 11.11 shows the diagram with these new interesting flows added.

Figure 11.11: Loaded gun and shooting flows added.

Note that some of the existing flows were moved around slightly to make room for the new flows and their text. ShootAllAmmo will cause sounds, graphic effects, and damage to another player or the environment. Doing GetLoadedGun will cause effects similar to the combined effects of separately picking up an unloaded gun and its ammo. The actions for these new events were named AllAmmoEffects and LoadedGunEffects to reflect the fact that these multiple effects are supposed to happen and need to be checked by the tester. The ShootAllAmmo event illustrates that your test events do not have to be atomic. You do not need a separate event and flow for firing each individual round of ammo, unless that is exactly what your test is focusing on.

Do the same for HaveGun and HaveAmmo that you just did for HaveGunHaveAmmo . Question whether there are other things that could happen in those states to cause a transition or a new kind of action. You should recognize that you can attempt to fire the weapon at any time whether or not you have ammo, so a flow should come out from HaveGun to represent the game behavior when you try to shoot with no ammo. But where does this flow go to? It ends up right back at HaveGun . This is drawn as a loop as shown in Figure 11.12.

Figure 11.12: Flow added to shoot gun with no ammo.

At this point, only two things remain to do according to the procedures given earlier in this chapter: add the OUT box and number the flows. Keep in mind that the numbering is totally arbitrary. The only requirement is that each flow has a unique number.

Another thing that has been done is to name the IN and OUT boxes to identify this specific TFD, which might be part of a collection of multiple TFDs created for various features of a game. This also makes it possible to uniquely specify the test setup and tear-down procedures in the data dictionary definition for these boxes. This is described in further detail later in this chapter.

Once you complete your diagram, be sure to save your file and give it an appropriate descriptive name. Figure 11.13 shows the completed Ammo TFD.

Figure 11.13: The completed Ammo TFD.