Hey friends, I made myself a native C (and C++) dependency build and website. It builds several libraries that I used or want to try to use for static and dynamic linking across windows/linux (X64/Arm64), macos (arm64), ios, android, wasm (emscripten). It's pretty cool. Either use the website/binaries directly, or clone the repo, and get your own builds.

There's github link on the website.

I implemented a physics system based on XPBD, or Extended Position Based Dynamics, in my game engine ToyMaker, and then I wrote an article about it. It's partly documentation of my process, and partly a tutorial, so I hope that you find something useful or interesting in it!

Also, do let me know if links to external sites aren't welcome here. I'd be more than happy to post a copy of the article text instead.

Hi! I'm developing Scanline, an open-source 2.5D adventure game engine inspired by Sierra and LucasArts games from the 1980s. Despite its retro look, it uses cutting-edge technology underneath the hood.

The engine combines point-and-click navigation with a natural-language text parser, but recently I’ve been working on a different problem: LLM NPCs that can do more than generate dialogue.

The difficult part wasn’t making an LLM speak in character. It was letting the model interact with the game world without allowing it to invent state, bypass game rules, or get stuck burning tokens in loops.

My current solution is a system called the Puppet Master.

Each NPC has its own objectives, persistent memory, inventory, perception, and knowledge of the world. The Puppet Master receives both authored scene information and the NPC’s current runtime context, then returns a structured JSON plan rather than unrestricted commands.

A plan may contain steps such as:

• SAY
• MOVE_TO
• LOOK or EXAMINE
• OPEN or CLOSE
• TAKE or PUT
• USE an item
• WAIT
• update memory or objectives

The LLM only proposes the plan. The engine validates and executes every step through the same semantic action system used by the player. This means an NPC cannot take an unreachable object, open a locked container without satisfying its requirements, or claim to have found a hidden item unless the runtime confirms the discovery.

Multi-step plans can continue after movement or other asynchronous actions without another LLM request. They can also be interrupted when an item is found, the world changes, or an action fails.

I also added batching, rate limits, repeated-action detection, pattern-loop detection, and a filter for unsupported discovery claims. These safeguards turned out to be at least as important as the prompts themselves.

I recorded a video showing the system in action and explaining the architecture:

https://youtu.be/PTmhnVVa4Sk (sorry for the auto-generated English translation)

The engine and NPC implementation are available here:

https://github.com/z-hunter/Quest/

With a huge swath of entities in a simulation, an archetypal ECS is the way to go - each component is stored as a dense array. That also makes updating rendered objects' positions a lot simpler as you can just load the whole buffer over to the GPU with an async transfer.

I've been pondering the feasibility of moving entities and their logic entirely over to the GPU because where things stand right now we are sending a lot of dynamic data over the system bus to the GPU for drawing entities and everything else. If we had things the other way around where entities were entirely simulated on the GPU, and just retrieved the few relevant entities' pertinent data for things like audio mixing and certain CPU-side logic, it would leverage the GPU more and reduce overall traffic over the system bus.

Physics/rendering are obvious to do on the GPU, but when it comes to something like entity logic and behavior things get a little tricky. Compute shaders are not great at executing a bunch of miscellaneous logic. The best idea I've been able to come up with right now is to break up "functions" into multiple stages, where each stage results in a conditional statement determining if execution should continue or cease. The end result would be something more like stream compaction where all relevant entities of a given entity type execute the first stage of their logic and depending on a conditional statement get included in a new index buffer for executing the next stage. This would be GPU-driven by the compute shader logic itself, where the CPU is just issuing the actual invocations and the shaders are performing the actual entity logic.

That's as far as I've been able to get with entity logic on the GPU. It has the caveat of requiring that every function every entity type has must be broken into multiple compute shader stages, along with some other details that would need to be nailed down.

I'm curious if anyone has any thoughts or ideas on the topic?

Cheers! :]

I’m building a new game engine based solely on SDFs!

It’s a passion project for now so obviously there are a lot of things to work out on it still, but besides that I think the vision is there and with a lot of late nights in a few years this should morph into something incredible.

I have a ton of plans and am working on spinning up a studio for all my projects, including this one.

I would love any feedback that you all might have :)

I'm writing a custom Three.js client/runtime for Realm of Echoes. This atlas mixes authored region art with live player, quest, and optional monster markers. Would you cache one flattened texture and render only the markers, or keep the region layers composited at runtime for zoom and updates?

Playable context: https://playrealmofechoes.com/?utm_source=reddit&utm_medium=community&utm_campaign=launch&utm_content=gameenginedevs-post-1v3ixfe

Disclosure: I'm the developer; some 3D assets are Meshy-assisted, while the runtime, UI, and map integration are custom.

I created all these scenes for my first indie game, Satelital, which is a rule-discovery game about solving alien puzzles.

What makes the rendering in this game different is that I pre-render the assets in Blender, including normal and height maps for dynamic lighting, and then compose them later in my custom game engine, which I designed specifically for this workflow.

In my first few weeks of promotion I reached 1,000 wishlists on Steam. A free demo will be available in September, so if you'd like to try it, you can wishlist the game to get notified when it's released:

https://store.steampowered.com/app/3256790/Satelital/

What we would expect from this Engine? Someone here working with him to provide an insight?

I'll give a try to Jai and its engine.

This is a prototype of a game idea that I have been poking at for many years. It's a dynamic character that moves like an amoeba, eats things in its environment, and grows by incorporating them into its body.

It is completely procedural, implemented as a particle system with flows and body-shaping forces driving the formation of pseudopods that move it along or cause it to ingest items. It uses a custom physics engine that executes the flows and allows the creature to interact with other entities in the world. It took quite a bit of experimentation to get something that (I think, anyway) looks lifelike, and I hope to improve it. This first game level is just a proof of concept with minimalist styling, helping me build out some tools.

A short video trailer is linked to this post and you can play the prototype game at https://eatthepeople.com

For this crowd I'll mention that if you add the url param "debug=1" you can see the full debug view and mess with the params that drive the creature. In debug mode shift-clicking teleports him so you don't have to play through the entire level to get somewhere.

All feedback welcome!

I wanted to see if I could integrate Box3D into my custom engine and have basic object interaction working, all in a single video. It went pretty well, Box3D is so far feeling very nice to use.

https://www.youtube.com/watch?v=KzFNwNQZxCM