[TFUI] Integration Test Servers for Videogames

Newsgroupies:

I summarized my recent project, functional and integration tests for a
videogame, here:

    http://flea.sourceforge.net/gameTestServer.pdf

Some highlights:

"This paper describes an automated test strategy in terms of growing a test
server from simple and accessible game components.

"The goals of this test server were:

* integration testing-verify the game each time source upgrades
* scenario testing-scripting the game hero to spot-check a game effect
* soak testing-abuse the game at much higher intensity than normal gameplay
* display of test cases, results, and metrics in a rapid, flexible web site.

"The resulting framework extends easily into new test categories.

"A videogame project is like a spider and her orb web. At the center, the
spider is the game engine. Her labor pulls together and integrates the
activities on each web spoke. They represent a game's visual & sound assets,
special effects, design scripts, actors & props, user interface, physics,
database, rendering & animation systems, and input channels. A spiral of
threads cross-link each spoke, representing the interdependencies between
all the game elements. The engine weaves many different kinds of threads
together.

"Growing a videogame requires repeatedly disturbing the spokes in that web.
Small problems in one spoke might grow into large ones in another spoke. For
example, an artist might change a level, and not notice a new hole in its
geometry. The navigation systems then permit the game's hero to fall through
the hole, and the physics system now obligingly drops our hero into the
netherworld, unable to finish that level. Problems like these might ripple
through the system before they get attention. Symptoms appear far from their
sources. The spider in our parable must work very hard to maintain her web.

'Most advanced applications use more than one language. For example, a
data-driven application may use an Object Oriented language for its logical
engine, and use a Declarative language, SQL, to manage and query a database.
Similarly, many games use C++ for the hard engine layer, and Lua for a
scripting layer. The distinction lies (roughly) between code that must be
fast, and code that must change easily.

...

"Our tests exploit this scripting layer, to trigger situations, and verify
their outcomes. Suppose a test level contains a spawn point, a barrel full
of dynamite, and our hero. A monster pops out of the spawn point, runs
towards our hero, and passes close to the barrel.

"We write functions in Lua to manipulate our hero at a high level:

 aimAt("Powder_Keg")

 while 3 > distanceToKeg("Enemy_1") do
  delay(0.3)
 end

 Shoot()
 takeScreenshot()
 Assert(isDead("Enemy_1"), "enemy should die")
 Assert(isDead("Powder_Keg"), "keg should be destroyed")

"We aim at the keg, wait until the enemy passes it, and shoot the keg...

"For a final flourish, takeScreenshot() records an image of the keg
exploding and killing the enemy.

The Assert() statement pushes an error line into the log if its condition
fails. More advanced assertion systems could reflect their source into their
error logs:

 Error - 09:46:02 - Script - false == isDead("Powder_Keg") -
                                             keg should be destroyed

"Forcing Lua to reflect the source statements into its assertion output
('isDead("Powder_Keg")') is left as an exercise for the reader.

"That test may fail for any number of reasons. If a designer changes the
enemy's spawning behaviors, it might not run close to the barrel on its way
to our hero. If the physics system lost the ability to explode barrels, or
if the barrel's damage radius changes, it might not affect the enemy. These
scripts operate at the level of gameplay, matching users expectations. If a
player depended on such a 'barrel strategy' to defeat an enemy, and if the
player executed the operations correctly but the trap failed, the player
would feel disappointed."

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces




To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/