Mean salary

Just a quickie… interesting follow up to my recent article, which was followed by some comments about salaries in the games industry.

Develop have got their annual survey salary out, and list the following:

Average Yearly Salaries:
Lead Programmer – £41,250
Programmer – £25,810
Junior Programmer – £18,928

A few thoughts spring to mind:

1. Wow. Now I remember why I left the games industry.

2. £26K for a programmer is less than £29K for an artist or £27 for a junior audio engineer! That disagrees very strongly with my anecdotal experience. I don’t know of any artists or audio guys paid more than their programmer colleagues, and didn’t think that was the normal state of affairs at any games company anywhere. (Design is a tricky one. Junior designers get shafted, but lead designers / directors can make a fortune). Surprising.

3. £19K average for a junior programmer (implying many get less)? That’s appalling! I was paid £20K as a junior seven years ago! Also, the last company I was involved with hiring at, offered around £23K as standard for new junior hires.

I’m not going to say the Develop survey is wrong, because they’ve had a wide range of respondents whereas I’ve only got my own personal limited anecdotal experience to draw from. What I will say is, if those Develop figures are right, there’s a lot of people out there getting completely stitched up. They’d be earning a lot more in another industry. Is that worth giving up, in order to fulfil their childhood dream of making games for a living? That’s a question only they can answer. For a while, my answer was “yes”. Now, though, I stand my updated decision of making software for a living, and making games for fun.

It’s not the size that counts

Indulge me as I walk down memory lane…

It was summer 2002 and I’d just landed my first professional job. (I’m still not sure how. I wasn’t very good back then. I like to think they saw that I’d become good, and I like to think I am good now. It might just have been luck!). I’d spent some time in the RnD department, to learn the ropes, become familiar with devkits (console hardware with added stuff to enable game development), and understand a bit about how the shared game engine worked; and then the time came to move onto a game team, of which there were five or six to choose from. The choice wasn’t freely given. Each team had different needs, so the question was asked: what did I want to work on? What did I want to specialise in?

I didn’t really know how to answer that. I was vaguely aware of the division between systems programming and gameplay programming, and knew that I preferred the former (I actually think the latter is better solved by a good data-driven system and a good designer, though I have worked with gameplay programmers who produced excellent results); but which system? And how would my choice affect my working day?

Games teams on “AAA” titles nowadays can easily have several tens of programmers. Clearly, if they all worked on whatever they fancied from day to day it would be a disaster. Each programmer therefore gets designated an area of responsibility. Generally speaking, the programming lead and the most senior programmers determine the overall architecture of the game early in development (or it may be mandated by the engine, particularly if it is middleware), and the programming team splits into several sub-teams, each led by a senior programmer who reports to the lead programmer. Examples of roles in the team (in no particular order) include:

Graphics: the celebrities of programming because they get to write code that produces awesome looking screenshots (or at least… code that lets the artists do so). Every time the publishers come for a visit, they’ll get led into the graphics programmers’ office and shown all the latest particle-laden explosions on flashy HDTVs. Graphics programmers spend a lot of time writing shaders, optimising the renderer, and talking with artists.
Networking: modern games are immensely complex and with multiplayer online being practically compulsory nowadays, every game will have network specialists. They tend to spend all their time trying to teach other programmers how to write code that doesn’t break the online mode, for example by sending 600KB packets every frame or updating something on the local client but not the game server. They usually look a bit stressed.
Physics: even with middleware like Havok (or in XNA, JiglibX and the like) available, physics remains one of the most complicated things in a game because it affects just about everything else. One game I worked on had five physics programmers.
AI: most games have enemies or some kind of non-player entity. While scripting and other designer-facing tools mean AI is not as hard-coded as it once was, someone’s got to write the code that interprets the scripts – that’s the job of the AI coder.
Audio: given that the only two ways your game can influence the player is via the screen and the speakers, audio is half of every game. Unfortunately it’s the second half (because it doesn’t look good in screenshots) and all too often audio is neglected. Done well, it can turn a good game into a mind-shatteringly atmospheric epic. Audio coders spend a lot of time talking to the musicians and SFX engineers, and they’re usually slightly bitter that the graphics programmers get all the plaudits (and flashy HDTVs).
Tools: there might be twenty programmers on a team, but there might be ten designers, fifty artists, and five audio engineers (as well as testers, producers, marketing, translators…). You can’t just give them a copy of Photoshop and Maya and tell them to get on with it. Every game needs specific tools that enables these people to get their assets into the game and tweaked until fun and in my experience, the better the tools the better the finished game.  Historically tools were DOS-based and unreliable; increasingly, they’re now written in C#/.NET and actually work more often than not. Tools programmers are the unsung heroes of the programming team. Their work is almost never seen by the public, but without them, the game itself won’t get seen by the public either.
Systems: asset loading. The game camera. Multithreading. Save games. Text, and menus. Achievements. DVD file layout. TCR compliance (rules that the console makers require you to obey before your game can be released). Support for steering wheels, dance mats, webcams and chatpads. The build process (putting together versions of the game to give to artists, management and testing). A veritable pot pourri of tasks that no game can go without. Some of these tasks will be given to the most senior programmers because they’re critical to the game’s success. Others will be given to the most junior programmers because they’re relatively self-contained and can be developed in isolation. Most don’t get noticed, until you try to make a game without them!

There’s more, but that’s a good initial summary. (Just think – when you write an XNA game, you’re responsible for all of the above! Lucky XNA itself is brilliant at doing it loads of it for you). My first ever task on a game team was to write the game camera, and looking back I’m pretty proud of how it turned out. Very soon afterward I also took on the audio programming. Eventually, on that first game (I worked on it for three years – some were working on it for twice that), I was responsible for, or otherwise involved with, text and menus, localisation (making the game support other languages), asset loading, the build process, save games and TCR compliance. Later I’d work on asset optimisation and arranging files on the DVD, and probably some other stuff I’ve forgotten. So it became clear: my specialisation was that I was a Jack-of-all-trades. Hurrah!

With all these people working on different things, it’s critical that they don’t interfere with one another by writing over one another’s changes. This is achieved by use of a Source Control System. Basically, this keeps track of every code file and asset in the game, keeps records of how they change over time, and tries to ensure that if two people make changes at once, those changes are seamlessly merged together. Different teams use different products and approach this in different ways. Some examples using the codenames of games I worked on:

Game Two: used CVS for source control. This is an horrific abomination that should be scourged from the earth. A coder would make all the changes he wanted, send out an email to the team saying “please don’t commit”, commit all the files he’d changed, and send another email saying “OK to commit”. Inevitably he’d have missed something so the next coder to update would have to come and ask him to fix the problem before they could continue. Worst of all, the artists couldn’t get anything into the game without giving it to a programmer to commit it for them. This was frustrating for everyone involved and meant that changes to a level, for example, could take two or three days to get into the game. Putting together a build was an eight hour manual process; all too often it wouldn’t start until 5pm the night before a deadline. I’m not completely sure how we managed to get the game finished, and I’m stunned that it turned out as good as it did despite everything. This is How Not To Do It.

Pocket/Pikelet: an improvement in every area, these teams used Source Depot (basically the same as Perforce) for source control. No more emails to control who could commit – a tool that lived in every developer’s System Tray would lock out commits while someone was going through the process of updating, building the game, running the unit tests and committing. A separate build machine would then automatically update to that version, run the tests again and if they were passed make the build available to all the non-programmers – who, incidentally, had the tools available to do all their work without needing to go through a programmer. It was brilliant, broken builds and artist downtime were unheard of – the game was bulletproof throughout development. There was only one small problem. Updating, building, running unit tests and committing took half an hour or more. In a normal eight hour day, only sixteen programmers could do it – at most. With twenty programmers on the team, there’s an obvious problem and it got very frantic near deadlines – and leaving at least a day between committing meant that you’d commit too much at once, introducing bugs (which would fail the unit tests and delay your commit even longer). This was a problem, but in general this was the best system I’ve had the pleasure of working in.

Polished Turd (not the real codename, just what I call it): again this used Perforce for source control, except this time without a formal commit queue like Pocket/Pikelet. The commit queue had originally been introduced to stop CVS from breaking everything, but Perforce is so much better than CVS that actually things rarely break even if you’re free and easy with committing. It meant that you could fix a bug, commit your changes, fix another bug, commit your changes, and iterate very rapidly through your work. You’d update over lunch and overnight, or when you noticed someone had committed something you need. If we’d only had the same team build system, unit tests, build suite, and artists tools from Pocket/Pikelet this would have been the ideal way of working. (Unfortunately all those things didn’t exist so the game was unstable, the artists couldn’t do their job, and every deadline was a mad scramble to put together get something vaguely playable that lasted more than five minutes between crashes).

Now, most people reading this will be hobbyists working in XNA on their own. At the moment, that applies to me too. However, I’m uncomfortably aware that the big blue blobs and soulless grey polygons that currently represent the actors and props in my game won’t inspire other people to play my game – and I’m closer to being autistic than artistic. So sooner or later, I’m going to need other team members to make models, textures, animations and sound for me. (Any volunteers?) And, while I’m currently planning to save all the coding duties for myself (with the XNA Framework itself and the multitude of excellent community libraries out there, this is a realisitic proposition in a non-trivial game for really the first time this side of about 1998) many of you will no doubt be thinking of forming small coding teams, to split the work among you. (I don’t blame you. Just look at the list above. Even a simple game has a lot to do…) So – how well does XNA support medium-to-large game teams? And what would such a team require?

Source control is absolutely essential the moment your team grows larger than one. And, with a team of one or two, there’s only one choice – Perforce, which is free for up to two users, and so good I use it even though no-one’s forcing me to. Unfortunately, as soon as your team size hits three people, it’s something like $700 a license. Ouch. Worth absolutely every penny and more if you’re a pro developer with your outgoings covered by a publisher, but out of reach of everyone else. I am told that Subversion is good for a free product, but I look at the lack of atomic changelists and cringe. Probably the next best if you can’t afford Perforce though. There’s nothing here that’s different for XNA than if you were using C++ or any other language.

It will be essential to have a configuration of your game that allows your artists to put their assets into the game without waiting for you to do it for them. The XNA content pipeline is a wonderful, wonderful thing of great beauty, but by default it is tied into Visual Studio – the content pipeline build occurs just before you run your game, and that’s it. An artist doesn’t want Visual Studio, and he doesn’t want to restart the game every time he changes a texture – he should be able to save off the texture file and see it change in-game. So you need to provide them with a version of the game that runs on its own (perhaps in a WinForm) and a tool that hooks into the content pipeline and will let them build assets while the game is running, notify the game, and the game then reloads that asset. This is pretty easy for assets that already exist in a content project, but the tool will need to support adding to the content project (hidden from the artist) and even creating new ones. All this needs to hook into your source control system without your artist needing to learn to type “p4 -d -a -q -z” or whatever.

The content pipeline causes a few other problems too. (Though don’t think for a second that I’m knocking it. What it does is amazing). Big games tend to generate thousands, even hundreds of thousands of assets – and in the content pipeline, each of those is a different file. People often don’t realise that opening a file, even from a hard drive, can sometimes take as long as a quarter of a second. That doesn’t sound like much until you multiply it by a hundred thousand. (You can very easily see this for yourself by using WinZip to zip up one large file of say 10MB, then compare it to zipping up a thousand files of 10KB each – I guarantee the latter will be much slower). To give an XNA-related example: Kameo, Pocket and Pikelet all used XACT, the same audio tool as provided with XNA (and which I’ve used very extensively). Pocket, in particular, had well over 200 soundbanks which all needed loading at startup. Even though they were only between just 1 and 4KB each, this took a long time to load from the DVD – so long that the 20 second load time mandated by Xbox 360 TCRs seemed an impossibility. The fix was pretty simple: we altered the build process to package all those soundbanks into a single file, loaded the file into memory, and loaded the soundbanks from that memory. Instantly the problem was solved. The same solution won’t work in XNA: there’s no method to load soundbanks from memory. It expects each soundbank as a separate file, and that’s that. A big game in XNA would really struggle under such restrictions. (Loading on a background thread won’t help, 20 seconds of disk access is 20 seconds of disk access and that’s that, though admittedly an XNA game would be on a hard drive not a DVD which helps a lot). You’d have to plan ahead very carefully – in terms of the game design, not just code; which is hard, because designers don’t understand arbitrary restrictions from code, and nor should they have to – to ensure that there was never a need to load so many individual files all at once.

With these caveats in mind I’m convinced a medium-to-large game can realistically be made in XNA. The “poor performance” of C# compared to C++ is for the most part a myth, though to get the absolute 100% optimum out of the hardware might require C++ – but you could get at least 95% of the way there with C#, and 98% of all games don’t need 100% performance. It’s unfortunate that the biggest win for hobbyists and small-team endeavours – the brilliant content pipeline – appears to be the biggest limiting factor for large teams. The issue of when and how assets are built, and how they can be rapidly iterated without restarting the game, is definitely solvable, though with a fair bit of coding effort; the fact that so much of the pipeline relies on a one asset, one file relationship is trickier. A hundred-thousand-asset game would need a hundred thousand files, and loading times would be horrific.

So really large games might not be easy in XNA. Happily (?) few large games nowadays are single platform, and since XNA is not available on PS3 and Gamecube, I don’t think many large teams will be evaluating XNA anyway. Medium teams, independents, and small hobbyist teams can definitely have a field day with it (though profitability of XBLCG at least has yet to be proven). Just remember that the limiting factor for such games is content, and put a lot of effort into making your artists’ lives easy. If they can make a model, put it in your game, play with it, tweak it, play with it again, tweak it, play with it, and check it into source control, they’ll beg to be allowed to make more. If they have to send you the model and wait two days for you to send them a build with it in, they’ll give up within a week. Frankly – even if you’re working on your own, and doing all the code and art yourself, a little bit of work to make good tools will make your own life easier; and isn’t that what we all want?

The Masonic Handshake

I’ve had a few people contact me to ask, “do you have any advice for how to get into the games industry?” Besides being ironic given that I’m no longer a part of the industry myself, this is a phrase that I really despise, because – well, I’ll get to that in a minute.

I’m going to start by making a couple of assumptions. I’m going to assume that the the person asking the question is really asking, “how do I get a job as a games programmer?” The reason for this assumption is that it’s the only thing I can speak with any experience about. Modern games (at least, console and AAA PC games, which is what people usually mean by “the games industry”; casual or flash games, not so much) involve teams of tens or even hundreds, involving programmers, artists, designers, scriptwriters, musicians, testers, producers, marketing, and a whole bunch of other roles. I’ve worked with all of the above, but I’d be guessing if I tried to tell you how they ended up there.

The second assumption I’ll make is that working as a games programmer is something you really want. The pay is low, compared to non-games programming. The hours are longer (though this is starting change) and the respect from management lower. Most games – and hence, the games worked on by most people – aren’t the amazing high-quality AAA 96%-rated blockbusters like Half-Life 2 that we’d all love to be a part of; in fact, most of the work you do will be soul-destroying just like in any other job. If you’re lucky, you’ll get to work at a company that lets you leave at 5pm, in which case you will get to see the sun; but even if you don’t have to crunch you could easily go months without seeing those strange creatures they call “females”. In fact, for all these reasons and more, I no longer work in games myself. But be clear about this – I’m glad I did it (for about six years). Knowing you’re doing a job you love, and finally seeing your baby on the shelf at Game and hearing someone say “yeah I played that, it’s quite good actually”, is a buzz of fulfilment like no other. Decide for yourself whether the balance works for you. It did for me, for a long while.

Anyway, where was I? Oh yes – “getting into the games industry”. I hate that phrase. It suggests there’s something magical about it, as if you need to know a special password or shake hands with the interviewer in a particular way. The truth is that games have matured into an industry like any other and you’ll get a job programming games the same way you’d get any other job.

Let’s pretend I’m going for a job as an architect. Should I:

(a) spend all day looking at my favourite building, but not really bother about any others because they suck, take a course in Social Studies because you only have to go to three lectures a week, then wonder why architecture companies don’t even respond to my applications even when I put “…it’s what I’ve always wanted to do, and I’m a fast learner!” on my CV; or

(b) learn how to be an architect, get qualified, put together a portfolio, apply for jobs, and make sure I nail the interview?

Third assumption: you answered (b).

Get Competent

If you’re going to be a games programmer, you need to be a good programmer. Sounds obvious really. I’m tempted to say, “it’s that simple”, but of course it’s not. The thing is, if you’ve yet got a job as a professional programmer, you’re probably not aware (even if you think you are!) of what being a good programmer means. That’s OK. The good news is: no-one expects you to.

The simple fact of the matter is that learning to program well comes only with experience. And, if you don’t have QA teams tearing your work to shreds, or customer complaining your software crashes, you may never realise when you’re making mistakes. (Don’t let that stop you coding – a lot – in your spare time. Any experience is better than none). When I first began applying for jobs, I rated my coding skills as 8/10. Looking back, I was more like 2/10. I’m not sure I’m more than 7/10 now, more than six years later. That’s fine – companies looking to employ new hires only really expect 2/10. So why, you might wonder, bother putting any effort into learning to code at all? You’ll learn it all on the job, right? Wrong. Getting to 2/10 is hard (remember the default state is zero!). If you don’t understand pointers, if you can’t fix compiler errors and warnings, if you can’t identify and eliminates bugs in your own code and other peoples’, if you can’t make estimates about the performance of a given algorithm: either learn that stuff or give up now. No company will expect a new hire to be the finished product. But no company will hire someone who hasn’t bothered to learn what they need to know to do the job, either.

What language should you be programming in? I’d love to say C#, but I can’t. Not yet anyway, perhaps in a few years. Currently, most companies only use C# for tools (and some not even then). The overwhelming majority of games companies use C++, and most of the rest use C. (Or, mobile developers probably use Java?) A few devs are starting to use C#, but most don’t and sadly won’t. There are a few very good reasons for this, despite the fact that C++ is a dinosaur and C++0x is going to be at least ten years too late. The first very good reason is that companies currently have millions of lines of C++ and tens of C++ programmers, and they’re not about to throw either of those away just because someone like me claims C# is more productive. The second very good reason is that there is no C# compiler for PS3 or Wii – and that’s a winning argument for companies intending to make games for those platforms. So if you want to make games,  I recommend C# and XNA. But if you want to get a job as a games programmer, I’d be doing you a disservice to say anything other than to learn C++.

You should also have a passing familiarity with two or three other languages (even if only to know that “the major differences between C++ and <language> are…”), an understanding of computer science principles, and above all, the ability to work as part of a team, including with team members who are non-programmers.

Get Qualified

Already, I’m sure some of you out there are screaming at me about this. “You don’t need a degree to be a good programmer!” they’re shouting. That’s not in dispute. “Just because you have a piece of paper, doesn’t mean you are a good programmer!” they’re adding. Completely agree with that too. However, nowadays, if you don’t have a degree in some kind of computing-related field, you probably won’t get past the recruiter’s first cut. Yes, there are exceptions, but they are exceptional! You could take a gamble, but the odds are desperately slim and you’d be much better off getting a degree. (The only time I’d say that doesn’t apply is if you’ve already been working as a professional programmer for years, in which case, yes, experience counts at least as much as a degree. But for a school-leaver or graduate, a degree is, to all intents and purposes, essential).

But – a degree in Computer Science or similar traditional field, or a new-fangled degree in Computer Games Development, perhaps even from a games-specialist University? Well… I cannot deny my prejudice here. My degree was in Computer Science, and I learned things on that course that I don’t think I’d have learned on a games-specific course that since proved invaluable. There is also the consideration that, should things not turn out as you hope, a CompSci degree will get you a job in a non-games company. I’m not sure that a Games degree would do the same. Or, look at it another way: any company will hire someone with a CompSci degree, some companies won’t hire people with a Games degree. That may change over the years, in fact I expect it to, but again – play the odds!

I should mention that at least two excellent people I worked with had Games degrees, so I wouldn’t dismiss someone with a Games degree out of hand. But, I got the impression that they were brilliant despite their Games degree, not because of it. I’ve also seen a lot of applicants with Games degrees who were simply awful and had clearly been let down by their course. It’s up to you, in the end – a Games degree or a CompSci degree is entirely your choice, and either can be made to work – but I’d still suggest that, for now at least, the latter is the better option.

Put Together a Portfolio

So you’re a good programmer and you have a piece of paper to prove it. Excellent! Regrettably, companies will still need convincing. There’s only one way to do that – happily, it coincides with the first piece of advice, “get competent” – and that’s to write some code to show to a prospective employer. (Writing the code will help you become competent, and as you become more competent you will have better code to show to employers).

What kind of code? Well, you’ll need to show a few things really. First, a simple, yet complete, polished, and bug-free game. When I say “simple”, I mean something like Tetris – but when I say complete, I mean with menus, high-score tables, multiplayer, pause, an options screen… everything you get in a pro game. Bug-free should speak for itself… Secondly, you’ll need a more advanced game that may be incomplete but demonstrates more demanding problem-solving. It should involve two or preferably more of the following: 3D graphics, 3D audio, physics, networking, AI, data driven development, and save/load. Finally, you’ll need one game component (from the list above, or “something else”) that is highly polished and well developed and could be plugged into someone else’s game if they chose to use it, so should also be clearly documented with a sensible API.

You should provide this code with your application, either on CD if it’s by snail mail, or on a website  if your application is in electronic form. Provide your complete source code, and make crystal clear exactly which parts were written by you and which by someone else. Also provide the built versions of the software (on the CD, or as a separate download from the code) but remember that actually it’s the code that’s important – recruiters probably won’t run the game and certainly won’t play it for more than five minutes to check it doesn’t crash, but they will be interested in whether your code is well-written. Only ever show your latest, best code – quality beats quantity every time.

Apply For Jobs

First impressions count for a lot: make sure yours is positive. Ensure your CV and covering letter are polished, clear and professional. There’s a lot of websites with good advice which I won’t attempt to repeat here.

Where should you apply? Well, there’s a lot of options. Do some research (subscribe to Develop and Game Developer, and join Gamasutra, GameDev.net, GameDevMap.com and probably a bunch of other places), and try not to close too many doors. When I was a graduate, I applied to forty games companies. I got three interviews, one of which was cancelled the day before the interview itself, and one job offer, which became two a few months later, after I’d already started working for the first. (In contrast, when I started looking to leave Rare, just six applications garnered me six interviews and five job offers – that’s the power of experience!).

Remember that large companies (EA, Microsoft, Sony, Nintendo, etc) are more likely to recruit new hires than small companies, who may not be able to afford to employ someone who will, inevitably, not be very productive for at least the first six to twelve months. Bear in mind the corporate culture of such companies – though remember you might not be able to afford to be choosy. Medium-sized companies sometimes offer a less corporate culture while still hiring graduates; some are more noted for recruiting out of University than others, for example Rare, Blitz and Codemasters in the UK. (Again consider the implications. Are they hiring graduates because they are able to recognise untapped potential – which is a very good thing – or to get a cheap source of labour – which is a bad thing? You’ll need to work that out for yourself at the interview). Whatever happens, don’t apply blind. I’d encourage you to send lots of applications, but you do need to understand what you’re applying for and why, before you do.

Ace The Interview

Again, there’s plenty of websites that can teach good interview technique, so do some research. I can tell you that having done some interviews myself, there are many things I’d be looking for, but basically I’d be looking to answer these questions: (1) will they be any good at the job? (2) will they fit into the team? (3) would I want to work with them myself? Three yes-es and I’d make an offer, any no-s and I’d give a polite “no thanks”.

To answer (1), as a programmer, you should absolutely expect to be given a programming test at (or possibly before) an interview. I’ve taken a lot of these – erm, about twenty-eight altogether? – and they vary a lot. Some – the worst – ask you obscure questions about bizarre corner cases of C++ in an effort to find out what you don’t know (that the examiner does); others ask you to debug code and write some of your own, to find out what you do know and how well you know it. Most are written, some involve giving you a laptop with a game project on it and asking you to fix the bugs. Some involve general programming knowledge, others are strictly C++ only. Whatever happens, all you can do is your best, and if you’re competent, you’ll do well enough to pass.

(2) and (3) are much more up to you. Remember that they’re looking for someone who is competent and confident, but not arrogant. One of my favourite interview techniques is to say something the candidate should know is wrong. If they agree with me, they don’t know their stuff – no hire. If they quietly say nothing, they might know it’s wrong but aren’t confident – I’d try to give them the chance to show that, but it would leave a question mark. If they argue with me or (as one candidate did) call me stupid, it shows they might have trouble fitting into a team environment, especially with temperamental non-technical types – and I won’t be offering them a job. If, however, they calmly explain that I am mistaken, and in fact the truth is this, which they know because they once did that – well, that’s a model answer.

With all that said, there’s a couple of things you need to bear in mind. Firstly, the company has gone through potentially hundreds of CVs and code samples and chosen you as someone worth inviting to interview. They may have spoken to you on the phone, and they’ve certainly set aside time for one or (usually) more people to take time out from developing a game to interview you. They wouldn’t do that if they didn’t want you to do well. If you’ve been invited to an interview – when you get there, relax. The interviewers will want to hire you, or they wouldn’t have asked to meet you: you just need to convince them that they’ll be right to do so. Secondly – remember that in a sense you are interviewing them, too, and not just when they ask “do you have any questions for us?” You should try to get a sense of the working environment, see if you get on with the interviewers, and think deeply about whether, if an offer is forthcoming, you’d want to work there. I had five very good years at Rare and I have generally positive memories, but my second games job was a big mistake, the biggest of my life – one that I could have avoided if I’d been smarter. At some stage you’re going to have to take the plunge, but if there’s a nagging voice in your head saying “…are you sure?”, make sure you can answer “yes” before accepting the job.

Getting In

With that lot under your belt you’ll soon be getting hundreds of job offers. Good luck! Hopefully you’ll be able to choose a company that is right for you. Making games for a living is a lot of fun and I’m very glad I did it. One day, I may even go back – who knows what the future holds? If you’re visiting this blog chances are you already make XNA games as a hobby and, yes, there are few things better than being paid to do something you’d be doing for fun anyway. Just remember that ultimately it’s a job like any other and you’ll do fine.

Oh yeah- speaking of which – money! Again, do some research (principally in Develop and Game Developer magazines which have annual salary surveys) to find the range of starter salaries in your area. Last I was hiring in games, about 18 months ago, £23-25K was a decent offer for a graduate programmer in the UK (outside London). Unfortunately, as a graduate you’re unlikely to have much leverage to ask for more, but equally, don’t quietly let yourself get shafted just to take a job, any job. You should also consider working hours, benefits, location, company size and stability, and whether there is a career path. In what proportions? Well, that’s up to you!