The degree I’m doing currently has been very much centered around graphical programming, aswell as using various programming languages to bolster our CV’s I would imagine. We’ve not really touched on networking, or AI at all. Our main language in graphical programming has been OpenGL too, we’ve dabbled with DirectX a little, mostly managed directX with XNA.

As a programmer already in the industry, could you give me any advice on the type, and level of project I should aim for, for it to be a suitable demo project to show to prospective employers? It’s difficult enough as students to find our way into the games industry; if we don’t know what employers want, or what is considered worthy in the eyes of the employer, it lowers our odds tenfold.

In a way, the answer to the question depends on what kind of position you’re trying for. I’ll try to answer with regards to as many positions as I know.

For starters, is graphics programming what you want to be doing? If it is, things like what graphics APIs you know become a lot more important. From what I know, most games studios that do windows game development have gravitated towards DirectX. With that in mind, having done a large(ish) project on DirectX could definitely be a plus. If all other things are equal, I’d definitely go for learning DirectX.

Not having experience with networking or AI isn’t all that much of an issue, unless you imagine going specifically for a networking or AI programming position (and even then, it’s more of a bonus than a requirement). One thing is clear however… if you’re looking to get into professional development at a large studio, you should be going for C++.

Now if we look past the technical requirements, there are a few things that can be said about such a project in itself. What you get from a good project is a nice entry into your demo reel — something to show off. This has a few implications, but most importantly something I’ve touched on before, in A Spectacular Failure: your project is going to be judged on emotional first impressions, not how technologically advanced it is or how nicely coded it is.

Your number one enemy is over-scoping the project, ending up with something that does lots of things, but does none of them in a great way. Come up with a good core gameplay for the game, and then polish it to a great shine. Fix all those annoying glitches and bugs, make sure everything looks as impressive as possible. It doesn’t need to be rocket science, as long as it’s well executed. In the end, what a games studio is looking for is a programmer who knows how to finish projects in a good way.

That doesn’t mean your project should be Space Invaders, but in general trying for something too big is more of a problem than overdoing something too small.

Finally, as an entry on your demo reel, make sure you make the game available in an easy manner. Have a page with plenty of screen shots, videos and preferably the game itself easily downloadable. Your coding ability will definitely be tested with some form of work sample as you apply to studios, so the code itself being available is less important. Reading code is hard, so it’s unlikely that someone will have time to read yours. However, having a finished game to show off is worth a lot, as is the experience of going through all the phases in finishing a game.

Other posts you may find interesting, relating to getting into the games industry and getting started with games:

• Getting Into Games
• An Exceptionally Stupid Idea
• Let’s Make a Game Engine

Working at a Games Studio

Getting started with something I intentionally left out:

Low pay. Good luck trying to buy a house.

There’s a well known discrepancy between salary in your average programming gig and your average games programming gig. I left it out of the original post because of two factors:

1. The difference is highly overstated. Salary varies much more within each class of work than between the two. While it is true I could probably get more money by switching to another job, the same is true for many others, and the difference wouldn’t be worth it to me.
2. It’s your choice. I expect you to make a well-informed choice on taking any job when it comes to what you get paid. Don’t just take any job because someone told you you get paid a lot in a certain business — make sure you get what you’re worth.

A second issue from the same commenter (and several others):

Yes, you have to come to work on Saturday and Sunday.

This is an issue in the industry, and I’ve seen pretty bad cases of it. Since I started coding games, the working conditions have improved by far though — and this doesn’t only seem to be my situation but applies to many others I’ve spoken to at other studios (mainly within EA though — would be happy to hear the perspective of other people). At the moment, from where I’m sitting, things are looking pretty good.

I’m not saying crunches don’t happen, I’m just saying they’re reasonably few, have a good purpose and focused time span, and include a time off compensation after the deadline has been passed.

The most problematic part of this is that it’s extremely hard to figure out if this applies to any given studio without actually working there or knowing someone who does.

I wouldn’t want to be the guy working on the next Madden game

Well, I actually know the guy working on the next Madden game and he is incredibly dedicated and seemed to love what he was working with last time I saw him. About the comment, he told me “Well we don’t want that guy anyway,” which is very true — the reason there is a Madden game every year is because there are lots of people interested in a new Madden game every year, and among that crowd there will certainly be people who are interested enough to want to work on the game.

It’s funny, because I sometimes hear the exact opposite of this comment at work. “It’d be so awesome to work on an iterative title where you just got to improve things and do all those cool changes that we have to cut”. Working on Madden is a pretty sweet place to be if you love sports games.

People sometimes seem to think that innovation only means new game franchise. There are lots of interesting developments and innovations within franchises, even within a “plain old sequel”, and working on one of those titles avoids one of the great drawbacks of the games industry: half the time you’re semi-panicking because your game engine isn’t in a shippable state and there’s a whole game team trying to use it to create a game.

That way, working on Battlefield: Bad Company 2 is nicer than working with the first game: the same chance for innovation, but less problems with others not being able to innovate due to the state of the code.

Getting started

A question that keeps popping up is any version on this:

I’m a frustrated web developer who’s always wanted to make the move into game development, but have yet to find the time to train myself and start shifting my skills over.

Any tips for someone looking to start out in that direction?

I’ve touched on this subject before, in An Exceptionally Stupid Idea, which tells the story of what I did. That post may be best applicable if you’re still in college, but there is a certain truth to it regardless of where you are. Time is money however, and with anything in life  you’ll need to do investments… so seeing where you could free up time is a first step.

What do do with the time once you have it? Well, the games industry is looking for a few things:

• Skilled programmers
• … who know the language
• … and with some experience of games

The third is actually somewhat optional, though most recruiters would never admit that. Becoming a good programmer is a hard topic to cover — more than half the stuff on this blog is already devoted to that, so I’m not going to comment further on that one.

Chances are slim you’ll be coding anything but C++ if you code games, so if you’re not already very familiar with the language, you should get familiar with it. It’s often said that good programmers learn new languages quickly, and to a certain extent I agree with this… but if the problem is complicated enough, you need to be a language expert.

Finally, getting some form of portfolio is good, even if it’s “just a side project”. That could also be a good project to use as practice if you’re not too familiar with the language. Further, it helps if you’re a gamer and stay on top of what’s going on in the industry.

This actually ties into another comment, which was the most compact piece of information:

C++

If you dislike C++, turn elsewhere. I personally think it’s an extremely capable language once you learn to harness it properly. It is dangerous without the safety equipment though, and sadly some of that equipment doesn’t work with games.

Other languages are starting to appear when it comes to games coding. I’ve heard examples of LUA, java and C# being used as scripting languages, and of course there’s UnrealScript. These can be extremely beneficial for iteration times and such, but the grunt of the software is still going to be C++.

Update: I should also mention another old post of mine about this: Let’s Make a Game Engine!

Games Programming

I tried to avoid getting into the details of hardware and the coding that goes with it in the previous post, since I love talking about these sort of things and I didn’t want it to become a rant but hey, you asked!

Console hardware (I’m looking at you, PS3) is made for pretty graphics demos, not simulation. If you work on the AI or physics, be prepared to focus your energy on low level optimisation and cache misses, because your AI code is never going to be any more sophisticated than a state machine.

Well… I’m the lead AI coder on Frostbite, and while there are lots of things to be said about the Frostbite AI, “no more sophisticated than a state machine” is not one of them. I agree, some things (especially physics queries) are expensive on the hardware, but that simply means you need to re-think how you do stuff.

SPU code is a vastly different beast from your average code. There are some bad programming habits that can completely destroy your code for SPUs… and among those bad habits are the ones that would lead you to get stuck on low-level optimizations. Once you learn how it works, there is an incredible amount of power in the PS3. I’d dare to say it’s still relatively untapped, and that as time passes we’ll see more sophisticated uses of it.

The limitations of console hardware is different. That doesn’t mean you can’t implement physics or AI, it just means maybe you’ve got to challenge your assumptions about how you implement physics and AI.

I guess the Parallelism approaches are a little different in both worlds. I bet you gamedev guys have been working with Data Parallelism for a while (i.e: programming the Playstation2 Vector units. I don’t think life is getting any easier on you guys with all those Cell SPEs to squeeze!).

In the enterprisey side, task parallelism is an emerging topic with languages like Erlang, Clojure and Haskell offering different abstractions for spreading computations over different hardware threads/cores.

The vectorization units of the PS2 are a quite limited way to do data-parallel work, so I disagree with you here — with the SPUs on the PS3, it actually is easier, because it’s less limited in what you can do with them. Vectorization units and other primitive forms of data-parallelism often work in lockstep, whereas the PS3 actually has a bunch of individual, highly capable although slightly quirky processors.

Games are full of data-parallelisable problems as well. Rendering is the classic example — the reason GPUs have been such a hot development the last few years is that rendering lends itself so well to parallelism. But there are many other things as well — the aforementioned AI is ideal in some ways, as it tends to be made up of lots of separate processes for different actors or entities.

Task parallelism is also something that can be utilized to a great degree in games since there are simply so many orthogonal tasks to complete. Update the UI, do physics simulations, calculate character skinning, play audio… I can’t go into details on that, but we do a whole lot of it in Frostbite. Sadly, you do end up needing to care about many of the details that using an abstracted language would let you ignore though.

Still, it’s one of the most exciting aspects of coding for me, since games are one of those applications that can actually use all the power of parallel computers.

With this post, I will try to list what I see as the biggest differences between working on a game and working on a different kind of software project. If you have any questions related to it, please post them as comments and I’ll do a follow-up round.

The Passion and Dedication

It sounds like a cliché, but games are made by mostly gamers. In all the teams I’ve worked with spanning maybe a hundred, there’s only a few people that aren’t absolutely passionate about games, and completely dedicated to making kick-ass entertainment.

The enterprise coders I’ve worked with pretty much fall into two categories: the day job coders who don’t care much and the hackers that appreciate technical challenges. As you move into games, not only does just about everyone fall into the second category, but nearly everyone is also excited about the games themselves, regardless of the technical challenges involved.

If you’re looking for a place to work where your colleagues will be really cool, skilled people with a passion, then the games industry is where to look.

On a cynical note related to that, the abuse of this passion and dedication is what has given the games industry something of a bad reputation (and a well deserved one too). My impression is that working conditions have improved quite a lot across the board, even if there are still the occasional horror stories. If I were to give one piece of actual advice, it’d be to be rather thorough in your background checks on companies.

Creativity

Game developers live off creativity. Even the most simple churn-out-sequels factory will attract highly creative people, and studios will tend to cater to creativity to a much higher degree than most other software development companies.

If you’re highly creative, you will probably find it easy to fit in. My experience is that creative suggestions are almost universally appreciated regardless of source.

Cross-discipline, Bleeding Edge Development

Games teams are made up of a number of disciplines that vary depending on what type of game you’re making, but generally speaking you’ll at least have Designers, Graphical Artists, Animators, Sound Designers and Programmers. Our projects have Mission Designers, Environment Artists, Effects Designers and other disciplines as well.

In a way, this is no different than many other types projects where some end-users create some of the data for the system, but there is a major difference in the fact that the hardware platforms are either consoles or PCs with specs so high that they don’t even exist yet. The coders on the team will be creating a game framework, which is then populated with different kinds of content to produce the game.

The problem with this is that they’re using the software tools you’re building (like the editor and data processing pipeline) to create the game while you’re still trying to build the tools, only to run it in a game engine that is also not done yet.

It’s a bit like trying to produce a business application while part of your team is working on creating the source code editor you must use, and a different part of the team is building your compiler. In some magical way, the components must all mesh together so that not only are the tools done when it’s time to ship the product, but that content creators have time to do something useful with them as well.

This creates an extra layer of complexity to the projects that I haven’t seen anywhere else. Inter-discipline dependencies between disciplines that work in very different manners can cause common project management techniques for software development to break down, because most of the team isn’t developing software.

Performance Focus and Hardware Platforms

From a technical point of view, there is a heavy focus on code performance. This creates a different kind of environment, where some modern programming techniques are simply too expensive to use. It also means you tend to get good at optimizations after a while.

The hardware we run on is increasingly becoming paralell. Using all of the power in the PS3, for instance, requires a fairly well developed parallelism, forcing the shift from single-threaded to multi-threaded coding onto game programming long before most applications need to care all that much.

(Note that my view on the state of the industry is rather limited here. DICE is ahead with the Frostbite engine on current console tech, some other engines are hopelessly behind, but it’s always hard to tell what others have in development.)

The hardware platforms themselves can sometimes be immature and cause problems when you have to jump through hoops to get things working (simple example: graphics driver bugs).

The platforms themselves also impose other restrictions on your code, like the low memory cap of current generation consoles and extreme penalties for cache misses and branching.

Playing Games at Work (!)

I couldn’t leave that out, could I? Yes, we playtest our games at work. They’re a lot of fun, most of the time, so getting to play awesome games before anyone else is quite a perk. To be completely honest I must admit that there are times when it’s not much fun at all… but they are quite uncommon. And hey… you get to shoot your boss.

I hope to give you a chance to see how a games studio works — maybe it’ll create better understanding of what it is you’re saying when you chatter around forums about the latest greatest game from some studio, or maybe it even gives you valuable insight if you’re looking to get into the games industry.

The Myth of the A-Team and the B-Team

Somewhere in the DICE Office

As soon as a game announcement turns up, knowing fanboys will appear on all forums around, claiming grand things like “Wow, this sure is great. Now we know DICE has the A-team is working on this while the B-team was doing (other title here).” Substitute with “good team” and “bad team” or whatever you will.

The reality is not only that there isn’t any first or second-rate teams, but that the teams themselves don’t really exist as a concept. People move between teams constantly — some project doesn’t need any more audio work now, so the sound designers move over to the next one. Meanwhile, the programmers are fixing the remaining bugs and getting set to ship the game. Most of the artists left the project before that.

That means that there’s rarely a situation where a team in a large studio makes one title and then immediately goes on to make another one — more likely the team will split up and head to other projects. Some may jump on to help another project get the final bugs squashed, others may jump on to prototype a new game.

The Life of a Game Project

That leads us to the life cycle of a games project, because another misconception is that the team making a game will remain the same group of people all the way through.

A project generally starts out small. A few designers basically start up by spending some time trying to answer the simple question of “What game do we want to make?” Sometimes this is more straightforward than other times — but more often than not it is somewhat complicated and difficult. Even sequels usually start out in a state of “don’t really know what this is about”.

There’s this nice thought many people have about games as having this brilliant idea first, and then just making the game. This never happens. The project will probably get to some kind of rough concept of what they want to do, what kind of technology platform to use, what setting, and so on… and then go into pre-production.

The pre-production phase of a project is when the project starts taking on more people. Coders join, artists join, and most probably more designers join. The mission now becomes trying to prototype, test and prove all the different aspects of the game — figure out the core game mechanics, make art target concept environments, make sure all the tools needed work properly. The goal is usually to build a small section of the game as a proof of concept.

The project has probably been running for at least six months by the time it finishes pre-production and heads into production. It staffs up even more, and sets about building all the levels, missions, features and content needed for the complete game. The amount of time it takes to do this varies wildly depending on the game.

Still, through production concepts are refined. As playtests are done, the developers think of new ways to improve the game, and the new ideas are worked into the concept.

What You See Is All There Is?

By the time you hear of a project, it’ll generally be in production. Conceptual prototyping is relatively cheap, so studios can afford doing concepts for games as a test, and if they don’t turn out well then cancel the project. This means that at any time, your favourite games studios out there are probably doing cool stuff you have no clue about.

This way of doing things also means most views on the state of a game are somewhat flawed. By the time a game hits beta and you get to see it, it’s virtually completed and only bug fixing remains. Comments like “well this is an early beta, they’ll change lots of stuff” are quite common and somewhat funny to see — very few game changes will be done once a game is in beta.

That doesn’t mean quality doesn’t increase though — much of the quality you see in a game comes from the actual fixing of bugs, not the adding of features.

“Not that the devs are ever gonna care”

Gamers tend to show a pretty large dose of resentment towards game developers. In general, what you see is an announcement met with awe and comments like “this’ll be the most awesome ever”. This attitude then changes over time, until at release, the comments tend to sound more like “they messed it up”.

A strange aspect of this is that many gamers seem to be deep into the belief that game devs don’t care about them, about the games they make, or about anything at all other than earning a quick buck. This is strange because the games industry is not the place to go to make the good money while slacking — it’s generally a grind of long hours of dedicated work and not as well paid as other comparable areas (making business apps is definitely much more lucrative for a programmer).

Yet people still do it? Why? Because these people are gamers and love what they do. Maybe somewhere there are big-name execs that don’t care, but I haven’t met them yet. I’ve only met the EA execs who beat half the dev team on Battlefield: Bad Company (though dogtagging your boss is sweet indeed).

That’s all part of what makes the games industry such a great place to be if you love games — not only do you get to work with games, you get to work with gamers.

Yet most people seem to think that game developers isolate themselves in a small glass jar somewhere, and start ignoring the internet as soon as their project becomes public. Nearly every forum or blog post about a game has a bitter comment about “no chance the devs will bother to read this”.

Guess what — we do read stuff on the ‘net. Not only because we’re gamers but because we care deeply about making the best game possible. So why don’t we answer? Well, I think you could imagine what’d happen. Half the people would call you a liar, and the rest would bombard you with even more. There’s no way for a game developer to answer questions or opinions on a forum without immediately being subjected to at least twice the amount of new questions or opinions. We’d simply run out of time.

And well… at the end of the day, we have games to make.

For my own part, I’m more connected than most. Toss me a line on twitter if you have a question.

Usually, the competitions themselves were not that exciting, but you know you take what you can get in terms of exposure and if you’re making a game anyway, then why not enter it into the competition? So we did.

The immediate result of this is that we now had a deadline. Deadlines can be incredibly healthy things because they force you to pull together and produce something solid. It doesn’t matter how many subsystems you have in place or how brilliant they are unless you’ve got something you can actually show off to impress people.

Another thing about deadlines is that you’re always behind for them. We were no exception here… I’ve done some crazy crunching at my current job, but for a single crunch, the one we did on Velox for that competition must be the absolute worst kind of crazy. The setup of the competition that year was that you bring your machine in (unless you liked the ones they had), and you show off the game on a big projector screen.

We worked incredibly long hours the week leading up to that deadline. The game was coming together really well, but we were working ourselves dead. We didn’t really have all the stuff in that we wanted, however, and the deadline loomed. We worked all through the night to the presentation day, and then finally packed up our demo machine and left for the presentation.

At this time, I’d been awake and at work on this thing for about 30 hours. I was dead tired, and I’m sure my colleague wasn’t much better off. I was running on fumes and Coca-Cola.

Anyway, we set up the game, show off our menu system, host and join a network game and fly around for a bit in the hovercraft. Really high-tech stuff for the kind of level the competition was at, but it was also pretty rough around the edges. A minimap bug led to us having a hard time finding each others, for instance. Also, not having prepared any presentation as such, we sort of played around for a bit and showed off most of what we had in a rather unordered manner.

Then I went home, slept for 4 hours or so, got up, fixed most of our major bugs, and slept for another 10 hours.

The competition? We lost it to a team who’s game was an un-innovative re-make of an old game and whos engine was basically a Maya file viewer that needed really top-end hardware to even run properly, despite the really simple stuff they were doing.

So just what happened there?

The first thing to take away from this story is hidden in what happened after the demo. I slept for just a few hours, and was so conditioned to working with the game that I went back to it, even though we didn’t have a deadline anymore. But something had changed — I wasn’t dead tired anymore, so my mental clarity was much much better, which meant I could do much more good.

If you ever think about doing an all-nighter to hit a deadline, think again. If you’re crunching hard for long periods of time, stop to think, because chances are you’ve crunched so long that you now produce less in 12 hours than you normally would in 8.

The second question is the key to why we lost the competition: Polish and show. We failed to analyse the situation of what our target was, so instead of locking down early and polishing what we had, we forged on adding stuff to our game. If we’d come to our demo in a better shape with a presentation we’d practiced for beforehand and a polished game, we might have done a lot better. Now our high-tech stuff just looked bland next to the shiny effects of the winner-to-be (as did many other teams’ high-tech stuff, by the way).

Whenever you’re up against a deadline and need to show off what you’re working on, take a few minutes to identify what could give you the maximum impact with the people who’ll be watching and judging your stuff. Focus on the right things.

And have a good night’s sleep before you go there.

One company seemed impressed with my enthusiasm for the job but it was part of their policy to provide coding tests. This seemed perfectly reasonable and I did it by using the first solution I thought about. When I got to the phone interview, the guy spent about five minutes telling me how inefficient my coding solution was and that they were not very impressed. Then I asked whether he had looked at the open source projects I mentioned. He said no – but it seems his impression was already set based on my performance in the coding test.

The anonymous programmer then goes on to ask if Open Source experience is overrated? I’m sure it isn’t, but just like Jeff writes, you’ve got to pick a good project – one that will impress me by its result. The thought that having done Open Source software development will somehow get you out of having to perform well on a coding test and on interviews is kind of peculiar.

In a recruitment situation, what you’re looking for is not only someone who’s skilled enough, but also passionate enough about getting that job to prove it. Joel Spolsky calls it pickiness. Now going back to what our anonymous coder wrote:

I did it by using the first solution I thought about

I’m not surprised about the result. Caring about the code you’re doing and the job you’re applying for shows, both on coding test results and on your cover letter.

Open Source development does look good on a resume to me, but I’ve also seem some people with impressive resumes completely fail at implementing a very simple coding test. I absolutely understand the recruiter in the quote above — if your coding test result is bad, I’m not going to take the time to give more than a cursory glance to your previous projects, especially if you can’t answer well about why you wrote it the way you did.

It’s also a somewhat weird expectation from his side. Reading code you don’t know is hard and takes lots of time so the chance I’m going to download your open source code and actually read through it is virtually zero. If you haven’t done anything that actually achieved something, why should I care?  Even if you have, why would that matter if you just proved to me that you’re not what I’m looking for? Trust me, reading the results of a coding test is hard enough work, and if you have a fair few candidates, you’re not going to want to do much more than that.

He continues:

One of the reasons I worked so hard on open source projects was to make job interviews easier. By providing prospective employers with large samples of publically available working code, I thought I would give them something more useful to think about than my performance on a particular coding test or whether the acronyms in the job skills matched my “years spent”.

I agree with Jeff that working on an open source development project is a good way to boost your resume — but it’s not a shortcut through having to perform well in all other areas. My tip is if you care about getting that job, put as much effort into the application and coding test as you would on any project code — open source or closed.

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.