Test first strategy and iterative development

I´ve spent the better part of the last year soaking up all the Torque knowledge I can. Needless to say, while I don´t have the vast knowledge that other veterans do (and the GG guys) I´m comfortable with the engine, the scripting model and pretty much everything in between so I´m ready to move forward. For me, a few months with a tool is weeks in Bil years. I´m a silicon sponge that just consumes knowledge. Somehow it all stays there in that gray matter of mine. I´m sure someone will make a game about it someday.

When I do development, I generally use two principals in creating them. Test first and iterative development.

Test First

A test first strategy is that every part of a game is first written as a test. This might be something to test opening a door or leveling up a character (or the very basic, show a character on the screen). The test is written to fail. This way we know it can be broken. So a piece of code might look like:


class CharacterTestCase : public CppUnit::TestCase
{
CPPUNIT_TEST_SUITE( CharacterTestCase );
CPPUNIT_TEST( levelUp );
CPPUNIT_TEST_SUITE_END();
long m_level;
void levelUp();
public:
void setUp();
};

This sets up a simple character test case with a method called levelUp(). To setup my test case I use:


void CharacterTestCase::setUp()
{
m_level = 0;
}

So now my character starts at level 1. When I call my level up function I first code it to fail like this:


void CharacterTestCase::levelUp()
{
CPPUNIT_ASSERT_EQUAL(m_level, 0);
}

This will produce a failure because I know the level gets initialized to 0. This is my test first development. Now I can go in and write code to support the level up function (and do a test to boot) by refactoring the levelUp() function like this:


void CharacterTestCase::levelUp()
{
long oldLevel = m_level;
m_level++;
CPPUNIT_ASSERT_EQUAL(m_level, oldLevel);
}

So now not only am I doing my levelUp() function, increasing the level of the character but I´m also testing that when I level the character up it doesn´t equal what the old level was (which would fail if the code was broken).

This is just a simple example but the idea here is to write the test (based on your game design document) to fail, fix it then move onto another test. Soon enough you´ll find you have hundreds of tests, some dependant on others. This is where a test first strategy pays off. Let´s say that somewhere I decide that I want to start the character off at level 1 instead of 0. So I change the constructor of my character class to do this. Now by running my tests I might notice that my levelUp() function fails because the character isn´t starting where I thought it was. Even though I haven´t touched the code here in my levelUp() function it still broke and I´ll know why. So I have the option to either change my character class or alter my test (although we generally don´t want to break tests just to suit changes in the code elsewhere, there was a reason why we wrote the test that way in the first place).

You might find the benefits of a test first driven development to be useful. For more information please check out the following sites:

cppunit.sourceforge.net

www.xprogramming.com/software.htm

www.xprogramming.com/testfram.htm

Iterative Development

The second main principal I use when developing software (game or otherwise) is to use an iterative development approach. Iterative development is basically working in small, incremental steps to achieve a bigger goal. Okay, so you´re thinking “wait a minute, we always do that”. Some do, some don´t. Iterative development is not “let´s keep doing it until it´s finished”. With each *planned* iteration, software is created as a fully functional unit, up to the point of that iteration. Let´s say you have a spell system you need to develop for your game. Okay, so you need the ability to cast spells, learn new ones, spells for magic users and clerics, spell casting for non-spell casting users, etc. All of these are iterative pieces of the big “spell casting” puzzle. Each can be delivered on it´s own (some are dependant on others) so you can work on them in pieces. It might go something like this:

First iteration: cast a single hard coded spell.

Second iteration: cast a single text file based spell.

Third iteration: cast a series of different types of spells.

You get the idea. The benefit is that you always a working system. It may not be complete (i.e. only mage spells are in this iteration) but it is functional. Something you can test, improve and build on.

These are all working titles and subject to change at a hats drop. At some point I´ll have websites up with the initial design docs and first iterations.

Lost Tales

Description: Hundreds of fairy tales come to life through the eyes of the player as they wander through the various fairy tale worlds solving puzzles.

Type: Single player and co-op

RPG Game (no title yet)

Description: Players take on various classes (Fighter, Mage, Thief, Cleric) and complete objective based missions competing against other races.

Type: Multiplayer

Mythical Fantasies

Description: Cyclops, dragons and magicians form the basis of this worlds challenges. This is my *pet* project, a tribute to the great Ray Harryhausen and his creations.

Type: Single and co-op

Artifact Adventures

Description: Travel through time collecting artifacts that aid you in your quest and help you return to your time, all being controlled by an unknown group of individuals.

Type: Single and co-op.

No Boundaries

Description: Fast action team based hoverboard play in various arenas competing for a single goal.

Type: Multiplayer