How To Become A Video Game Systems Programmer

Meet David C. Galloway, Video Game Systems Programmer

David Galloway began his game programming career on the Commodore 64 home computer, and has created game play code for top-shelf franchises like Assassin’s Creed and X-Men.

But his real super power is in building game system code – the core programming that drives a game engine. From math libraries, to 3D animation systems, to the code that empowers Atair to free climb across Cyprus, David writes the code that turns lifeless polygons into living, breathing 3D worlds.

What exactly does a Game Systems Programmer do each day?

My daily responsibilities as a systems programmer change over the course of the project, from the early phases to the later phases.

During the beginning phase I work on tools and pipeline, or on making an old system better, or on designing new systems. The tools and pipeline improvements move the development team towards better automation, and streamline the process for the game designers and artists. It can also make the job of the game programmers easier by streamlining the mechanisms they use to add new objects to the game, and let them edit things in real time.

We may also research new technologies that could help reduce build times, allow more powerful debugging, or take advantage of the parallelism that has become a primary technique in the everlasting struggle to increase performance in our build and run-time systems.

You’ve programmed many computers and consoles, from the Atari ST to the PS4. How do you keep up?

When we’re moving to a new system or console, we have a large amount of work to get our systems – from the build system to the game engine – up and running on the new hardware. Everything from getting the game controllers working, to audio, to rendering needs to be adapted to the new hardware.

Even without migrating to new hardware, other things you might possibly be working on are file input/output and streaming, the occlusion culling (pre render), device input/output (controls/camera/Kinect), or memory allocation. We need to adapt to things you may never have even heard of before, like the profiling tools and the job-task manager for multithreaded job management.

That sounds like a very busy early phase. What comes next?

During the late phase of the project, it’s all about reacting to the needs of the game team. I might find myself heading up the investigation of a very difficult crash, or taking charge of getting the builds onto Steam or in the hands of Sony or Microsoft. A lot of the work in this phase is to fix bugs and deal with Technical Requirements – an official set of guidelines for publishing a game with Sony or Microsoft.

During the late phase of the project, it’s all about reacting to the needs of the game team.

Also during the late phase, you’ll probably be faced with some optimization issues to tackle. It can be scary but you’ll need to somehow free up an additional 30ms of time per frame because your publisher contract says you need to reach 60 frames per second. Often, the game is over that target by 50% toward the end because the artists and developers have piled in too much density. It doesn’t always happen that way, but it happens more than it should.

How did you become a Video Game Systems Programmer?

Primarily because of two things. One is that when I started in games, a team had one or maybe two programmers and everything was written right to the hardware. Those were systems like the SEGA Genesis (Megadrive) and the Super Nintendo Entertainment System (SNES).

The other reason is that I’ve always had a compulsive curiosity and fascination with what’s happening under the hood. My early exposure to working with computers at a very low level – we programmed the games entirely in assembly code – has turned into a knack for being able to tackle today’s difficult hardware-related aspects of game engines and build systems.

What do you like, or not like, about the job?

I like all of the work as long as we don’t stay in the later phase all the time. You need time to be in a research and development phase as well. I love crunch – the long hours at the end of a project – but at the same time if you do it too much for too long you will become mentally exhausted. It does take a toll on the family life.

You’d be surprised at how much we work when we really have to finish a game by a particular deadline. The deadline is non-negotiable and it’s often it’s moved – but never in the good direction. It’s not unheard of for people to work 70-hour weeks, 4 weeks in a row.

What talents and personality does it take to succeed as a Systems Programmer?

It takes a natural curiosity and a love of computers – a real willingness to roll up your sleeves and work hard every day. You will be somewhat removed from the actual game design aspect of game making, so you have to enjoy the technical side of things.

What books or other learning would you recommend to someone just starting out?

An education in computer engineering would be helpful. It’s a different degree than computer science – you’ll learn to understand hardware caches, Translation Lookaside Buffers and memory architecture, that sort of thing. My advice would be to take some engineering classes that would at least include some embedded systems programming. And, with luck, some classes on hardware design.

You’ll also need a good foundation in linear algebra. Some calculus and physics is useful, especially if you’ll be going near the physics engine, or the collision systems for example. It will really only hold you back if you don’t have some capability in this area. Mastery over regular computer science topics such as heaps, priority queues, and sorting is also necessary.

You can also learn it on your own! I’d recommend reading the books and papers below.

Dave’s List: Best Video Game Systems Programming Books

Real-Time Collision Detection
by Christer Ericson
Also a great systems book! Has perhaps the best chapter on optimization in any book related to game production. read it

Game Engine Architecture
by Jason Gregory
Hailed as a “must-have textbook,” this book provides readers with a complete guide to the theory and practice of game engine software development. read it

What Every Computer Scientist Should Know About Floating-Point Arithmetic
by David Goldberg
Floating-point is ubiquitous in computer systems. This paper presents a tutorial on those aspects of floating-point that have a direct impact on designers of computer systems. read it

Bruce Dawson’s blog
Lots of great stuff – profiling with xPerf for example. read it

Realtime Rendering
by Moller, Haines, Hoffman
Current, practical rendering methods used in games and other applications. It also presents a solid theoretical framework and relevant mathematics for interactive computer graphics, all in an approachable style. read it

The Art of Concurrency: A Thread Monkey’s Guide to Writing Parallel Applications
Clay Breshears
If you’re looking to take full advantage of multi-core processors with concurrent programming, this practical book provides the knowledge and hands-on experience you need. read it

Dragged Kicking and Screaming: Source Multicore
by Tom Leonard
This paper was presented by Valve at GDC 2007, and is still relevant today. read it

Practical Linear Algebra: A Geometry Toolbox
by Farin, Hansford
Teach yourself linear algebra! First this book… read it

…then this book/web page:
Essential Mathematics for Games and Interactive Applications: A Programmer’s Guide
by Van Verth, Bishop read it

Fabian Giesen’s blog
Caches, multi-threading, DX11 pipeline, optimizing, lots of great systems level stuff. read it

You can reach David via his LinkedIn page. If this article was helpful, please say thanks by clicking a share button below.