Software Testing In The Gaming Industry – Episode Three

0012

In this weeks instalment of your handy guide to the world of software testing in the gaming industry, we talk to Jamie Lowes, Director of indie gaming company VAMflax. I have a personal interest in this of course, as Jamie’s game Chopper Mike happened to be the first game I reviewed for zero1gaming. You can read that here, or you could read this article first.

First things first, tell us a little about you, your game and your company?

 I’m Jamie, I’ve been coding videogames for a living since 1997. In 2012 I started my own games company, called VAMflax, and in 2013 I published my first game, Chopper Mike!

 In the day job I’ve worked for Codemasters, Sega, and Sony. I’ve worked on Colin McRae Rally 1, 2, & 3, SEGA Rally, Motorstorm Arctic Edge, and Little Deviants.

 I’ve worked in most areas of game programming.. tools, low level libraries, audio, networking, and general gameplay. I am currently working back at Codemasters, leading the gameplay group on a new, (and top secret!), project.

What sort of code do you work with and what do you like about it?

 I have a dual development life! By day it’s mainly C++, and at home I write everything using Unity and C#. I like both. C++ just does what you tell it to do, which is great once you know *exactly* what you’re doing. C# is fantastic for smashing code together and creating things in very little time. It feels a little naughty, not freeing memory, using the magical containers, etc. But, I managed to write a 60 frames-per-second arcade helicopter game that runs on a telephone with C#, so it can’t be that bad!! :D

shots-catformer Who does your testing? (you/another developer/someone independent etc)

For VAMflax, I do most of the testing. Once I have something that feels pretty bulletproof I make it available for a small group of friends to try and then collate their feedback. This includes any bug reports.

 Ok so we’ve covered Alpha and Beta testing before, all standard fare that you would come to expect from most forms of software development. Obviously, you’ve got to make sure that it works on a computer other than the one you’ve built it on, otherwise you’ve made yourself something that’s lovely and pretty but of no use to anyone. But what’s this?

What stages of testing do you normally go through (debugging/functional testing/integration of new code/end product testing etc)

There aren’t really any distinct phases. I kept adding features to Chopper Mike until I felt it was ready to be published. Each feature was worked on until it felt good enough to be published. I guess each feature had micro-stages to its development and testing, but they all kind of blurred into one.

 I work in one branch in a perforce depot, and as I’m the only developer, there’s never any new code to integrate, it’s always developed in the live branch!

 Well this is new! In every example we’ve looked at so far, we’ve worked on the basis of small chunks of code being plugged together to form a whole, in it’s practically finished form. No waste, no duplication, and here we have someone adding stuff, then adding more stuff, then adding more stuff over and over again?! Madness! Before we start throwing together the digital wicker man, breathe easy – this is quite common. This is called iterative development, but you may well have heard of it in some other format, namely prototypes. You’ve seen a prototype car right? Looks BEAUTIFUL. All sharp sweeping lines, blue interior up lighting and enough cream leather to wipe out the albino cow genome. Can you drive it away? Hell no you can’t! The engine has all the power of mittens the asthmatic kitten and do you have any idea how much albino cows cost?! The finished product has been toned down, refined, tuned to needs and constraints mass production. Iterative development works in a similar way; you go through cycles of development, adding something new each time as your requirements are defined by the previous version. Here’s your character and his ray gun, he runs around fine. Next time around when we add in the baddies we better make sure they vaporise when they get shot not fall over with arrows sticking out of their chests, that sort of thing. This way, you can keep working with the same version (Perforce Depot is a version control system, and Jamie says that he develops the same version throughout), there’s surprisingly little wasted effort. This makes development fast, and fast is good. This type of development tends to work well for small close-knit teams as the testers need to be very well informed about each new piece of development that’s been added, otherwise they can’t check it effectively.

How easy does Unity’s IDE (integrated development environment) make things for you and what functionality does it give you?

 The Unity IDE is so amazingly cool. To be able to have the editor running in realtime as you play the game in another window is the best. To be able to turn things on and off, or quickly edit their parameters as the game runs, massively cuts down development and debugging time. You have so much power over your game!

 The other thing I love about Unity is the ease of which I can reorganise my assets and code. Move things around… they stay linked together, rename… still works! I really like duplicating existing objects to make variations. It’s so fast! CTRL+D, drag it into the scene, CTRL+P… the new asset is running in your game. So, so cool!

 Debugging at a code level is… basic. I’m not a fan of MonoDevelop, and the link between it and Unity can be a bit janky. But, it gets the job done. You can set a breakpoint, and that’s all you need really.

 There’s a lot left for me to learn about Unity’s editor. I keep finding new features, and I didn’t write one extension to the editor itself during the development of Chopper Mike. I’m sure I could have streamlined my workflows if I had written some custom tools along the way.

A lot of technical information here, so let’s summarise; the IDE is basically the page where the developer writes their code. Unity allows you to ‘play’ your code whilst the game is running (on the left is your character walking around, and on the right is the code to make him walk around ticking along), meaning that if something goes wrong you can see exactly where it is. That’s what a breakpoint is for – it’s a little marker you can place in your code where it will either start or stop, meaning you can change it and not have to replay the whole code to check that particular piece still works. This makes debugging easier and faster, which is probably why it’s so basic.

 14280-shot0

We’ve talked before about the joys of Unity, and in particular how easy having a repository of tried and tested coding in the asset store available, so I asked Jamie whether he uses it or not.

Do you use Unity’s Asset store and if so how easy is it to integrate something pre-existing into your project?

For Chopper Mike I wrote and made everything myself, I even made the music and sound effects! :D  Since Chopper, I have been using a few things from the Asset Store. I’m concentrating on PC and Mac now, so with the extra power I’ve been able to use the Marmoset Skyshop and Colorful post-processing packages. I also now use NGUI for UI. All of these packages drop straight into your project and just work! Even cooler than that, you have the source code, so you can adapt them to do whatever you want them to do!

Jamie has a long history in the game development industry, and has worked on some big titles previously.

You’ve obviously worked on games like SEGA Rally and Little Deviants, how does the expectations on the development differ based on the scale of the project and what differences does that lead to in terms of testing?

The thing that changes most with the scale of a project is the day-to-day testing, as on a big project it’s important to keep the workers working! Automated build robots that cry when the build is broken, that kind of thing.

Other than that, it’s pretty similar. Just that a bigger project, with more developers and more features, ends in more bugs! :D

Ah automated testing. There’s a subject we could talk about for hours! Sadly, we’ll have to save that for another lecture (yes it’s a lecture), as we’re out of time here I’m afraid. My thanks to Jamie for his time and input, and if you’re interested in VAMflax or Chopper Mike then check out their website here http://www.vamflax.com/

© 2014, zero1gaming.com. All rights reserved. On republishing this article your must provide a link to this original post

About Drew Pontikis
Drew Pontikis is an avid gamer and writer. A fan of racing sims and first person shooters, Drew is notable for talking almost exclusively using Futurama quotes.He's usually found in front of his Xbox or his laptop, follow him on Twitter as Gamertag: drewski060609