How Long Does it Take to Learn Game Programming?

Nov 30, 2011

A friend asked this question the other day. To peers nearby with more programming experience than him, it seemed like a silly, almost nonsensical question. Whether or not that’s true, explaining why someone would think that sheds light on qualities of programming that may be invisible to someone newer to it. It’s a useful question either way.

Game programming is not something someone goes from not knowing to knowing, in the same way that someone goes from not knowing how to drive to knowing how to drive, or from not knowing how to read to being able to read. Even disregarding other purposes of programming, looking specifically at programming for videogame creation, there is an enormous range of potential outcomes, and many different metrics by which someone’s work might be evaluated.

The question is a bit like asking how long it takes to learn how to paint a picture, or how to play an instrument. Getting set up and putting a paint-covered brush on canvas or producing a musical note can probably happen on day one, but after that there are people who devote decades of their lives to becoming better and/or more versatile at these tasks. Then there’s everyone in-between, from people a few weeks or months in (able to poorly mimic the prior work of others), to those a few years in (able to effectly mimic and perhaps personalize the prior work of others), to those several or more years in that begin to identify with the art, striving to excel in either classical execution or exploring to discover a distinctly personal style.

Game programming is similar. Getting a development environment installed and configured to turn sample code from a book or website into a runnable application can probably happen on day 1, or at least within the first few days depending on the amount of troubleshooting needed. Once that works, there are a few fundamental concepts and new vocabulary words to pick up, then a bit of puzzling over example code to make sense out of why it behaves as it does. This is typically followed by being able to modify example code to achieve slightly different results, increasingly so until someone’s familiar with enough patterns and basics to start building something on their own. Even still, that first something will usually be quite familiar to previous dabbling, more a partial mash-up of ideas than a project made from scratch, but there’s nothing wrong with doing that to gain practice.

From here, there are countless directions in which to grow in the art of game programming. Someone might focus their energy on writing well-documented, easily understood code, learning about best practices to work more effectively with one or more other programmers on a team. Such skills are essential for career programmers on large teams, although their importance among solo and hobby developers varies so long as they are able to produce the results they desire. Someone could become a specialist in highly technical details or specific problems that other programmers count on libraries or engines to solve, learning how to write better network code, graphics rendering/effects, memory management, custom file formats (such as levels, packed images, etc.), or ways to address common issues involved in making in-game artificial intelligence. It’s also an option within the repitoire of a game programmer to delve into hardware interfacing and the construction of custom input or output devices, to make games utilizing new types of controllers (think about how games like DDR and Guitar Hero might have started) or unusual forms of output (tactile feedback, external LEDs, etc.).

Then there is the matter of learning more programming languages and development tools. Occasional shifts in technology – along with an acquired sense for when it’s appropriate to switch between competing technologies – can feel like setbacks at the time, but in the long haul they can save a lot of time and effort if done wisely.

Also like painting or playing an instrument, some people will find that they immediately feel somewhat natural about it, or seem to achieve presentable efforts earlier in their exploration of the form, while others may need a bit more time to fiddle and experiment before feeling as comfortable. How long someone takes to feel like they have a handle on it isn’t necessarily a sign of how much they’ll accomplish with it though – like any creative endeavor, persistence and plenty of practice will gradually outpace others that don’t work at it.

Any game programmer is also able to stretch themselves too thin or to focus, either taking on a task at the edge of what they can keep organized and directed through to completion, or, alternatively, doing what they have a lot of practice at doing well. An inexperienced programmer may technically be able to make an RPG from scratch, but it will be a very bad one by historical standards. Likewise, a very experienced programmer can still make a simple breakout-style or classic tank game of the sort that an inexperienced programmer might be wise to take on, but it could likely be done by the expert in much less time, with (virtually) no crash issues, and/or at a much higher level of overall polish.

The last similarity to painting or playing an instrument is that, especially at a hobby level for personal enrichment and enjoyment, game programming is something that anyone with enough patience can learn to do. Not everyone that paints is going to make works of art that sell for huge sums of money – very, very few will – and likewise the majority of people that play an instrument will likely never do so professionally. We’re quite used to painting and instrument playing being a healthy part of life without needing to see careers defined by them, for example hanging up paintings by our relatives around the home, or playing guitar in the company of friends. I’m eager to see the generation after ours find it increasingly normal to compete in the freeware videogame made by a close relative, or to hang out on weekends playing a videogame made by one or more of those friends playing.

Of course if someone does have a professional interest in game making, whether at a company or going it alone, they are much more likely to build momentum and relevant skills by creating videogames as a hobby than by simply talking and thinking about it.

This goes back to the opening question. Professional videogame programmers – including lifelong programmers with world-renowned accomplishments in the videogame industry – are still in the process of learning game programming, in the sense that they are continually learning new practices to make the most of new technologies. Someone is never done learning game programming until they are completely done with programming videogames, since the very act of programming videogames always involves some experimentation, digging through APIs, and solving problems that are new to us (even when said problems have been solved by someone else, some other way, some other time before, for all but very hardest and most general of problems we can often solve them on our own in less time and effort than it would take to dig up and adapt someone else’s solution).

But, roughly speaking, I’d offer the following estimates (remember that this is time to learn how to do something, not the time it takes to do it once learned) –

Recompiling and running existing sample code: 1 day.

Being able to tweak someone else’s code: a few days, to a few weeks.

Being able to significantly add to or change example code: a few months, to a few years, depending on the complexity of code being altered, or the size of the change being made.

Here there is already a massive dovetail of differences – adding a weapon to someone else’s 2D sh’mup example code is a very different undertaking than adding network play to an open-sourced single-player 3D game. To continue, though –

Being able to write a crummy game from scratch: a few months.

Being able to make a decent game: 1-3 years of practice.

Ability to create something a stranger might like: 2-5 years.

Ability to create something strangers might buy: 5-15 years, though obviously varies based on the price, the strangers, the project, the presentation, and a million other factors outside the programming itself.

Note too that due to the team nature of game development beyond the smallest scale, it’s somewhat possible to “import experience” by partnering with someone that has been doing it longer. Working with someone that has more practice with videogame creation can improve the overall quality of work coming from everyone on the team, due to the added ability for the team as a whole to detect and avoid common issues, to employ tried-and-proven strategies that have worked out on previous projects, and to build while accounting for how the big picture will need to come together by some fixed date in the future. When working alone, by comparison, those skills typically need to be learned cumulatively by working first on simple enough games that the light at the end of the tunnel is visible from the moment the project starts, then gradually incrementing project complexity in a way that the lessons learned from past projects can be built upon for the next.

In closing, here’s a fine comic about the “Teach Yourself C++ in 21 Days” books, and another software engineer’s excellent overview of the time and process involved in learning how to program.



I train beginning-intermediate developers worldwide via Gamkedo.


Subscribe by e-mail to receive an update every month of all new HobbyGameDev articles, videos, and game development resources.



3 Comments

  1. athile says:

    I think it’s also important to ask why the person is asking the question.

    Is game programming a means to an end, or is it something the asker is interested in as a skill in itself? In other words:

    Do you want to learn game programming in order to have sufficient skill that you’d be confident that you could make almost ‘any’ game / feature of a game out there? Or do you want to learn game programming in order to make a particular game?

    Your post above does a good job addressing the first question, so I’ll primarily look at the second.

    The second question is an interesting one because I think numerous people who ask, “How long does it take to learn game programming?” often really want to know “How long would it take me to learn how to make the game I’ve been dreaming of making?”

    A good starting point, if that’s the asker’s real question is the fact that making a good, popular game doesn’t necessarily require any programming (e.g. think of the Magic the Gathering card game).

    If the focus is on making the game – not learning the technology – a person only needs to learn the absolute minimal amount of programming to achieve their goal (yes, there are corollary risks to that, but ignore that for the moment). If the end-user experience is of a good, fun, stable game it doesn’t matter how “inelegant” an experienced programmer might find the code internals or how many third-party libraries and tools were glued and stitched together to make it happen – as long as the end result is good, fun, and stable (i.e. the goals were met).

    I think this is a valuable thing to remember because it forces the asker (especially in the case of novices) to think about whether they really care more about making the game or learning to code.

    The better someone understands their own goals, the more likely they are to achieve them. A novice ready to embark on the dream of making a MMORPG might more quickly realize that avoiding coding from scratch and pursuing SDKs, game makers, and other such tools is the quickest (albeit very long) route to their goal. On the other hand, if they realize they really want to learn low-level graphics code, they might spend their time contributing a new effect to an open source game. Either is probably a better approach than rather than starting from an empty main() function with the next World of Warcraft in mind.

    As with anything, before estimating how long it takes to do something, I think it’s important to ask *absolutely* clearly as possible define what the end goal that defines success really, really is. Once you know the goals with precision, the answers become much more clear.

  2. Mark Ivey says:

    Something I find helpful is to examine the experience and size of the teams behind games I’m familiar with. Especially interesting is looking at student entries to the IGF. These are usually made by teams of 3-6 (I think?) students, so they have been studying programming for a few years. These are much better measuring sticks than games like Minecraft (Markus Persson has been programming for decades), Limbo (team of 9 pro developers), World of Warcraft (hundreds of pros).

    Once you can program a bit, an insanely fast way to improve is to do pair programming (2 people at 1 computer) with a more experienced programmer. Finding someone willing to do this with an inexperienced programmer will be hard, but if you get the chance jump on it! It will be worth it!

    Depending on your goals, even knowing a little programming can be helpful. Game designers who can do some programming are able to do some things on their own without waiting for the programmers…this gives them an advantage over game designers who can’t program. Same with art…if you know some programming you’ll be able to do things other artists can do.

  3. PowerWielder says:

    Kirk: “Spock! You lied!”
    Spock: “I exaggerated.”
    Kirk: “Exaggerated?”

    In this article: Weeks became months and months became years.

Leave a comment

Comments Form
  • Your email will not be used for any purpose other than to update you in replies to your comments. Your website address will be shown as a link from your name with your comment. Your profile photo is auto-magically provided by Gravatar.

All contents Copyright ©2014 Chris DeLeon.

Site production by Ryan Burrell.