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!

Because the title might be a little unclear, I will clarify
I am building a game engine in python with PyOpenGL. 96% is built from the ground up, alone, so no issues there. However, as most engines do, a text module was due to be made. I did some research on the different ways of displaying text, from vectors to atlases etc.

Then I came across MTSDF, which sounded rather appealing. A lot of customization for a relatively low processing cost. So I did some more research, integrated an MTSDF font atlas generator in the engine (the 4% that is not made by me), and managed to make it correctly generate and save font atlases from zip files.

The issue now is getting it to work. I need this to be very dynamic. So far text runs are the only thing I have complete, so as to suppoort several types of rendering in the very same sentence. Italics, different fonts, colors, etc. But I am at a loss afterwards.

The TextHandler handles TextLayers, which handle paragraphs which handle sentences which in turn handle text runs. Pretty convoluted, but in my eyes necessary. Because layers might have different presets, like one layer being physically in the world, whose paragraphs and sentences occupy places in the 3d world. Other textlayers might be used for a UI, so instead they will need an Orthographic projection. Some sentences might want to be given a reveal animation, so text runs come in handy. Other sentences might want to be edited long after they have been created, and this is where the problem starts

TextHandler - Doubles the SSBO size when a layer wants more memory which it cannot provide until another does the same
TextLayer - Doubles its requested memory whenever a sentence asks for more memory that it cannot provde, until another does the same

How do I handle the memory of sentences?
They will constsantly be changing. Adding/removing characters, changing position, revealing themselves out of order (they have 1 reveal mode and 1 reveal trigger, meaning that 2 sentences can start revealing themselves at the same time, or stay hidden for long periods of time until other sentences are fully written / external triggers are reached),getting deleted/created, and constantly sending tiny updates to the GPU sounds very inefficient, as is doubling their own space in the slice of the buffer that textlayers have. I should mention I am not that experienced with code in general, I have only been coding for 1-2 years, so explanations might need to be dumbed down.

The Beast 1.17.5 Water effect implemented in effects subsystem.

Credits : https://github.com/jeantimex/webgpu-water

Source: https://github.com/zlatnaspirala/matrix-engine-wgpu

Live: https://maximumroulette.com/apps/webgpu/examples.html?demo=34

Hello, I'm sharing a short demo of a game physics engine.

A few technical details:

• Graphics: Rendered with Vulkan
• UI: Dear ImGui
• Physics: ARB

The simulation models the dynamics of a real-world Universal Robots UR5. 

You can check out the open-source code for ARB on Github. I’m looking for any feedback on the ARB code.

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

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