How a game engine is made?

This article will explain how a game engine can be made. Mostly, it will explain this from retroperspective, and compare old game engines and modern game engines. This is not a tutorial. It will, for example, not explain how to render polygons with a random 3D accelerated API (i assume you can google a glvertex3f tutorial for yourself). It will losely discuss how a real game engine can be made, what parts a game engine has, and how these part work and interact. You dont have to know any programming skills to read this article, you can totally enjoy it as some sort of documentary movie.

The last game engine i have created is Maker4D (its free for both personal and commercial use). I have made various game engines in the last 20 years. Some of them was not more than a callable function-set, some of them was genre-specific game engine with game editor. I made my first game engines for DOS when i was an elementary school kid, using BASIC. Later, i moved to Windows, later i have learned the C programming language and OpenGL, and in this decade, i have discontinued using OpenGL and switched to software 3D rendering. Some of these engines were available publicly, some were made for request, some were never released.

I will probably not develop game engines or 3D engines in the future (althrough i still maintain Maker4D), as i have discontinuing this business due to multiple factors. One of them is profitability (people dont buy game engine any more, and if they do, they use the popular game engines of this era). Another factor is personal (i dont enjoy gaming and 3D any more). I dont like the new generation of games nowdays, so i dont even have any kind of bond with them. Therefore, i am fine writing this article, as giving out secrets would not hurt my business at all.

(illustration: Chrono Cross)

What a 3D engine is?

The 3D engine is the core of a game engine. The 3D engine is a separate and independent code block. The 3D engine is a monolithic method, that allows you to display textured 3D polygons. The 3D engine also manages this content for you. For example, lets see you have a LoadModell function, that can accept an ID (integer number), and a file name. The LoadModell function loads the file from the disk (for example, it loads the obj file). Then it decodes it, and places the raw data into arrays. For example, you have an array for all of your models like float ** mymodellpolygons. Then the LoadModell function, when you load the potato.obj as ID 2, then it populates this as a malloc-ed memory block like mymodellpolygons[2]=(float*)malloc(numberofpolygons9*sizeof(float)). It stores the polygon number, the uv map as well. It also loads the textures, saves the texture bitmap similarly in memory, it also saves its X and Y size.

The 3D engine can also position this model in the scene, or rotate it. For example, you need to make functions like ModellLocation(ID, x,y,z). Modell rotation, modell rescale, modell color, etc, will have different functions, and modell deletion will also have its own function. You can see, that managing the 3D scene is a very simple task. A simplistic 3D engine can be made from a few 1000 lines. You will also need camera management (that will have x,y,z and rotation as well). Once everything is done, you will need a render function that displays all the 3D scene on your screen, going through every modell, and calling a 3D api (or your own software renderer) to display the content.

If you need animation, that will be much harder to implement, and also you must do input and output, which may vary bethwen operating systems (interacting with touchscreen, joystick, keyboard, etc). In my case, these parts are also part of the 3D engine, usually terrain generation and collision engine is also part of the 3D engine. Some people have an independent collision engine and physical engine, which i never separate from the 3D itself to keep the things more simple. The 3D engine may contains functions to dynamically generate content, such as, generating spheres, boxes, or even more complex geometric shapes. Particle engine can be also part of the 3D engine.

Basically, the 3D engine contains all the important functions in a monolithic manner to load, process, and render the 3D scene, and supply functions which allows interaction with the models and the raw data loaded in the engine.

What a 2D engine is?

The 2D engine is similar to the 3D engine, the difference is, that it will manage the sprites and texts. You will need functions to allow you to display text on the screen. You cant just use the operating system to draw texts above your 3D scene, so you have to do a renderer that can display fonts. The sprite engine can use the texture management from the 3D engine, you dont have to totally re-implement everything.

The 2D engine must be capable of displaying texts above sprites, so you can create buttons to make fashionable menus in the game. In some cases, you maybe want to write a 2D game. In that practicular case, you need a very complex 2D engine, and writing just the rendering for it is not enough. Like, if you want to create a Mario clone, you will need at least a 2D collision engine, and you must insert the conception of 2D objects and gravity into the 2D engine as well.

The minimum for a 2D engine is rendering ASCII texts, in some cases you will have to do utf8 or unicode capability as well. That will be a much complex task due to all the asian character sets, and you will need a font file which your engine can load. You may want to create 2D effects at the engine level, if you are making a complex 2D game. You may want a 2D particle engine as well.

Sound engine

Nowdays you dont need to have a real sound or music engine. You can just load your wav file, check the bitrate and sample rate, then shovel the pointer into the operating system. The operating system and the sound card drivers will be able to supply at least 4 stereo sound channels, at least from Windows XP and above.

The game engine itself

The parts discussed above are part of the game engine - WITHOUT beint part of the game engine. So whats going on? The game engine is not part of either your 2D and 3D engine. But your game engine will call your 2D engine and 3D engine. Lets see, you want to make a 3D snake game. The game you must create, will employ the 3D and 2D engine you wrote, and in that aspect, your 2D and 3D engine is part of your game engine. However, the actual game engine you will implement for this practicular purpose, is a code that generates the level for the snake from a 40x40 array. Then, it randomly tosses down apples, if your snake reaches the previous apple. Its a very short code, it will use only a small subset of the total code you wrote. This is a very simple situation, as you dont have to implement the GAME and the GAME ENGINE as a separate entity. In the case of snake, the game and the game engine is not separated together, its just a random code that calls your 3D engine.

Complex game engine

Lets say, you want to write more complex thing. For example, you want to do a fighter game, or an RPG. Now, the game engine will became a big mutant code. To make an RPG, you need a method to load the level (it can be just a txt file, it does not have to be some really fancy thing), process this level, put all the NPC-s, furnitures, etc in position. Manage if you teleport out from a map to a different map by deleting all the old contents and loading the new contents. Manage the battle system, manage which items you have picked up, if an item is present, where you should have teleport if you touch random things, and so on. And the game itself will be written in forms of txt files (or in an editor, if you want to do an editor for it). The game engine loads these files, controls the ,,code flow'', and calls the 2D and 3D engine.

Proper abstraction is the clue

As you can see, the game is having multiple abstraction layers. So your game itself is only a few txt file where you describe a room. The game engine loads and interprets these short txt files. Then it calls the 3D engine to display everything. Usually, the most frequent beginner's mistake overabstraction or underabstraction. For example, sometimes incapable persons can be ovserved, who thinks that somehow writing a few for-cycles with glvertex3f is some unachieavable superquirk so he uses some glorified engine library which already overabstracts the whole problem. Sometimes, you can see people who implement even texture management in objectum oriented classes, where the container specification of the problem is multiple 1000 lines alone, because some random professor once told him thats the way to do. To finish everything in time and in good quality, the programmer must write a simple and efficient code, and he must learn how to write actual code that works.

How long it takes?

Depends on which are your goals, and how good programmer you are, and how much time you want to spend. If you are a good programmer, writing your 3D engine will take 2-4 weeks. Testing, and writing more complex effects (such as particle effects) will take maybe another month. The 2D engine will also take 2-4 weeks to implement everything fancy you need. These times apply if you spend maybe 1-2 every day. The research time is also included in this, but assuming you already know what a polygon and what a texture is.

How much people needed?

One person can made the 2D and 3D engine within 1-2 months, and maybe can make the whole game and game engine within another 1-2 months. If we talking about a small studio or from a small group of people, usually one person is assigned to do the 3D engine, one is assigned to do the game engine itself, and a few people is simultanously working on the game and on the content. You may have a person for social media and sales, and so on.

Nowdays

Back then, usually maximum 2 person were working on the coding. One was writing the 3D engine, and the another person was writing the game engine. Other people worked on the game itself, or worked on sales, marketing, website, hr, and so on. But games were developed in much smaller teams. Most of the teams usually had 2 or 3 person (3d engine + engine + the game itself). Games created by just one person from ground to top, was also very frequent.

This development model was used in the 80's America. Later on, this development model was used in East Europe and Britain in the 90s and 2000s, and almost every game made in East Europe still following this conception. If a group fails upon this conception, thats usually due to the inability to find competent programmers.

Nowdays, the things are changed on the West. People usually use some existing game engine, and downloading and writing plugins specifically designed for that game engine. Instead of writing one, people learning a popular game engine. Developers learn how to make plugins for that game engine, and everyone is using that.

This new method allows huge number of developers to work on the game, and allows very nice and modern visuals using modern technology. But at the same time, both developing the game needs strong hardware, and both playing it will require a strong and modern hardware. In the case of a game engine malfunction, its impossible to fix it, and the problem must be tackled with workarounds. These type of game engines usually using script languages and you cant use real programming languages (such as C) to control them. Games developed in this way are less unique, cannot be ported bethwen to some platforms, slow.

This development model is usually used in USA and West Europe, B and C class of games mass-manufactured for Steam and Apple store. If the group fails upon this conception, thats usually due to the incompetence (they think flying around with WASD is somehow a game, and they dont even understand that the actual development is still not yet done). This conception results in the biggest failure rate of never-finished products.

To fight this problem, some studios try to bring the two contepction together - they develop an engine, but it follows the modern conception, where the game engine itself will be put together from plugins using script languages. This method is usually used in Japan. Its usually succesfull, but the method combines both the advantages and disadvantages as well. Visually these games are nice, but not really modern, and also the machine requirements are big.

(photo: FTP japan office, illustration)

Is it profitable?

You must have the actual skills and you must actually produce the end result. But even after that, unless you are very very lucky, or you do it under the wings of a well and professionally established franchise, its hard to produce notable sales. If you would like to sell your game engine on the internet, its very hard. As discussed in the previous pharagraphs, people will rather jump on a recently hyped game engine just to burn theyself and never try to make a game again. We are not in the 2000's, people have much better hobbies and opportunities than making a game, so the number of people you can sell your engine, is not that much.

Illustration: RPG popularity in google trends

The number of gamers are also smaller. Gadgets with internet are very popular, but people usually use them for social media and not gaming. The era when gaming was used to kill the time, is slowly ending. Before investing time and resources in something, be sure there is a need for it, and you do a proper market research to know what you can expect.

Other information:

User documentation of Maker4D is available behind a paywall:

https://satoshiwall.cash/paywall/4a0782bb-1dda-11ea-b37f-0242ac130003