hi.

i know asking for references is not good in forums but it's the place of the question for me.

most of the game engine tutorials are all about theory (like game engine architecture) and some are completely practical that only can cover drawing triangles.

i like to understand the big picture like how the base framework is defined or how serialization works or how scripting language is used in a game engine to run codes and lower level or how to build systems and editor work and…

i don't need ver low-level implementation details but I need to know how can I make a good architecture for may simple game engine

moeen k said:
how can I make a good architecture for may simple game engine

But isn't all of this about theory in architecture?

A game engine is just the majority of code of a number of games which is structured in a way to allow reuse of common features.

References can be found a lot on GitHub, for example Godot, Urho 3D or Unreal Engine 5 (free account needed). There are also some other brands and names like Amazon Lumberyard or the original Cry Engine source code available, but I used mostly Unreal for reference.

But having a good reference is worth nothing if you don't understand how game engines work and what features they provide. This starts with the language you choose, the project pattern you want and ends on the platforms it should support.

I guess you already decided for a language but have you thought about alternatives or a hybrid approach? Why coding the editor in C++ for example when C# could be used?

What is your desired project structure, how do you want your engine to be used? There are a couple of approaches which can be set to either closed or (semi) open source. Engines like Unity or Source Engine are closed source and so you have to do everything via the editor while engines like Unreal or Godot are open source or semi open source which allows to write game code in a language compatible with the engine and call the engine directly instead of using a launcher application.

Our design approach is even different from that. We aim to have only the minimum required feature set of the game you want to make present on a development machine and packed everything into small atomic feature modules you can manage for every project individually. Something like the major engines Asset Store approach on an extreme.

That said, I can just recommend Game Engine Architecture, Third Edition as a start to read into general design principles, download and use some of the major engines you find in the web, work on some projects and finally get a picture of what they do, what you like and dislike and finally find your way of designing an engine. And if you want to have a deep talk about that topic, you're welcome to join our Discord and get some insights into how we do these things. I'm dojng research about game engines since I first got into game development as a kid back in the 90's and earned a lot of experience in my past 9 years of being a professional in games industry. So I got my impression of dos and don'ts and a team of an equal vision

moeen k said:
i like to understand the big picture like how the base framework is defined or how serialization works or how scripting language is used in a game engine to run codes and lower level or how to build systems and editor work and… i don't need ver low-level implementation details but I need to know how can I make a good architecture for may simple game engine

Personally, I feel the best way to know how to build a game engine is to actually start building one. I know this might sound stupid, but humor me for a bit.

Making an actual game engine with the intent to reuse it, as opposed to just coding a game with the intend of later refactoring out common parts, is a huge endeavor. No amount of tutorials, references or guides can prepare you for what it actually takes to make a functional engine. Theres just too many different parts the all somehow need to interface with one another. Thats why most books that you see cover the theory about the separate topics like physics and rendering, because those are (comparatively) easy to comprehensively explain. How to build a physics-system is somehow “solved”, but how you want your physics to integrate into the rest of the engine is largely an open question based on your surrounding systems. Do you haven an ECS or a classic GameObject-model? What type of scripting do you support, if any? Those are all questions where there is no right or wrong. Some coders consider ie. visual scripting a waste of time, while I personally like it (when done right like in UE4) very much, and adapted it for my own engine. There's nothing going to be able to tell you what to do in such a case, though you can find information about the distinct topics.

So my personal advice for learning how to build a game-engine is the following:

1. Pick a reference project that you want to build. Even if you intent to make an engine as the core project, if you don't have a project to work on you'll just head nowhere working on features that you don't need, because you have nothing practical to base your requirements on. With a project, you'll always have a set of steps that you must take to be able to run this project, allowing you to structurally add features that are actually required or at least help with development.
2. Just get started. As I said, I don't belive you'll find anything that tells you how things completely fit together in an engine, so your best bet is to just get going. Don't worry about doing it right the first time. Just pick a feature that you need to have (based on your reference-game), find some information about how you could build that feature, and select what you like the most. Just build it until its functional, don't get lost in analysis paralysis about the details; but be prepared to refactor later on.
3. Learn, and refactor. Every feature you build will give you some more insights on what worked well, what didn't, and working on your project will over time tell you which workflows that you build are efficient and which can be improved upon. With the knowledge in mind, be ready to restructure large parts of the engine with the knowledge you gained. Personally, I have pretty much replaced every single aspect of the original engine I started building back in 2012 at least once, which is why I went to “Acclimate Engine 2”. The newer parts I write are way more stable though, as I know have a fundamentally better grasp on what works and what doesn't, and I have certain “patterns” of my own that I use whenever I implement a new big system.

I belive that this is the most practical way of going about learning about game-engines. You might say it sounds like a waste of time having to build something while pretty much knowing you'll replace it later, but I belive that for any sufficiently complex part in programming (like what building an engine is), you cannot simply learn the optimal way without having tried and potentially failed in the same area. Especially when talking about the “big picture” of the matter.

to continue my question,

is it possible to know how the technologies behind existing game engines work? for example, how unity scripting language is translated to machine code to how il2cpp or mono works in unity on different platforms or these are the things that are highly confidential and no one knows outside of the company?

You're living in a time where even companies like Epic discovered open source as their key concept. Many game engines are already on GitHub. And if they don't, like Unity, then there are a couple of blog posts and knowledge base articles about their technology. A good starting point are GDC Talks, for example from Unity.

Unity doesn't has an own scripting language anymore. Instead they use standard C# and an own roslyn compiler, which is located in the Unity installation folder. This translates C# to .Net/mono IL assemblies, which are loaded by an embedded runtime into the Unity player application. Such things like Update, OnDestroy etc. are custom implementations in the Unity embedded CLR. The platform doesn't matter as everything platform related is implemented in the engine itself and offers a unified C# interface.

Mono itself is open source on GitHub as well.

IL2CPP is also well documented. It is a custom built over LLVM, which reads the MS IL instructions from a .Net assembly, translates that into C++ code and has the clang compiler create platform assembly from that code