If it ain’t broken, you haven’t tested it

27 09 2010

And by you I mean me, but let’s start in the beginning. I’ve been contracted to write a game. A platformer in ActionScript 3.0, a language I knew nothing about on a platform [Flash] I’ve never even remotely tried, so it’s been an intereseting ride. But more on my adventures in AS3 land in upcoming posts. This one in particular I would like to dedicate to my two favorite beta [gameplay] testers. My wife and my daughter. And the importance of letting other people test your code.

It’s the last leg of the journey now, with the level design near completion and the core mechanics in place [being jumping, falling and colliding like there’s no tomorrow], I raised my fingers in triumpth having just finished testing the collisions myself and called out to any who dared to challenge my game.

Not five minutes later my three and a half year-old, amazing, daughter comes laughing. But dad, why is the little guy stuck in a wall??

Huh? I replied, surely some mistake was made, obviously the players are playing my game wrong. I played the same build on the desktop and found no such thing, so I asked my little tester to show me. Deftly she moved slowly to the left on a platform, fell down and got stuck in a wall. So much for testing my own game.

Some keystrokes, a coffee and forty five minutes later and the collisions were fixed [the collision tests were almost, but not quite, entirely unlike Tea; they were also a bit buggy]. I called out for more players. My wife stepped out to the plate. Played, ran, jumped, fell and collided perfectly. I smiled and left the room to make a cup of Tea [blasphemy, or sheer genius?] and when I came back there was nothing on the screen. And by that I don’t mean the screen was off but rather the entire level, player and tiles included, just vanished… Clear blue skies wherever you looked. And I looked perplexed. My wife had done something which had never occured to me; she let the timer run out and then tried to play the level AGAIN – crazy I know…

Well, some more tweaking [this time I knew exectly where the offending code was so it only took a few minutes] and it’s up and running again. And I’ve re-learnt an important lesson. Don’t play-test your own games.

As the developer I’m biased towards my playing of the level, even if I’m unaware of it, I’ll still try to view the gameplay from a code perspective; trying to fit and push all the numbers rather than just having unfamiliar fun with it. I’m not saying that is not important, it’s the developer’s job to test and see whether buildings are floating and the likes. But letting others play and break the application you’ve made [or in this case I made] in different and exciting ways only serves to create a stronger program. There’s very little point in getting upset over spilled code, in fact rejoice in testers finding broken gameplay because in the end they are there to help you create better software. I’m off to play someone else’s games for a while…

“Seasons don’t fear the reaper, Nor do the wind, the sun or the rain..we can be like they are”

Advertisements

Actions

Information

One response

27 09 2010
Tatham

So true! Even just developing business applications the tendency is always to test the functionality I’ve just implemented, instead of trying to use the system as a system to see where the gaps are. Unit testing helps us write better code, but it’s no replacement fr having a good ol’ beta tester break your game 🙂
Great post.

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




%d bloggers like this: