Prototypes, Testing and Python

Lately I was tinkering with the Event Manager. The Event Manager, or Dispatcher, is a software module that manages the game simulation. You can think about it as an ordered queue of actions: when someone (the player or one of the AI controlled characters) do something they send an event to the Event Manager, like “move me left” or “cast a spell to a target”, and the Event Manager will place the action in the correct order and will execute the action accordingly, by acting directly on the game world.

Event Manager Architecture

Event Manager Architecture

This module is quite complex and while it is easy to put on paper it is not so easy to do it right and make sure that everything act accordingly to the design.

Test-driven development (TDD) is one of the possible answers, one that is gaining a lot of momentum in the last years. The concept in a nutshell is to write a test even before you write a line of code. The test then becomes a sort of “requirement specification” that your code needs to meet. When you write your code you immediately test it and find out if it was correct or not, then you iterate until your code passes every test.

The nice thing is that when you make some changes at the code you can just rerun the test and you will immediately see if you broke something because some of the tests will fail. This can guard you against regression bugs and quickly point you to where there is a problem to correct.

TDD cycle

TDD cycle (see original file)

Test are often called “unit tests”, this is so because the concept is to test a single “unit” of code, a very specific functionality, usually just a function. For heavily interdependent modules, such as the ones found in videogames, testing single functions in a vacuum can be hard. The usual solutions it to use mock-up objects that replicates the functionality of other modules.

As for me, when I am not sure on what implementation is better for a certain functionality, I like to take a step further and do my testing on working prototypes. I do this because I tend to learn faster and with better results by making something rather than by reading or designing on paper.

For fast prototyping I prefer to use Python. Python is not only a very nice language to use, it is also so fast to write and easy to deploy! I can just write the program in a text editor and test it without any need to set up a development environment. The syntax is so expressive that you can just “read” the program to understand what is happening (this can, of course, be done with many high-level languages, mind you) and so translating it to another language is usually also very fast.

What are your experience with TDD? Do you have any suggestion on how to manage code and regressions?

Thanks for reading.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s