Making a 2d game engine from scratch

Have you made any games yet? If so what kind of games? If not, don't bother trying to make an 2D Game Engine. Work on making games and over time you'll have a collection of code which can be merged to make your desired engine.

Rutin said:
don't bother trying to make an 2D Game Engine. Work on making games

Or simply answer the question the OP asked for! “Making games not engines” is not helpful, it discourages everyone into learning the technology behind games and scares everyone else not to ask for this again if reading through this topic later. Instead you should add this as a side note and share your knowledge as a developer with those people, thats why we all are here.

TimothyPidashev said:
i want to know were to start on making a 2d game engine

You start where every game engine starts, at the beginning. For 75% of your code it dosen't matter if you are developing for 2D, 3D, AR, XR or VR because this is “just graphics” and graphics is one but not the major part of a game engine.

A game engine is more seen as the foundation of your game, a framework if this helps to better understand whats going on in the back.

So the first step is that you define your needs and wishes for an engine. Is it designed for certain type of platform or do you have certain genre in mind your games will belong to? Do you want a “developer's engine” (anything can be controlled by code) or a more design driven one (Blueprint, Scene management, Scripts …)?

Second, choose the programming language that fits to the platform. This is important because you should take care of the capabilities of your platform and have a language that supports those well, don't end in complaining about performance when you decided to write your game in Java because just for the reason that you know how to code in Java. You may take this raw overview if you like

• For PC, take something that is well in interacting with the OS APIs. This may be C/C++ by default but also C#, Rust and anything that compiles into assembly or has a very string CLR in the back. Don't use scripting languages like Python or Javascript for desktop applications as they all come with certain penality.
• An exception to the above is using NodeJS with Edge and Electron. This is a web interface that behaves like a desktop app and can (but must not) be performing well too. The clue about using Electron is that you can use Javascript as UI and display logic and place your core code in a C# assembly that will be embedded.
• Console development of the big players Nintendo and Sony (yes Microsoft but I don't like Microsoft nor the XBox) has to take place in C/C++ because there SDKs require it and the compiler chain is designed to support their Hardware.
• Android development has to happen in java, at least for the bootcode of your App while you are also allowed to use C/C++ (Android is a modified Unix platform under the hood and so has many of the UNIX OS APIs available for C/C++) and Javascript with NodeJS and AngularJS.
• Mac/ iOS require Objective C like Android requires Java for Apps to run. It is not worth to develop for Apple in my opinion because you have to buy Apple hardware first (to legaly) develop for Apple.
• I haven't developed games for Browser/ Web yet and don't consider to do it one day. I even believe that there will be a drop of it in the next major update of Unreal and Unity carries it because it looks llike they support much platforms. They even have project support for Blackberry and some other legacy devices. I know that some Online Browser Games use Java Applets, some still require Adobe Flash to be present so it belongs to what dimension your game will have.

If you want to support multiple platforms at once, plan your project properly and implement them step by step. C/C++ will be a good choice and even C# .Net/Mono has become an adequate alternative. Keep in Mind that you still need some Java/ Objective C code for mobile to bootstrap into your engine. You can export a Unity project to Gradle (Unity allows instead of building an APK export to Android Studio and Gradle) if you want to have a look at how Unity does it, Apple projects are exported as Objective C anyways.

Know as you considered which platform to use, you can start planing your project and design your engine features. It is ok to use support libraries and recommended to use wrapper libraries and SDKs for example for your desired Graphics API. But be carefull, not everything that shines is gold and you might end up writing more glue- and management code as if you have written it by your own entirely.

The biggest plus that people argue for using a library or an SDK over writing something on your own (including writing a game engine) is that people are already doing it for you and it is likely more maintained as you on your own could do and saves you some time for doing other stuff. This can be right at some point but at least building up the basic features has the advantage you can find and fix bugs sometimes faster than there will be an update on the lib/ SDK you use. A big counter argument is Godot, they started building the engine froms cratch too and are know one of the most favored game engines for beginners and indies; so what!

If you want to start learning from the ground up, like me, you can also develop everything on your own from scratch. This sounds like a mountain of work but it isn't because you can find everything you need explained on the web; either because the knowledge hasn't changed for some years or developers tend to share it with the world in talks, GDC presentations or blog-posts. However, getting things fast and performing well requires some experience in general development, especially in C/C++. Know your programming language as well as your native speech.

(had to split this because GD.net wasn't able to push my post entirely)

Plan your project in milestones! This is important to keep motivation up. A game engine is not implementing a window and have some nice graphics rendered rather than building the foundation, abstract hardwware access to files, input, network, manage resources like memory and CPU/ GPU time and depending on your language and version of your language (I use C++99 standard with a pinch of C++11) you have to implement convenience functions like delegates or a Type System on your own.

Youse a source control system like Git, SVN or even Perforce (it is really easy to use once you got into it) and save your code on a gloal repository. This helps reverting code if something breaks or your PC is going odd, you have an overview why you wrote some code how you wrote it (as long as you set proper commit messages) and enables you to have people colaborate with your work one day.

Last but not least, depending on your desired platform and language, use a build system. Setting up a Visual Studio project is easy and runs well once configured but you'll reach the point where you probably want to use another compiler or platform. This is the point where you end up in a configuration mess of project files, shell/ cmd scripts and external tools; if something breaks you are investing more time to find the issue than you are writing code. A build system helps because you have everything in your build files and the system does anything else.

If you are like me and want to write code instead of build instructions, then there are also some tools that help or you have a look at our tool on GitHub. I'm maintaining this (at the moment writing this post) and will add support for more languages/ platforms in the future.

The last tip I can give to the general “how do I start creating an engine” topic is: Peek at other projects. There are plenty of engines out in the wild on GitHub and elsewhere, that are open source like Unreal (full code available), Cry/ Lumberyard (full code available), Godot (full code available), Urho3D (full code available) and Unity (C# code is partial available) to have a look into. It might be difficult in first place to get familiar with their project structure (thats why you should do better!) but after a few reads you'll get familiar with it.

However, don't think because one or the other is your favorit or has such millions of $ a year that they are doing everything right. Developers at those companies/ projects have decided to go this way for whatever reason and took their needs and best practice into account while writing the code, for big players with time and financial pressure, so always have a good overview of the big picture and take some reference projects into your decision. My work was inspired by Unreal because they made good decisions with their minifed HAL and Build Tool, but I also took ideas from Urho3D for example their startup macro that makes an Engine class obsolete. Take what you like best and get to your best practice with increasing experience.

Don't know how about you but I also needed some kind of code conventions, most of the time for me because I'm doing this as a hobby project and get confused sometimes with the coding guidelines of my company.

TimothyPidashev said:
2d game engine

The math is similar to that used in 3D, you need to know the basics and should read this discussion. Every game has some kind of linear algebra math, matrices, vector transforms and quaternions are the 3 basic mechanisms you should be familiar with. Anything else can most likely be applied fom 3D by removing one dimension.

3D games use meshes (a cloud of connected points in 3D space), 2D games use sprites (textured quads moved on the X/Y axis) and have to manage foreground, center and background of the scene, this is the major difference. Both use textures, shaders, normal maps and even lighting.

You have to learn to write Shaders, they are sometimes different in 2D vs 3D depending on the look of your game. Pixel Art is especially difficult to look good in cases of interpolation but again, take a look at what is already there, especially Godot has good 2D and Pixel Art support.

One word of warning you should always keep in mind: There is no real 2D in our games since at least 20 years, when developers had to draw pixels onto the screen and later faked 3D by using isometric views. Our modern hardware is highly optimized fo 3D, they use 3D matrices in shader calculations and need to manage the ZBuffer.

Finally anything I have to say is good luck on your road to dive into the wonderfull world of game engine development and finding your own way of doing things

Shaarigan said:
Or simply answer the question the OP asked for! “Making games not engines” is not helpful, it discourages everyone into learning the technology behind games and scares everyone else not to ask for this again if reading through this topic later. Instead you should add this as a side note and share your knowledge as a developer with those people, thats why we all are here

It doesn't make sense to make Game Engines if you have zero idea on how to make actual games so I completely disagree with your comment. When you've worked on several games you'll have a better understanding of how to program certain systems, and what systems are actually needed. Coming fresh out the gate and attempting engine development is ridiculous without having some form of experience about actual game development.

This post is also in the “beginners section” so I would rather be more realistic as opposed to giving the OP rose-colored glasses. Telling someone to make games and not engines doesn't discourage anyone from learning technology. What you seem to forget is if the OP had to make a simple pong game they already have to learn how to handle input, render to the screen, and deal with collision, ect… The complexity of course depends on what the OP is using. Throwing someone into the deep end and hoping they can swim isn't proper advice at this level and this is coming from someone that voluntarily did lots of engine and tool-kit development years ago and it was an up-hill battle. I would've made life way easier for myself if I worked on making the games first and letting the engine become a by-product of those games.

@Rutin I understand and i have another question if you dont mind. What language or game engine should i use if i want to make a 2d platformer game? any recommendations? Thank you

@Shaarigan Thank you so much. Your response was awesome. Will definitely consider everything you said.

TimothyPidashev said:

@Rutin I understand and i have another question if you dont mind. What language or game engine should i use if i want to make a 2d platformer game? any recommendations? Thank you

If you want to remain with JavaScript you have a few options:

CONSTRUCT 3

https://www.scirra.com/

https://www.construct.net/en/tutorials?flang=1

https://www.construct.net/en/make-games/manuals/construct-3/scripting/using-scripting/javascript-construct

PixiJS

https://www.pixijs.com/

https://www.pixijs.com/tutorials

Phaser

https://phaser.io/

https://phaser.io/tutorials/making-your-first-phaser-3-game/part1

Later on if you decide to go down the engine route and depending how much you want to do on your own you will have to program many of the features already available in the above engines and frameworks. This can get pretty complex depending on what you're doing but you'll get a general idea after a period of time on what systems you might need, then you'll have to work on studying how to create those systems. Eventually you might want to make a visual editor for your engine and by using editors you'll gain an idea for what your's might look like along with the features it might have.

The most important thing is to pick something and stick with it. You can accomplish the same tasks in a variety of languages, engines, frameworks, and libraries. What you will learn is highly transferable.

I have been working on a 2d game engine on the Windows GDI for 1 year now using C++ and the Win32 api. I feel I'm qualified to offer my two cents.

I wasn't planning on creating a 2d game engine, it just sort of turned into that. I first started experimenting with the gdi to see what I could do and slowly, I kept creating experiments to explore what the various functions did. Then I applied my own ideas to create intended results.

I kept up the experimentation process and eventually learned how to load bitmaps as resources and work with them, it wasn't long before I wrote a wrapper class in C++ to manage those resources for me and then, the idea of a 2d game engine was born.

I started working on a sprite class so that I could take the bitmap resource created by my class and give it properties, for example and x,y co-ordinate, width, height, etc. I kept coding and adding more features to it.

I then continued the experiments and wanted to try and see if I could interact with the objects, like use one object to move another, or one bitmap moving another bitmap, etc. I created my first hard draft of a collision system with out even knowing it and I was doing some pretty amazing things that got me excited and pumped up, I wanted more. I would come home from work every day and just dive right now, writing more code and adding more features.

I then wrote a logic class, a class that basically took a sprite object and by giving it a set of boolean conditions, I could model the behaviour of that object, for example … does it have mass? can it be moved? does it have gravity? I got this work but then created a block that started to resemble a player sprite.

It was after that experiment that I decided to create a little character with eyes and a mouth and then wrote a player class. At first the jump of the player was cone shaped and about a month later, I figured out how to make the jump into an arc, a month after that, I added legs to my little character and he could now walk and interact with other objects. It was right there that I realized, hey, I can probably make a game out of this!

I sat down with a book and started to create an architecture for a game engine and the many classes to make it work. I spent about another month writing documents and mock up code of ideas that could work, some got implemented others got thrown out the door.

Every day I kept coming home and writing more code and doing more experiments, pushing the GDI to very limits to see what I could and could not do.

This project has required a lot of hard work and dedication on my part and a year later, I'm still working on it. If your making a 2d game engine, don't think that this will be a walk in the park, it is very very complex and others will actually encourage you NOT to do it a large majority WILL, there is a lot to be learned from it. A lot of problem solving and a lot of fun and it will also strengthen your skills in which ever language you are using to make it because it will test you on every level.

Anyway, yes it can be done but you have to be committed to it. Here is a video of my 2d game engine, if I can do it, so can you, feel free ask questions.

@rafaelsantana Wow! Thanks a lot for the advice! I will probably continue on this path and try my best at making a 2d game engine. I will continue to post updates on this forum as i go. And again thanks for the advice. The support is greatly appreciated!

TimothyPidashev said:

@rafaelsantana Wow! Thanks a lot for the advice! I will probably continue on this path and try my best at making a 2d game engine. I will continue to post updates on this forum as i go. And again thanks for the advice. The support is greatly appreciated!

Pick a programming language you really like and don't focus on making a 2d game engine first, instead, learn the syntax of the language, make a few programs that behave like games and then slowly start adding art work to it. A 2d game engine while simple, is extremely complex … and you will be overwhelmed with the details.

So take baby steps, focus on the most simplest task ever … start by learning how to load bitmap resources, it doesn't matter how you do it, just start there and then write code to change the behavior of the bitmap; for example, it's position on the screen, it's size, etc.

Less is more … if you try to do too much at once, you'll walk away from it. I have been so overwhelmed with my project that I do in fact take breaks from it, sometimes for 1 week sometimes for over a month.

You can also take the more modern route, use Construct2d to make a simple game, this will no doubt get you excited and soon your curiosity will start to take you to places that will make you wonder the following things,

1. what is making the player move?
2. how does it move?
3. how are all the graphics drawn?
4. how does the player detect the surface it is on?
5. how do I make the level scroll left or right?

These are the things that will make you want want to create a 2d game engine of your own. It's not the best route for learning to make games but it is a project that I highly recommend any gamer who is into writing code takes. Like I said, it will test your knowledge of the programming language at every level. I strongly believe it is a great project to actually learn any programming language because it's hands on and lots of fun, a 2d game engine is more on the techy side of things.

There are two kinds of people,

1. The person who uses a microwave to heat up a sandwich and only care that it works.
2. The person that wants to crack open the microwave to study how it heats up the sandwich and learn about the mathematical algorithms that make it work.

You have to discover which one of the two you are.

hmm, would c++ be a great language to make a 2d game, and later on game engine? Thanks.

TimothyPidashev said:

hmm, would c++ be a great language to make a 2d game, and later on game engine? Thanks.

There are many languages which are good options for 2D games, and engines. C++ would be one of them.

TimothyPidashev said:

hmm, would c++ be a great language to make a 2d game, and later on game engine? Thanks.

You can choose any language really but c++ allows you to encapsulate things into objects for example, you could have a class for a player sprite, an enemy sprite, as well as other things, it allows you to take the approach object oriented. In my 2d game engine for example, the different tiles in maps are separate sprite objects, this means that every single one as individual properties which can be modified and they can self maintain themselves and react with the things around them.

rafaelsantana said:
it allows you to take the approach object oriented

OOP is something you want to avoid if it comes to performance. The “this”-call generates additional overhead, even if you don't need it and a good amount of code can stay in pure global functions (in C++)

If you want to go the engine route I recommend you the book: game engine architecture third edition. This will give you a good foundation. You also might be interessted in handmade hero.

Shaarigan said:
OOP is something you want to avoid if it comes to performance. The “this”-call generates additional overhead, even if you don't need it and a good amount of code can stay in pure global functions (in C++)

The “overhead” of a this-pointer is exactly equivalent to passing a reference/pointer as an additional argument to a free function. While there are reasons why DOD is important, and why OOP (especially java OOP) can be slower, this is not one of them. See https://godbolt.org/z/UeDXEA for proof - both a free function and a member function produce exactly the same assembly (not even talking about inlining at that point).

Shaarigan said:

rafaelsantana said:
it allows you to take the approach object oriented

OOP is something you want to avoid if it comes to performance. The “this”-call generates additional overhead, even if you don't need it and a good amount of code can stay in pure global functions (in C++)

I disagree. OOP is helpful because it helps create maintainable code; code that is understandable, adaptable, and extendable.

It also helps create reusable code by following the don't repeat yourself method: write the code once and then reuse it, rather than copying and pasting.

The OOP way of thinking also lends itself well to directly translating real-world objects and interactions into code.

Also, the “this” pointer is an address to the invoking object. I have rarely ever used it for anything.

That “this”-reference is passed in the ECX register every time you perform a member function call to a class, while the register is already set if you make the call from an instance method of the same class. This means switching between different class instances at a high frequency (like in games) is a very CPU intens operation compared to have pure static and/or global functions.

I don't know about static functions but as soon as you are referencing any static member variable of the class, there will also be some kind of overhead to populate the pointer to the static class memory in heap I guess

That “this”-reference is passed in the ECX register every time you perform a member function call to a class, while the register is already set if you make the call from an instance method of the same class. This means switching between different class instances at a high frequency (like in games) is a very CPU intens operation compared to have pure static and/or global functions.

Thats all well and good, except that I just showed you a link to compiler-explorer, showing that the exact same asm is generated for both cases. Including used registeres. Maybe its a matter of calling convention? Maybe you can try to put together some short codesample on godbolt to emphasise what your point is (so that we can eigther see what you mean, or you'll see for yourself that you are wrong).

Shaarigan said:
I don't know about static functions but as soon as you are referencing any static member variable of the class, there will also be some kind of overhead to populate the pointer to the static class memory in heap I guess

I'm pretty sure static class member are just like regular static variables. Again, look at the generated assembly: https://godbolt.org/z/kb9Shp

Foo::X(int):                            # @Foo::X(int)
        add     dword ptr [rip + Foo::z], edi
        ret
(anonymous namespace)::x(int):                  # @(anonymous namespace)::x(int)
        add     dword ptr [rip + (anonymous namespace)::z], 10
        ret

(there is a minor difference which I think is a bug in clang, where the compiler inlines the “10” on the global function, even though I specify noinline).

So yeah. Unless you can prove otherwise, your statement are just plainly wrong. Sorry, but thats an important point not to scare people by making them think that just by using a class they get performance degradation.