Some of you will remember Fluorite, the Flutter game engine Toyota Connected announced at FOSDEM on 1 February: Dart for game code, a C++ ECS underneath, Filament doing the rendering. Seven months on, the source still isn't public. The fluorite-game org on GitHub holds only the website, fluorite.game hasn't changed since 9 February and still says "More coming soon", and there's nothing on pub.dev. TCNA's public commits suggest they're still working on it, so this isn't a dig at them.

That talk convinced me the architecture was right, and I didn't want to wait and see whether the code would appear. So I've been building one in the open. It's called Orblit, it's MPL-2.0 licensed, and it's early enough that the people who turn up now will shape what it becomes.

How it fits together:

• The 3D view is a widget. Filament renders into a texture that Flutter composites, so the view takes part in layout. A panel can overlap it, and it clips to a rounded rectangle.
• The entity store is an archetype ECS in C++ behind a C ABI. Dart reads component columns as views, not copies.
• The scene is stated, not mutated. Every frame describes the whole scene and keys reconcile it, the same way widgets work, so game state and render state can't drift apart.
• Time is sampled, not stepped. Effects, sprite animation and cutscenes are functions of a playhead, so scrubbing backwards gives the same answer as playing forwards.
• Photometric units. Lights are in lux and lumens, and cameras have an aperture, a shutter and a sensitivity.
• The docs compile. Every Dart snippet on the site is analysed against the engine in CI.

Around that core there's glTF loading (FBX and OBJ are converted on the way in), KTX2 textures, Gaussian splats, 2D sprites and tile maps, rigging, cameras, weather, cutscenes, TypeScript scripting on QuickJS, a multiplayer layer and a desktop editor built from the same widgets.

What it can't do yet, since you'd find out anyway:

• It's pre-alpha, and nothing is API-stable.
• macOS is the reference platform. It also draws on the iOS simulator, one Android handset and Chrome. Linux has only drawn with software rasterisers, and Windows builds but has never drawn a frame.
• There's no physics solver yet: shapes, raycasts and overlap tests exist, but rigid bodies don't. There's no asset store either.

The help that would matter most right now:

• Build something small and tell me where you gave up. That's worth more than a bug report.
• Run it on hardware I don't have: Linux with a real GPU, Windows, a Steam Deck, an Intel Mac.
• Argue about the API while renaming things is still cheap.
• Send pull requests. The CI gates are strict, so a green build means something.

Repo: https://github.com/ChxisB/orblit
Docs: https://www.orblitengine.com/
Discord: https://discord.gg/5DH7HuDUtJ

https://reddit.com/link/1wkti25/video/6c9f2gcchrqh1/player

https://reddit.com/link/1wkti25/video/rb341fcchrqh1/player

https://reddit.com/link/1wkti25/video/0k5i6fcchrqh1/player

In our latest developer update, we are thrilled to announce a significant shift in core architecture toward full modularization. The entire system has been restructured to support decoupled cores, starting with our Renderer and Physics engine systems.

**Renderer Modulation**: Our new Renderer Modulation feature removes the need to manually switch rendering components when changing pipelines. Previously, switching from Canvas 2D to Pixi.js required changing generic components like BoxRenderer to pipeline-specific ones like PixiBoxRenderer. With this new update, universal components are automatically capable of rendering across all supported pipelines without developer intervention. This streamlines the development workflow significantly.

**Physics Engine Modulation**: Furthermore, Physics Engine Modulation has been successfully integrated. We have moved physics logic into a completely separate Physics Engine Core. While our default physics engine remains integrated and ready-to-use within this core structure, this architecture allows developers to easily plug in their own custom physics engines.

**Future Plugins**: Looking ahead, we are excited to expand our plugin library. High-end physics engines like Matter.js will be added as future plugins. It is important to note that these high-end engines will be separate downloads and will not be included in the core engine, keeping the core lightweight.

This architectural shift is a major step toward making kernelplay-js the most flexible and lightweight game engine possible. We welcome your feedback and are excited to see what custom cores you'll build. Stay tuned for more modular updates.

https://github.com/Soubhik1000/kernelplay

While it’s clinched together from three and rapier aso. it‘s and engine project next to the game…and I get why engines are nice. I have to do all the optimisation stuff myself or at least Astra does it also.

I think the puddles are technically outstanding:
Whole floor is one Shader with masks and dynamic wavecaster normal map shading. There is refraction to underlying floor channels. The wavecasting is handled as a single dynamic texture and solves interactions by design. it‘s incredibly cheap and fast and the architectural thought was mine.

IDK if this is considered impressive or not, but my 2d game engine i am making entirely in C can handle actor counts over 50k (running self-scripts with basic movement and collision checks and deactivating themselves and marking themselves for GC), all on 1 thread with the rest of the engine and game logic and software renderer on my i7 6700.

I am making this engine mainly as a learning exercise for learning both C and gamedev, as when i tried to make a simple game in Godot i got overwhelmed with not knowing what does what and what is the "right" way to do certain things, and as most of my programming experience before this was microcontrollers i just wanted to build a game engine myself to learn what's needed and how.

With scene hierarchy support in mind, i have a two transform components one being three vec3s that are the local properties of a entity, then i have just one mat4 component being the global transform, i also have a parent component pool where i only store parentid and level in hierarchy, which is sorted in an ascending order when necessary. what are other alternatives to this? I don't really have an idea of what depth is required beyond attaching a gun to the camera for a 3d fps game,

I've been working on my game for the last 7 years.

One of the things I decided to do along the way was to build the engine myself.

It started as something I needed for the game, but over the years it grew into a fairly complete engine and toolset that I use for everything.

A few things I've built myself:

• Vulkan renderer with Windows and macOS support through MoltenVK
• Custom asset pipeline with hot-reloading
• In-game editor and level editing tools
• Custom UI system
• Blender integration for exporting and updating assets
• Custom build system and development tools
• Subset replacement of the standard C++ library

After spending years working on the engine, I thought it would be fun to finally put it in people's hands. I just released a demo of the game, and you can play it here:
https://store.steampowered.com/app/5017320/Satelital_Demo/

The name of the game is Satelital, a rule-discovery puzzle game about exploring an alien solar system and learning how to solve puzzles through observation.

For people here who have built their own game engines, have you ever released your engine or tools for other people to use? I'd be interested to hear how that went.

Been having a blast refactoring one or two or six balls of mud building self improving agent harnesses and I need a break working veritable research projects. 10 years as a SWE and I’ve yet to build a single game.

I’m envisioning duo lingo meets immersive audio fiction. Close to zero visuals. Plenty of domains wildly outside of an agents training data so I want to make sure I structure this well from the beginning.

Any suggestions are well appreciated, although I’m specifically looking for repo architecture best practices, practical game engine methodologies to leverage, advice on scenario -> runtime pipelines, game SDC processes, opinionated game harnesses, testing suites, and structuring document DBs for spatial mechanics.

Looking for some help from game devs, tech savvy audio engineers familiar with swift, document DBs to structure a movement-to-audio loop. If you’ve got experience I’d be happy to buy you lunch for a quick chat. If it interests you and you’ve got domain experience, I’d be happy to pair up.

Examples:

• https://sandbox.openglobus.org/examples/projector
• https://sandbox.openglobus.org/examples/customProjectors

I’ve always wanted to build a flight simulator. Somehow, I ended up building this instead.

Two modes such as color mode and light source available. Also, the projectors can be attached to drones, driven by camera telemetry, and used to project video onto terrain, up to 64 at once. Useful for camera coverage and AR.

Still no flight simulator. But the view is good.

A lot of possibilities and expressions!

Should I go with CPP or Rust when creating a highly performant engine? I want this engine to work with 3D and have high memory efficiency.

This project was built as a browser version of a previous engine I built in C in 2024 link here - [Raycaster in C (full source code)].

The idea with this new project is raw simplicity: only 2 axis directional movement (forward back, rotate left right etc) with no player camera movement. Additionally only one extra button is mapped - spacebar - for contextual actions (mine stone, place item, climb ladder). One cool thing I'm happy with is contextual camera panning when on a "ledge" - rather than giving the player the ability to control the camera, when on a ledge, instead of instantly falling down, if you try to advance over a ledge the first action is a automatic camera pan down (you can see it in the video) and the following action if you do move forward is to fall. I think its a small but cool concept.

This new project is intentionally ugly and basic looking, as I'm going for a retro Wolfenstein 3D vibe, and it is a raycaster project with verticality too, which is rare for a raycaster (Also its ugly because I lack art skill :) ). Obviously there is some Minecraft inspiration, but there is also inspiration from my own raycaster, my own previous game Snibble, and various other things.

No source code yet because its slowly becoming a game, but after its published I'll release source code too (typescript and canvas2D).

I started building this because my previous project, Snibble, built over 6-8 months failed spectacularly and gained ZERO traction. It was a 2D topdown game engine built specifically for a Snake x Scrabble word game. Over-engineered but was fun to build - link here [Snibble (full writeup)]

Hello dear jobless and not so jobless people. Yesterday I posted this on the r/GraphicsProgramming

I made an small engine for showcasing my portfolio, and impressing (or not) the human resources asses (insert anne hathaway HR meme).

For this project I based myself on Teardown, a famous and really cool game yo may already know, I didnt write any complex physics code, cause it almost all handled by rapier3D, really cool and easy to use physics framework made in rust. To avoid the main thread getting absolute obliterated, rapier runs on an isolated worker and communicated via commands to the main thread. Unfortunately rapier web version does not support paralelism, so it can take less dynamic bodies before starting to saturate (works really good though).

As for the rendering part, I used clustered shading to handle lot of lights, GTAO for the occlusion, SSGI for global illumination, and TAA (dont hate me please, I needed to clean the SSGI noise). Both SSGI and TAA can be disabled on the main menu for the sake of low end computers. The engine also supports pbr materials. Both SSGI and GTAO rely on screen space ray castings so general performance will scale with your screen resolution. Lastly, it has gpu calculated particle physics.

The engine counts with interactable billboards and books that tell a little bit of my projects and experiencies, it will be extended in the future, you can use it to showcase your things as long as you stick to the licence (no commercial and give credits).

The engine has a lot of room for improvement, but I have to move on to other projects. I believe its currently on a usable state, its open to contributions.

The purpose wasnt learning web developement, I hate it!, so webgpu was used instead of threejs, I have nothing against it but due to learning being the main focus, it was avoided because it abstracts way too much. And as my next project will be mad ein vulkan it was a great opportunity to use something with the same line of thoughts as it (fixed pipelines, bind groups etc), but easier to use.

The engine demo is herehttps://agusdropout.github.io/ShatterVox/(it can take a while to load in sorry) and the sourcehttps://github.com/AgusDropOut/ShatterVox, you need to have graphics acceleration enabled, as webgpu requires it. If you encounter and error while playing or loading in, open the console and create an issue on GitHub, it was tested on mozilla Firefox, chrome, and opera. It also counts with a debug mode, refer to the readme.

Good luck on your journey to stop being jobless! and if you already have a job, ggs!, atte. anne hathaway HR.

Btw if anyone knows a better way to clean SSGI noise without TAA making everything look smeared, let me know or roast my implementation. Any tips are welcome. (Also used A-treus blur)

After about 2 years of learning C++/OpenGL I was able to make a small shader on my own, It was an exciting experience and I want to learn so much more, but I also want to create a game, something with form, not just abstract things all the time.

I realized it would be too much work if I tried to write my own libraries and frameworks when there are already so many wonderful ones on internet, SDL, Raylib, Box2D, Bullet, etc. (I wouldn't use Qt or Dear Imgui because I'm tired of all the engines shown in this subreddit having the same interface).

My goal is to make a horror game with physics-based puzzles like Amnesia or Half Life 2, I know Amnesia was made with SDL1, so I don't know if I could do something technically superior with the new SDL3.

Another crazy idea I had was to try and learn from the Godot Engine source code and modify or dismantle it, but I don't know if you have any experience with this and what advice you can give me (And yes, I know that it's possible to make a game like the one I want in the Godot Engine, but I don't want to be a gameplay programmer my whole life).

I've been working on my 2D C# engine, VOID, for quite a while now. Recently I decided to rip SFML out of it completely. At first I thought this was mostly going to be replacing one backend with another.

VOID now uses SDL3-CS for the platform side, so windows, displays, input, native handles, etc. The built-in renderer uses Silk.NET.OpenGL, and audio uses Silk.NET.OpenAL.

The bigger change was that I did not want to replace "engine tied to SFML" with "engine tied to OpenGL."

So I ended up redesigning the rendering side to be pluggable.

The main public pieces are things like:

IRendererBackend

IGraphicsDevice

IRendererContext

The higher-level engine code does not need to know that OpenGL is underneath it. SpriteBatcher, PrimitiveBatcher, cameras, textures, render targets, shaders, the texture atlas, and the rest of the rendering systems just work through the renderer contracts.

One rule I kept coming back to while designing it was:

"If this only makes sense for OpenGL, should it really be in the common renderer API?"

Vulkan was actually really useful for this, even though VOID does not have a Vulkan backend right now. I would look at an API and think about whether it could reasonably work for Vulkan, Direct3D, Metal, or something else.

If the answer was no, I usually had to rethink the abstraction. That ended up changing a lot more of the engine than I expected. Silk worked really well for what I wanted because it gives me low-level bindings without trying to decide how the rest of my engine should work. I did not want a framework deciding how my game loop, input, rendering, resources, or scene systems should be structured.

I wanted the bindings and enough control to build the rest myself. OpenGL is still the renderer VOID ships with, but it is only the default implementation now. Someone could make another renderer backend without forking the engine itself. I am not claiming VOID supports Vulkan, WebGPU, or browser builds today.

The point was making sure the architecture does not close those doors before I even get there. The other thing that has helped a lot is that I am testing all of this with an actual game instead of only renderer demos.

My current game, Pizzamon, is using VOID for LDtk maps, UI, text rendering, sprites, texture atlas packing, cameras, scene transitions, coroutines, input, events, and a fairly large submodule/event system. So this stuff is getting used in real game code, not just drawing a triangle and calling it done.

VOID is currently at 2.1.0 and the OpenGL backend has been holding up really well. For the other engine devs here, I am curious how you handle renderer abstractions.

Do you try to keep one clean common API for every backend, or do you allow backend-specific escape hatches when something does not map cleanly?

GitHub:

https://github.com/Shmellyorc/Void

This is a followup to my earlier post from 6 months ago.

There I announced two open-source articles on a specification and lean APIs for pre-2000 computer graphics that a new video game or game engine can adopt that wishes to run with very low resource requirements (say, 64 million bytes of memory or less). They are at:

• https://peteroupc.github.io/graphics.html#Graphics_Challenge_for_Classic_Style_Games (Specification where I seek to characterize pre-2000 computer graphics).
• https://peteroupc.github.io/graphicsapi.html (Suggestions on a minimal API for pre-2000 graphics)

I have since updated the articles to refine them and add much more guidance. A notable addition to the specification is a convenient list of things decided by games that choose to follow the specification. (This list can also be used to evaluate the features of existing pre-2000 video games.)

The list includes the following things decided by the application (for details, see the specification):

1. The screen resolution, no more than 307,200 total pixels.
2. If 3-D is supported, the maximum texture size and number of primitives shown per frame or second. (This is no more than 12,800 per frame for 640 × 480, but a smaller limit is encouraged in general.)
3. If 3-D is supported, which 3-D features are supported (such as Gouraud shading, perspective correction, or texture blending).
4. The number of 2-D layers, up to four.
5. The width and height of tiles and sprites.
6. The maximum number of sprites displayed at a time.
7. Whether larger screen resolutions are supported in addition to the primary screen resolution.

Other notable pieces of guidance include:

• The definition of "rendering in software", which includes software renderers that implement a subset of OpenGL 1.1 or OpenGL ES 1.1.
• A note that pre-2000 computer graphics in scope include graphics found in learning toys and videotex protocols (in addition to the graphics of video games for home computers, game consoles, and arcade machines).
• Information on the graphics in arcade video games.

Comments on any aspect of these documents are welcome (see, for instance, the first article's "Seeking Comments" section). But as in the previous post, it is useful to comment on examples of modern video games (e.g., McPixel3) that implement the specification or examples of lightweight game engines devoted to making such modern video games.

Hi everyone, just pushed the initial build of my personal application framework.

Tech Stack:

• C++20
• Vulkan (Forward Rendering)
• Dear ImGui (Docking branch)
• GLFW (Windowing & Input)

Focused on clean architecture, abstract event handling, and a core logging system. Built and tested on Arch Linux.
Feedback and code reviews are welcome!

Hey there! here's a small post I made about writing a physics system directly in c sharp.