how should I start making a game engine

Learning to program, knowing what a game engine should contain, and writing it all.

If you don't know how to program, I'd say start with that first.

If you don't know what a game engine should contain, I'd say investigate. One fun way to do that is by writing games. After a dozen of them, you will start to see patterns, some code is in every game. Other code is only in a few games. The game engine is that code that you always or often find in the games.

Of course, if you compare code between different games you'll find that the common parts are not always literally the same. So you need to push the changes out, that is, generalize the functionality before making it available as game engine part.

By coding something, anything.

Think of the features you need in a game engine:

• logging
• asset loading (images, audio files, fonts, etc. etc.)
• rendering (sprites and shapes if 2d, or all the 3d facilities)
• audio (2d or 3d audio)
• data loading (if your game has an item database, you need a way to load this database from somewhere)
• etc. etc. etc.

Choose one of them. Make it. Cross of it from your list. Keep going.

Don't. This is one of these cases where if you have to ask how to do it, you almost certainly shouldn't do it.

rohit3 said:
how should I start making a game engine

0. Now your programming language. This is the most difficult part to go through because it may take days to learn programming but years to master it. You should at least choose a language which has either a very well framework environment available, like C# for example, or low level access to necessary platform APIs to access what you need, like C#, C/C++ or Rust.

Most important because a portential performance bottleneck is that you know how to work with the memory model of your language chosen.

Also get familiar with tools that help you managing your project. Make/cmake for example

1. Get a source code version control system to manage your work. I like SVN more than Git but GitHub is free of charge so this may be your way to go for. Perforce (p4) is even better than SVN because you can manage different commits in parallel without a full copy while you need to branch out everything in SVN and Git

2. Think of how you want to design your engine. You have a couple of options to choose from which define how you have to write your code and possible tools around it.

Monolithic is the usually most used design approach, which means you put everything into the same code repository and don't care much about code dependencies. Everything is in the end, built into a single application/library with potential a couple of dependencies. The downside is however, that you always have to take every feature with you, need it or not. 90% of engines (Unreal, Unity, Godot) and game creation toolkits (Game Maker) out there are monolithic and of a download size from a few hundret MB up to several GB.

Modular approaches try to separate everything into losely depending modules. The pro of doing this is that you can decide more fine grained which features you want and you can of course replace modules with custom ones. The downside is that you have to spend more time into planning every new feature and keep an eye on dependencies between modules to not run into a cyrcular dependency issue.

Plugins can be used from both. monolithic and modular approaches, but they are more common on the monolithic side because it makes them somehow more flexible to at least modify some of the features shipped

3. Get a book that gets you into game engine design and architecture like Game Engine Architecture, Third Edition as a first read. There are also thousands of blog posts in the internet which explain how they went through it.

A good one of those blogs is that from Bitsquid/Adobe Stringray which for example gave an interesting approach about memory management

4. Get a team or join an existing one because it is a lot of work, especially as a hobby project, to get everything from the ground up

Shaarigan said:
Monolithic is the usually most used design approach, which means you put everything into the same code repository and don't care much about code dependencies. Everything is in the end, built into a single application/library with potential a couple of dependencies.

A monolithic repository doesn't mean your code can not be modular. Personally I think they are a very good idea until interfaces become really stable. As long clear dependency boundaries are maintained then the repository can always be split down the line when ever its convenient.