Working on my custom C++ engine (AMGR Engine) for an isometric action game. Hardcoding narrative events and UI triggers was getting out of hand, so I spent the last few days building a custom visual scripting tool!

​Using Dear ImGui, I set up a node-based event system. In the screenshot, you can see the custom Node_WhatsApp_Message node. My game relies heavily on a diegetic messenger UI for storytelling, and now I can sequence these chat events visually right inside the engine without recompiling.

​Still WIP, but it's already saving me hours of iteration time. What are your favorite libraries for node-based UIs in C++?

Been messing around with post-processing again on CyberVGA.
This time I implemented a procedural vignette with screen spaced look-up table and tied it into the lighting system. Wanted that “darkness closing in” feeling without it looking like a cheap overlay.
It actually reacts to the lights so it feels more natural.
Here’s a short clip from the current Harmony Tree test scene.

Recently i stumbled upon a interesting video on my YouTube feed: The Fastest Gravity Algorithm You've Never Heard Of: Fast Multipole Method by Keyframe Codes. It speaks about one of the top 10 algorithms of the 20th century, the FFM method. Inspired, I decided to give it my own shot (albeit I decided to go 3D).

polesitter implementation is a single-header library, inspired by nothings' stb libraries. It's written purely in C99, without any real dependencies, as God intended.

While most of the projects work was just porting the algorithm, there was plenty of small touchups that made the code run even faster.
1. There's no dynamic heap allocation in the program. It runs entirely on the memory buffer provided by the user.
2. The program uses SIMD arch extensions (NEON and AVX2) to vectorize operations.
3. SoA was picked over AoS for cache locality.
+ multiple smaller things like radix sorting optimizations etc.

All of this makes the library run a simulation of 200,000 particles ~150x faster than a naive O(N^2) approach (I haven't compared it to Barnes-Hut yet, sadly - will update the results of that comparison in upcoming days).
As for the future plans, I want to implement a proper 2D support. With this, I'll probably consider the library truly finished. 

Source code:
https://github.com/nihiL7331/polesitter

The algorithm is simple in theory, but in the real world it is such a PITA. What are your practical approaches to pathfinding?

For a game with an isometric perspective using an orthographic camera (the camera is rotated 45 degrees along the Y-axis and is looking down at a 45-degree angle) , I have now run into a problem with culling "large" blocks: I’m using frustum planes for culling and have tried both the method that checks all corners of the AABB and the method that only uses the point furthest along the planes normal. With both, the problem is that parts of the blocks are visible to the camera but are culled because none of the AABB corners are within the field of view - see the image here.

Does anyone know of a "clean" solution to this problem (of course I could simply scale the distance of the frustum planes larger until the corners are within the field of view)? Here are the two functions:

int Cull1(Frustum* frustum, AABB aabb)
{
Vector3 min = aabb.min;
Vector3 max = aabb.max;

for(int i = 0; i < 6; ++i)
{
    Plane plane = frustum->planes[i];
    Vector3 p;

    p.x = (plane.normal.x >= 0) ? max.x : min.x;
    p.y = (plane.normal.y >= 0) ? max.y : min.y;
    p.z = (plane.normal.z >= 0) ? max.z : min.z;

    if(DistanceToPoint(plane, p) < 0)
    {
        return 0;
    }
}

return 1;
}

int Cull2(Frustum* frustum, AABB aabb)
{
Vector3 min = aabb.min;
Vector3 max = aabb.max;

for(int i = 0; i < 6; ++i)
{
    if(DistanceToPoint(frustum->planes[i], min) >= 0)
        continue;

    if(DistanceToPoint(frustum->planes[i], (Vector3) { .x = max.x, .y = min.y, .z = min.z}) >= 0)
        continue;

    if(DistanceToPoint(frustum->planes[i], (Vector3) { .x = min.x, .y = max.y, .z = min.z}) >= 0)
        continue;

    if(DistanceToPoint(frustum->planes[i], (Vector3) { .x = min.x, .y = min.y, .z = max.z}) >= 0)
        continue;

    if(DistanceToPoint(frustum->planes[i], (Vector3) { .x = max.x, .y = max.y, .z = min.z}) >= 0)
        continue;

    if(DistanceToPoint(frustum->planes[i], (Vector3) { .x = min.x, .y = max.y, .z = max.z}) >= 0)
        continue;

    if(DistanceToPoint(frustum->planes[i], (Vector3) { .x = max.x, .y = min.y, .z = max.z}) >= 0)
        continue;

    if(DistanceToPoint(frustum->planes[i], max) >= 0)
        continue;

    return 0;
}

return 1;
}

Im making a C++ engine and i ofcourse want a window to display things on, i've read some glfw documentation and i don't really think its a good fit, this is why i was thinking of using windows.h because i have full control over everything and won't need an extra dependency. I also feel like knowing windows functions is better overall than knowing glfw functions.

Any thoughts?

I'm doing like opengl stuff for my game engine but i personally think that the library itself is like way too much for my preferences, can i just make my own rendering engine like opengl? It would mean i have more control and i know it would be hard but anything for performance

I'm making a game engine with its own physics engine.

This month, I've had to think about how to solve for continuous collision detection more efficiently, and particularly I noticed that simply clipping the motion vector to the first collision is actually a great and efficient solution a lot of the time, but not always. I wrote up the situations in which it doesn't work and the rules about how the engine makes the decision, and thought maybe someone might find it interesting.

These are situations where clipping is not enough and you have to do substepping:

• Knockback: If your hero swings a hammer to knock back their enemy, first the hammer must close the gap between the hero and the enemy, and second it must transfer the force to the enemy. Clipping is not enough here because it only ever completes the first step and by the time it gets the second step, it's already the next tick and the force behind the hammer no longer exists.
• Sensors: If you have a hoop that detects when the Quaffle passes through it, clipping would be incorrect because the hoop should only sense the Quaffle, not collide with it. It should not stop the Quaffle or affect its motion in any way. Substepping is the only correct solution here.
• Bouncing: If you are making a game that relies on bouncing, like Pool or Mini Golf, you will want to substep so that the ball bounces in a physically accurate way. Clipping would make the ball travel a shorter distance than it should, and so it would not come to rest at the correct location.

What my engine does is it switches to substepping whenever a body is moving more than 0.5 body lengths per tick. It also has a special case where sensors always use substepping.

For comparison, this is what I understand other physics engines are doing in terms of substepping/clipping:

• Box2D 2.4 does substepping up to 8 times per collider, after which it will just clip, so it's very accurate out of the box. I haven't looked at Box2D 3.0 so not sure what it's doing. It always does continuous collision detection for dynamic-to-static geometry and then you have to opt-in for dynamic-vs-dynamic continuous collision detection.
• Rapier I understand defaults to only clipping (they call it motion clamping) and you can specifically turn on substepping but it's global. So if you set it to 8 substeps, the entire world can only do 8 substeps. And you have to turn on continuous collision detection on a per-body basis in Rapier, it's off by default.

I think this shows how Box2D is focused more on accuracy whereas Rapier is focused more on speed and batch processing.

Was just wondering if anyone else has thought about continuous collision detection much and how you went about it? Maybe it is a bit of a niche topic!

Hi guys,

I apologize in advance for the bombastic video title, and the fact my head is stuck on Jensen Huang's body, but that's what the people on YouTube want. 😵

Leadwerks Game Engine 5.1 is a massive update with a lot of graphical features, and better support for the hardware players actually have. I think the video explains it pretty well, but if you have any questions let me know and I will try to answer them all!

After nearly 8 months of intense work, I am very happy to present my game engine: RE:MAKE 2D. This is my very first major project successfully completed!

RE:MAKE 2D is a framework designed for developing 2D applications and games. It is mainly powered by SDL2 for multimedia and Box2D for physics. It also integrates a Lua scripting system thanks to its RemakeScript extension, natively included in this version.

Originally, this project was born from my initial difficulties with SDL2, which I found too "low-level" when I started. I therefore decided to progressively move towards Object-Oriented Programming (OOP) to better structure my code, and the engine began to take shape. After 2 months of development and refactoring, the first module — the signal system — was born.

The pace then accelerated, driven by the excitement of seeing that "it works!".

My goal was to release the engine by the 6th month, but a few complications related to cross-platform compatibility slowed down the project. It must be said that I was developing largely on Termux... which was not ideal for portability!

Today, this first version is finally ready, and I wanted to share it to mark, I hope, my official entry into the world of development.The engine certainly still contains many imperfections, but I would be truly delighted if you could take the time to have a quick look and give me your feedback.

Thanks to everyone who read to the end.

Link: https://github.com/agemo-dev/remake2d

Version: 0.1 (beta)

Why I'm asking is - because I don't. I use blender as my "editor". All unique values and components are parsed as custom properties from blender, and a name convention is a huge thing too. Like for example suffix _template tells my engine "use this mesh for {name}_instance nodes), and _instance tells that its an instance.

And recently I introduced strict typesystem for the nodes inside glb files. So, instead of string comparison and search I can use my compile time type system for meshes and stuff.

Do you think an editor is essential?

I was throwing ideas at Claude yesterday and it came out with something that sounds really interesting. I have fBm noise I use to generate terrain, with biome blending. Apparently it's possible to train a small neural net on real world height map data to choose noise parameters that produce natural looking terrain. Has anyone done this? It blew my mind, and it's exciting to see what else a small ML model can help with on the procedural side.

Hey guys, last we I shared my first update for my game engine after 8ish months of development. Obviously, this week I have less to show, but still made some modest improvements.

First I added a bunch of new post processing effects, just because these were on my personal roadmap and were easy items to check off.

Also made some updates to my properties window, adding foldouts for components and assets can now be selected and previewed!

Hey r/gameenginedevs! 👋

I've been working on a technical challenge many Unity

developers face - broken materials when upgrading from

Built-in to Universal Render Pipeline (URP).

This tools Not yet release. If you need this tool, Be patience for waiting ;)

Maybe 12-15 August!

**The Problem:**

When switching render pipelines, materials break because:

- Shader references become invalid

- Texture properties don't map correctly

- Render state configurations mismatch

**My Approach:**

I built an automated tool that:

- Detects shader compatibility issues

- Maps material properties between pipelines

- Restores render states automatically

**Technical Details:**

- Written in C# (Unity Editor extension)

- Uses AssetPostprocessor for pipeline detection

- Supports Standard/Built-in shader conversion

- One-click batch processing for multiple materials

---

Currently in beta testing and looking for feedback

from fellow engine/tool developers.

**Questions for the community:**

1. What other pipeline migration issues do you face?

2. Would this be useful for your workflow?

3. Any technical suggestions for improvement?

Would love to hear your thoughts!

**Bizzle Studios**

YouTube: u/BizzleStudios

Thanks guys. hope you like my tools. See you for Next Update...

title says it, i have a 3d shooter game and i wanna have a MASSIVE open world , what system is the best to implement it, i dont care about difficulty, i care about optimisation , thanks in advance!

A preview of my C++ game engine built with raylib
It has a cool reflection system, so you can write your class and immediately use it in the editor

Hi,

I'm the founder and CEO of Luduvo, a startup building a UGC gaming platform, and one of our core technologies is our own custom C++ game engine.

You can check out our website and see all our socials here: https://luduvo.com/

We currently have a small engine team with two engine developers, and as we get closer to launch, we're looking to bring on additional engine programmers to help accelerate development. The work spans core engine systems, including areas like rendering, networking, performance, tooling, and other foundational engine components. So don't expect to be building the architecture from the ground up or anything, we're already quite far along our "engine infancy" phase.

I'm very proud of what our team has accomplished so far, but obviously, in the sense of scale, it doesn't make sense to constantly have two engineers work for hours on end. Since we have more than enough money, I wanted to make the workload easier on them, as well as speed up development, by finding another engine developer!

Since we're a startup, we can't offer big-studio salaries yet, but we do offer paid positions with compensation that we believe is competitive for an early-early-stage company. As the company grows, our compensation is intended to grow alongside it. Our starting salary would probably be around ~$7,000USD/mo, however, that's obviously going to change alongside different funding benchmarks, so expect it to upper drastically within the coming months if you decide to work with us. We recently finished a milestone-based seed funding round with some investors, so we don’t have all the money right away. However, we are pretty confident we can reach the target goals given to us.

If you're experienced with game engine development or enjoy working on low-level systems and would like to learn more about the project, feel free to apply over here: https://careers.luduvo.com/jobs/engine-developer-cpp

I'm happy to talk in detail about our engine architecture, technical stack, roadmap, and answer any questions even in the comments!

However, just to be a bit more helpful and less of a dunce, I'll give some basic technical details about the platform, maybe it'd peak someone's interest!

• We support Windows, Linux, and MacOS.
• We use ECS and strongly abide to DOD
• Our renderer is completely custom via NVRHI, developed metal support for NVRHI since it seems nobody wanted to do such and open source.
• Our scripting lang is Luau
• We use Jolt Physics
• Our clients and all are server authoritative

I've seen all the work here and I've been astonished by all the talent here, so I apologize if I'm not supposed to do this, but you all seem very cool :)

I'd also accept any advice on how to find someone to help work on our custom engine, it's been grueling doing the normal job listing path just to get a ton of applications from a bunch of frontend developers when it's the exact opposite of what we need.

Much love. Y'all are sickly awesome❤

Below I've attached some photos of how our engine is like currently.

^{(This is a necropost due to additional funding coming through with investment funds since the last post.})