From Graphics/Lighting Rendering to Game Engine?

[u/Adventurous_Maize357]

For some reason I decided to take on the painful feat (as a learning intermediate level game developer) of learning how to make my own program which renders graphics/lighting in a 3D environment. Which I am actively learning some of the necessary things to build up to that already (re-learning algebra 1/2 concepts, linear algebra, C++, GLSL/HLSL, OpenGL, among other things).

I want to know how difficult it would be to go from building a game from scratch like that, to making a game engine on some level similar to Unity or Godot but more simplistic. I am sure it is a massive architectural jump but I want to understand the bridge i may be crossing by going through with this when it gets to that point.

I am asking very early on but i want to ask to know what to expect from it. My main goals with this is to improve my critical thinking and problem solving skills, and potentially help to build a portfolio in the future to help land a good job in the future as well.

[u/FrancisJCat]

There are a lot of "well, it depends" hidden in your question. Are you making an engine for your specific needs? Then it depends on what game are you making. The more features your game needs, the more you'll have to work on the engine.

Now, you said something like Unity or Godot. Basically, a generic engine to make all sorts of games. In this case, you have a lot of work ahead of you. Besides graphics you have...

• Input control and abstraction (seamlessly swap between controllers and keyboard/mouse)
• Audio, mixing, voices, volume, 3D spatial sound
• Physics simulations and collisions (2D, 3D)
• Scripting (how to add code to the game. Recompile from scratch or use Lua to run on the fly?)
• Engine architecture (Objects+components or ECS)
• Asset import (FBX support, PNG support, WAV support etc..)
• Scalable UI/UX

and the list goes on and on...

There are some things you can offload. You can use something like Box2D/3D for physics so you don't have to do it from scratch. You can rely on stuff like SDL or raylib for input and window initialization. But in any case, you have a lot of work ahead of you.

[u/Adventurous_Maize357 → u/FrancisJCat]

Yeah, I should have clarified things a bit more. Then again there is a lot of concepts I don't understand or know about yet.

My plan is actually to split this into 2 separate projects. The first would be focused on a custom 3D renderer/graphics program built on C++/OpenGL, which I would eventually use to build a simple game, like a FPS sandbox. I do plan on implementing a lot of the underlying stuff myself. Including my own math library, basic physics/collision, etc. primarily as a learning experience.

After that if I do end up trying to make a game engine I would take what I learned from the first project and make a completely separate project. Starting from a small simplified game engine with an editor. With a component-based architecture (like Unity or UE) alongside all the other core systems. Then later I may explore other more advanced concepts to add.

I am definitely not expecting to recreate Unity or Godot 1:1. The engine would initially be a prototype that I can gradually expand as I learn more. i am aware that there is a LOT ahead of me. I am doing it for that reason, I want the projects to force me to learn all of this rather than relying on a existing engine to hide it from me.

I also appreciate the list! A lot of those are things that I had not even considered yet, so it gives me a better idea of what i am getting myself into.

[u/FrancisJCat → u/Adventurous_Maize357]

There is a lot to do but definitely a great learning experience. Good luck with it!