Getting Into Games — A Follow-up
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.
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.
The Games Industry | slicedlime | 
Saturday, July 11, 2009 17:14
8 Comments
Other Links to this Post
RSS feed for comments on this post. TrackBack URI
Subscribe
By Psykocyber, Saturday, July 11, 2009 @ 20:00
Great blog, nice to hear about the PS3s processing power from someone who actually programs for it and not just from people on forums with a search engine next to them.
So I must ask you, how “difficult” is it really to parallelize your code for optimal SPU performance? Any different on the 360?
By slicedlime, Saturday, July 11, 2009 @ 20:15
The 360 is much more like a multi-core PC when it comes to coding. Any normal multi-threaded code will work for it… and while that’s a major step away from the sequential approach for older platforms, it’s still roughly the same.
The PS3 SPUs don’t work like normal hardware in that they don’t have a memory cache. Instead they have an on-die memory chunk that you can DMA memory into and out of… so that affects you quite heavily; you’ve got to think much more about what memory to pull in to a function you want to run.
… but on the up side, if you do manage to use them right, they’re blazingly fast.
By ANdrew, Sunday, July 12, 2009 @ 7:51
I don’t know “the guy working on the next Madden” but I do know people who worked on the last few and it was a pretty awful experience. Three months of crunch on a 12 month project? Thanks, but no.
By CodeJustin, Monday, July 13, 2009 @ 5:06
Ya, I’m actually trying to make my own mobile RPG right now using J2ME.
By Gustavo Barrancos, Wednesday, July 15, 2009 @ 12:42
Thanks for clearing the SPU concepts
By Susan, Friday, July 24, 2009 @ 16:20
I recently came across your blog and have been reading along. I thought I would leave my first comment. I don’t know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.
Susan
http://onlinegamesforgirls.net
By Rene, Tuesday, July 28, 2009 @ 19:26
I really enjoyed reading this & the linked blog posts and just subscribed to your feed.
Mostly I use C# for quick development.
I was always interested in the game biz and coded computer graphics, physics, AI stuff and simple games (see http://rene-schulte.info). I also wrote a small 3D Engine in C++ a few years ago. Since 3 years I work as a business app developer with .Net and C#, but also implemented interesting stuff like a genetic algorithm for the optimization of price calculation parameters. Recently I developed a generic parallel Software pipeline, which is now used for fast data warehouse filling. At night I pursue my passion for computer graphics, physics and algorithms.
A former fellow student of mine made an internship at a German game studio during our university time and told me some horror stories about heavy crunch times at the weekends and really bad salary. They even had folding beds at the office! Because I wanted to start a family, I decided to stay in my town and don’t look for a game dev job. Now, that I’m married and have two little kids I think it’s hard to get into the business, especially here in my region where I don’t know any studio. And I guess remote work isn’t an option in the companies?
We have also crunch time in my current job before major releases, which is OK for me as long as it’s not the standard. IMHO too much crunch time is a sign for bad management.
Although I forgot some C++ stuff, I think it wouldn’t be too hard to get into it again. You wrote that it’s really important to be an expert in C++. I think it’s more important to know how to write good code and understand the principles of optimization, parallel programming, math, AI, computer graphics, … And it’s even more important to have an understanding about how business works and the ability to priories work tasks. Good programming language knowledge is crucial, but if you encounter a tricky problem in C++, why not ask a senior colleague at the beginning? And why don’t the companies make some sort of in-depth training at the first time? In every game dev job opening I’ve read they want experts with long experience in the game industry and some released titles. IMHO they overlook great potential.
Greetings
Rene
http://blog.rene-schulte.info
http://twitter.com/rschu
By Kevin, Friday, September 18, 2009 @ 17:34
Recently discovered your blog & working my way through the archives. A perspective from “in the
industry” is always appreciated!
This one pushed a bunch of my buttons:
>I wouldn’t want to be the guy working on the
>next Madden game
This sounds like the old “clean slate” vs “existing codebase” dilemma. You need to work on the one you’re more comfortable with, and find your motivation in whichever situation you pick. I get the impression that the game industry has tended toward the “make it once and you’re done” situation, but that may be changing. A pro working on version(n) would know that they were likely to be the poor sucker working on version(n+1) and program accordingly.
Alas, the typical university curriculum is usually geared to the “write once, throw away” mentality. The average student project doesn’t involve facing the poor decisions and coding flaws from an earlier version of the code.
Thanks again for the post!
Kevin