Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 23, 2014
arrowPress Releases
October 23, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Becoming A Better Game Programmer
by Alistair Doulin on 11/08/11 10:14:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


[This is a repost from my blog and #altdevblogaday]

Over the past 12 months I've worked as the sole programmer on the three games we've made. I've just started up a new project with a fellow programmer and found that I've picked up some bad habits in those past 12 months. I'm continually trying to make myself a better game programmer and today I'm sharing my thoughts on this topic.

Constructive Criticism

The most important way I feel I grow as a programmer is to listen to criticism from my peers. In the past (particularly during puberty) I found this quite difficult to do. Over the past few years as my confidence has grown my view of constructive criticism has changed from fear to embracing wholeheartedly. I'm now at the point where I'll purposely ask people to give me negative feedback on my code, design, games and in general so I can learn. If nothing else in this list resonates with you, I strongly recommend at least thinking on this point. I've met many programmers in the past (including myself) that either ignored criticism or actively fought it. There will always be better programmers than yourself out there and taking constructive criticism from these people is an excellent way of improving.

Continually Learning

I tend to go through peaks and troughs when it comes to reading and learning. During the middle 80% of a project and particularly deep within crunch I find I put my blinkers on and ignore most of the world around me. Once completing a project, and as I start on a new one I'll resurface and look at what I've missed in the previous months. I think learning new techniques, technologies and generally discussing game development with my peers is a great way of improving my skill-set and maintaining an optimal development velocity. I generally count GDC in this as I find I'm invigorated after each visit to SF.

Complete Difficult Problems

When time is short (when is it not) for a particular milestone I find myself shying away from difficult problems in favor of a quick fix or doing something different entirely. I've found this is often a sub-optimal solution as the problem is often not solved and inevitably crops up again later in the project. On a project-wide time frame the problem ends up taking far more time to solve than if I had simply taken the time initially to solve the original difficult problem at the expense of the milestone time frame. My solution to this situation is to allow enough padding in my milestone estimates so that I have time to dig deep into a complex problem when needed without worrying too much about the ticking clock. This is easier said than done, however focusing on the project-wide velocity improvement makes it an easy choice to solve complex problems as they crop up.

Cross Discipline

Unlike other software development I've done, game development has an extremely wide range of skills across a team. One of the most stark differences is between programmers and artists. With our different hemispheres at work programmers often band together and feel like they are working against the other disciplines in the company. This was the case for the first few jobs I had in the video game industry and it wasn't until I worked on a cross-discipline team that I realized how incomplete my earlier teams had been. Without a working knowledge of the other key areas of game development I was missing a large part of the big picture. Not until I sat next to an artist and watched them complete repetitive tasks for hours at a time did I realize that spending 10 minutes writing a simple tool for them would make their live much easier. It wasn't until our latest game that I worked closely with a sound engineer and learned how easy it is to build an extremely powerful sound system to rival many AAA games on the market. Spending time with developers from other disciplines is invaluable to both becoming a better programmer and improving the quality of your team.

Critical Thinking

I often fall into the trap of completing a particular task in a certain way as "that's the way it's always been done". It's not until I discuss my processes and thinking with other programmers that I realize there can be a better way. There are two main groups I find I get the most "aha" moments that often have radical changes to the way I do things. The first group is junior developers newly out of university. They will often be exposed to new ways of thinking or have simply thought outside the box to solve problems. The second group is developers from outside the video game industry. Test driven development is a great example of something I picked up from a web developer friend (and have since started evangelizing to other game programmers). Looking introspectively at your processes and development style at the end of a project is a great time to be critical of how you do things and see if you can improve.


Do you have other recommendations and thoughts on becoming a better game programmer? What techniques have you picked up over the years that have helped you grow?

Related Jobs

Avalanche Studios
Avalanche Studios — New York, New York, United States

UI Programmer
Avalanche Studios
Avalanche Studios — New York, New York, United States

UI Artist/Designer — Hunt Valley, Maryland, United States

Lead UI Engineer — Chicago, Illinois, United States

Lead UI Engineer


Timothee Garnaud
profile image
Good points here.

One good recommendation I can give is thinking of who will read the code. It is, I think, always a hard thing to do because of course you can read your own code instantly, but it's sometimes difficult to remember that other people will read your code to understand it or if you need help with it. It's a basic advice, but every programmer should try to make his code as readable for other as possible.

Alistair Doulin
profile image
Great point Timothee. It's easy to forget (particularly deep in crunch) that the creation of code is often the easiest part. It's not until weeks or months later that you go back over this code that the real challenge begins. Code reviews and pair programming are great ways of reducing issues in this area.

Enrique Hernandez
profile image
I'm still pretty much a noob, but I have a small tip for other noobs.

Before compiling, read what you just typed!.

When I program like 10 lines of code, I'm tempted to just compile it and run it to see what happens.

Usually there aren't any syntax errors so that's not why I do. I type something, then check to see the results.

Most of the times, what I had just typed was wrong somehow.

So lately before I press F5, I go back and read each line carefully, trying to understand what it does as if it wasn't my own code, and most of the times finding a problem much quicker than testing the game.

This won't work for certain people, or for certain games / programs. but it's working for me.

Sean Farrell
profile image
Actually, if you take a strict test drive development approach you hit F5 so often that you don't really need to read you code twice. You know if it works when you get a green bar. I actually integrated the test run into the build and you can only get an error free build if all tests passed.

But you are right, making code reviews really helps. The simplest form of code review is to go over your own code after a while.

As an advice, code beauty is more than esthetics. It really pays off if you open a source file and immediately see what the code does. And I don't mean reading the code, you should be able to understand the code at a glance.

Sean Farrell
profile image
This kind of sounds like: duh! The tips you give kind of apply to almost any discipline. But I think striving to get better, educating yourself and taking criticism will probably help you in any craft.

What I really think improved my programming was taking the time out to learn or explore areas that are completely unrelated to your normal tasks. On the way I learned Python, Ruby (on Rails), Lisp, functional programming, aspect oriented programming, garbage collection theory and much more. You probably will never need it but it shifts you perspective on your work. For example I tend to build more functional interfaces when the style amends itself to the problem.

It also helps to look around and learn the "management" theories. I know many developers that fail to communicate with their leads or peers and blame it on the evil waterfall development model or the process. Sure each project management approach has its strengths and weaknesses, but failing to know what needs to be done when is not the failure of the process. Obviously critically analyzing your process also helps solve many bumps on the road.

On thing that really helps me is I keep a private wiki. I note anything and everything. Its full text searchable and as a result I find stuff. The reason why I keep a private wiki on top of a project wiki is because some stuff just is to specific to my task and will only clutter the project wiki.

Mathieu MarquisBolduc
profile image
In my opinion, the difference between good and great programmers are maths. A lot of colleges teach maths in the first year, and never after, with the result that most programmers forget most of their math by the time they get their first job. And boy is it useful! Gameplay, AI, Physics, Rendering are all areas where a deeper math knowledge and understanding will allow you to find better solutions.

Thomas Engelbert
profile image
Teaching and learning are very close. There are even languages that only have one word for both (kinda like "Please learn me X"). Whenever you explain something to someone you're forced to think about it again. And your scholar(s) could maybe come up with questions you never asked yourself. All in all, aside from the happy face people get when they understand something, you get a great chance of reflecting on topics, maybe even show you that you had a few wrong assumptions, because you never thought it through enough or didn't dig deep enough.

And besides: This newbie you just explained what a function is? Yeah, chances are he's gonna save your butt one day by returning the favor. Most valuable lesson I learned at university.

Another thing is: Do it early, do it often: A few weeks ago, when I was sitting there with my roleplaying group, I realized space on he table would be a rarity. I had to put my laptop there anyways, as all my preps were on it, so I quickly wrote a dice tool. 10min to get a basic version and another 15 to style the output and add one or two little extra features. There are so many opportunities in live if you just look close enough... Use them ;)