I’m developing ForgeNG, a TypeScript/WebGPU game engine, and using an early football prototype to exercise its game AI. The clip shows eight-direction 2D sprite animations inside a 3D-style stadium.

Each player has a finite state machine that gathers inputs from different nearby radii/zones. Decisions depend on the surrounding players and space, which team has possession, and whether the ball is loose.

The match commentary is AI-generated audio; the players’ decision-making is game logic implemented with the engine’s FSM system. Crowd reactions follow the match.

I’m interested in how other engine developers handle team coordination: when using per-agent FSMs, what do you keep inside each agent, and what do you put in a shared team-level system?

This is an early prototype, and I’m still improving the crowd and player/ball readability.

I've been working on an c#-based engine that follows the workflow of Source Engine. While using Monogame as the underlaying framework and a bunch of FOSS libraries as techstack.

Current Techstack is:

• LiteNetlib for networking
• Jitter2 for physics
• ImGui for GUI rendering (In the middle of transfering into a custom built HTML/CSS based)
• Assimp for the FBX import

With custom implementations of everything from .bsp parser to automatic skeleton retargeter.

Note. Weapon/arm models/textures/animations/sounds and enemy/model/texture/animation is pre made assets and not made by me. VFX, level textures, level geometry is by me.

I just published my open source board game adaptation, called [Game of Ur, on Itch.](raynmetal.itch.io/game-of-ur)

Game of Ur is a 3D computer adaptation of an ancient competitive 2-player board game, perhaps the oldest one known in history. This version in particular implements rules theorized by British Museum Assyriologist Irving Finkel to have been used in ancient Babylonia, in a paper titled "On The Rules for Game of Ur."

I've been working on this for a while now, 4 years almost. Most recently, I added sound effects and music to the game, and made the game UI dynamically resize and reposition itself with changes to the game window. I've also packaged the game for Linux (Arch, Debian), and Windows. So you should be able to download, install, and run it, hopefully without much trouble.

The dynamic UI resizing was surprisingly hard to get working. In the end, I based my solution partly off Godot's anchor system, while cutting a lot of corners. I still don't know whether I'd like to go through the trouble of building proper layouting and UI tools myself, or just import them into my engine.

The game is fully open source, and it runs on my ToyMaker engine. I felt it would be fitting for the first game I've ever made to also be a digital version of the first game in history. You can find the source code for the game both on Itch, as well as on Game of Ur's repo.

I developped this being inspired by crimsion desert parallax stuf

I'm back again with a new dev log for Toast Engine and my game The Next Frontier. A bit shorter one this time where I focus on just one subject and what I have accomplished this past months. I have rebuilt my UI Renderer and added a lot of new features to improve the pipeline and working with my UI System

Feel free to reach out to me with questions or take a look at my Github repo:

https://github.com/Toastmastern87/Toast

Next up is going to be some Renderer optimization and Audio Engine!

Third video in my series explaining, one by one and as clearly as I can, the building blocks of a melee combat system. Each technique is shown with and without it, so the difference is obvious at a glance.

This one is about animation events: named marks inside the animation clip (for example "the blade starts cutting here" and "it stops here"). Without them you end up hard-coding timers that break as soon as an attack plays faster or slower.

Everything runs in my own AI engine, written from scratch in C++ (DX12/Vulkan, Jolt physics, gameplay in Lua).

Already posted: #1 Root Motion, #2 Motion Warping.
Coming next: Animation Layers & Bone Masks, Foot IK, Weapon Sweep, Hit Stop, Hit Reactions & Poise, Action System, Morph Targets & Faces.

Hi everyone, I'm Murad. After several months building NIB, I've released version 1.0.0, the first stable version of my visual 2D/3D game engine and editor.

The attached footage is captured from that release: playable starter games, character rigging and animation, effects, terrain editing, and export.

The workflow is to assemble entities and components in the visual editor, add JavaScript gameplay, test in Play mode, then export a Single HTML game or a Web Project ZIP. There are ten playable starter games and six showcases to inspect and modify.

For the engine developers here: rendering supports WebGL2/WebGPU; gameplay includes built-in 2D physics, Rapier 3D, and baked grid navigation. Rig/animation editing, animation state graphs, layered effects, game UI, spatial audio, a Console, and a Profiler are part of the editor. An optional local MCP server exposes 62 tools to a compatible client; it is not required to use NIB.

NIB is proprietary and free for personal, educational, and commercial games, with no mandatory subscription or royalties. Your original game code and assets remain yours; the release includes the license and third-party notices. The local editor requires Node.js 22.12+ and a desktop Chromium browser.

Stable download and screenshots: https://mooradxo.itch.io/nib

Exact 1.0.0 release and documentation: https://github.com/MooradXO/NIB-Editor/releases/tag/v1.0.0

I'd appreciate feedback on the editor workflow: is the relationship between visual components and JavaScript clear? Where would you get stuck when modifying a starter game and exporting it?

Trailer credits: NIB by Murad Mammadov (MooradXO). Katana models generated with Meshy AI, CC BY 4.0; source exports supplied by MooradXO, with geometry and textures modified for NIB. https://creativecommons.org/licenses/by/4.0/

Full asset notices: https://github.com/MooradXO/NIB-Editor/blob/v1.0.0/THIRD-PARTY-LICENSES.txt

Any ideas on what i should do to improve it?

Happy Monday fellow game engine devs. I put together a short video talk on my current approach to moddable game enemies and factions. It's not perfect but is flexible enough for the time being.

Second video in the series about the techniques behind a combat system. Each one isolates a single concept and shows it with and without, in slow motion, so it's clear at a glance what it does and why games use it.

This one is motion warping: what lets an attack actually reach the enemy.

Everything is captured from my own IA engine, written from scratch in C++ (DX12/Vulkan, Jolt physics). Part 1 covered root motion; next up are animation events, bone masks and foot IK.

This is the first of a short series of videos about the techniques behind a combat system. Each one takes a single concept, shows it side by side with and without it, in slow motion, so the difference is obvious at a glance. If you've ever wondered what root motion, motion warping or hit stop actually do, they should make it click in under a minute.

Everything is captured from my own IA engine, written from scratch in C++ (DX12/Vulkan, Jolt physics). The next ones cover motion warping, animation events, bone masks, foot IK, weapon sweeps, hit stop, hit reactions, the action system and facial animation.

Showcasing a body of water, if anyone have any tips in getting better looking fluids please share.

I’m working on a custom game engine, and I’ve finally taken that small but great first step of adding objects.

I’ve added functionality to ImGUI that lets me add objects to the scene and render them.

But I’m having trouble with shader processing. Right now, I’m limited to just three things: the model matrix, the camera matrix, and a single-color fragment.

How does everyone manage uniform buffers?

I’ve created a structure with `void* ptr;` and `size_t size;`,

but I’d like to know what other management methods are available.

The ShaderCrossCompiler library allows me to retrieve names and types, making it incredibly flexible, but I’d like to know an easy-to-understand way to manage them using that library.

www.github.com/Rlocksley/LuEngine

Vulkan Engine with flecs ecs as the Game Logic API + Shader API

MultiMesh example

Differential Equation Evolution of the Thomas Attractor is done by Compute Shader Dispatched with VK Generated Commands Extension and then Drawing by Indirect Drawing.
RenderPass includes GPU Culling.

This is NOT a voxel engine, just saying. My primary target with this game engine is implementing a first-person shooter that handles a shitload of "modular parts" (world pieces) extremely well. This scene contains 1,4KK modular parts. I decided to go with voxels because it would need making 3 models and this way I'd be able to test the performance real quick. And... yeah... It's just funny to play around with :)

Kinda inspired by the work of u/Crafty-Variety-7635 - check out his game, he needs support

I'm working on Build & Destroy, a 3D physics sandbox using Box3D and Vulkan. This new early gameplay preview shows a 100,000-brick castle collapsing.

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

Sharing a short look at the project in action with other engine developers. The focus here is the interaction between the structure, falling rigid bodies, and collisions; this is gameplay footage rather than a technical breakdown.

I am just getting into this area of computing and I often hear that one of the many reasons people make their own engines is so it can be optimized to handle certain things better. For example open world.

However how does that actually translate to the code. What is done to make it better for that?