Game Development Reference
In-Depth Information
Their goal was to significantly reduce costs, appreciably stabilize the game, and reduce
errors in
The Sims Online
(TSO) by automating their testing program. They wanted
the tools they created to increase the efficiency of the initial development of the game,
provide early load testing, and carry over to central company operations as long-term
aids in the maintenance and testing of extensions of TSO and future games.
The TSO test team focused its automation efforts on game aspects involving highly
repetitive actions and scenarios that would require large numbers of connected play-
ers. For this reason, the team identified regression and load testing as the ideal candi-
dates for automation, because a roadblock in the client connection process could
make the entire game grind to a halt. Other less mission-critical elements could be
tested by hand and would not have as great an effect on the gameplay. Additionally,
the team wanted to add further automated code to assist in game development, game
tuning, and marketing.
SimScript
The TSO team used a subset of the main game client to create a test client in which
the GUI is mimicked via a script-driven control system. To the main game server these
test clients look identical to actual connected game player clients. Test scripts produce
in-game actions in place of human players. This is enabled by a Presentation Layer
inserted between the TSO client's GUI and the supporting client-side portions of the
game code. Their scripting system—which they dubbed
SimScript
—is attached to this
Presentation Layer. Simulated user play sessions are generated by a series of scripted
actions such as “Create Avatar,�? “Use Object,�? or “Buy House.�?
SimScript is an extremely simple scripting system. As it is intended to mimic or record a series of
user actions, it supports no conditional statements, loop constructs, or arithmetic operations.
Stored procedures and const-style parameters are used to support reusable scripts for common
functionality across multiple tests.
Two basic flow control statements exist in SimScript:
WaitFor
and
WaitUntil
. These provide the ability
to simulate the time gaps between mimicked user actions “wait_for 5 seconds�?, “wait_until reading
_skill:100�?, to block until a process enters a particular state (“wait_until client_state:in_a_house�?), and
to synchronize actions across the distributed system (“wait_until avatar_two:arrives�?).
WaitUntil
com-
mands simply block script execution until the condition is met, or a timeout value is exceeded.
