From OpenLieroX Wiki

Jump to: navigation, search

I often stated that game development is a great way to learn coding. Despite the advertisement to source code contribution to OpenLieroX, there are indeed really a lot of good reasons why you can learn a lot by game development. And not only about coding itself, but also about advanced algorithms of various sorts and much more. I will present a list on this page.

If you compare it to the learning value of working on any tool or whatever other application, in most cases you will learn more by developing a game because games include a very wide area of technics while most other applications are mostly very limited in the amount of theories and technics involved.


Computer science


Of course the most basic part is the coding itself. That includes the programming language and getting used to it. Learning a programming language is not only learning the syntax and semantics - it is also about how you do it right.

In a medium/big sized game (and often even in small), there are often a bunch of different languages used together. In the OpenLieroX project, you will find applications of at least these languages:

  • C++. Most of the game and its core is written with it.
  • C. Some rare parts of the game are C code.
  • Assembler. Some performance critical parts of the game are written in Asm.
  • Lua. We use Lua for ingame scripting.
  • Python. The dedicated script and a few other scripts use Python.
  • Bash / Zsh. Many scripts to do some management (like preparing release packages and distributing them) are using either Bash or Zsh.
  • CMake. Our build system uses it.
  • PHP. Our homepage uses it and also the reference implementation of the HTTP masterserver.


Knowing programming languages is not enough. Most languages also come with their own standard library but in many cases, you also need some external libraries or frameworks.

Here a list of libraries that the OpenLieroX core uses.

  • C standard library
  • STL
  • Boost
  • SDL. This is for initialising the window/screen, doing graphics operations and handling user input.
  • SDL_image. For some more image formats.
  • GD. Another lib for various image formats and image handlings.
  • HawkNL. For networking (TCP/UDP).
  • zlib. Compression.
  • libzip. ZIP support.
  • libxml2. XML support.
  • libcurl. HTTP support.
  • OpenAL. For sound.
  • ALUT. For initialising the OpenAL environment and WAV support.
  • libvorbis/libogg. For Vorbis OGG support.

For the other languages, we mostly restrict ourself to the standard library.

Cross platform

If you don't want to restrict yourself to only one platform (like Linux or MacOSX or even Windows), you need to write your code in a way that it is mostly cross platform.

One important point is that the dependencies and libraries you are using are all also cross platform, i.e. available for most or all platforms. If you take a look at the list of libraries we are using, you will find that this is mostly the case.

In practice, this is not all. You will face problems that some things will just behave and work different depending on the platform. Also the platforms themself are by purpose somewhat different and handle things differently. So you will still end up in having different solutions and code paths in these cases for different platforms.

By working on a cross platform project like OpenLieroX, you will learn how to deal with such problems. We have a special article about this topic: Port OpenLieroX to another system

Architecture independence

This is somewhat related to cross platform. If you don't want to restrict yourself to one architecture (like x86 32bit) you need to write your code in a way that it is architecture independent. As some platforms (like iPhone or Playstation) are naturally running on a different architecture (like arm or ppc), you are often forced to write architecture independent if you want to support those.

OpenLieroX should run on pretty much every architecture. Problems you are facing are for example about big/little endianness and 32bit versus 64bit.

Protocols and file formats

In many cases, knowledge of protocols and file formats can be usefull, even if a library is doing all the handling for you. In some cases, you even need to implement some basic support for yourself.

Here a list of protocols or file formats you most likely will at least get a bit in touch with at OpenLieroX:

Of course, OpenLieroX introduces also some own protocols (for networking) and file formats (maps and mods).

Algorithms and data structures

You will need and learn all of the basic algorithms and data structures. That are at least:

  • linked lists, hash maps, vectors, stacks, queues, sets, trees
  • sort, search, ...


When writing graphics related code, you are dealing with a wide range of topics, many of them being mathematical. Despite the mathematical part, you are often also dealing with performance problems and optimisations because this is often the most performance critical part. So you need to learn how to optimise your code and at the same time keep it maintainable.

Depending if your game is 2D or 3D, the type of mathematics you are applying differs a bit (and probably 3D graphics need even some more deep knowledge of Linear Algebra) but there is also a big intersection.


You learn about the basic calculation and principles how to calculate the sound modifications when you want to get a 3D sound experience.

Artificial intelligence

The most obvious application of artificial intelligence in games is the computer enemy. AI in games and AI in general is really a topic for itself. Maybe the biggest and most important of all things which you learn by game development but that is up to your own focus.

Also, the subtopics of AI you can apply in a game depends a bit on the type of game. But in most cases, that are at least:

OpenLieroX has some advanced searching functions (sort of A* in an almost continuous space) and a bunch of hardcoded strategies and plans. We are planning to integrate much more soon, like a self-learning bot (based on neural networks) and also a genetically engineered bot. Also some basic support of natural language processing is planned so that the bot can chat.

Game theory

Game theory deals with theoretical questions about strategies and states of games. If you want to answer questions like if there is a strategy for your game where you always will win - that is game theory.

Game theory also matters for some of the artificial intelligence applications.


If you want to support some sort of multiplayer over a network (like the Internet), you need to know a bit about networking. It is not just about encoding and serializing your data and transfer it somehow over network. A game often needs very low latency. You are usually dealing with problems like:

Operating systems

How operating systems work is also a whole huge topic for itself. You will scratch many parts of this because a game often has many low level parts in its code where you must know some basics about operating systems. Esp, that is:

Memory handling

In case you need to handle with huge amounts of memory, you need to know about memory optimisations and how a computer program usually handles the memory allocations on a low level.

We at OpenLieroX esp. considered once to apply parts of jemalloc.

OpenLieroX also can be build as a special debug version with our own malloc implementation. (See file memstats.cpp.)

Parallel computing

Parallel computing is where many computations are done simultaniosly in parallel. Games often need to make a lot of very heavy and intense calculations. The trend of computers is to have multiple CPUs (or cores) instead of having a single one. To use them all, it is mandatory to write your code in a way that several parts can be executed in parallel. Despite the need for it, it also often leads to more clean code (if you do it right).

So, what you will learn is how to do parallel computing in general. That is both theoretic knowledge and practical knowledge. In the practice, parallel computing is often solved via multiple threads, i.e. multithreading. The interesting parts are about how you synchronise your threads and how you communicate your data from one thread to another in a safe way.

Version control

You will learn how to work with some kind of version control system which manages all your source code files and often also other resources of your project. It will keep track over all changes in all files and will make it possible that multiple people can work on the same code. With the history of the changes, you will be able to see what person has done what changes and you can hunt down bugs to specific changes. You can also see what person has written which parts of a source file and thus ask him about some details.

Such a system is even very helpfull and nice to have if you work alone on a project. And it is absolutely mandatory once you work in a team.

In OpenLieroX, we use Git - a very powerfull distributed revision control system. Learning Git is really a whole topic for itself.



A game usually needs graphics, sounds, levels or other media. Those need to be created and designed.


Depending on the type of game, you need a story.


A project of the size of OpenLieroX needs teamwork. Various people doing various different tasks (coding, designing, distribution, support, testing) need to coordinate. This is even more important for the coding which is the biggest of those tasks. Once there are multiple people working on the same code, they need to coordinate. The source code version control management system is very central for this.


A project like OpenLieroX also needs some noteable time for general mangement and other things. Here some points:

  • Issue/bug tracking
  • Releasing (prepare the packages for major platforms and distribution)
  • Documentation about interfaces (levels, mods, scripting)
  • Support for players
  • Development discussions
  • Version milestone planning