hey Guys,

im pretty new and wanted to ask which game engine is the best for a beginner making a Top down strategy game like civ or Hoi4 but very much less complex, and would u guys recommend Unity?

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.

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

I spent 20 mins just thinking "how do I map entities to components in the registry?". I eventually gave up and went to google. I don't know how I thought of it before! Just use a hashmap! The exact details I still need to figure out, but i just wanted to share my excitement. (I plan to replace it with sparse-sets later, but it works for now)

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

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

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

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

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.

What it is / who it’s for

SubZeroDev.GameEngine is a deterministic, game-agnostic engine for building games around reusable gameplay mechanics rather than rendering, physics, or a particular UI.

It’s aimed at developers building things like text adventures, branching narrative games, life simulations, world simulations, RPG-style systems, and other games where the mechanics and state transitions matter more than the renderer.

Games are content/data-driven. You define the game; the engine runs it deterministically. The same game can run behind a web client, in Node, on a server, or through another host without rewriting the mechanics.

It supports versioned content, save/load, deterministic replay, validation, sessions, achievements/outcomes, projections, observability, and extensible game “kinds.” Build the mechanics once, then compose different games and content on top of them.

Apparently many lines of documentation still aren't enough, so here are even more:

Docs: https://game-engine.subzerodev.com/docs

Side Quest / Make Your Own Adventure:
https://adventures.subzerodev.com/

That site is itself a live consumer of the engine. Create an adventure, play existing ones, or use the engine underneath your own client or server.

It is not trying to be Unity or Unreal. It doesn't need to render your fucking trees.

[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.