You Should Study the Old Masters

Introduction

There is a practice which is normal in drawing, music and other arts, but I rarely see in game development: recreating existing art. It’s commonly known as “Master Study”, presumably because you’re studying from the work of a Master. This is an amazing practice, because you’re deconstructing the piece into its components. This helps you understand how to make similar pieces by helping you understand the process. But more importantly, it will help you intuit the reasons behind decisions that were made creating it.

This is a very common advice given to every aspiring artist, but it also works for game developers! But nowadays, I barely see it. When I was younger, there were tons of Breakout clones. Every game developer who wished to learn more and get better made one and uploaded it onto their blog (another dying relic of a bygone era).

However, in this age, when there are more resources and it’s a lot easier to get into game development, this practice is gone. Why?

The Trap of Accessibility

Accessibility to game development is amazing! Unfortunately, this is a very sharp double-edged sword. Modern off-the-shelf solutions often make it easier to do start developing; few clicks and drags and you essentially have a functioning prototype. In this case, it’s easy to become ambitious and begin working on a more complex game, but the side-effect is skipping parts of the learning process, which can be a major detriment. I’m sure you’ve played a game which is fun at it’s core, but it has enough drawbacks that stop you from fully enjoying it. Whether it’s stuttery (or even consistently bad) performance, jank gameplay or opaque control schemes, these are all signs of inexperience with the basic foundation (or managerial meddling, but that’s something you can’t improve by yourself). A lot of great games are made similarly to how a partially blind chicken finds seed: pick a direction, try it, hope for the best. Modern games contain many intricate and interconnected systems, which may appear arbitrary or random. But the truth is that they were not built overnight, they were incrementally improved. So, in order to better understand them, it is neccessary to break them down into “simpler shapes”.

Iterative improvement is key

In the before-times, starting development on a new game was more involved. As a result the games were incrementally built upon, with each game expanding upon the previous. If you know how to make Pong, it’s a small step to Breakout. If you know how to make Breakout, you’re just a few lines away from Space Invaders. If you know Asteroids and Space Invaders, it’s easy to make Galaga. This pattern even continues into more complex games: Quake wasn’t built from nothing, its lineage starts at Hovertank One, then goes through Catacomb 3-D, Wolfenstein 3D, and finally Doom.

But we today have one major leg-up over developers of yore - these games already exist. We don’t have to spend a lot of time thinking about new inventions, we can read up on existing ones. However, reading is only the start, implementation is the important step which helps with internalising the concepts. And once you have recreated these features, putting them into your future games becomes nearly trivial! Please, don’t let me stop you from re-inventing the wheel. If you’re interested in how a game might’ve turned out if a feature was implemented differently, or if a game had a completely different feature, feel free to experiment! These projects can also be a very valuable learning resource. Once you have simpler games to build upon, experimentation becomes a breeze!

Begin Building!

If you’re reading this, you’re likely already working on a game, and it probably has many of the modern systems. I’m not telling you to scrap your game and build it from scratch. But I will suggest you allocate time for side projects.

For example: every weekend, I work on simple games that contain features I wish to explore in-depth. At the time of writing that’s axiometric projections, more specifically trimetric projections like you would find in the original Fallout game. (At the time of editing, it’s CPU rendering, kind of how Wolfenstein, Doom and Quake did it. I’ve made a simple-to-use C library out of it.)

Tim Cain calls his side-projects “Coding Toys” and he does them whenever he has free time.

The side-projects don’t have to be fully detached from your main project. You could always make a smaller game that focuses on just one piece of your game. For example: if you’re making a twin-stick shooter platformer, you can take the ‘platformer’ idea, and make just a simple platformer. Refine your physics engine (or your usage of a physics engine library), make sure the movement feels good, that you can perform various tricky movement. It’s going to be a lot easier to do it, since you only have to focus on one mechanic, and have no distractions caused by other mechanics. Once you’re happy with it, re-implement it back into your main project. It should take you only a nugget of time the first implementation took!

What you use to make your side-projects is less important than just making them. But I like to keep it as lightweight as possible, and avoid pre-existing general purpose engines. I prefer libraries like SDL, or raylib (which I wrote an article about), because they relieve me from worrying about the operating system specifics, but also don’t do any of the game loop for me. The perfect Goldylocks zone for learning!

Thanks

Many thanks to Alex Reed, Duka, BlackySparky, and No Need, for providing feedback and proofreading the article!