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.
