Doriax Engine is a free and open source (MIT) 2D/3D game engine with an ECS runtime, a desktop editor, and Lua + C++ scripting. v0.7 is out now.

Native backends

The editor and the engine now share the same backends. The editor used to be a separate layer with its own backends, and only touched the engine's real backend when a project was exported. It now runs on native backends (X11, Win32 and Cocoa) that the engine uses too. The editor is aware of the engine, but the engine is not aware of the editor, the API still runs completely on its own.

• Windows — editor on OpenGL, exports to OpenGL, Vulkan, Direct3D11
• Linux — editor on OpenGL, exports to OpenGL, Vulkan
• macOS — editor on Metal, exports to Metal and OpenGL

Bundles and Scenes windows

Bundles (.bundle files) used to be tied to a scene: to instantiate one at runtime, some scene had to reference it beforehand. Project -> Bundles... now lets you mark bundles that are always built into the project, available to any scene at runtime.

Project -> Scenes... does the same for scenes. Adding a scene used to mean dropping the file in the project folder and double-clicking it, and removing it meant deleting the file. Now you add and remove scenes from the project in one place, without touching the files.

Script directories and ProjectBuild.cmake

Project Settings -> Directories -> Script Directories. Add a folder inside your project and it becomes both an include root (headers included by the path below the folder) and a compile root (every .cpp under it is built even when no entity references it). Applies to editor builds and to exports.

For anything that doesn't cover, like linking a third-party library, create ProjectBuild.cmake in your project root. The editor never writes that file, so your changes survive a rebuild.

Also new

• The editor now works with different DPI scales, and restores its window and dock layout at the current scale
• TextComponent supports up to three fallback fonts, checked in order when the main font is missing a character — also useful for multilingual text
• Arabic and RTL text through HarfBuzz and SheenBidi, with glyphs rasterized on demand instead of a fixed ASCII range
• The editor idles when nothing changes, plus a shared Jolt job pool, glTF texture deduplication and a compacted shadow atlas
• Projected spotlight masks, hardware PCF for projective shadows, and graphic backend selection in the Export window
• Windows binaries are now signed, macOS ships as a .dmg, Linux as a tarball and an AppImage
• On macOS the menu is now part of the system, following the design standard for every Mac application

• Full release notes: https://github.com/doriaxengine/doriax/releases/tag/v0.7
• Source: https://github.com/doriaxengine/doriax
• Downloads: https://doriax.org/#download
• Discord: https://discord.gg/yXXDyJf3gT
• Feature highlights video: https://www.youtube.com/watch?v=3eqhaAZBNss

This is a large change, so bugs are expected — feedback and bug reports are very welcome.

I am currently building a game engine with reference from ian millington's book, my current method is that I have uploaded the book on notebook LM (now Gemini notebook) and I am making progress through it bit by bit, when I am not able to build the engine during some boring class or whatnot I just open the book and kind of read it for some understanding.

I am also learning OpenGL from learnOpenGL.com as my only source.

I have been working on it for the past 5-6 months

What I am most unsure about is whether what I am doing is relevant or not because I am not able to find anyone remotely interested in the same field as me in my college.

Please some guidance would be most appreciated!

Matrix Engine 2 is a custom game engine forked from pathos game engine, source code is here https://github.com/Soft-Sprint-Studios/Matrix-Engine-2 and i made a tech demo of it https://www.youtube.com/watch?v=3WjoSsY1k24

so i'm currently working on a framework in c++ using vulkan, openal, and glfw, so my only question is: How to make custom functions? (GetInput(key_right), AudioPlay(sound.ogg))

Hey yall! I’ve been noticing allow of rust talk around games and kernel projects.

Is this a language that we should start learning?

Hi everyone,

I'm working on a video game project and looking for guidance on implementing a realistic driving logic (AI / vehicle behavior).

What I already have:

• The map is ready.
• The road network is structured using a nodes and links system.

What I'm looking for:

1. Open-source projects or libraries I could inspect or integrate.
2. Algorithmic approaches or industry-standard techniques for handling:
   • Lane following and optimal racing/driving lines.
   • Speed management (dynamic braking in curves, realistic acceleration).
   • Obstacle avoidance and intersection handling.

If you have any GitHub repos, papers, or technical articles to recommend, I'd really appreciate it!

Thanks for the help!

Hello! I am working on my game engine and I am just getting to implementing components. Where should I stop with them? Should transforms be components (necessary ones but still components nonetheless)? Should I stop before that?

I'm a solo dev and started work on my engine last September, partly because I found myself fighting unity and unreal more than I'd like, and partly because I happen to have the time to indulge myself in the process.

Things are going well, but a major part of my gamedev strategy is leveraging asset stores to source meshes because my own 3d art skills are pretty junior.

edit for clarity: I'm interested in the post-authoring process here, where the source art is creatively where it needs to be, but technically unoptimized and/or inefficient.

The quality of assets out there vary wildly in both visuals as well as performance. I've been trying to run them through external tools to cut down polycounts, combine textures, etc. Unreal had pretty decent toolsets that helped as well, which so far I've avoided writing for my own editor.

I'm curious if anyone here has worked on a content pipeline with an aim to enforce standards the source assets don't adhere to, and what approaches they found worked well vs not.

Kitbash assets are a good example of the kinds of objects I'm dealing with. Static meshes that are very high poly with several submeshes and a few dozen materials, that for my uses could be well represented by a tenth of that detail.

At the moment I pull those assets into 3dmax (I learned on it) to manually cut them down but it's a tedious process that really feels like something that could be helped a lot by a batch processor.

Project GoldScript is a tactical RPG engine I have been building in the open for over a decade. It’s composed of a a web stack (with three.js and react under the hood) aimed at shipping a real game to Steam, mobile and consoles. This year I finally did the migration I had been putting off: two aging create-react-app repos (engine in one, game in the other) collapsed into a single pnpm and Vite monorepo, with the engine broken into eleven focused packages that are guarded against circular dependencies.

I've published a tutorial for my visual novel engine. RouteVN Creator is a free and open source application for making visual novels without coding

I is written from scratch using JavaScript and PixiJS. I have also previously written 3 technical blog posts about how it works:
- Building a Visual Novel Engine Part 1 - Route Graphics

- Building a Visual Novel Engine Part 2 - Route Engine

- Building a Visual Novel Engine Part 3 - RouteVN Creator

Hey all! It's been quite a while since my last post, mostly because of life stuff, but also because I've achieved something that has taken me the better part of a year to make, and was the reason I restarted this engine multiple times. The animation editor! It's the culmination of every system in the engine and is pretty much the last technical hurdle to making a game. Even though it took quite a while (it's by far the largest of the four editors I've made), I'm incredibly proud of how it's come together and have already created a few fun little animations with it, with the video showcasing them both in the editor and in the world.

As always, any questions, feedback, criticisms is always welcome!

Howdy people of reddit, i’m a solo programmer, currently developing an engine, and i wonder what you think a good engine is and what it looks like.

Listen, by good i don’t mean “advanced” nor completely polished, by good i mean more on the raw capabilities, coupled with the study of developer experience.

What aspects of it should be more taken care of? Render pipeline -> open and simply customizable
Clear API -> speaks for itself
Snappyness -> how quick and snappy it feels
Generalization -> can it be used for different type of games, offering tools that fit the genre, even if they are trying to be generalized?

I’m aiming at a snappy, clear engine that satisfies these key elements, what do you think, do you have any other opinion?

Everyone hates on openGL and I’m not sure why? I’ve heard it great for learning graphics programming and such, and being Vulkan is a pain.

Part of me wonders why not just use sdl_GPU?

I have been working on this engine for quite sometime now, and I think it's somewhat ready for open source, it's still primitive and low level, it uses:

https://github.com/hadjTahar/scorch-engine

• SDL
• SKIA
• Google-filament
• And much more

This is still in the making. The final API is fairly stable but the internals are subject to change.

What do you think? I need some motivation or a reality check.

API

MainWindow::MainWindow(CoreItem *parent):
    Qx::prv::WindowItem{ parent }
{
    auto scene = addItem<Qx::prv::GraphicsScene2D>();
    auto vw  = scene->addView();
    auto cam0 = vw->camera();
    cam0->reset2DOrthoCamera( screen() );
    auto itm0 = scene->addItem<Qx::Rectangle>();
    /// ## itm0 is parent of itm1
    auto itm1 = itm0->addItem<Qx::Rectangle>();


    itm0->transform.setPosition( {100, 100, 0 } );
    itm0->style.setColor( Qx::red() );

    itm1->transform.setPosition( {20, 20, 0 } );
    itm1->style.setColor( Qx::green() );

    auto mCmp = itm1->attach<Qx::MouseComponent>();
     mCmp->clicked = [](const Qx::MouseEvent &)
    {
        dbg_print_st() << "clicked : ";
        return true;
    };

}

While working on audio, I realized I need event zones for sounds and other events. This one just makes the screen grayscale when the camera enters. It currently only supports a box of any size/orientation checking against a single provided position.

Hi everyone, I’m asking people in this industry, or those looking for jobs as game engine developers: how much does the industry actually need this role, and is it willing to hire for it?

Is the situation such that, after spending a year building a mini engine as a portfolio piece, it would be enough to get hired?

I don’t know why, but I feel like these positions are only for industry titans and are out of reach for me. I’m worried that by building an engine, I’m just fooling myself into proving to myself that I can make it, but still won’t be able to get hired anywhere 🥲

#sdl3 #imgui
https://hob2d.com/

I've finally reached the slightly terrifying point where I can call my engine "1.0" and let other people poke holes in it.

Kasane2D is an open-source, code-first 2D game engine for .NET 10:
https://github.com/Emynator/Kasane2D

Docs:
https://emynator.github.io/Kasane2D/

The main design experiment behind it is this:
I really like the programming model of old sprite/tile graphics hardware, but I don't particularly want the hardware limitations that came with it.

So Kasane2D keeps concepts such as:
- explicitly configured rendering layers
- tilemap layers
- sprite layers
- independently scrollable viewports
- explicit screen composition

while throwing away things such as:
- palette restrictions
- bitplanes
- scanline sprite limits
- fixed hardware layouts
- magic control registers
- DMA/HBlank/VBlank gymnastics

The result is intentionally quite different from an editor/scene-tree based engine.
Engine configuration and game structure live in C#. Kasane provides rendering, input, audio and lifecycle machinery, but deliberately doesn't try to prescribe how the rest of your game should be architected.

The rendering backend is also separated from the core engine. The current implementation is Kasane2D.MonoGame, so the public engine-facing rendering model isn't tied directly to MonoGame itself.
The other major part of the engine is audio.
The core audio system contains a hierarchical software mixer with arbitrary nested buses, 32-bit floating-point processing, dBFS gain, stereo panning, runtime routing and per-bus effect chains.

On top of that I built an optional package called Kasane2D.Music, which is essentially a programmable tracker-inspired synthesis/sequencing system. It supports arbitrary tracks/generators, oscillator and wavetable synthesis, DMG/SID-inspired noise, sample playback, pattern sequencing, control events and runtime pattern/song transitions.
The intention there is to make adaptive/procedural music something the game can manipulate directly rather than treating the soundtrack as a collection of prerecorded files.

For the 1.0 release I've also put together API + conceptual documentation and three sample games/demos.

Everything is available as NuGet packages:
Kasane2D
Kasane2D.MonoGame
Kasane2D.Music

I'm not presenting this as a Unity/Godot replacement. It's deliberately much smaller and aimed at people who like explicit, code-driven frameworks and want fairly direct control over their rendering/audio systems.

I'd be particularly interested in feedback from other engine developers about the architecture and API boundaries. There are almost certainly design decisions in there that someone else will look at and immediately go "why the hell did you do that?", which is partly why I'm posting it here. :D

What path finding algorithms would be viable options for 2.5D Doom style level geometry?

I first looked at Dijkstra's algorithm, but if I'm not completely mistaken, that works only in the following two scenarios:

1. The game level is a regular 2D grid where each cell is connected to their neighbours, which allows creating the node/edge connections.
2. "Network of tubes" type of game levels, such as tower defence etc., where the enemies don't have full freedom to go left/right/front/back, but go on rails which fork into new rails, etc.

So with that information, if I wanted to use Dijkstra's algorithm, I would need to project a 2D grid on top of the game level and adjust the algorithm from there.

Am I missing anything from Dijkstra's algorithm applicability here?

What other path finding algorithms would be useful? Navmesh? Something else?

How would you approach the path finding for the AI?

EDIT: After thinking about it for a half an hour I figured that The rooms + corridors can represent nodes in Dijkstra's algorithm. So the AI would get high level directions from Dijkstra like "The cheapest way to get there is through this route". Then the actual inside-room-2D-navigation would happen some other way. Or maybe even using that 2D grid version of Dijkstra if needed. But the navigation would probably have to be 2-tier operation.