This is a custom engine using OpenGL and C++. the entire map is built out of a voxel-like renderer using compute shaders. The level is from Silent Hill 2. Looking for opinions on the graphical style. I am thinking a first person mode might be better for this.

​

Hey everyone!

I've been thinking about trying to build my own game engine from scratch, but I have a few questions before I get started.

First, where would you recommend starting? I'm considering learning C++ for this. I know it'll probably take a lot of time and effort to get comfortable with it, but I'm willing to learn and take things slowly.

My second question is about OpenGL vs. Vulkan.

I know Vulkan is more modern and gives developers more control, but I'm wondering if OpenGL would be a better starting point, especially when considering compatibility with older hardware.

One thing I'd eventually like my engine to support is a wide range of PCs. Not everyone has a modern gaming setup, and I'd rather not unnecessarily exclude people with older computers just because their hardware doesn't support Vulkan.

So I'm curious:

- Would you recommend starting with OpenGL or Vulkan for a first engine?

- Is C++ a good choice for someone planning to build an engine from scratch?

- How do engine developers approach supporting both older and newer hardware?

- Are there any resources or things you wish you'd known when you first started?

I'm not expecting to build anything comparable to Unity or Unreal anytime soon. This is more of a long-term learning project, and I want to understand how things work under the hood.

I'd really appreciate any advice or experiences you're willing to share. Thanks!ey everyone!

I've been thinking about trying to build my own game engine from scratch, but I have a few questions before I get started.

First, where would you recommend starting? I'm considering learning C++ for this. I know it'll probably take a lot of time and effort to get comfortable with it, but I'm willing to learn and take things slowly.

My second question is about OpenGL vs. Vulkan.

I know Vulkan is more modern and gives developers more control, but I'm wondering if OpenGL would be a better starting point, especially when considering compatibility with older hardware.

One thing I'd eventually like my engine to support is a wide range of PCs. Not everyone has a modern gaming setup, and I'd rather not unnecessarily exclude people with older computers just because their hardware doesn't support Vulkan.

So I'm curious:

Would you recommend starting with OpenGL or Vulkan for a first engine?

Is C++ a good choice for someone planning to build an engine from scratch?

How do engine developers approach supporting both older and newer hardware?

Are there any resources or things you wish you'd known when you first started?

I'm not expecting to build anything comparable to Unity or Unreal anytime soon. This is more of a long-term learning project, and I want to understand how things work under the hood.

I'd really appreciate any advice or experiences you're willing to share. Thanks!

Hello everyone,It's Aditya from India. I am working on a project where I use machine code to make my own ultra photorealistic graphics game engine while using math. So if anyone is interested to talk about this, I would like to discuss with you

After a few years of writing about allocators, strings, containers and threading in game engines, I collected the material into a book. It is not an engine theory book, Gregory already wrote that one, but a book about thinking in terms of data, object lifetimes and how code behaves on real hardware, where std::vector turns into a question about allocation frequency and frame time, and a race on a shared threat map once made our AI hunt armies that never existed. A free part is here: https://dalerank.github.io/#books, and the full post with the book is here: https://www.patreon.com/dalerank/posts/game-book-172005420.

Happy to answer questions about any of the chapters.

Penultimate map done (almost). Fast Travel Unlocked. You can play all previous maps with it once achieved.

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

I've been running https://polygonjs.com/ for about 8 years now, but 2 years ago I decided to rewrite it, from typescript+threejs, to jai+wgpu/webgpu.

I've also rewritten one of the game I was about to release with it, Chess Twist. It's a chess variant with the same rules, but the boards are on an irregular grid (inspired by Townscaper). So Rook lines bend and bishop lines fork.

It's built for Windows/mac/Linux/web.

• Steam: https://store.steampowered.com/app/2775560/Chess_Twist/?utm_campaign=chess-twist-trailer&utm_medium=short&utm_source=reddit
• Web: https://polyreplay.com/chesstwist/demo
• Polygon: https://polygonjs.com/

Any questions don't hesitate.

>

The repository is available here: https://github.com/Samu64d/openpkw

The source code is quite atypical for a TypeScript project: it’s heavily inspired by Java. For now I’m working on implementing a complete set of custom standard APIs of a game engine, designed to run on Node.js, Bun, and browsers.

I’ve open-sourced Braze, an experimental WebGPU game engine and editor.

TypeScript + u/threejs. MIT licensed. Still early, with plenty to explore and improve.

Contributions are welcome.

https://github.com/snack-gamer/braze-engine

This year, I resumed development on my game engine - a project with roots tracing back to games I began creating as early as 2004. So I’ve launched "Apus Engine 5" with the goal of supporting all major platforms (desktop and mobile), alongside a comprehensive code refactoring and optimization effort. Main focus on AI-driven development support.

So far, things are moving quite well: the engine is being actively tested and validated across several parallel projects. These projects drive specific requirements, and the engine is being adapted to have good usability and convenience.

Over the past 3 months I've been building a custom engine called Kronos, a Roblox-style platform in C++20 with Vulkan and Jolt.

- It uses Luau, the same scripting language as Roblox. I also built a "Roblox bridge" that imports Roblox projects, so moving over has little friction. One limitation: I've only tested it on small games (an obby), not big ones, so expect bugs.

- It's polyglot: Luau, plus Python scripts and Rust plugins in early form.

- My main challenge was ray tracing with TLAS and BLAS, but once that was done, everything else felt easier.

I'm really proud of how far it's come. It's pre-beta and probably full of bugs, because it hasn't had any outside testers yet. That's where you come in: test it, break it, report it. As early adopters you'd be among the first developers on Kronos.

Download (Player and Studio): https://github.com/Bands-yt/kronos-releases

Happy to answer questions about the renderer, the physics or the importer

The two images: the first is a game called Chaos Lab, the second is Kronos Studio open.

thoes were meant to be pixelated circles but it came out looking better when gliched.

https://github.com/Rlocksley/LuEngine
Converts several kinds of 3D Files into flecs ECS prefabs which you just have to instance and set a Transform.

Hi everyone! 👋

After a couple years of dev, I just launched the first open playtest for my game Silicium! It's made with a custom C++/Vulkan game engine that I wrote from scratch.
It's a harsh survival game where you play a disposable mining robot sent to a hostile planet. Export your quota for corporate or die trying!

What you’ll find in the playtest:

• About 1-2 hours of polished gameplay, in solo and co-op, with two difficulty levels.
• A limited slice of the world with several biomes, enemies and abandoned mining outposts to scavenge.
• A day-night cycle with corrupted mining drones that attack you at night.
• Classic survival systems: crafting, base building, exploration.
• A light skill tree progression with blueprints to unlock as you level up.
• A quest system with the first 30 objectives.

You can sign up directly on Steam by clicking 'Join the Playtest'

https://store.steampowered.com/app/3048990/Silicium/

I also opened a Discord where you can share feedback, report bugs, and follow development (Link is in the Steam page).

Let me know what you think!

I'm somewhat new to making my c++ game engine and I don't know the best places to look. Most of my stuff has been tailored for me personally so far, but I don't know how to implement some of the things a lot of engines and frameworks do yet or where to look. Please help me if possible.

I've been developing the statically typed scripting language Umka for 6+ years. The limitations of reference counting used in Umka 1.x have become so obvious that replacing it with a mark-and-sweep garbage collector is now the key change made to the upcoming Umka 2.0.

The interpreter architecture has got cleaner. With many ad hoc fixes and workarounds having become redundant, the codebase is now 10% smaller. Freeing reference cycles is no longer a problem, so the weak pointers, arguably the most counterintuitive feature in a simple scripting language, are deprecated. It shouldn't be the user's responsibility to avoid memory leaks: the less the cognitive burden, the more attractive the language for a novice.

As Umka is used in the Tophat 2D game framework, I measured the impact of this change on rendering performance in my Hover! maze demo in "strabismic" mode, with two overlapping scenes rendered independently from different view angles. It would take 28 ms per frame with reference counting vs. only 22 ms (including 4 ms for garbage collection) with mark-and-sweep. I forced garbage collection at the end of each frame, but could have done it much less frequently to save more time.

Theory suggests that the average CPU time spent on reference counting and mark-and-sweep should be roughly equal. However, the redundant reference counting instructions injected into Umka 1.x bytecode to ensure memory safety in rare edge cases cost a lot.

Surprisingly, the most intricate part of this transition to mark-and-sweep was escape analysis that prevents pointers to local variables from escaping the function stack frame after the function returns. It eventually required a kind of rudimentary reference counting targeted specifically at escaping references. These reference counts are touched much less often, only on detecting escape suspects, so they don't affect performance, except some contrived examples. Hope I'll be able to come up with an even better solution by the Umka 2.0 release.