Unit testing - suitable for all development?

Geoff Howland ghowland at lupineNO.SPAMgames.com
Sat Mar 13 19:22:39 EST 2004


On 8 Mar 2004 13:00:51 -0800, kylotan at hotmail.com (Kylotan) wrote:

>"John Roth" <newsgroups at jhrothjr.com> wrote in message news:<104nnqlq81dvj48 at news.supernews.com>...
>
>> Your comment below makes me wonder if you're trying
>> to create a "text adventure" game. I'm not certain whether
>> to take it literally or not.
>
>Well, it's a graphical game. There are many similarities to text games
>but also quite a few differences, such as input handling and sound
>often being dependent on the display being set up, for instance.

Sorry if this reply is too late to be useful.  :)

Coming along late in this process, there are ways to do functional
tests on games from a higher viewpoint than than various bits of the
engine, which can be tested by more conventional method.

The basics are saving user input and time when it changes, and then
replaying to back.  You should be able to test that things stay the
same when you make changes, as long as you save your random seeds and
all the time differences between
frames/cycles/whatever-you-use-to-control-looping.

You can do this to check positions of actors/entities in the game,
game states at various points, or even graphics by taking screen shots
and checking them.

When the game really changes, you can just rebaseline your data and
work off the new results.  You will at least have a way to make sure
you arent breaking things.

I think this is especially important after you have released a game
and are either making fixes or improvements.  It's very scary to
release a game again when you have changed it, as there are a lot of
conditions that could fail or crash or break because of the large
variety of actions the user can take (including going into menus,
changing options, and back into the game, etc).

Baseline functional tests can still be useful for this.  I did this to
some extent with my last game, and it was very useful.  I implemented
the screenshot testing as well, but didnt use it extensively as it was
at the end of my development cycle.  I also made stability tests
(maybe "load test" similarity) by having an 'AI' control the player
and do fairly random things, make random walks through the UI, go back
to playing, etc.  After normal unit/function tests, this randomy-AI
player test gave me a lot more confidence to release changes after a
few days of running without crashes.

As a bonus, it also worked great as an "attract mode", and since I
presented this game at a conference, I could just let it play itself
and have people walk up and interrupt the test to start playing
themselves.  :)
 

-Geoff Howland
http://ludumdare.com/



More information about the Python-list mailing list