Congratulations, you’re now in The Games Industry! Sort of. For a bit, at any rate. If you’re lucky the studio which has employed you may have multiple projects on the go so that when the game you’re working on is complete you won’t instantly be laid off.

It is important to use this time to build up a network of friends and slowly worm your way into the design team, where permanent contracts exist along with the chance that you might actually enjoy aspects of your job. This is not going to happen unless people know who on Earth you actually are.

Here are some simple rules to follow to help achieve this aim:

1. Have a memorable name

The thing you have to remember is that artists and programmers are going to be receiving a lot of bug report e-mails. They already loathe getting e-mails from you, so the last thing you want to do is combine a bug which involves them doing loads of work with something else that pisses them off.

So do not for the love of God sign your e-mails / reports / etc with an utterly hateful signature like, “Bob Smith – the Master of Disaster”, or “Jack Jones: The Testinator”.

No, it’s better just to have an amusingly bizarre name, like Peter Penishead. If you do not have a name like this, blame your parents.

2. Don’t be annoying

Yes – we all know that what you really want to be is a designer/artist/programmer and not a tester. But bug reports are not the place to show the World how good you would be in these roles. So less of the, “the main character should be wearing denim trousers instead of leather” or, “the grass should be more green” type bug reports please. And bugs that you find are not automatically more important than the others. So if you find yourself only ever submitting A-class bugs, it might be time to give yourself a slap before someone else does.

3. Don’t be creepy

Imagine for a moment you’re a programmer or an artist. Now imagine that you’re in the office having a chat to a co-worker. Now imagine that out of the corner of your eye you can see a completely generic person who’s unremarkable in every single conceivable way staring at you. Now imagine this figure starts popping up all over the place, possibly following you. It’s starting to get a little creepy, isn’t it?

Now, the fact is that you, the tester, aren’t completely generic but simply appear that way to the dev team because there are literally hundreds of you buggers. If you want to stand out, have no torso or two heads instead. If you have a torso and the conventional number of heads, blame your parents.

4. Be friends with the QA Manager

This is a much more realistic goal. Forget design, art, or programming for the time being. By all means practise all that stuff in your spare time (ahahahahaha!) and if you waddle over to an artist or designer clutching some work and looking adorable, chances are they’ll happily give you some feedback and blurt out some advice significantly more useful than this blog.

But the QA Manager is your target. The team knows who the QA Manager is, for a start, since he/she is one of them. A bit of sucking up here could mean the difference between being kept around for the next project and not. Plus, no matter how many heads you have or how mundane your name is, if you’re around for long enough eventually people are going to remember you.

When it comes to graphics, everybody has an opinion – it doesn’t matter if you’re a coder, tester, designer, producer, or tea boy. It requires absolutely no qualifications to look at something and decide whether or not you like it. It requires slightly more skill to determine why you like or dislike something but we all get some ability to that end just by being alive for a reasonable period of time.

So this means that, especially early on in a game’s development, it’s the artists who are doing the things that most people are interested in. New concepts going up on the walls, a new character model, a pretty sunset for the skydome. It’s an unfortunate truth that the only people who particularly care that a programmer is writing a particularly elegant function is other programmers.

So unless you’re the special effects programmer or are responsible for enabling exciting new engine functionality, you have a diminished set of people that really care about what you’re doing.

Of course, on the flip side, while as an artist it’s very nice that mid-way through the creation of one of the player characters you get plenty of attention from everybody wandering past on their way for a smoke and/or coffee, it’s less nice when they remark that what you’re doing looks a bit shit. Because, of course, while everyone can recognise the difference between things they like and dislike, not everyone is particularly informed as to what a really good character model might look like when it’s only ten percent complete.

This only gets more severe when it comes to design.

The trouble with designing, is that not only does pretty much everybody in the building have an idea of what it is about games they think makes them good or bad, but there’s also less people for them to blame when they think something’s awful.

If a programmer fires up the latest build and thinks that the screen looks a bit iffy, any particular artist can at least claim that it’s the lighting, or the environment, or anything else that they didn’t personally do (or that who did is currently present) that is the problem before skulking back to their desks to repair the ropey skin weighting on their model.

But as a designer in a similar position, the best you can do is blame the implementation of your idea which isn’t exactly the best way to endear yourself with the programming team. Alternatively, you could blame the other designers but then, if it’s a mid – to – small sized project, there’s a good chance that there aren’t any. If you say nothing and skulk back to your desk to repair the flaw in the design document, it’s going to be pretty obvious what you’ve done since you’ll have to tell everybody that the document has been updated. No, there’s really no option but to suck it up and either attempt to convince everyone that what you’ve designed is correct, or admit error then and there.

The first option will annoy people if they all think you’re obviously wrong and therefore just being stubborn and the latter will cause people to start questioning why on Earth you’re responsible for the design. All paths lead to everybody hating the designer and you’re screwed.

The only way out of this situation is to be the sort of designer that everyone likes regardless of how good or bad you are at actually designing. If you’ve reached a design position via testing and QA, there’s a good chance that everyone in the studio already hates you, so this is the kind of approach that needs to be planned for well in advance (and would be a whole new blog topic - how to be a tester and have people know who you are without it being because they hate you).

The less time you’ve been at the company, the less work you have to do – especially if you join a company which already employs a bunch of designers everyone hates. In this case all you need to be is something approaching reasonably normal to surprise the hell out of everyone in the studio and put you on their good side. Immediately start whinging about the other designers in this event, otherwise the team will get suspicious and you’ll lose your advantage.

In either case, you could start smoking and/or drinking huge quantities of coffee so that you’re always present to hear what everybody else in the studio is whinging about. Hopefully, it’s time constraints, team size, or management decisions. If it’s you they’re whinging about then they are less likely to do so if you’re stood next to them offering cigarettes and so, if you’re lucky, they’ll start complaining about something or somebody else. At this point, join in.

Glad I could help!