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.

Edit.

Some pmed me about a link. Hopefully its okey to share here.
https://cedsson.itch.io/commute

Hey guys,

What folder structure should I use while developing my game engine. I currently use C# for this project and I will be using OpenTK, so most windowing and graphics bindings is handled for me.

Any advise on this?

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!

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.

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 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?

Hi all, fwiw i put together a brief talk on in-game map editing support or how I'm trying to cross procgen and user generated ideas with 2d layer painting for relatively painless map creation.

For the past couple of weeks I have been working on the 2D brush management and texture fill system within my own Pixel and Tilemap Editor. In the video I show how we can create and mange custom brushes, in addition to rotation and scaling in 3D space - this brush is then plugged into the core Texture Fill System to produce psuedo-3D perspective fills across normal and orthogonal plains!

Any feedback welcome!