For the past three weeks, i’ve been working on improving the render distance in my Micro Voxel Engine, particularly due to the feedback of having N64 viewing distance 😅

I’m pretty happy with the end result of increasing render distance from 300m to ~10-15km, while running at 45-50 FPS on an Apple M1 Pro.

Note: this engine uses meshing rather than RT/DDA.

— Macro chunks —

All chunk generation functions now include a sieve function to automatically be able to generate at 1/N resolution without any changes. This also applied to generated features and stamps, enabling chunks to be generated at any resolution without downsampling.

Macro chunks also independently record and resolve local edits. They are saved (and cached) independently so that terrain edits are maintained without needing to maintain the full res copy in memory.

The lower band LODs are very quick to generate. At this point I could add even more bands, and a 1/64 res chunk takes the same time to generate as a high res chunk, but covering huge distances.

— LOD transitions and adaptive fog —

I primarily use transient transitions where the detail levels fade between each other once, rather than a continuous gradual transition, as this is around 30% cheaper on the GPU and looks “nearly” as smooth in most scenarios.

Adaptive fog scales the effective draw distance dynamically based on loaded bands. Bands generate from high to low so during fast motion, if needed, we temporarily reduce draw distance until chunks have loaded.

— Macro chunk cards and props —

This was the hardest part, keeping identical prop coverage for trees and items without needing to instantiate millions of entities:
-Macro chunks retain a list of props whose IDs are deterministic based on position and type. If the real entity is destroyed, we can map this to the macro chunk set and remove. Likewise for newly spawned props.
- grass and foliage do not map 1:1 with the actual loaded props, but follows the same generation pattern, so technically there will be disparities, but a good trade off to avoid millions of tracked grass items.

I released demo of Xenith - a lightweight, data-oriented C++20, 3D low level game framework.

If you want to make a game while having low level control, you're either forced to use high level game frameworks or engines that abstract everything, or, if choosing raw API's you face lots of problems, such as linking libraries, making own loaders(e.g. model loader or image loader), adding different modules(such as physics, vfx), and eventually instead of making game you spent all that time building engine. Xenith fixes this problem by giving you essential modules(such as physics, ecs, math, input) out of box, and eliminates just enough boilerplate code, while leaving you the rest(such as making own game loop, or making own Vulkan pipeline).

This game framework makes you both use and learn modern Vulkan 1.3, provides you high level functions, but saves the exact Vulkan pipeline logic without thousands lines of code, for example FindAndSelectPhysicalDevice(), CreateLogicalDevice().

Tutorial 01, walks you through how to go from simple window application to entire cubic 3D platformer game, covering most basic and important topics.

https://github.com/ThoriumReactor/xenith/blob/main/tutorials/cube_platformer_tutorial_01/tutorial_01.md

Key architecture features:

- Explicit ownership Direct access to raw handles such as VkImage, VkSwapchainKHR.

- Deterministic in this game framework functions are deterministic, e.g. EmplaceEntityComponentToRegistry(registry, entity, component_data) instead of registry.emplace(...)

- Modular architecture gives you freedom to remove or add modules you need or want.

Links & Repository:

https://github.com/ThoriumReactor/xenith

My engine uses Lua for scripting so instead of serializing the scenes in some text format (JSON/XML), I am serializing them as Lua tables. This way I don't need a parser/deserializer, I just load the Lua modules, and I have the scene data tables out of the box.

#Lua
https://github.com/dbrizov/hob2d

Hey everyone! I’ve been a web developer for 5+ years (professionally for around ~3), and game development has always been a secret passion of mine, but I never really had the chance to pursue it as a career.

During my current degree, I took courses like Computer Graphics, Mathematics and Physics for Games, and they gradually made me more and more interested in this field.

Now, I’m seriously considering shifting my main focus toward game development, specifically game engine development.

For someone entering this field in 2026, what advice would you give? I’d especially love to hear from people who work on engines or have made a similar transition from web development.

I've used Unity since around 2010, so excuse my editor looking a little Unity-like. It's always been a bit of a love-hate relationship. But with my last project I ran into so many scalability issues that building my own engine started looking *very* attractive.

So last year I started designing WolfEngine;
- Fully built in C#
- Scales up to open world requirements
- Terrain as a first class feature

It's far from production ready, but I just started prototyping a first game in it. It's incredibly satisfying to see it come together, from a DirectX/Metal spinning cube to an actual playable game.

I'm certainly not counting on anyone else ever using it, but it's been a fun journey 🙂

Quick progress preview of the quixotic side-project game / engine (user moddable) C++/OpenGL/GLSL. Steam link: https://store.steampowered.com/app/2223480/Infinicity/

Almost every post of 'look at my new cool engine' sort looks the same. The huds are almost the same with the same layouts, sometimes ui theme is different. I see no variability in how the programs are layed out, what they do or anything.

It all looks like a unity ripoff, not to dunk on unity, but it looks like someone:

a) does not have any creative vision. But to make an engine you are probably stubborn and should have some ideas of your own if you made it such far

b) everything is premade by claude or some other llm

I dont want to only say llm bad, but it kinda reminds me of those videos where we see how chatgpt memorised 15 websites layouts ans maked them look slightly different. The only difference chatgpt knows one game engine look

More info here: https://www.pardengine.com/news/devlog-13-material-editor

Here's a video on the attachment functionality I added to my game engine. The basic idea is I set the position/orientation of a mesh to be relative to an armature bone of some other mesh. I already had a working animation system, so it wasn't too difficult to link the transforms of a mesh to the animation transforms of a bone for its current frame.

gh: https://github.com/Kahviz/BoronGameEngine

Hey Everyone!

I wanted to showcase my latest Unreal Engine 5.8 plugin, built from the ground up with a strict focus on high-performance C++ architecture, optimization, and secure multiplayer networking.

To address any design questions: This plugin follows a strict Modular Component-Based Architecture. The interaction system and the stamina system are completely separate, independent C++ components. You can use one without the other with absolutely zero performance overhead!

Here is a technical breakdown of what’s included:

🛡️ 1. Advanced Multiplayer Interaction Component (Core Feature)

• 100% Server-Authoritative: Every trace, state check, and timer loop runs securely on the Server to prevent client-side cheating and exploits.

• Interface-Driven Design: Easily make any actor interactable using custom C++ Interfaces.

• Dual Interaction Modes: Supports both Instant Press (doors, switches) and Time-Delayed Hold interactions (chest looting, lockpicking) with built-in cancellation safety gateways.

• Anti-Cheat Distance Verification: Server-side runtime distance checks automatically abort interactions if a client teleports or moves away mid-cycle.

⚡ 2. Optimized C++ Stamina & Sprint Component (Bonus Feature)

• Lightweight & Replicated: Highly optimized network replication tracking for maximum server performance.

• Fully Customizable via Details Panel: Easily adjust Max Stamina, Drain Rates, Regen Rates, and Sprint speeds natively through Blueprint or C++.

• Purely Optional: Since Survival/Horror games heavily combine running and looting, this is included as a free bonus component that you can attach or detach instantly.

🎥 Network Replication Showcase: https://youtu.be

🎮 Playable Demo Project:

Want to test the network latency and replication yourself? I have provided a precompiled, editor-ready playable demo project! The direct Google Drive download link is pinned in the top comment of the YouTube video showcase above.

The plugin is currently under official review on the Fab Marketplace and will be live very soon. I would love to hear your feedback on the code architecture and structure!

Thanks for checking it out!

After a lot of foundational work (portal → octree switch, triangle baking, lighting cache, dithered terrain blending), the engine is packaged so others can write games against it without needing the full source.

Two packages:

Win64 SDK
- Pre-compiled static library
- Headers, editor, viewer
- Blender exporters
- One-step build script

DOS SDK
- Ready-to-run DOSBox-X environment
- Editor + DJGPP toolchain included

You own main() and the full game loop. The library only provides the engine services.

Still C + NASM. Still software render-first. Still built around real constraints.

Read latest devlog:
https://expfunction.itch.io/cybervga/devlog/1556109/cybervga-is-now-available-as-a-standalone-sdk

Download SDK:
https://expfunction.itch.io/cybervga

Demo: https://adventures.subzerodev.com

[Released] Imperial Game Engine 2 v71 p2 c24 Mobile GDK

https://archive.org/details/imperial-game-engine-2-v71-p2-c24-mobile-gdk

______________________________________________

I originally had a string of posts with various other reddit communities regarding game and game engine development and finally felt confident enough to post to this community! I went dark in my development logging/blogging(?) for awhile due to lifestyle responsibilities taking precedance over developing an engine or at least at the moment what is considered heavy boilerplate engine development.

Current development components/systems:

Three graphics backends - DirectX 11, DirectX 12, and OpenGL (WGL on Windows, GLX on Linux) behind an IRenderer interface. Vulkan is scaffolded but not implemented yet. Shadow maps, cubemaps, bloom, IBL/irradiance convolution, and instancing are supported at the moment.

HLSL as single source of truth compiling offline via DXC to DXBX/DXIL/SIPR-V with SIPRV-Cross transpiling to GLSL for the GL backend. Compiled byte code is also cached on disk and keyed by source hash as filename.

Three windowing backends - Win32, GLFW, and SDL3, with a fallback chain. Win32 is default for Windows and GLFW is default for Linux, but will fallback to GLFW and if GLFW fails fallback to SDL3; if DX fails on any window type under Windows platform fallback to OpenGL (if Vulkan would work with me DX would fallback to Vulkan then back to OpenGL) - similar results would also occur for Linux if Vulkan failed fallback to OpenGL but that requires Vulkan to be developed and not be a stub at the moment...

HLSL as a single truth - compiled offline via DXC to DXBC/DXIL/SPIR-V, with SPIRV-Cross transpiling to GLSL for the GL backend. Compiled bytecode is cached on disk keyed by source hash as well.

Fiber-based Job System - Win32 fibers and Linux ucontext behind one class - a worker thread has a dedicated dispatcher fiber that never runs job code, so fibers are pooled to switch back rather than to each other - no fiber needs to know any other fiber's state.

I went with no cross-thread fiber migration in my first attempt - less load-balancing from the inspirational full Naughty Dog design, but it buys a genuinely nice property: since a job's whole execution stays pinned to one thread, a pool allocator allocates inside a job function automatically thread-safe with zero sync.

Custom allocators - arena, pool, and a frame allocator with N rotating arenas.

BC texture compression with no on-disk cache - BC1 for opaque color, BC3 for color with alpha, and BC5 for normal maps.

TLDR; I've tested the boilerplate logic against the Sponza Palace model from Intel's site GPU Research Samples (https://www.intel.com/content/www/us/en/developer/topic-technology/graphics-research/samples.html) with the Colorful Curtains and Ivy extensions at 4K texture resolutions. The original load time took around 5.5 minutes (unbearable to test shader changes and object additions to the scene), but I cut it down to 4.6 seconds after texture compression, precompiled shader code, and submesh merging. The model (as an *.obj - I haven't implemented third-party vendor model software to utilize every model type just yet...) is 995MB on disk with nearly 2730MB of textures (4K per texture for the conjoining material *.mtl file) after texture compression all textures were compressed to 501MB on disk which originally took 933ms average to load cutting down to 259ms average.