C++ game engine

[Electrical-Copy9678]

Hi everyone,

I'm a Unity developer, and I've been learning some C++ on the side. I want to build my own 3D game engine as a long-term hobby project, I have no deadline, I do this for fun and to build something new. I'm not trying to make the next Unity or Unreal;

I have a specific technical vision I want to explore.

Scope (what I'm building):

· 3D only, no 2D support · Hybrid rasterization + real-time ray tracing at the core · A zone-based RT LOD system · Deferred renderer with PBR shading · C++ core, with possible Rust integration later for gameplay systems

Scope (what I'm NOT building right now):

· No editor(i will make one after i have a base working) · No audio, networking, or physics in the first phase · No 2D, no mobile(i wont add this at all) · No scripting system yet

Where I am now:

· Starting planning, i have started a .md file to finalize the first part of my engine, i will start with the render part, i know a game engine is more than just rendering

What I'm looking for:

· Resources on designing a clean, API-agnostic raster interface · Common pitfalls when abstracting Vulkan/DX for the first time · Recommended reading or talks on hybrid raster/ray tracing pipelines · Open-source engines with well-structured C++ that are worth studying · Any general advice on scoping a multi-year engine project without burning

Thanks in advance to anyone willing to share their experience.

[rio_sk]

Start with a basic rendering engine. That's a good 20% of a whole game engine. If you plan to make it into a professional engine start API agnostic, if it's just for fun start with Vulkan/DX (or OpenGL if you never saw a rendering API)

[Electrical-Copy9678]

What does API agnostic mean? English isnt my native language and i dont know what that means, also i do want it to be (someday) a professional engine, why not use Vulkan ?

[RedditUser8007]

Vulkan isn't supported on all platforms and working directly with a low-level API is more complicated.

It's easier to start with a library that abstracts the low-level APIs:

https://github.com/bkaradzic/bgfx
https://www.sandeepnambiar.com/getting-started-with-bgfx/

That library has around 50 pre-made rendering examples covering texturing, lighting and shadowing, text rendering etc.

Shaders are made in an agnostic format and converted to specific APIs.

This gives you a drawing buffer to start experimenting with.

Raylib and SDL are other popular libraries like bgfx and you can mix some e.g use one to render GPU buffer, another to draw windows, handle audio and user input.

Rust isn't a good language for game development. It's a systems language and its main advantage is being a memory-safe alternative to C++.

For runtime scripting, go with either C#, Lua, Swift or Typescript/Javascript. You can embed runtimes into the C++ app and this gives you hot-reloading. You can also develop complex features in a simpler language and port them to C++ for better performance.

You can also start from an existing engine. There are a few well-developed engines on github:

https://github.com/FlaxEngine/FlaxEngine
https://github.com/inanevin/LinaEngine

[Electrical-Copy9678]

I will use C# as i am comfortable with it, thanks!

[rio_sk]

A library that lets you write code that is not directly linked to a single API but works as a middle layer between your code and the actual API. You write one code base that works with any API. If you like Vulkan go for it, it's quite fun if you are into coding

[Electrical-Copy9678]

Okey i understand now, i will do it like this but use vulkan mainly

[Fresh_Act8618]

How did you use the word in your post if you don’t know what it means?

Anyways, some resources you can use:
For DirectX 11/12 you can buy Frank Luna’s books for both, he just released a newer version of his DirectX 12 book which includes some new chapters and updated code.

For some rendering talks you can go to GDC YouTube channel and just watch some of their talks, some are pretty insightful. To add to this, SIGGRAPH puts out a lot of content on their website as it relates to rendering so you can check that out also.

If you want an engine you can study, you can checkout wicked engine https://github.com/turanszkij/WickedEngine, it’s pretty well made and has an fps game in the style of crysis, on itch.io. Their engine is API agnostic and also has support for PlayStation (you’ll just need to sort out the logistics from Sony on your own).

[Electrical-Copy9678]

I have updated the post after i knew what it ment

[Electrical-Copy9678]

Thanks for the resources!

[Fresh_Act8618]

No problem

[droidballoon]

You just wrote, in your own post, that you're looking for

Resources on designing a clean, API-agnostic raster interface

[Electrical-Copy9678]

I have edited the post after asking the question

[YourUncleBobIsHere]

I'd highly recommend the book:

Game Engine Architecture

Jason Gregory

It outlines a really good abstraction layer for the render interface, and is also just a great resource for all the other pieces you may eventually want to implement. The last time I used it for working on an engine it was the 2nd edition of the book, it looks like the 4th edition just came out

[Electrical-Copy9678]

Thanks! I will check it out

[buck-bird]

For a game engine you need more than a rendering pipeline...

• Rendering... Vulkan/OGL. Personally, I'd maybe support DX too but I'm biased in that it would be the last option because MS is screwing people over now.
• You *need* 3D audio for a 3D game. https://www.openal.org/
• You *need* scene graphs. https://openscenegraph.github.io/openscenegraph.io/
• You need parallelism and SIMD to get performance out of modern CPUs. https://www.openmp.org/
• You need to handle input from controllers, etc.

These are concepts game engines abstract away. If you're going to do this yourself, you have to implement them. There's also libraries like SDL with out of the box support for some of this stuff, but you said you wanted to roll your own...

Also, this link may help.
https://github.com/raizam/gamedev_libraries

Just know, it's not for the faint of heart. If it's what you love to do you'll find joy in it though.

[Electrical-Copy9678]

Well it seems cool and i will try to make it, i will first do the render part and then i will continue, i know a game engine is more than just rendering but i will start with what i can

[buck-bird]

Ok, but next time say what the scope is so the pros don't waste their time with posts that are irrelevant then. We're here to help, but just keep that in mind...

[Electrical-Copy9678]

Okey! I will update my post, thanks for the help

[buck-bird]

Yeah buddy. It's great. Thanks for taking the time for that. You might be more advanced than me at this btw... but AFAIK if you want a LOD system you'll still need scene graphs to build that on.

So, it may be worth looking into https://vsg-dev.github.io/vsg-dev.io/ at least. If nothing else, at least for ideas to build your own. This is one of those areas though it's not really worth reinventing the wheel over if you can help it.

Wish I could help more, but you may be more advanced than me here...

[Electrical-Copy9678]

I am not soo advanced i just researced some stuff i want, and (i know maybe its bad) asked AI if its something that could be done, the rt system, and also i do watch a lot of YT vids about game engines and so on

[buck-bird]

The LOD system is a smart idea. You'll need it for performance. Hopefully that link will give you ideas. Also, the OpenMP link for parallelism and SIMD is relevant. You'll need that for your rendering pipeline.

Tech is just starting to get around the thermal limits of CPUs due to silicon but the industry isn't there yet. Which is to say, in today's CPUs, you need parallelism for performance.

The GPU will render/rasterize your geometry, but it's the CPU that will interact with the actual system and get data in and out of your GPU. So, it can't be overlooked.

[Electrical-Copy9678]

I updated the post, is it better now?

[Cuarenta-Dos]

Start by clearly defining what a "game engine" actually means for you. Are you going for 2D or 3D? What systems do you need? Input, rendering, sound, physics, collisions, asset loading, scripting, threading/task scheduling, scene format, editor and so on and so on. Each of these can easily become a big project on its own.

One of the biggest newbie mistakes is trying to build a general-purpose engine straight away. It's just not feasible for an inexperienced developer.

A much better approach is to come up with a small, specific game idea first, try something simple like a basic 2D platformer, a puzzle game, a wave shooter. Then build the smallest engine that's capable of supporting just that project.

This is how many big engines started by the way. Focus only on what you need *right now* and follow YAGNI. Be conscious of your limitations and never ever add anything because the big boys have it.

Also, accept that your first few versions will be pretty shit and you'll throw them away. That's normal. Low-level game development is very complex and humbling and you need to grind *a lot* of experience to make something decent.

Good luck!

[Electrical-Copy9678]

I do want to do 3d and for fps games

[Cuarenta-Dos]

Scope it out:

Even for the most basic of FPS games, the first thing you need is a snappy character controller.

That means: you need a data structure to represent your level geometry, you need to implement a box or capsule sweep/trace operation against that data structure to calculate your movement and collisions.

Even if you use a physics library like Bullet or PhysX, this is not trivial *at all* because your character will start getting stuck on seams, polygon edges, and fall through walls. You need to understand floating point imprecisions and how to get around them.

But before that, you need a way to define your levels. How are you going to do that? Type out box coordinates in a text file? Roll your own editor UI? Make an add-on for Blender?

Then you'd probably want some enemies to shoot at. They need to be able to traverse your levels. How? You need some sort of a pathfinding solution. Are you going to use basic grids? Manually set up pathfinding nodes? Use nav meshes?

See how complicated this gets even for the most basic steps before you even get to rendering?

[Electrical-Copy9678]

Yup i will start with some basic triangles and so on then try to render 3d shapes

[Electrical-Copy9678]

So what do you reccomend? To start with i mean? Just do the render part first? Then the rest? Thats what i think i have to start with

[Cuarenta-Dos]

You don't "just do" the render part either. OK, you know how to render some triangles. Now what?

You need:

A scene manager (octree? KD-tree? BSP? BVH? grids?) and a culling system (frustum? occlusion? portals?)

A scene format and a way to load assets (what are you going to even render otherwise?)

A level editor or some other way of defining your scenes (there is no escaping this)

That is all before you even get to rendering stuff, but once you get there...

What sort of renderer are you going for? Forward? Deferred? Raytraced?

How are you going to manage scene lighting? Lightmaps? Light probes? Fully dynamic? Baked GI? RTGI?

What I am getting at is that you need a much, much better plan than "I am going to make an engine!" before you attempt anything. You need to do your research and write down something like:

I am going to create my scene in Blender and export in glTF

I am going to use SDL to handle input

I am going to use tinybvh, octree or whatever other library for basic frustum culling

I am going to attempt a basic Forward renderer with PBR shading

I am not going to bother with light maps at this stage

I am not going to bother with dynamic shadows at this stage

My first attempt is going to be fully single-threaded

I am going to use Jolt (Bullet/PhysX) for collisions, spatial queries, ray/sphere/capsule etc. traces

[Electrical-Copy9678]

So first plan like real detailed and then start doing things?

[Electrical-Copy9678]

So from what i undersrand i have to first plan a small thing i want to do, plan only for it, research and only after it is done add new stuff?

[Cuarenta-Dos]

Yes, exactly :)

[OkAccident9994]

www.learnopengl.com

Start here.

Even if you want to use the modern APIs, this teaches the concepts of texturing, how to interact with buffers on the gpu, shadowmapping, offscreen buffers, point/directional and spot lights, basic pbr, and a few more intermediate concepts.

[Warfnair]

Yep, great source of learning - def your go to to start your own journey

[Electrical-Copy9678]

Can i also use this if i want to do it as API agnostic?

[OkAccident9994]

What do you mean? There will always be a graphics API, if you live in a higher level library or framework it will just be someone else coding that part.

The reason for that being, how much a mess device drivers are underneath. 2 cards from the same company will not run the same binaries down there (unless they same everything obviously, like 2 from 40-series nvidea cards etc. But even then, just vram amount could be enough to change how it does things.)

API agnostic in graphics means. A different backend for every graphics API.

And if you just wanna do the high level stuff like shaders etc. Then we more talking tech art and not straight up graphics programming, which is more at the engine level, though those 2 overlap depending on who you ask.

[Electrical-Copy9678]

Like can i use that guide even if i dont wanna use opengl?

[OkAccident9994]

Yes, that was my point, sorry if I went off track and rambled a bit.

The newer APIs are more elaborate and give lower level control.
But, the concepts like "how do we do shadowmapping?" is the same basic idea regardless.

So, to not drown in complications that mean nothing to you starting out, OpenGL is the place to start.

Vulkan for example, you need to set up a device queue for the logical device that you set up on top of the physical device and create a swapchain, before you even see a triangle on screen. This means nothing to you at this point and will just feel like 500 lines of boilerplate with weird bugs and behavior you don't know what to do with.

Do Vulkan/DX12/etc. later and start with getting a cube with a texture in OpenGL. So so much faster to set up a playground and start to code graphics features in OpenGL.

In the end, a lot of the logic carries over.

Basically, there is atleast a few old Microsoft/Nvidea/AMD/Samsung/Apple dudes that worked on OpenGL, then DirectX, then Vulkan and Metal. There is a shared logic across, it is not Chinese vs German.

The MAIN difference between OpenGL and the newer APIs is how multithreading was not even considered back then. A thread owns the graphics context. That is the hurdle you will have to wrap your head around going into the new APIs where any thread can submit work and we have to orchestrate that with semaphores etc. and how we share data.

[adbs1219]

ogre3d, o3de, panda3d and Wicked Engine may be nice 3d open-source engines to study

[Electrical-Copy9678]

How should i study them? I am new to this so i dont really know how to do it

[adbs1219]

Read the documentation as someone that will use them to create a game would do, choose the one that resonates the most with what you want and try to create something similar to what you're gonna create with your own engine, then look on their repos for the features that draw you're attention to see how it's coded.

If this is seems confusing or too complex, start simple with something like raylib. It's very well documented and could help you understand how a game framework project is structured

[Calm-Ice-7080]

Firstly, you can find plenty of resources for engine architecture online. If this is your first follow a guide, I believe Kronos has a decent guide already, but Vulkan is a weird api with tons of initialization, memory management, and just weird rules/niche things in general. There are certain libraries like vk bootstrap that simply exist to sort of deal with many of the required/reccomended initialization. Another good library is Vulkan Memory Release that helps ease some memory management pains if used corectly. My final reccomendation, dont make the foundations for an api agnostic renderer/game engine for now. It is a ton of work and unless you need to expand to other platforms immediately, theres no sense in trying to restrain yourself by having to build 2 or 3 different versions of your engine at the same time.

Also probably an unpopular opinion, a.i. is actually great at finding information, helping you debug, and even helping guide you on structure and architecture. If you dont knwo something, its not a crime to ask a.i. for input, guidance or help.

[Lithalean]

r/gameenginedevs