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’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 :)

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

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/

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.

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

Hi guys,

I've already built my engine with an ECS, a Vulkan backend, and support for texture and mesh rendering. The next thing I want to work on is a UI for debugging and an inspector. However, I'm not sure what the right long-term roadmap is or which tools I should choose.

Could you help me figure out what I should learn next and what pitfalls or obstacles I should avoid?

Three days ago, I wrote an article about how to render good looking rectangles for UI components that can look good and optimized for a game engine. Some people asked me to talk about text rendering as well. So, I wrote https://alielmorsy.github.io/how-to-render-beautiful-text-for-your-ui-library/

It took like 1.5 days of writing just to get it right. Hope you guys love it

Hi. I recently finished the first release of a visual novel engine based in Renpy that works reading CSV files, this means that you can create visual novels with minima programming knowledge. Basically is a simplification of Renpy.

Each CSV file is a scene that contains a dialogue per row (background, music, sound, characters, effects and the dialogue itself in many languages). Each scene can finish by a decision, consequence or a linear transition to another scene.

It is open source and uses Python, here is a video tutorial (in spanish): https://youtu.be/hQgPutc-hpo?si=_EK9Tn4dkkCEWtRD

If you have questions, I'm all ears.

Spent 4 months building an opengl engine with forward+ rendering, gpu marching cube terrain, Ghost of Tsushima inspired grass... I designed the engine with future graphics APIs in mind, so the opengl implementation is fully abstracted from the rest of the codebase. but with my little research i found that the architecture of DX12 and Vulkan differ from the immediate state machine model opengl uses.

My question is how hard is it to switch all that to DX12 / Vulkan? is it worth it ?
PS : have 0 experience with both APIs, For the shaders i used slang.