An Exceptionally Stupid Idea

I’ve been asked a fair few times how to get into the games industry. It’s one of those job sectors where there’s tons of people who want to work, but still a shortage of people due to the lack of actually qualified people. Some of this is because there’s been a lack of education, some because it’s a somewhat harsh business to be in with a high turnover. Either way, it means there should be openings, if you’re interested.

So how do you get in?

The answer is very dependent on what you like, and what you do. The lack of education for designers has been solved lately with game design schools popping up like mushrooms all over the place. That creates a new problem though, as some of these schools aren’t exactly viewed as top notch by game studios. If you choose to go that route, be very careful about what school you pick.

If you’re a programmer, however, do not go anywhere near specialized “games” schools. What you need is a regular Software Engineering / Computer Science college. Don’t make the mistake of thinking that game coding is some special form of coding, that doesn’t abide by the normal rules of code. When choosing classes, go for anything in connection to games — graphics courses are common. Take anything they have with low-level programming and hardware. And take at least one programming project course.

Regardless of what education you end up in and what field you’re in, I have two generic pieces of advice that should apply to just about everyone:

  1. Have a side project.
  2. Put your heart into it.

I’m not going to claim this is the only way you can do it — but I’ll offer you a way that’s very effective if you’ve got the energy to stick to it.

Side Projects

And by side project, I don’t mean “implement space invaders”, I mean make something about two levels above your own experience and ability, and a lot larger than anything you’ve ever made before. Get at least one other person on board in the project, and work hard on it, reworking it and trying to perfect it.

The point of doing this is not the project itself, though it certainly helps to have a major project to show as a demo when talking about getting that job, the point is the experience you get while doing it. There’s a range of vital skills that nothing in any formal education will teach you, so you better get those skills for yourself.

I teamed up with a classmate and started writing a game engine while I was in college. It turned out to be a project that lasted four years, and that with a bit more luck could have led to something more than just a side project. The experience was invaluable.

Trying to tie your courses and your side project together is also a worthwhile enterprise. We ended up doing a number of home works in several 3d graphics courses in our game engine, and even made a game prototype as a software project course.

Put Your Heart Into It

Lots of students seem to go to college more for the college parties than for the college studies. That’s fine, in a general sense, but if you want to get yourself set to get any highly sought-after job, really, you’ll want to do everything you do with a sense of perfection.

Make it a goal to do well even on the difficult and boring things, and to excel on the interesting things. Take one step further than you really need to, and if things are interesting, keep walking even if it seems silly. Far too many people stop when they’ve completed an interesting task because that’s as far as they needed to take it, even though they were interested in the subject and could learn more by just keeping at it.

If I were to describe my method of doing things in college in one word, it’d be “Overkill”.

An Exceptionally Stupid Idea

Let me illustrate the above with a story.

In a course on mechanics we were making differential equation solver calculations on a housefly walking across a surface — calculating how the limbs and body moved while keeping the feet steady. The calculation application we were using was fancy enough to include a 3d visualization of the process. Cool idea, but to someone used to working with 3d graphics engines it was brutally ugly.

So the afternoon on the day before we were due to present it, we got an exceptionally stupid idea: “Let’s render this thing to a movie instead — it’ll look sweet”. The presentation was the morning after, we had the Solaris environment on the Sun boxes in the computer rooms to toy with, and my incredibly underpowered PC laptop… not much to cheer for, when looking for 3d graphics tools on a tight notice — but we did have POVRay on the Solaris boxes.

We looked at the file format of our calculation tool, looked at the povray file format, and set off writing a converter. A number of hours, a break for pizza and lots of fiddling later, we had a converter and something that key-framed each frame into a separate povray source file. By now it was evening and the place was near-empty.

We ray traced the first frame. It took a disheartening amount of time. We had a couple of minutes of video to render, which turns out to be several thousand frames. I don’t remember the exact numbers now, but at the speed we were going, we’d be done a few weeks later. Give up, go home time?

Not for us. We had a near-empty room full of Sun workstations, and a way to run remote commands. So we tried to build frames remotely, but had no way to make a direct copy to the computers. Home directories were on a tight quota, which meant we couldn’t work online.

So we set to work creating a script that set up packages of work, copied them onto the home directory, started a remote job which copied the package to a local temp drive on the remote computer and rendered the frames.

We shipped packages to every free computer in the room, which was basically all of them by that point. Midnight came and went with a frightening speed. Still not good enough. A scan of the computer net confirmed that the rest of the rooms were as empty as the one we were in — so a list of computers with no-one logged in later we’d shipped off packages to every available computer on 3 floors, and 100+ computers were happily chugging out frames for our video.

By sunrise the next day we’ve got thousands of frames of video data spread out across every computer on site. An epic struggle of sending off remote jobs to copy these onto the network home drive started, moving them down onto my laptop as soon as they were online. We managed to get them all copied in time, and set the laptop on encoding them all into a video file.

Encoding videos isn’t the quickest thing you could do, and on a laptop at the time it was painfully slow. It was still building by the time the class started. Clock’s ticking, and the progress bar’s hardly moving… but our presentation was scheduled for the second of two hours of class, so we let the laptop encode as the first presentations were held.

In total, working all through that night, we managed to get the video together with 15 minutes to spare. And it did indeed look sweet. People went “ooh” when they saw it.

The Point?

So what was the point of the entire thing? We had been done with the actual assignment before this story even started. We had the idea at about the same time anyone else would have stopped because the assignment was done. It didn’t give us any academic benefits. But we learned a lot. We took on a challenge and grew with beating it.

By the time we were forced to give up the development of our game engine, and I went to work on Battlefield: Bad Company for DICE, we’d already created a fully networked multi-player hovercraft racing game with fully scriptable game modes that had error-correcting network transfer, could automatically send you any maps or game modes you were missing when you joined a server and worked on Windows, Linux, Mac OS X and Solaris.

With that kind of experience and track record, getting a games industry job won’t be hard, and performing far above everyone’s expectations will be something that comes naturally.

6 Comments

  • By Alex, Saturday, March 7, 2009 @ 8:14

    Another great post and most likely the kick in the butt I need. 😉

    On the other hand I’ve gotten a lot of ideas for software I want to write the last week or so.

  • By WikkaWikka, Saturday, March 7, 2009 @ 22:40

    Hi Mikael,

    I graduated last year with a major in CS and a minor in math. I’ve moved to Silicon Valley, and am currently working at a large non-game company; however, my goal has always been to get into the games industry.

    I recently got married and my perspective has shifted a bit (obviously). I’m concerned about how much time I will have to devote to my work if I do work in game development. I want to be able to have a rich life with my family and would sacrifice my dream job for that, if necessary.

    With that in mind, could you comment more on the “harsh business” that leads to a high turnover rate? How many hours would you say a typical game programmer (or manager) works a week, in or out of crunch time? How often does a crunch time occur?

    Maybe this would be a whole other post entirely, as it deals with “should I” rather than “how do I”, but if you could give me a high-level overview, I’d appreciate it. I want to align my goals correctly to either progress where I am currently or move towards a game company.

    On another note, would you suggest steering clear of XNA as a way to gain experience and to demo in favor of something more low-level, like C++? My work experience consists mostly of C#.

    Thanks

  • By slicedlime, Sunday, March 8, 2009 @ 0:41

    The second question is easiest to answer, really: XNA is good in a way, because it can give you experience with actually making games (so you can learn the principles of how stuff works). However, no actual games company I know of makes games in C#. I know some people use it as a scripting language, but noone uses it for the actual game engine.

    So if you want a shot at actual game code (as opposed to toolchains or support code), you’ll need to get experience coding C++.

    The other question is, as you say, a larger subject… maybe I can write a full post about that at some point. A short answer would be: it varies incredibly much between studios, and even between projects. Some studios do basically no crunching at all, some crunch all the time.

    As studios learn development practices these things change as well… during Bad Company, we worked incredibly long hours for a range of demos and such, for BC2 we’ve had a much more sane development with almost no crunch at all.

    I guess something you could factor in: You’d be surprised at how many people at DICE have families.

  • By WikkaWikka, Thursday, March 12, 2009 @ 22:10

    Thanks for the tips. I might switch over to getting more experience in C++, then.

    That gives me hope…I’ll continue striving towards getting experiences that’ll land me a job somewhere in games.

    Thanks a lot for your comments, and I look forward to anything else you have to say on this subject. Great stuff on this blog.

  • By Peter Jaric, Friday, March 13, 2009 @ 12:33

    I understand that you named it “An Exceptionally Stupid Idea” partly ironically, but nevertheless I must object! How could you have done anything else once you thought about it? Ideas exist to be implemented and code craves for realization.

    When was this? On a course on Uppsala University I once did a ray tracer assignment with a friend where we were *supposed* to create movies and it didn’t take that long. Yes, it was our own little measly ray tracer, but on the other hand, POVRay must be pretty optimized. That was around 1995 I think.

    Hmmm, maybe it *is* like comparing apples and oranges, though…

  • By slicedlime, Friday, March 13, 2009 @ 15:12

    I agree ideas are good to follow up on… but in context it’s a somewhat stupid idea to follow up on when you don’t really need to (doing an all nighter for… “oh shiny”). It felt sort of silly at the time, but part of the charm with stuff like that is the utter pointlessness of it. Exploration for the sake of exploration, or scratch the itch.

    About the time, um… maybe 2001, possibly 2002. Something like that anyway. The performance of it is probably ok-ish, but not on the old sun boxes we ran on, and not if you haven’t had more than 3 hours to set up your scene.

    So in that way I guess the tradeoff was between setup time and render time — if we’d spent a week properly trying to learn to use povray, we could probably have rendered it a lot quicker.

    Also, part of it was that the longer we worked on it, the less time we had to actually render it out. At some point you just had to stop trying to make it better and hit the big “Start” button.

Other Links to this Post

RSS feed for comments on this post. TrackBack URI

Leave a comment

WordPress Themes