DEV Community

Albert Zeyer
Albert Zeyer

Posted on

Why game development is a great learning playgroung

#programming #gamedev #beginners

(This is copy of the article from here.)

Game development is a great way to learn coding and computer science in general. 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. 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 techniques involved.

Related resources

Programming languages

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.

For example, 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.

But when you are just starting with coding,
for a simpler game project, any single language is enough.

The programming language doesn't really matter that much for learning. Don't be scared about C++. It isn't really that complicated. Or maybe Rust, or Nim, or some of the other newer native languages. Python is of course also a very good starting language.

Libraries

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
  • 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, mostly only the standard library is used. (Python has a "batteries included" philosophy.)

Also see this list about useful game libraries.

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 from above, 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 game like OpenLieroX, you will learn how to deal with this. When you use the right libraries,
this is not that much of a problem.

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 useful, 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, ...

Graphics

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.

User interface

The user interface is e.g. the menus, the buttons, the dialogs, etc.

Audio

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

Physics

Most games need some kind of physics engine to simulate physics of the game world. For simple games, this is usually often kept very simple.

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 general, a lot of different AI topics can be applied in games. (The actual topics you will apply in a game are usually much simpler though.)
For example:

OpenLieroX has some advanced searching functions (variant of A* in an almost continuous space) and a bunch of hardcoded strategies and plans. There could be much more, like a self-learning bot (based on neural networks) or a genetically engineered bot. Or some basic support of natural language processing 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.

Networking

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. See the malloc() function,
or jemalloc (popular efficient malloc implementation).

OpenLieroX provides a build with a custom malloc implementation for debugging. See file memstats.cpp.

Parallel computing

Parallel computing is where many computations are done simultaneously 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 helpful 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 powerful distributed version control system.
Learning Git is really a whole topic for itself.
You might want to use a platform like GitHub to host your code and to make it available for others.

Testing

You might want to setup some kind of testing for your code, e.g. unit tests or integration tests.

Continuous integration

Continuous integration is a way to automate the testing and building of your code.
E.g. GitHub supports this with GitHub Actions.

Debugging

You will stumble upon bugs and problems in your code. You will need to learn how to find and fix them. This is called debugging. Fortunately, there are many tools available to help you with debugging, such as debuggers. See here for a list.

Profiling

Your code might be too slow (or hang) or use too much memory.
Profiling is a way to find out where your code is slow or uses too much memory. There are many tools available to help you with profiling, usually called profilers. See here for a list.

Media design

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

There are also many existing assets available online
(see this list).

Story and game design

Depending on the type of game, you need a story.
Game design is a whole topic for itself.

Teamwork

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 can be 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
(see version control)
(but this is useful even if you are working alone on a project).

Project management

Once the project is getting bigger, you need to manage the project, e.g. keep track of the tasks, bugs, features, etc.
Platforms like GitHub provide some tools for this
such as an issue tracker.
Project management is again a whole topic for itself.

Where to start

See Coding Game Intro. You could start some own simple game project
(some ideas),
or take an existing open source game and modify it
(examples), or contribute to an existing open source game project.

Reading code of existing games

To be able to do something useful with the code, it is very helpful / mandatory that you have a rough overview over the code. Many projects have an overview document. Also see here.

Contributing to an existing project

Many projects have a document like CONTRIBUTING.md describing how to contribute. It usually also makes sense to speak to someone from the project first. Also see here.

Setting up a development environment

For a beginner, this is often the most complicated part.
It is often not straightforward how you setup an IDE / editor / compiler to build the source code.
This is somewhat silly but you have to get through that.
(The compiler will convert the source code into an executable binary; on Windows, that is an EXE-file.)

The IDE is the editor where you edit the code. In theory, you could also use a simple text editor; however, an IDE will be mure more helpfull and easy to use.

In some cases (like MSVC), the IDE is bundled together with the compiler. In some other cases (on Linux), they are highly separate and independent from each other. That means that setting up the compiling is in some cases (like MSVC or Xcode) the same as setting up the IDE, in some cases (like on Linux) independent.

However, compiling the source code is the most important thing you need to be able to do. You cannot do anything if you are not able to do this.

Projects usually provide some documentation how to set up the development environment.

When you start a new project, it makes sense to see some simple examples how to set up the development environment.
Usually you would create a new version control repository, which is then an empty directory, and you would put your stuff into it. Also see here.

It might also make sense to setup some generic playground environment to test minimal ideas, code snippets, etc.
See here.

Top comments (0)