Can You Really Write a Game Engine in C?

Programming in C has a lot of advantages but also some disadvantages like not being object oriented or functional. Although you can theoretically develop most programs with any language, is it really practical to write a Game Engine completely in C?

As a general rule you can write a Game Engine in C. There are C libraries for all the important parts of a Game Engine like Graphics, Physics, Window Management, Input and Sound. Because of the hardware related nature of C you can implement potentially missing library features yourself.

Quake III Arena
Screenshot of Quake III Arena, developed in the id Tech 3 Engine

In the rest of this article we will look at Game Development vs. Game Engine Development, already existing Game Engines written in C and some Ideas on how to implement a Game Engine in C yourself, so read on.

Can You Write a Game Engine in C?

As I pointed out in this article, C is portable, fast and hardware related and therefore very well suited for Game Development. Thus you can also write a Game Engine in C and this has already been done successfully multiple times.

It more comes down to the question if either you should just program your Game or a Game Engine and then your Game. The term Game Engine is more a concept than a real definition. The idea behind a game engine is that you can reuse all (or at least some) parts of a Game for more than one game and “just” replace the content.

If you just start (Game) Programming then writing a Game Engine first might be a bit of an overhead. In addition, you do not yet know exactly what you will need at all. Therefore writing the game first and turning the technology parts of it into an Engine later might be the better approach.

However, this is independent of the programming language.

Which Game Engines use C?

Nowadays most Game Engines use C++ because of the richer feature set, especially the native support for Object Oriented Programming (OOP) or the modern Smart Pointers that can act like a garbage collection. Therefore the most C Game Engines you will find reside from 1990s.

The most famous Game Engines come from the company id Software and are called id Tech. There are several iterations of this engine, mostly linked to the famous games that they were developed for.

Engine IterationDeveloped forRelease Year
id Tech 1Doom1992
id Tech 2Quake & Quake II1996
id Tech 3Quake III Arena1999
id Tech 4*Doom 32004*
C Game Engine Iterations by id Software

* During the development of the id Tech 4 Engine, the programming language switched from C to C++. The forthcoming iterations since then are all programmed in C++, too.

The other engines are not that well known and not used for big commercial products. The most notable ones are Allegro Opens in a new tab.and Build Engine Opens in a new tab.which You can find at their respective links.

How To Make Your Own Game Engine in C

A Game Engine can consist of many different parts. Below are some explanations of the most basic parts that you may need for your own Game Engine in C.

System Requirements

The first question (besides the programming language) should be the operating system(s) on which your Game is developed and where it should run. Are you just developing for windows or should it be playable on Windows, Linux, Mac and/or the even PlayStation?

C is a portable language but you have to compile an executable for all these systems individually. You also have to watch out for some system dependent stuff that you have to take care of in your programs (e.g. with conditional compiling).

The Game Loop

The most basic part of every Game and therefore of every Game Engine to, is the so called Game Loop. It is an infinite loop that checks the user input, calculates the actual game states and renders the output while trying to maintain a acceptable frame rate.

A Game Loop in Pseudo C Code would look something like this:

int main()
  /* Initialize Game */
  while(gameIsRunning) {
    gameIsRunning = hasGameEnded();      
  /* Shutdown Game */


This is the part where the focus is on the Player. Depending on your Game you would want to have keyboard, mouse, joystick or gamepad as input device. Each of these devices is a piece of hardware that you have to access through its appropriate drivers. There are, however, libraries that encapsulate this for you and give you wrapper functions in order to access it.

Putting this into a Game Engine makes sense because every Game needs input and the devices are more or less fixed, so the technical aspect stays more or less the same. The things that changes are the reaction of the Game to the inputs from the Player.


Before you can think about rendering and animations you first have to have a window (fullscreen or not) where you can show your graphics in. This depends on your chosen operating system and the libraries you are going to use. Examples of portables libraries with window management would be GLFWOpens in a new tab. and SDL2Opens in a new tab..

When it comes to graphics there are a ton of options and libraries that you can choose from. For more advanced (and even 3D) graphics you could use OpenGL which is also available for C programmers. If you just want to have simple graphics than maybe this would be an overhead.

For starters, the SDL2 Library would be a decent choice. You can find an example for the usage of SDL2 here. It is written in C, portable and easy to use. You can even use it in conjunction with OpenGL if your Game should go that way later in development.

Other Aspects of a Game Engine

Depending on the Game(s) you want to write, there are many more aspects that you should consider. In almost all cases you will need Sound and SFX (Sound Effects) and at least some form of artificial intelligence for enemies or the game world. You can read about programming a sophisticated AI in C in this article that I wrote.

In more action oriented games you will need physics (and maybe complex calculations for this) and animation. All of this and more could be part of your next Game Engine in C.

Marco Lieblang

Professional Programmer since 2003, passionate Programmer since the mid 90's. Developing in many languages from C/C++ to Java, C#, Python and some more. And I also may know a bit about Assembly Languages and Retro Systems.

Recent Posts