How to start coding your own game?
Independent video games, or indie games, are games done by individual developers or small teams without the support of publishers. The key is self-sufficiency, the solo developer being able to solve by itself all the problems associated with making a game.
The bar of entry is as low as it has ever been for an indie game to be available in the leading game platforms1. That’s because the tools and the technology are in place to make game development accessible for those who want to put effort into doing it. Several changes contributed to this state of affairs. First, professional workstations are not a necessity anymore, personal computers have become powerful enough for handling game development—you can develop a game with the same machine you are using to surf the web now. Second, professional game engines, libraries, and publishing rights are available for free, gone are the days of expensive licenses. Third and last, digital game stores annihilated the cost of publishing and distribution. There’s no more upfront payment in licenses to be able to use professional tools, or upfront payment in publishing to be able to distribute a game. Technology and scale of sales allowed this cost to be transferred into a percentage of each game sold.
Overview of your choices
Two dimensional or three dimensional?
Now let’s go down into more details about the previous options. When setting off to make a game, the first technical consideration is as to whether it should be 2D or 3D. When taking the 2D route all the assets of the game can be images, and those assets can be produced in any image editor software. Even better, it’s possible to embrace the aesthetics and limitations of the games from the NES and SNES era and do assets with a limited pixel and color count, the so-called pixel art. By limiting yourself, the focus becomes doing great solutions not solving technical issues. By simplifying the technical challenges of the asset production it’s possible to put more effort on the game mechanics, and how the game plays.
For a 3D game, the asset pipeline can get much more complicated; everything has to be modeled in three dimensions using specialized software. Textures, shaders, rigging, and animation also need to be developed for the models. Each one of those is a specific problem that requires a particular tool, and for those tools, the industry standard is not available cheap. Apart from assets, 3D games also have more technical challenges in rendering, physics, and game logic. Those problems are more manageable in 2D games, and good solutions are more readily available. While 3D is a unique and powerful medium, great game mechanics don’t depend on it, and a well designed 2D game will be much better than the average 3D game.
The next consideration is whether to use a game engine. Today, the three main game engines are: Game Maker, Unity 3D and Unreal Engine. With 3D games there’s no much of an option, the technical challenges are such that a good game engine is practically a must for a solo developer. But for a 2D game, we can better ponder its pros and cons. Modern game engines simplify the execution of common patterns by providing graphical interfaces for their setup and configuration. They promise the ability to be able to do a game without knowing how to code. They also abstract the difference between gaming platforms; they can export games for multiple platforms from the same project.
But not everything about a game engine is positive. Game engines are heavy applications that need more computer resources and screen state. The code they produce is generalized across platforms and usages, so its performance suffer from long loading times and big files. Cross-platform support in game engines never comes for free, the quality and performance of the game won’t be the same as a dedicated solution. Last, when learning to use a game engine, you’re learning to use its abstractions; when learning to code, you’re learning to build your abstractions. It’s the difference between being a cook and a chef.
Programming your game
Next, we have C++ with the SDL library. C++ (spelled c-plus-plus) is the language that operational systems and game consoles are written with. High performance is guaranteed, but the cost is a more complex code with more low-level maintenance. This option can be developed in Windows, Mac or Linux; but Mac and Linux offer a more straightforward experience. The SDL (Simple DirectMedia Layer) handles window management, keyboard and joystick input, rendering sprites and others. SDL can target games for Windows, Mac, Linux, iOS, and Android; to do that it wraps up the underlying target implementation for each one those systems into a common higher level API. For example, on windows, SDL wraps its calls around DirectX for executing the render, on Mac and Linux it uses OpenGL.
The SDL library does not offer out of the box support for game consoles, but it’s possible to do ports. The problem is that game consoles don’t disclose the low-level APIs of their systems; only registered developers can have access to them. To be a registered developer you need first to prove yourself with a working game. When porting to a console, it’s possible to change the underlying implementation of the SDL functions so that they call the proper native console APIs.
Lastly we have C# with MonoGame. C# (spelled c-sharp) is a coding language developed by Microsoft. Being a Microsoft language, windows machines offer less friction to work with it; but it’s also compatible with Mac and Linux. For C# we have Monogame2, a library for handling the basics of window management, inputs, render, etc. Monogame can officially target all the main game platforms; but because console APIs are a secret, you need to prove that you’re a registered developer with a specific console before being able to access the private target code.
Apart from all those decisions is good to always keep the focus on the game mechanic, how it plays. When solving technical problems don’t reinvent the wheel, keep it simple, prototype often and quickly.