games testing

Well Ideally you've written automated tests for your software which allows most of the code to be exercised w/out a tester. Then you run it on as many machines as you can.

After that you have testers play the game. Sometimes it's ad-hoc testing but usually it's running through test scripts (written instructions, not code scripts)

For the automated part of testing it's nice to have something like VMWare installed on your machine. Then you can run your code on a "generic" machine with different OSs like Win98, Win2000, Win2000 SP1, Win2000 SP2, ... to determine any gross problems before you deploy the game on a a bunch of machines. This is also a good way to test installers to make certain that it contains everything to run your game.

[edited by - mauman on March 11, 2004 9:29:52 AM]

i'm pretty new to programming im afraid, you couldnt tell me what automated tests would actually do in the context of games?



[edited by - BlimeyOReilly on March 11, 2004 11:30:57 AM]

Automated tests include things like unit tests... code that exercises your real game-code, and verifies that results are correct.

To take an extremely simple example... let''s say you''ve got a function that takes game events and modifies the score based on the event. We''ll call it UpdateScore. When the player destroys a flying saucer, it''s supposed to add 100 to the score. So your test code might be:

bool TestUpdateScore()
{
	int previousScore, changedScore;

	// Get the original score prior to firing off the event.
	previousScore = GameGetPlayerScore();

	// Now update the score...
	UpdateScore(Event_PlayerKilledFlyingSaucer);

	// Get the NEW score...
	changedScore=GameGetPlayerScore();

	// Check that the player''s score has improved by exactly 100 points
	if (changedScore - previousScore == 100)
	{
		return true;
	}
	else
	{
		return false;
	}

} 

Trivial? Kinda. Too trivial? Maybe not. It helps protect you from bit-rot... maybe you forget a BREAK statement in your switch somewhere, and your saucer ends up getting a score added for two events, or whatever. So down the road, when you run your test suite, you get a failure. This helps you catch it early.