Game Development Reference
In-Depth Information
There are increasing trends in game design toward procedurally written code and
algorithmic approaches to game design. This suggests that in moving forward, it may
become easier and easier to integrate automated testing into game code because the
code will often be generated by algorithms that may be modified to perform self-
detection of errors and self-healing of errors identified. For instance, if the on-screen
experience (path-finding, collision detection, clipping, and so on) is being generated
algorithmically, then logically the same algorithmic substructure can be used to test
the outcomes and self-cure any errors that are detected.
Beyond the advantages that game design trends may bring, the game industry is likely
to remain one where test automation, while desirable, is going to remain difficult to
deploy on a wide-scale basis simply because so much game code is custom written for
each game. There is likely to remain a fundamental problem that large-scale test
automation will be only justifiable if a company can envision ways in which automation
will eventually pay off because the test system is reusable for all games they produce
over the course of many years. This, however, is unlikely to happen unless the idea of
testing the code is built into the game design practices of the company at a very deep
level and deployed across all games that the company works on.
Finally, once the practice of designing tests becomes more prevalent, they can be inte-
grated into an automated test generation process. As features evolve during the course
of the project, you would only need to update the design and regenerate a new set of
automated tests. Here's a small SimScript test that checks that when a player with 0
money bashes a piñata his money total will go up:
set_data avatar skill 10
set_data avatar money 0
use_object piñata bash
wait_until piñata broken
log_message Money should go up after breaking the piñata
log_dat avatar money
This test case might appear in a combinatorial test design, as shown in Figure 16.2.
The test parameters are starting skill, money, and what kind of item to bash. The values
for this test are 0, 10, and piñata, respectively.
