Game Development Reference
Ideally with an MMP, whether you are testing highly repetitive tasks or seeking to
emulate server load, you will want to create test scripts that mimic actual players as
closely as possible. For this reason you will likely want to have the actual main game
code run the scripts and, where possible, use prerecorded actions of real players as
templates upon which to build your automated scripts (another reason that even with
test automation, human testing is unlikely to entirely disappear!). Furthermore, where
possible you will want to have test clients speaking to the same server that live players
speak to, so that the main game server cannot tell whether it is receiving input from
live players or your automated script-based client. To achieve this, you can create a
simple scripting language that sends common commands to the game server, such as
pickup_object , buy_object , open_door , and so on. Ideally, you will also provide a simple
interface so testers can easily set up scripts to automate a series of repetitive actions by
indicating how often a given loop must be repeated, for example.
Other Types of Games
Many other types of games can benefit from automated testing, too. Level-based
games such as first-person shooters could have sequences of play tested by well-written
scripts that imitate a player repeatedly shooting in a certain pattern. Additional tests
could be automated to randomly test paths through a level. Such tests would seek out
instances where clipping occurs, check if the game hangs, or find where players can
pass through walls and floors. Although automated tests are unlikely to be of much
use on level balancing or the subjective elements of playing a level (how much “fun�?
it is), any aspect of the design that can be tested by repeated action is optimal for auto-
mated testing. For instance, it can be highly tedious to have to test the entire GUI of a
game over and over again with every new build. This is traditionally an area where
human testers are—or can be—inefficient. Simple scripts that automatically test each
combination of button press or menu item selection can significantly increase the
early detection of bugs in the game code and lessen the chance that any bug will persist
to retail release of the game.
On the face of it, simple puzzle games might seem to be the least likely candidates for
automatic testing. In fact, testing can be extremely useful for such titles. Many early
EDGE games produced in the 1980s were puzzle games in which the clear danger
faced by testers was that they knew the solution to the game and the players did not.
Thus, automated scripts were used in even simple puzzle games to specifically test
what would happen if players made moves the programmers had not expected them
to make. These were moves that the human testers tended to miss. The result of that
approach was that not a single error of this kind was reported in any of the puzzle
games released during that period. Needless to say, this is a good way to make your
manager a fan of game test automation!