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.
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.
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.
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.
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.
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'
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.
Over the past few weeks, I've been working on added flying cars to my cyberpunk world. To do this, I added pathfinding and splines to my engine.
Now, I am able to create node groups within the level, and use the A* algorithm for pathfinding within the node group.
To actually move the cars, I use the points on the found path as control points for a Catmull-Rom spline with centripetal parameterisation. I also added mesh extrusion from the splines, though currently that's only for debugging and visualisation purposes.
For a more in depth look at how I created the system, I have a video on my youtube channel: https://youtu.be/fu4fQHIakoo
Any questions, feedback and critiques are always welcome!
Managed to get through a full map playthrough on the Steam Machine now most bugs and glitches have been resolved (C++/OpenGL/GLSL). Final polishing before release (+ a few more candidate maps to clean up and include). It won't sell but I'll continue working on it anyway.
