i want to know were to start on making a 2d game engine. What to use: opengl, with javascript and htm15?

plz help

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.