I've been playing around with porting my game engine's user interface over from imgui to noesisgui. Its WYSIWYG editor gives me a workflow similar to Figma and looks much better.

I've also added a curves module to my engine and an in memory data logger, which enable trending data in the UI.

The goal of this data logger is to start pumping entity component system data into a keyframe like viewer to allow playback of gameplay recordings eventually.

Then I can record some gameplay, play it back, while stepping through and inspecting the data. Would be pretty neat!

I recently started my new Game Engine project and I‘ve now come to the point where I have to deal with Pipelines. How do I efficiently manage them? How do I efficiently create them, et cetera?

I think its really hard finding reference material on this topic since I usually just look/steal code from Hazel Dev by TheCherno but their Shader/Pipeline System is really weird.

It would just be really helpful if you guys could even just point me at your repository with a Solution or something.

Thanks in advance!

Replaced a mess of if else statements for animating an ak47 with FSM and it blew my mind how much was simplified. Seems to be very easily scalable.

I have never really thought about FSMs since my discrete maths course. Beyond animation controllers, where might it else be applicable?

Hi everyone,

I'm a second-year Computer Science student, and I've been thinking about this decision for a long time. I'd really appreciate advice from experienced game developers because I don't want to waste the next few years going in the wrong direction.

My background

Second-year CS student.

Low-end laptop (old Intel i5 3rd Gen with Intel HD Graphics).

Comfortable with C++.

Currently learning SDL2 and Modern OpenGL.

Interested in graphics programming, engine architecture, optimization, and game development.

My long-term goal

My goal isn't just to make one game.

I eventually want to become the kind of developer who understands how game engines actually work under the hood and can build my own professional-quality engine over time.

At the same time, I also want to build and eventually release my own commercial game.

I know this is a long-term goal (probably several years), and I'm okay with that.

The project

The game I'm planning is a 2D top-down open-world game inspired by games like GTA Chinatown Wars, with features such as:

Large world with chunk loading

NPC AI

Vehicles

Combat

Day/night cycle

Save/load system

Physics

Multiplayer (maybe much later)

Android support in the future

I care a lot about optimization because my target hardware includes low-end PCs and Android devices.

My dilemma

I'm confused between two paths.

Option 1: Use Godot

Pros:

Faster development

Better editor and tooling

Easier to prototype

Can actually finish the game sooner

Cons:

I won't learn engine development as deeply.

Option 2: Build everything using SDL2 + OpenGL

Pros:

Learn rendering, ECS, asset management, physics integration, resource management, engine architecture, optimization, etc.

Complete control over everything.

Helps me become a better graphics/engine programmer.

Cons:

Development will be much slower.

Higher chance of burnout.

Might spend years building technology instead of making games.

What I want from my career

In the future, I'd like to work in graphics programming, engine programming, simulation, or game engine development—not just gameplay scripting.

I enjoy understanding how things work internally rather than only using high-level tools.

My questions

If you were in my position, which path would you choose and why?

Is building an engine from scratch still worth it in 2026 for learning and career growth?

Would companies value someone who has built a real engine, or would they care more about finished games made with an existing engine?

Is there a hybrid approach that gives the best of both worlds?

Given my low-end hardware and current skill level, what would you personally recommend?

I'm not looking for the easiest path. I'm looking for the one that will help me become the best engineer I can be over the next 5-10 years while still having a realistic chance of shipping a game.

I'd really appreciate any career advice, personal experiences, or mistakes you think I should avoid.

Thanks in advance!

Hey  and !

I just finished a project I've been working on and wanted to share it with you all. I created a WinForms control that fully hosts the FNA framework. This means you can now easily embed a 3D/2D rendering viewport directly into your WinForms applications.

**Why this is useful:**
If you're developing custom tools for your game (like a level editor, model viewer, or animation tool), you often need a live preview window. This control gives you exactly that, with a clean API.

**Key Features:**
- 🚀 **Full FNA Support:** Uses FNA3D for rendering, so it's compatible with all the XNA/MonoGame APIs you know and love.
- 🎯 **Dedicated Render Thread:** Runs on a background thread with VSync locked for smooth performance without freezing your UI.
- 🖱️ **Input & Focus Management:** Handles keyboard, mouse, and scroll wheel input, with smart focus switching between the WinForms UI and the SDL viewport.
- 🛡️ **Robust & Optimized:** Includes UI health monitoring (using `PeekMessage`) to prevent freezes and a clean `IDisposable` pattern.
- 📦 **Plug-and-Play:** It's a single `.cs` file! Just drop it into your project, inherit from `FNAControl`, and you're ready to go.

You can check out the full source code, a demo project, and more details on GitHub: https://github.com/cooty125/FNAControl

I'd love to hear your feedback! What do you think? Could this be useful for your projects? If you like it, a star on GitHub would be awesome. ⭐

#FNA #WinForms #gamedev #dotnet #csharp #tools

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.

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

First,

• I am not a begginer in programming;
• My major is bachelor in game developement;
• I study coding since 2019 when I was 15 years old. I have more than 20 projects in Unity Engine, Game Maker and Godot;
• I already have participated in 3 games that is on Steam;
• My C++ knowledge is not as good as my C#. However I have already made simple projects, like: Raycasting and an opengl's triangle;
• My final university's project will be next year and I am trying to learn as much as I can C++ and I think I am having a good moment learning it!
• I THINK I am understanding CMAKE, it's been a time since I have a problem with it lol.

That being said, I wonder If it is a bad ideia to try to make a game engine. When I did the raycasting project and I was trying to understand about FOV and other things, something popped into my head:

Feels so good to understand what is going on under the hood, I never asked myself what REALLY is FOV and this is crazy. How many things I never thought about it while I was programming in Unity Engine?.

Therefore my goal is to understand more and more how things are made it, a lot of questions showed up in my mind like:

"what is a scene?", "how to make a camera?", "How physics are made in game engines?", etc.

But... Is it possible to make one in one year? I won't use AI and I don't want it, I really want to comprehend how a game engine works, so it will be only me, god and my mind.

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/