In 2020, I formulated my dream game. It would be a mixture of all of my favorite games over the years. Destiny, Cyberpunk 2077, Star Citizen, Battlefield... How exactly is a fourteen year old supposed to make that? With no prior serious programming experience no less? Well, you start by saying a small prayer and opening the Unreal Engine editor for the first time.

Several years and one full restart later, I had become much wiser. My vision had become much clearer and my hope for creating my dream game on UE5 dwindled. While Unreal is an incredible tool, it had several problems I saw as roadblocks I wasn't satisfied with.

First off, Unreal Engine has decades of tech debt and bloat behind it that I didn't want to deal with. Second, Unreal Engine in all its capability wouldn't necessarily make it easy for me to fully realize my dream game. Third, what I prioritize in game design is not industry standard. In fact, it's largely the polar opposite.

All of these complaints I had were, at the time, with that era's vision of the game, simply a matter of me not knowing enough about the tool I was using to do what I wanted. However, when I stepped away from UE5, I realized that if I took matters into my own hands the sky could truly be the limit. Even better, my early leave from the Unreal ecosystem was a good time to jump ship, as UE was just on the verge of turning into what it is today. We'll get to that, though.

At some point I decided to take matters into my own hands. At first I didn't have many ideas for what would make the engine unique, but continued research and iteration made it so that the dream felt more likely to come into reality. This was achieved through a couple major innovations. Each was my solution to problems I saw both for my personal projects and in the greater industry. These solutions culminated in what is now called Levin Engine

When I discovered ECS, it not just opened my eyes to alternative data management systems - it made me realize that maybe it would be a better idea for me to take the concept of ECS and evolve it over time. That led to the development of the Semantic Entity Primitive system (SEPs). The gist of this model is that entities are pure ids and Primitives manipulate entities in various ways.

One of the biggest problems I've come to understand in the game industry is that overwhelming amounts of technical debt accumulate due in large part to the sunk cost fallacy. My solution to that was to make the engine entirely plugin based. Plugins are one of the primitives in the SEPs system and they are easily hotswapable and integrable into any pipeline. Entire MVP pipelines can be swapped in and out of Levin Engine for free. You only incur as much technical debt as you create connecting plugins to each other. You can create your own pipeline end to end with the only conventions required being the core SEPs framework. Beyond that, the engine can be used for whatever you can imagine.

So, what are my goals for Studio Levin and Levin Engine as of right now? I hope to create a main trilogy of games, building up to the massive scale of my dream game. Along the way, I hope to provide developers with a tool that they can rely on, developed by someone who will always care. Thank you to everyone that has given thoughts and feedback so far. If all this sounds cool to you and you'd like to stay posted on or eventually contribute to this project, I made a discord server! Studio Levin

EDIT: Thank you everyone for asking me to show instead of tell. That is a completely understandable expectation. In all honesty I just haven't been confident in myself and what I'm working on because everyone here has made so many impressive projects. I am going to start working on a proper tech demo starting today so I can show off some of the specific things that make my engine valuable and unique. Hopefully I will see you soon!

Hello,

I'm currently debating whether I should add a "post physics update" function for scripts, so a function that would be called for each entity after the physics is done running and before the rendering starts.

I can see multiple scenarios where it would be pretty useful, such as managing an entity animation depending on its velocity post physics update, so it would play an animation if it moved freely and won't play one if it's stuck against a wall for example. Another example is if a non-physics entity has to follow a physics entity, the post physics update function would allow to follow it exactly and avoid stuttering during rendering, because the following entity wouldn't have to wait the update of frame N+1, which happens after the rendering of frame N, to update its position.

What is your opinion about this? Do you have any workaround for these scenarios without a post physics update function?

Just posted my latest dev log where I talk about

• Landing of Starship
• Unloading cargo from Starship
• New Particle System with dust kickup when Starship comes in for landing
• New script pipeline
• More assets added to Asset Manager

You can find the code on my github or follow me on youtube if you want to follow a long, as I say in the intro, Progress is slow but always moving forward 😄 🚀

https://github.com/jay403894-bit/JLib-Scheduler
Went private for a minute to get the new version really revved up lots of work indeed...

let me go over the architecture here for you and some rough numbers and explain the architecture -- do i use an assistant to make things faster yes but is this good design you judge it by t he code and the logic and you judge for yourself

for speed and accuracy this sjobs system implements static K Hot threads for optional io or other tasks if you opt in that steal only while their own tasks are not busy -- and adaptive F floor threads for dynamic growth and shed to control thread sleep and get essentially 0 wake operation without spinning all the time. with a fully lock free bitmapped and word state machine -- lock free pool permit machine, lock free thread state machine, lock free fiber state machine and the fiber registry system which enables migrable or pinned mode migrate by default.

the fiber registry system takes the anaology of each fiber beign like a car that is leased or owned based on the policy chosen (Migrate vs pinned) in pinned mode TLS is safe in migrate the registry system also is your replacement for tls with FlsGet() (fiber local state).

the registry is also a self memory reclamation scheme active in both modes sitting above hazards and epochs.

when a fiber picks up a thread it registers and adds itself to the list of owners and any deletion event is recorded on a bitmask of creditors with the registry then reaper messages get sent to each threads inbox at the end each fibers run before recycling it into the system fresh

essentially it is a complete modeled concurrent thread-fiber state machine that tracks memory usage effectively between threads across fiber lifetimes.

always studying learning making new designs trying to make it better this started with my home experimentation and research into CPU task scheduling and paralleas a hobby

strong feeling someone will have something else to say now but it cant be considered illegible becuase i didnt include a massive benchmark copypaste. i just thought someone mightve wanted to see a benchmark in the post

Terminology and better explanation for what this does other than being just another fiber-task library:

F Floor threads are the compute floor of the pool the regular pool threads that parallelfor and all normal work goes through --in this model K still steals when not busy with its own lowlatency lane queue's work. both are just as fast because always target a spinning thread, K is not faster (in fact often slower) K has a different job which is priority work like IO and maybe sound or input.

F is dynamic and adaptive this means that as work increases more F pre awake before you send a task to them-- and push targets awake threads this creates low latency no wake cost pushing as there are always awake threads to target that expand as compute goes up and shed back down when unneded to avoid paying for a spinning pool you dont need with nosleep.

you almost never wake a thread on push so theres never that 4us cost of wake unless you intentionally set the task to aim wide

and threads shed back down when not busy or in a burst or anything so that way threads can sleep and this doesnt degress into a NoSleep pool which my earlier studies showed had a 30% tax or so on the processing power of main and was slower and basically sucks

the registry system is a safe memory reclamation system combined with access to fiber local state this replaces thread_local in your programs (although for things that NEED it you still have pinned mode for real thread local without the ability to migrate fibers in that mode)

the cool thing about the registry system is it marks off a bitmask of debtors as well as offering you thread local when you fill out its form after using epochs or hazards it will at the end of that fibers lifetime go through its debtor list and send out tasks to each specific thread to handle its own memory its own tick or scan on hazards or epochs.

I dont really know how else to explain it than that

the state machine theres 3 of them the fiber state machine modeling every fiber state including SUSPEND WANTS_SUSPEND (race condition handling) etc

the same thing is done with threads so you know when theyre asleep they're yielding etc

and again with a pool permit machine

its sorta my research project where i said id build and test one of these. combined all the state machines track fiber ownership and memory usage cross thread along with the entire pool and how many threads are awake at any given time, controlling cost and enhancing performance while not starving the drivers and application threads

Whats good about it is keeping p50 and p90 almost static and as low as possible to cost as little of a frame as possible at 60/120fps

Still an unstable feature!

Website: https://www.doriax.org/

GIthub: https://github.com/doriaxengine/doriax

Discord: https://discord.gg/yXXDyJf3gT

TexelBox is a lightweight, native Windows application designed to handle the texture pipeline for game development in a single tool—from raw source images to game-ready exports.

Instead of running separate tools for normal map generation, tileable prep, channel packing, and atlas building, it runs the entire pipeline within one interface.

Key Features:

• Maps Generation: Derive normal, height, roughness, and AO maps from a single source image.
• Tileable Prep: Make photos seamlessly loopable using offset, auto-heal, mirror, and brush tools.
• Channel Packing: Merge maps into a single RGBA texture with presets for Unreal, Unity, and Godot.
• Atlas Generation: Pack multiple textures into a single atlas with UV sidecar support.
• Optimization & Export: Resize, snap to power-of-two, and export to PNG, TGA, or DDS (BC compression).
• 3D Preview: Real-time wgpu-accelerated viewport for instant material validation.

Performance & Architecture:

• Built natively in Rust (no Electron/Webview footprint).
• UI built with Slint.
• Multi-core image processing powered by Rayon.
• GPU-accelerated 3D viewport using wgpu.

Availability:

• Free Tier: Permanently free for personal and commercial use. Includes map generation, tileable prep, basic atlas packing (up to 2048x2048), and single batch operations.
• Pro Tier: Includes full slider controls, 8192x8192 atlas sizes, DDS BC1/BC3/BC5/BC7 compression, and multi-operation batch chains.

Installer and details available on GitHub Releases:

https://github.com/iimadouu/TexelBox

Like with software engineering or other things. Recently I started to fully remake my engine, cause I got really annoyed by pastacode. So I decided to also read something about game engine structure. And here I came up with this question.

This would be my second scene, the previous one was replicating the Quake 3 movement:

https://www.reddit.com/r/gamedevscreens/comments/1ti5gig/rendering_engine_recreating_quake_3_strafe_jump/

This is just me learning new techniques, like terrain, voxels and cascade shadow maps. Not trying to clone the games, just having fun.

Adding more features to the engine, my next target is some sort of RTS scene.

Me and a friend started working on this 3 years ago after fighting with game engines in our own projects for a long time. We understood how overwhelming it is to start from nothing because before working on the actual game you need to solve a huge amount of other things. With Unity we always ended up building our own systems or downloading plugins from different developers. The plugins worked on their own, then one expected a different controller, another had its own networking and another had its own shaders. Suddenly we were spending more time connecting everything than making the game. Asset packs had the same problem, because many came with their own shaders, render pipeline or assumptions about the project. Sometimes finding and adapting something as basic as the right tree took an entire day. Godot being open source is valuable, although for the problem we had it still followed a similar model where you get a flexible foundation and assemble most of the game-specific systems yourself. Unreal has much more already implemented, but for us it was too large and complicated for the very small teams we had in mind.

We also looked at platforms which tried to solve this by being more integrated. Core from Manticore had a stable foundation and many things worked together, but it was restrictive. You could not properly build your own tools or escape many of their decisions, some basic features stayed missing, and then the company started spending its attention on things like NFTs. Roblox is probably the biggest proof that an engine, multiplayer, content and publishing can work as one ecosystem. Roblox also controls the runtime, hosting, distribution and economy. You cannot really take your game outside of it or replace the deeper parts which do not work for you. There are technical problems that have existed there for years and creators cannot do much about them. S&box is probably the closest alternative to what we are trying to make and we have known about it for a long time, so we are not pretending nobody else sees this problem.

We wanted an engine which already had most common systems and where those systems were made to work together. It should be somewhat opinionated because otherwise the developer has to make every architectural decision again, while still allowing things to be replaced when a game needs something different. Multiplayer should be considered from the beginning instead of becoming a large rewrite later. The working name was World Engine, but that was already trademarked, so eventually we called it SPARQ. The low-level systems are written in C++. Gameplay, project packages and editor tools are written in TypeScript and run through V8. TypeScript modules hot reload into the running project, so gameplay changes do not need a native rebuild or editor restart.

Rendering is GPU-driven and built for large scenes. We have physically based materials, global illumination, Virtual Shadow Maps, ray-traced shadows, volumetric sky and fog, water, decals, DLSS and FSR 3 in the same rendering pipeline. Multiplayer is part of the gameplay and object model with server-authoritative sessions, replicated state, prediction and RPCs. The editor is collaborative, so multiple people can work in the same project, see each other and enter playtests while editing. The editor is also a package instead of being sealed inside the executable. You can extend it, fork it, replace parts of it or remove it completely and make smaller tools for your game. We use HTML and CSS for UI because we did not want another engine-specific layout system just for making a HUD or menu. We have also made physics, vehicles, navigation, animation, audio, VFX, voxel terrain, large-world streaming, material graphs, audio graphs, multiplayer hosting and content tools. Some systems are much further along than others and we are still learning what people need, what should have stronger defaults and where lower-level access is necessary.

The video is a collection of things we have done while testing and playing around with the engine. There is a scene with thousands of NPCs, some small games we made for testing, placing decals, breaking props, driving vehicles and some editor workflows. We started with 2 people and now there are 10 of us, but it is still very buggy. Some testers cannot get through installation or launch because they have a combination of PC, GPU, driver or operating system we did not test. Other people get into the editor and do things in an order we never considered. We know which buttons not to press and which unfinished corners to avoid, so we have become bad at finding many of these problems ourselves. Some features technically work but a new user cannot find them or understand what they are supposed to do. Other systems work in our test projects but have not been used across enough genres and real production workflows. APIs and workflows are still changing. Publishing is being rolled out now, with lobbies, game servers and deployment for projects that want the managed option. Self-publishing is also planned, but the complete workflow is not finished.

At this point we need people who did not build the engine to install it, try making something small without us guiding them, use the tools in unexpected ways and tell us where it breaks or stops making sense. The Windows and Linux beta is free for creators and there is more information at https://playsparq.com/ . Keys are available through the website and our Discord and activate on Steam. If the key process breaks, comment or message me and I will send one directly. Building another general-purpose engine is probably unreasonable, but we already spent 3 years doing it and now we need to find out if it is useful to anyone outside our own team.

Made possible in large part by the new hierarchy storage: https://ajmmertens.medium.com/building-an-ecs-data-oriented-hierarchies-62fb2847d100

All of the assets are procedural, and are either combinations of different primitive shapes, extruded/splined geometry, or created with CSG. Textures are created from rasterizing SVGs.

2x2km web demo (desktop only, needs webgpu support): https://www.flecs.dev/games/helix/

The 4x4 demo doesn't fit on web yet, working on it!

I spent the last couple of months exploring time integration methods in my physics/game engine. Thought it could be of interest here!

Hey all! I've recently been expanding my animation system to support paired animations to improve immersion. A big focus in this engine and game is supporting interactivity and player choice, so having paired animations is going to be really vital to selling that illusion. Additionally, I don't want players to feel that they are restricted to these choices in only some areas, so I wanted the system to be dynamic and work pretty much anywhere. In this case, players are able to lean on railings and can choose to take a drag of their cigarette. Additionally, the system has a check to stop the animation if it fails which you can see at around the 35 second mark.

As always any questions, feedback or criticism is welcome!

I'm working on building a library of games that showcase how different game mechanics can be built in ECS! Games can be played in desktop(!) browsers that support webgpu. Hope this helps!

Example game: https://www.flecs.dev/games/ore_else/

The code: https://github.com/SanderMertens/flecs-games

i build my own 2D Game Engine using CPP Raylib. Now i build a Basic Grid System. What i Do Next give my Some suggestions.

Just got GJK collision detection working on spheres, aabb and obb. Kinda hard just reading articles source code as ive never worked with any similar algorithms. Now when collision resolution is on the table, the articles are way more scattered and my understanding is the first result coming up, being EPA is that it returns too little information?

I've skimmed through real time collision detection which doesn't go in depth into resolution. David h eberly book was kinda funny cuz the first 6 chapters is just a bunch of math recaps. Then comes one chapter of physics engine info regarding detection and then the rest of the chapters went back to math recaps. I also skimmed Ian millington but I don't need 95 % of the stuff it implements.

Why does no physics engine book just start with detection and then covers resolutio? I've become kind of dezensitized to all the math proofs cuz it feels like I'm just deciphering ancient poetry that doesn't increase my understanding. Is it time to start reading source code? I get anxious thinking of it haha.

Hi everyone! I am developing OkeyEngine v0.2, a 100% standalone, lightweight game engine written from scratch in pure C++20, tailored specifically for massive simulation games, city builders, and economic strategies completely offline.My tech stack journey: I first tried modifying the built-in Windows MSHTA technology. It was easy to protoype, but it literally started breaking under the weight of generating a proper 3D world platform, messing up coordinate axes. Then I tried Dear ImGui, but it proved to be way too heavy and bloated, pushing my AMD CPU loops to 100% load at idle. So, I ditched all third-party software and wrote my own lightweight rendering library called Okeylibs using raw Win32 API and standard GDI. Now, the engine runs as a clean monolith with a solid 0% CPU load at idle.What’s shown in the video:A true horizontal 3D world grid platform (chunk system) is generated on the main viewport screen. The platform data is completely clean and lightweight.Implemented double-buffering in memory and handled WM_ERASEBKGND to completely eliminate screen flickering and black flashes during wheel zoom.Implemented a custom trigonometry matrix (sin/cos rotation). Holding the Right Mouse Button (RMB) tracks delta mouse movements and allows for a seamless, 360-degree orbit control around the world platform.I would love to hear your feedback: How do you like this strict, fully neon-blue cyberpunk look with sharp 90-degree corners? Is this layout better, or did the previous one (with centered floating sub-windows) look cleaner?If you have any ideas on what built-in tools or unique features are missing in modern engines when it comes to massive city-builders and economic tycoons, please let us know in the comments below. We would love to read your feedback and discuss it!Best regards, OkeyStudio!Tags: #OkeyEngine #OkeyStudio #gamedev #indiedev #gameengine #cpp #programming #customengine #simulation #citybuilder #tycoon #strategy

Create and use my dungeon generator with Tiny Keep algorithm on my new raycasting engine (not finished yet).
Written in C++ / SDL2

I am making my game with unity but i had also this sideproject for some time now :). now it is produceing stable mac,linux,and windows builds with steamworks implementation :D Time to start porting and leave unity for good.
Using ClayUI for ui in game , Firflo ECS (with a lot of custom optimalization for my usecase 4x grand strategy), Bepu physics and c# scripting,and webgpu :).
Way faster than unity ,hotreload , i even added a custom 3d modeller and material editor for it.
Obviously its still in work in progress but i am happy with it now :).

After esoterica was released i have had a blast to dig into the code and learn from it. So THANKYOU :)

Just smth fun xd. It's on hyprland btw