My post from a week or so ago about the differences between working as a software engineer in a games studio and in other places generated a fair number of interesting comments and questions, both here and at various syndication sites. In this post I will try to answer and comment on the most common and interesting ones.
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:
- 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.
- 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.
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:
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!
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.