Mark Cooke’s G-Mixer

Are you working in the game industry already or want to break in? Do you want to be an awesome game tester that is highly valued and earns the respect of the team? You should if you want to do your job well and open up your career to the widest range of advancement possibilities.

Game testing is a great entry point to the industry as it exposes you to all aspects of development. It’s an important job and the gap between a bad or mediocre tester and a kick ass one is huge. Don’t be a mediocre tester. Be the kick ass tester.

Although I did not start my career doing testing – I started out as a programming intern – I do have professional testing experience and even as a lead programmer I often find myself testing code using the techniques that the best testers use (at the end of projects programmers have to test their code extensively before distributing updates to the team). When not testing new code or game features myself I constantly communicate with the testing group on whatever team I am working on.

The five skills listed below is what I believe to be the most important skills for a kick ass game tester to possess.  With these skills in hand I guarantee you will be respected by the team for your ability to contribute in a significant way to the quality of your game.

Technical understanding of games

Have a high level understanding about how game design rules affect what happens in games and how programming works. If you don’t have much experience in testing yet this may sound impossible but I do not believe it is. I am not talking about writing 3D engine code or designing 100% of the next big hit. I mean not being completely in the dark about how these people do their jobs and how their work is implemented in games.

To start, play some games that you own already. Don’t just have fun with them though. You’re a professional now – play them while carefully analyzing how the gameplay rules affect the fun factor and balance. Is it an online shooter? How is one character class’s machine gun balanced against another player’s grenade launcher? Is one patently better than the other? Is there a third weapon or player ability that further affects the situation? Apply this to other genres in an appropriate way. This will start to give you a sense of the thought process of designers.

Programming can be harder to get insight too but I recommend learning at leas a cursory amount. If you are in school, take at least one beginning programming class. If you are out of school already, try programming a simple mod for a game created on the Unreal Engine (e.g. Unreal Tournament 3) or on the Source Engine (e.g. Half-Life 2). Having just a high level understanding of how programming works and the kind of problems that programmers face goes a long way in being able to more deeply understand bugs. Sometimes this understanding will result in surprising insight for finding the root cause of a tricky bug.

Analytical mind

Be able to connect the dots between seemingly unrelated events. Some bugs are straightforward – when you push the button in level two the game crashes instantly 100% of the time – yet others can be quite obtuse and hard to track down. This is all about not just reporting those obtuse bugs but also being able to analyze what was happening and accurately convey that information to the development team.

This is also related to an important part of bug reporting – providing clear reproduction steps. With your technical understanding of games (see last point) and your ability to carefully analyze the situation you are in an excellent position to help the people fixing the bugs do their job efficiently and thus have a direct effect on the overall quality of the game. If you can do this, developers – especially programmers – will love you.

Clear Communicator

Vague language has no place in bug reports. Nor does it help when giving gameplay or design feedback. This is a trait important for most jobs in the world but in the world of game testing it is especially important.

Know who you are talking to and how to talk to them. Don’t rely on stereotypes – not all programmers are analytical robots and not all artists or designers are touchy-feely koombiyah singing hippies. Interact with your team frequently and understand who the individuals are and how to best present information to them. You’ll find you are able to contribute to the game more in feedback and that reported bugs get fixed faster. Once again contributing to an overall improvement of the game.

Sometimes you might run into difficult personalities. Sometimes you’ll be on the receiving end of flaring tempers when you report a new bug in the latest beta build. Stay cool and learn to diffuse people. This is a tough skill to master but it is very valuable.

Be consistent

Don’t write a great bug report one day and then a crappy one the next. I’ve known some good testers who did a great job 70% of the time and a crap job the other 30%. The difference between them and the kick ass testers was simply a matter of consistency.

No one can be 100% awesome all of the time (except Chuck Norris) but do your best to follow up any good work with more good work.

Keep up with the latest games

Last, but certainly not least, is to continue playing games to keep up with the industry. This is important for everyone. It’s important for testers to get exposure to other titles to understand how other teams have solved game design problems. Using your analytical mind you may find something that helps solve or at least breathe new life into an issue on the game you are working on.

Believe it or not I have known some game testers who do not play games outside of their work. Whether they were jaded or simply uninterested in the industry I’m not sure. What I do know is that these people were unable to contribute at the highest level because of their lack of exposure to what was going on around them.

Summary

If you master the skills from the list above you will be helping your team a great deal. Testing has a huge impact on the overall quality of a game. Be the tester that brings out the game’s full potential. Don’t let down customers by contributing to a buggy or broken game getting released.

Bottom line… be kick ass!

And whatever you do, don’t be these guys:

Lets finish the discussion of the XML sequencing script system I created for Prescription for Sleep. If you haven’t read part 1 one yet, please do so here.

The final component of the XML scripting system was the ability to add “custom commands” to the XML script. In the visualizers it quickly became clear that some actions would be repetitive. For example, in the “HIKARI” visualizer (can be seen in the free Lite version of the application), when a certain series of piano notes is played little twinkling stars appear, scale up, rotate, then scale down and disappear. This happens many times during the visualizer.

Instead of cutting and pasting the same XML over and over and updating the time for when to draw the little stars, which would have been a nightmare to maintain, I created a way to define series of XML commands that could be re-used. It was basically like programming a subroutine that could then be called from the main sequence XML. By using this, I could globally update the size of the twinkling stars by changing one line of XML in their subroutine instead of 50 pasted versions of the same line. Here’s what it looked like:

<Command name="starpulse" targetRefType="relative">
	<Add time="0" target="star" bitmap="star.png" zLevel="5"/>
	<MoveTo time="0" target="star" x="param0" y="param0"/>
	<RotateBy time="0" target="star" actionTime="1" angle="90"/>
	<ScaleTo time="0" target="star" actionTime="0.5" x="1.05" y="1.05"/>
	<ScaleTo time="0.5" target="star" actionTime="0.5"/>
	<Remove time="1" target="star"/>
</Command>

That defined the custom command. As you can see, there are parameterized definitions for where on screen the stars will appear. Thus this could be called from XML further down in the sequencing with the location passed in for maximum reuse. It was called like so:

<CustomCommand time="8.4" target="starpulse" param0="v_200_250"/>

The time in the <CustomCommand> block is relative to the timeline of the music but in the <Command> definition it is relative to when it is called (almost always doing something immediately at time 0). The backend code fixes up the time automatically.

The parameter passing is a bit too programmery at the moment as you have to specify the parameter type explicitly but it did support parameterizing any variable that could have been passed to a command.

I originally thought I might have put too much time into making this scripting system but now I have to admit I was wrong. It ended up paying dividends, as most data driven systems do, not only during content creation but more so in tuning and maintaining.

While this was originally created to sequence art to music it could also be used as a simple UI framework or even a cutscene system. You wouldn’t want to use this for really complicated scenes but it has a lot of applications for explicit time based sequences that are relatively simple.

The recent Prescription for Sleep (“P4S”) project I programmed was envisioned from the beginning as a music visualizer that assisted the user in relaxation before bed. Because graphical sequences are tied directly to musical events – for example, a piano note – or thematically to changes in song progression it was obvious to me that this should be implemented with a data driven scripting system. That way, events like “draw a star shape on screen at time 37.2 seconds in position 100, 120 and scaled down by half” would be easy to write and tune. I’m sure this is similar to how old-school demos were setup.

Before I discuss that system in more detail let me give some background cocos2d-iPhone. It is a piece of open source middleware for the iPhone (originally created for Python but the iPhone branch is much more active) and as of version 0.7 it includes the following main functionality that was useful for P4S:

• Manages and renders a scene graph with parent -> child relationships
• Easy to use and powerful sequencing system, supports actions over time – “tweening” in Flash terminology
• Some UI elements for menus and text boxes
• Particle system support
• Utility class for texture loading (compressed textures, etc.) and management

Given the above functionality it was an obvious choice for the P4S project.

Hardcoding the visualizers would have been a nightmare so I quickly created a simple XML schema for defining cocos2d InstantAction and IntervalAction sequences to move objects around the screen. The XML supported the following features:

• Specify what textures are used in the visualizer so they can be pre-loaded
• Every sequence element has a time associated with it so it can be tied to the music
• Add and remove objects from the scene graph at specific depth levels
• Apply the following actions to objects that live in the scene graph both instantaneously and over time:
  • Move – both MoveTo specific positions and MoveBy an offset
  • Rotate – both RotateTo a specific rotation and RotateBy an offset
  • Scale – both ScaleTo a specific scale and ScaleBy an offset
  • TintTo – texture tinting
  • SetAlpha – “opacity” in cocos2d, change alpha blending amount
• The above commands could also all be automatically reversed or repeated, or both in combination. This made it easy to sequence long strings of repetitive actions that were timed with things like rhythmic bass
• Utility commands
  • GridEffect – create a cocos2d grid effect and apply it to an object in the scene graph (renders object into a texture with a grid of verts then applies transformations on the verts)
  • ChangeBlendMode – change alpha blending function

In my next post I’ll show how all of this came together and explain the final feature of the XML scripting schema which allowed subroutines to be defined and called within the XML itself.

For the March 2009 issue of Game Developer I contributed to the article “Dirty Coding Tricks” which profiled sneaky programming done to finish games on time. My contribution is about a sneaky trick with changing a camera angle to get past a soak test.

I felt a little bit weird contributing to an article that specifically talks about bad programming and hacks but the article is in jest and it was fun to walk down memory lane.

The issue will be available at GDC for free – check it out if you are going – and in bookstores around the US.

If you’d like to check out the application before buying (I won’t hold it against you, I promise ;-) the free lite version is now up and can be downloaded from this link to iTunes:

Prescription for Sleep Lite

Or directly from your iPhone / iPod Touch as the lite version is under the 10 MB direct download limit.

This free version includes the space themed visualizer “HIKARI”, the second of the four visualizers.

The first iPhone application I’ve worked on has just been released. It is called “Prescription for Sleep” – read this link for more background on the concept of the software. I should start by mentioning that unlike most of my work it is not a game. It is a music visualizer that is intended to act as a sleep aid. The application will take you from reading a mysterious book in your house, to space, to an alien world, and finally to a psychedelic representation of the womb. I programmed the application and designed and implemented the majority of the visualizers. I also did some art – woot, first published art work in a game!

The music was composed specifically for the application by Norihiko Hibino, prolific composer most famously known for composing the music to the Metal Gear Solid series. It was produced by Marc Cellucci at Mission-One. It was a fun group to work with and I’m happy to have had the opportunity.

Here is the link to the full version in iTunes: Prescription for Sleep on iTunes

There is a free version but it is not yet up on the iTunes store (the mysteries of the Apple approval process at work). As soon as it is I will post a link. The full version includes four visualizers and the free version features one of the four.

Working on the platform was a fun diversion from my Playstation 3 and Xbox 360 work. It was also enjoyable working “outside the box” so to speak on a non-game application.

I will post again soon with more technical details about what it was like working on the project and platform. For now here are some brief development stats:

• Development time – approximately one month
• Number of developers – six (none were full time)
• Middleware used – cocos2d iPhone, Pinch Media analytics