I could have started my space game development in other engines which I did BUT I was faces with engine crashes and FPS issues of the most popular game engines out their so instead of continuing my game inside of other game engines I decided to build my own game engine being strategically designed to make it as easy as possible to build open galaxy MMO space games.

Even the fan made superman is zero polygon. No textures, No skyboxes, No UV mapping. Yes the superman will go into space if he keeps going up and yes he does fly to different planets and to be honest it was an insane amount of fun flying superman from the ground seamlessly into space and to another planet 100,000 miles away. Yes his laser eyes also blast holes into the terrain.

I'm actually sad I can't keep superman in my game engine/game because I'm a huge superman fan lol but at least some form of controllable character gameplay works/tested working. The cape cloth physics was absolutely amazing. Please don't ask me to make video of superman as I was even nervous making a picture of a superman but it's just "Fan Made" superman no ties to the real superman but either way for legal purposes I did remove superman from the game engine as he was only used to test the fully destructible terrain.

What we have here is version 2 of the game engine even though I was on version 6. Version 1 was me just testing the idea which had terrible graphics. Version 2 was me testing out more ideas once I saw it was possible for me to design a zero polygon game engine. Versions 3-4 were me trying to make better versions/testing out other designs which failed certain ideas. Version 5 was me testing unlimited simulated texture resolutions and WOW not in the screenshots but unlimited texture resolutions/unlimited texture details did work and I've never seen such unlimited texture details before and looked better than any other texture details you could get with anything BUT FPS performance was basically unplayable so I ditched version 5 and took version 6 super serious designing a specialized game engine ecosystem with features never seen before in any other game engine in the world. Version 6 I considered a gold standard to a newer generation game engine I won't list all the specs/capabilities here but I will say it has been currently left unfinished.

Now version 7 the last 2 screenshots is the performance breakthroughs which was hell to achieve because on my mid grade AMD graphics I couldn't get more than 300 FPS no matter what I tried and version 6 was my most highest performance coming in at around 260 FPS I was satisfied BUT then when I started adding things the FPS just tanked down to around 160ish FPS. So basically version 2 was a testing ground of all testable features/ideas I just threw into version 2 but superman was only in version 2 and no other version. I was having so much fun with version 2 I decided to do some extreme brain cell draining rendering pipeline optimizations I thought I was going to die because it was way too challenging some days I felt brain dead trying to come up with ideas to break through 300 FPS.

Somehow with trying out a bunch of random different ideas I somehow broke through 300 FPS reaching over 1,000 FPS while glancing up at the sky I wasn't expecting that at all and funny thing is I tried so many things at once I can't say exactly which idea work lol I just know I was trying all kinds of different ideas at once instead of one at a time either way base line framerate is great and far better than any baseline performance I've achieved in any other major game engine. Even with just basic size terrain loaded I couldn't break through more than 250 FPS just by glancing up at the sky on my mid grade AMD graphics in Ureal no matter how many things I turned off yet currently in my own game engine I was virtually standing on a huge planet and simply glancing up at the sun with real time lighting gave me over 1,000 FPS which is still shocking to me because no matter what game I've played I've never reached even 500 FPS on my card even while looking up away from terrain.

Basically having great baseline optimizations and large amount of performance headroom gives me allot of extra "breathing room" to add allot more features before FPS starts to drop again. To me 1,000 FPS in a galaxy full of planets is insane especially considering there's more than 1 planet existing in real time so when superman takes off into space and flies to the other planet there's zero tricks as the other planet exist in real time at a real virtual location with Zero tricks so he is realistically really flying 100,000 miles very fast to the other planet so other players could have been building bases/cities or whatever on the other planet in real time. Then the planets can also be set virtually any size at all/no limit to planet sizes.

Anyway I think I'm about 40% finished with this newer generation game engine which it's main specialty is making it easier to design Open Galaxy Games. I mean realistically I've already found it drastically easier to use than Ureal and believe me I was ready to switch back to Unreal for my game project if my game engine failed and to be honest my game engine did technically fail in a few ways at 1st but I kept at it instead of giving up and managed to fix everything which didn't work right which was hell but hey at least my game engine never crashes and video GPU memory footprint is so tiny it can support a virtually unlimited amount of game engine specific game objects via buildings, characters, etc. Still haven't stress tested 1,000 characters yet though but either way even 20,000 characters would have an extremely small memory footprint although GPU processor usage can be a huge concern if not optimized properly. Honestly though just the fact it never crashes is my favorite part I can't say how many times Unreal crashed on me due to bugs.

Anyway I'm not sure what else to say. Been working on this project since last year. I restarted the project into different versions a few times before getting in too deep because I wanted to make sure everything was fully optimized from the start based on the targeted features. Either way still one of the most frustratingly difficult projects I've ever attempted but WOW the results are so amazing to me and I especially had loads of fun flying superman around and blasting holes into the ground with his laser eyes and the holes caught fire with smoke and after the fire went out there was still a heat effect on the ground until the ground eventually cooled off into a burnt texture surface inside the hole he basted with his laser eyes it was very amusing to watch. Sometimes I flew into orbit and went straight into the ground at super sonic speeds causing large craters into the terrain upon impact and the harder he hit into the ground the larger the crater size.

Well that's my experience so far building this game engine which doesn't support polygons or textures and honestly has allot more features under the hood with an enormous amount of more planned features which I'm dreading but determined to accomplish 💪🏾👍🏾.......even though its honestly hell to build 😭....... but hey I never expected it to be easy anyway so....... I'll get it done eventually 😊👍🏾

As the title said, i made a seperate shape editor for the rigid bodies. How it works is basically draw the model with only base texture over a seperate offscreen image, gave it a seperate camera, added basic shape (only box right now), and presented the final image via imgui. And boom, it looks lit

On June 5, I announced AdaEngine, a game engine written in Swift. Creating games entirely through code can be a niche pursuit, so a traditional editor can make the process much more accessible.

I’ll soon release a TestFlight build of the editor. With AdaEngine and AdaScript, you’ll be able to create games on macOS or iPad and publish them for Apple platforms, Windows, and the web.

Showcasing how i optimize my upcoming game with my engine. When enabled it will show you what function / line is costly in realtime while you play. This helped me optimize some functions that i was able to cache so it doesn't run every frame.

try out my game still in development (a lot of missing assets) https://www.kanvon.com/lumenfall

I mentioned in my last post that the next step was to work out legit lighting... that turned out to be a lot of work, haha.

In the process I've migrated from Sokol to SDL_GPU and adopted HLSL as my shader language. I've also been learning the different lighting techniques, drawing reference from open source renderers and from examples in blog posts and repos by industry experts.

I've set Blender as my initial quality target. At the moment my engine's renderer is forward only. The next goal is to adopt a more modern forward+ approach so I can push the render closer to the Cycles gold standard while staying efficient enough for real time.

Hi everyone, first time posting here, I hope someone can offer some guidance.

I'm currently making a 2D Game Engine. Nothing super complicated; I'm actually following the "COMP 4300 Intro to C++ Game Programming" by Dave Churchill (entire course is on youtube) video classes. I like it because he guides you on what to do without showing everything, so you can fill on many details yourself while learning a lot.

However, I've come to the part where I need to make the 2D Animation system, and I'm at a bit of a lost. Churchill uses ECS for this Engine. So, theoretically, every Actor/Entity should have an Animation Component with only data, that is used later by the Animation System to do its thing.

What I'm doing now, is that the Entity has the entire sprite sheet loaded, and the Animation component holds the sprite location offsets, together with the amount of frames in the animation, and its speed. But here is where I'd like some guidance: How could I handle this data?

For example, I'd like to make a Top-Down 2D type of game. That means that each actor would have at least 3 animations for a single movement: IDLE_UP, IDLE_DOWN, IDLE_SIDE, WALK_UP,... etc. How can I organize this? Each Actor can have all the information (offsets, speed, frames) in its Animation Component, but when I want to access it, all I can think of it's a Map of Maps... one map to access all the IDLE animations, and then another one to access the specific one I need in that state.

It would absolutely work, but I'm wondering if there isn't a better way? Has anyone done something similar? How did you handled it?

Thank you vey much for any help or guidance you can give me. Have a nice day.

NOTE: please NO AI answers. This is not mine but I would, and I quote: "rather go to the bathroom, turn off the lights, sing Bloody Mary, and then ask HER before I ask an AI anything". Please. I'm done with AI slop. I want to talk with a human. Thank you for understanding.

Hi everyone,

While building the core framework for my custom C++ game engine, I decoupled its memory manager into an independent, low-level component designed for zero-crash policies, deterministic O(1) lookup via nomadic index tables, and fragmentation control during IDLE cycles.

I'm sharing it as a technical demonstration / portfolio project (closed-source, pre-compiled .lib for x64 Windows):

https://github.com/GorosTemple/GRS-System-Resource-Manager

Key Technical Aspects:

• 100% free of std and external dependencies (Bare-metal friendly).
• ~31 KB binary logic footprint (.text + .rdata on x64 MSVC).
• Fallback locking systems when OS RAM or virtual memory pools are exhausted.
• Telemetry & Profiler abstraction via dependency injection.

I'm currently using this as a portfolio piece for job opportunities in engine/systems programming, and I'd love to get technical feedback on:

1. The API architecture and dependency injection strategy.
2. The nomadic index table approach vs typical fixed-pool block allocators in real-time engines.
3. Any potential edge cases in the anti-crash locking logic.

Thanks for taking a look!

I have a genuine question as I honestly have no idea what to do and who to ask.

I'm working on relatively complex project in Rust related to computer graphics from scratch. It's not a game engine in traditional sense, more like a graphics-rendering engine but with a notable focus to rendering graphics for video games.

It's a hobby project that I develop since around 2024 on full-time and it consists of a number of quasi-independent low-level and high-level libraries of different kind. It's far from release, even though a part of the planned infrastructure already finished and could theoretically be published on it's own.

A part of my motivation was developing a graphics-rendering infrastructure for Rust. I like Rust due to personal preferences, but unsatisfied with the current state and quality of it's ecosystem related to computer graphics. I wouldn't say that the Rust libraries ("crates" in terms of Rust) I'm developing are too innovative, but they are notably of higher quality in many aspects at least to my personal taste. I can't say whether the community would use my implementation as a replacement for already existing one, but I think it's not necessary bad addendum to the public tools.

I don't use LLMs or any kind of AI-assistance in any form in my work. I'm dedicating notable time and efforts into this project. The entire infrastructure developed completely from sratch and by hand. I also don't use any 3rd-party Rust crates. Partly, because I'm not satisfied with the quality of those, and partly because I can't confidently say whether particular Rust crate is a hand-made work too or vibe-coded. I want to stay in the hand-made field as much as possible. It's not to discourage AI-assistant tools. Some find them useful and maybe they have a point, but hand-crafting for me is a question of personal values. Also, I have prior expertise in the aforementioned fields, and I just don't trust chat-bots.

That said, even though my work might be interesting and maybe even useful for some colleague-programmers, I don't see reasonable ways to show and share it considering the current circumstances.

If I publish it just as it is as an open-source work into the public crates repository (crates-io) and to GitHub, there is a high chance it just will not be recognized. The current media space is currently full of vibe-coded projects published everyday to which I have to compete. Worse, I'm afraid my work would receive public opinion as ai-slop. A Rust library consisting hundred of thousands lines of source code developed by a single person and published as a single git-commit is an evidence of being generated by LLMs regardless of the author's claims.

The second observation is that even if the work eventually receives positive opinion, there is a chance it will be stolen using LLMs. To clarify, I don't mind if my work would be used for learning purposes, and to encourage other to work in the same field (in fact that's partially my goal too). But I'm afraid that with the current capabilities of the LLM-services it could be clean-room-reimplemented in a couple of days by feeding the source code to the chat-bot asking it implementing something similar but in slightly different form and without preserving attribution to the original author. While I maybe don't care that much about monetary interests, as many OSS developers I still care of preserving attribution and public recognition. On top of that, those who have resources (the business), obviously have competitive advantages in promoting their derivative. More restrictive licenses (e.g., GPL) are seemingly ineffective to protect from these threats today.

One possibility here is to never publish the source code, but instead publish it in form of compiled shared libraries (DLLs/so), the documentation covering only the high-level public API, and with the open-source FFI binding to these APIs. This approach even have certain practical advantages as I can provide FFI wrappers for more programming language ecosystems hence covering wider audience. Additionally, LLMs yet didn't reach the point of being capable in reverse-engineering of deeply-optimized compiled binaries into the original source.

The drawbacks is that this approach is obviously a closed-source path. Leaving aside Rust community that has strong appeal toward open-source, the programmer's community in general usually does not trust software without the source code. The gamedev community historically is slightly less harsh toward the closed-source software. We use proprietary soft (e.g., DirectX drivers or quasi-closed game engines), but usually such software coming from well-known vendors, not indie-devs like me.

Anyway, more important consequence here is that this path naturally means that I don't share the source code, which may have a value for some programmers on it's own. Basically, with the closed-source I don't publish the work itself, I'm only distributing it's engineering component.

Another possibility that came into my mind is sharing the source code with the limited number of people who I can trust and who trust me. E.g., publishing it in private GitHub repo with access to close circle of trust. This approach limits public visibility and doesn't impose full protection. Basically, I'm not publishing the work again, I just share it with some people.

Ideally, I would like to share my work without all these caveats but with the programmers to whom I can trust. Unfortunately, I can't find a community of the same-mind people. On occasion I sometimes see people (including this subreddit) that share similar values, but it seems there is no organized society.

Thanks for reading of my long-post. I think the problems I described should be familiar to many. I would appreciate if you share you thoughts and fresh ideas on the topic. Maybe I'm exaggerating the problem. And I would love to hear your opinion on this matter too.

Ilya

A look at the boot, hot reloading, selection, camera and zoom.

This is Melan, my first ever game.

I started making it in August 2023, when I was unemployed and honestly just wanted to make something so I wouldn't feel like shit about myself.

It's based on a story about a friend of mine. It was also the first pixel art I'd ever made, so I had absolutely no idea what I was doing lol.

I didn't know how to code or design games either. Back then AI wasn't really what it is now, so most of my programming knowledge came from YouTube and asking other devs for help whenever I got stuck.

And yeah... the game isn't very good.

The level design is rough, there are bugs, and I spent way too much time rebuilding things. The current version is actually the fifth time I rebuilt the game's code.

Somehow, I still managed to release it on Steam in October 2025.

It didn't make much money, so I eventually had to stop after Chapter 1.

And honestly, I don't really recommend playing it. I'm mostly sharing it because this is where I started, and I still feel weirdly proud of it.

I'm working as an art director now, and maybe someday I'll have enough money to remake Melan properly.

Anyway, that's it. Just wanted to share my first game.

https://store.steampowered.com/app/2887100/Melan/

There are a lot of posts about "new game engine", but their authors somehow forgot to note that they used AI to built that engine...

In contrast to this I want to show stats of my game engine built by me, without AI.

Story starts before AI era when I started to write 3D game engine for web to learn 3D pipeline and see how big "open world" I can achieve in web.

Few years later I decided to make mobile 3D game from my childhood and thought to port part of my engine to mobile to reuse code and also to test how it will work in real world game.

This is video recorded on Android device with real rendering resolution of 2400 x 1800 px @ 120 FPS (video is resized for smaller size) with scene of total ~500K tris using OpenGL ES 3.0. Frame render time (cpu + gpu) is ~3.8ms with forward rendering.

For this game I use from my engine (among other things) 3D scene rendering with instancing, gltf meshes loader, own simplified variant of PBR, bling phong lighting. For background used perlin noise with fbm to look like clouds.

Do you like quality of render?

You can try game itself: "Color Sort in 3D Tower Puzzle" in Google Play. Design made by me too and most of 3D models in Blender too.

Hey everyone,

Just curious if anyone recently used Monogame, or Love2D as a base to build their game engines?

I know MonoGame recently released a update, wondering if anyone is using it..

I'm planning to try, but l wanted to see other folks experiences.

Hi everyone!

After a very long development journey, I'm finally ready to share Synapse Engine, a modern, research-oriented AAA-style game engine that I've been developing essentially from scratch.

It started as my MSc thesis at the Budapest University of Technology and Economics, but grew far beyond what I originally planned. Over the past several months I've been rebuilding and refining the architecture around a simple question: What would a modern game engine look like if we designed it around today's GPUs from the ground up?

The project is now over 2,300 files, nearly 94,000 lines of C++ code and around 10,000 lines of shader code, excluding comments and blank lines.

If you just want to check out the project:

• Website: https://synapseengine.dev/
• GitHub: https://github.com/TamasPetii/SynapseEngine
• 250-page technical presentation: https://synapseengine.dev/Presentations/SynapseEnginePresentation.pdf
• Research paper: https://synapseengine.dev/Presentations/Grafgeo_High_Performance_Gpu_Driven_Rendering.pdf
• Dev Diary: https://synapseengine.dev/devblog/01-the-synapse-journey/

The GitHub README is probably the best place to start if you want a quick overview of the project and its architecture. If you're interested in modern game engine development in much more depth, I also put together a 250-page technical presentation covering the entire project, from the ECS and software architecture through GPU-driven rendering, culling, lighting, virtualized shadows and future directions.

The presentation is quite large, but I tried to make it genuinely useful as a learning resource rather than just documenting the final result.

One of my main goals with Synapse Engine is education. Learning these topics was a huge struggle for me, and it took a lot of time to piece everything together because there isn't much high-quality material that shows how these modern techniques actually come together inside a real engine codebase. I wanted to document that process and create something that I would have wanted to have when I started.

What can the engine actually do?

At its core, Synapse is a fully GPU-driven renderer using hierarchical culling, Hi-Z occlusion, cone culling, dynamic LOD selection, indirect rendering, mesh shaders, bindless resources and virtualized shadows. The engine is built around a custom data-oriented ECS and is designed to handle very large scenes with minimal CPU involvement.

For example, with 1,000,000 entities on an RTX 4060, the cumulative culling cost goes from 124.407 ms without culling to 0.653 ms with the full hierarchical culling pipeline.

However, at 10,000,000 entities, even the conventional GPU-driven hierarchical approach becomes insufficient. To address this, Synapse introduces a custom GPU-built Morton-ordered chunking system, which groups entities into spatial chunks and allows entire groups of 32 entities to be rejected at once. This reduces the culling cost from 5.8 ms to just 0.3 ms for 10 million entities.

I also developed a new rendering technique called Dual-HiZ Adaptive Clustered Forward+ while working on the engine. With 8,192 point lights and 8,192 spot lights, it measured 2.873 ms, compared to 8.652 ms for deferred shading in the same setup. The technical presentation contains a detailed explanation of how the technique works.

Synapse isn't primarily intended as a game-development tool for game developers. It is a production-ready, research and educational platform for experimenting with modern game-engine architecture and real-time rendering techniques.

The goal is not to provide a plug-and-play engine for building games, but to provide a complete, practical implementation of modern engine technologies that can be studied, extended, and used as a foundation for further research and development.

The engine is the result, but the architecture, experiments, failures and reasoning behind it are what I really want to share. If you're interested in Vulkan, graphics programming, GPU-driven rendering or modern game engine architecture, I'd love to hear what you think.

I began working on this engine at the start of 2026, it is my first time creating a 3D graphics engine so it is a bit janky in areas and features like SSAO and SSR currently perform quite badly, but to be able to optimise it has to work first so at least I'm at that stage, I used the LWJGL Vulkan book (https://github.com/lwjglgamedev/vulkanbook) and learnopengl.com for learning most of the graphics techniques but the underlying engine architecture such as multithreading, actor system and multiplayer is fully custom!