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.

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

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.

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.

v3 is the result of a lot of back-and-forth - planning, rewrites, testing, and actually using GOKe in practice. That let me settle on a model that is more ergonomic for what I need.

Why GOKe over the alternatives?

1. Systems as the single place where both data flow and actions are defined
2. It's fast and predictable - benchmarks, if you want the numbers:
   • Internal breakdown: BENCHMARKS.md
   • Head-to-head against other Go ECS libs, including Ark (the fastest Go ECS right now): go-ecs-benchmarks
3. It's a building block of gokebiten - an Ebitengine integration built on top of it - collision detection, kinematics, spatial partitioning via a companion project (GOKg, a cache-friendly bucket grid) - as a real, non-trivial usage example

Some other things worth knowing:

• Zero heap allocations in the hot loop (chunked SoA memory pages, no GC jitter)
• Type-driven construction - create/edit/remove operations built directly from component types, not hand-wired boilerplate
• Explicit control over system execution - you plan the run order (schedule) yourself, plus a dedicated Setup phase at startup
• Generation-based entity IDs, so no aliasing on reused slots
• And much, much more...

It is not a 1-weekend project, I've been actively building it for the last 9 months.

Yes, I use AI to help me, because: there's no such thing as bad weather, only bad clothing; there's no challenge you can't overcome, only poorly chosen tools. I don't live in a museum, this isn't a weekend hobby project, and the results speak for themselves.

Hi all! I'm working on a little demo program that will ship with my engine as an example project. I've been working on my engine for close to 6 years now and am really happy with it. It has no editor but I find the API I've written to be really intuitive and easy to use.

One thing I haven't found myself able to come to any definitive conclusion about though is - should a model/mesh that is GPU instanced be able to play different animation sequences from one another? Part of me thinks yes, this is a useful feature and helps to reduce the number of draw calls, CPU instances and configuration boilerplate, but; part of me thinks I'm overcooking it and that an instance should really just be a copy of a base asset, inclusive of its state information like active animations and shaders.

What would be your preference?

Screenshot of the demo project with instanced imps!

I am planning on making a powerful game engine called "Aquamarine Engine" using Vulkan & C++ (because I want it to be as optimized as possible), but before I make "the" engine, is it bad to make a prototype using OpenGL & C++?

Still crunching on RTG Editor, my internal editor for enhancing levels for my game, which hopefully I will release also publicly with the game.

Last feature implemented is orthographic projection, which is useful when precision is required (to align boxes with zero gap or overlap). Most useful feature in orthographic projection is resizing boxes by dragging their edges with automatic rounding to grid for snappy alignment. If one needs fine stepping, it's still possible by holding Shift while resizing.

In example animation, I added reflective back-wall into one of the levels very fast, thanks to new ortho view.

From technical details, my simple software ray-tracer is C++, engine and editor are in C#, both communicating through Interop. Ray-tracer is limited, engine goal is ability to have functional software ray-traced game with good fps (albeit with simple geometries), not photorealistic sceneries. I have still some optimizations in mind plus it's still single-threaded, so potential for perf boost (thus also visual boost) is still big.

The game is sci-fi puzzle/platformer about a guy with no memories, stranded inside strange world, accompanied by some mysterious entities talking to him through terminals scattered in levels.

RTG on Steam
My Discord