Dungeon Data
A blog about game development, game design, and game mechanics

Dec 26, 2018 ∙ 7 min read

How to start coding your own game?

Understand the development landscape for indie games

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

Let’s do a quick overview of the main technical decisions you need to make for doing a game—we’re going to put more detail in each one of those next. First, decide if you’re taking the two dimensional (2D) or three dimensional (3D) road—most technical decisions depend on that choice. My suggestion is to keep things 2D, it’s a more straightforward group of problems that will allow you to put greater focus on the design of the game mechanics. After that, we have the game engine problem, for a 3D game you should stick with a good engine, but for a 2D game, it’s manageable to skip user interfaces and go directly into code—in the end code is the most malleable and powerful medium for doing a game—a focused and optimized experience is more achievable when coding a game directly than when using a game engine. Lastly, we have the coding languages and libraries option. For small and simple games that you want everybody to play with very little friction go with Javascript and the browser. For more complex games with a path for monetization, pick up C++ and SDL if you’re a Mac or Linux user, or C# with Monogame if you’re a Windows user.

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.

Game engines

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

For directly programming games there are three main options. Each one is made of a programming language, the main gaming libraries available for it and the publishing platforms it supports. The first option is Javascript on the web browser. It’s more effortless to start doing a game for the browser; there’s no software to download or compilers to run, an HTML file and a browser is all you need. The browser is a powerful graphics engine, it has APIs for loading data, loading images, rendering graphics in multiples ways and dealing with keyboard and mouse input. The best way to render and manipulate games graphics on the browser is through the Canvas 2D API. The browser is also a highly accessible platform, everybody who has a computer and internet can access a game published on the web without needing to download or install anything. The main problem with the browser is performance. Because the game run inside of it will never run as fast as if it was executed directly by the operational system or a game console. The browser is not an option for computational intensive games.

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.

  1. PC, Mac, iOS, Android, PlayStation 4, Xbox One, and Nintendo Switch.
  2. The spiritual successor of Microsoft XNA. I’m not a windows guy, neither I knew about XNA before, but there’s seem to be plenty of love for it.
Receive new posts on your e-mail:
No spam. Unsubscribe at any time.

What's pixel art and how to start doing it?

The beauty of constraints in gaming art