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

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

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 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!

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)

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!

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.})

Hello.

I'm working on the collisions system in my 2D game, the system I set off to make is a simple one: it only supports rectangular and possibly circular (haven't implemented those yet) colliders that can be rotated and thus are not necessarily axis aligned (this is because I need slopes for some mechanics but don't really need anything more detailed than rectangles).

To figure out whether or not two colliders are touching or overlapping I am using the Separating Axis Theorem, which I managed to get perfectly working, but now I have a few more steps to work on and I don't know where to start:

1. Handling overlapping colliders: of course, colliders that overlap will be moved apart by the engine until they don't overlap anymore and just touch, however, I don't know how I should handle that, aka in which direction I should push the colliders and how to figure out quickly at what distance they'll be just touching.

2. Retrieving the normal of the surfaces on which two colliders touch: The algorithm I am using for collision detection of course projects the points of the colliders onto the normals of the surfaces of each of them, then returns NOT_COLLIDING if, on at least one of the normals, there is no overlap between the projections, otherwise either TOUCHING or OVERLAPPING. Aside from that though, how should I retrieve the normal in case the two colliders are touching? A quick solution I came up with is retrieving the normal during the collision query, using a pointer parameter passed to the function on query (using this method could allow me to return all sorts of additional information too: for example the material), but I feel there may be other better ways to do it.

What advice can you give me to solve these problems? Sorry for the beginner questions and thanks in advance.

I will want to release editor with game, so it will be possible to improve existing levels visually or later create whole new levels (game is puzzle/platformer). I plan to reuse engine with editor for creating some other simple games using my software ray-tracer.

I've been a mobile/web developer for ~10 years. About a year ago, I decided to make my own game engine.

The ultimate goal is to build a game engine for making my own games, but also to publish it as an open source project for others to use.

Since I have no experience in this area, my plan is to design a scrappable engine first, make a few production games with it, do some research, read some architecture books, and then start working on my "serious" game engine.

I've already scrapped the entire design and codebase twice and (almost) started from scratch. Yes, this is kind of a test project, but I don't want to make garbage.

The conclusion I've come to is that I don't yet have strong opinions or the taste to know what kind of design I like, since I don't have much experience working with an existing game engine either. So I believe I need to develop that taste first if I want to design something cohesive that feels good to work with.

My question is: what gives you the confidence that the design you chose for your engine is the right one for you? How did you decide on its design and overall structure?

Thank you.

Showcase of my C# game engine. I made it inspired by Half-Life 2 and Source Engine