New Game Release!
May 24, 2026 ⋮ The Kireji Project ⋮ 4 min read
I'm reintroducing 3D game development features into the Kireji Web Framework. To test it, I needed to start a real game project.
Enter Orbital, a new - and very tiny - first-person shooter!
Warning: this game is very early in development. You play as a disembodied first-person camera running around a very rough looking map... but rendering, player movement and collision are working. There's no mobile or mouse interactivity yet; you'll need WASD and arrow keys to move and look around, respectively.
Finally!
I've been waiting a long time to bring 3D rendering and first person game mechanics back into my demo project. In a previous iteration of the project (a couple of years ago now...) I put up a very rudimentary WebGPU game. It had no textures, just vertex colors. You could jet pack around and there was basic gravity and collisions. WebGPU wasn't widely available yet. I was building and publishing the game through Google's Origin Trial.
I hadn't quite cracked the case back then on meeting the bigger design objectives of my framework - namely, the ability to efficiently achieve the maximum possible compression for runtime variables in order to store them in the URL. This allows the URL to act as a save game file that can be bookmarked and shared. Alas, I had to remove the WebGPU features entirely while I continued rapidly prototyping different paradigms for the framework.
Finally, that struggle is over. I'm very happy with the broad strokes of the framework's design at this point. The latest iteration of the framework made it very enjoyable to model the game parameters and get everything up and running quickly. I spent a lot of time ironing out the exact state management details I wanted for all my web projects in general and didn't have the chance to bring back the "fun" part - building a real 3D game - until this past weekend. Looking back at my old WebGPU code, I can see clearly that the groundwork has paid off.
I've spent the last three days refamiliarizing myself with everything I need to get this project up and running. That includes the glTF file format, WebGPU features, WGSL shaders, render pass management, world building, game design and creating 3D environment art (modelling, UV mapping, texture painting, etc). I'm creating all of the art using free, open source software (Blender and GIMP).
glTF in particular is delightfully easy to work with in this context because it's designed to be easy to parse and to work directly with WebGPU.
The Real MVP (Minimum Viable Product)
The purpose of this game is firstly to demonstrate and advance the development of the Kireji Web Framework. If it turns out to be a fun and exciting game with deep lore, that will be cool, but that's icing on the cake.
The art style for the game is "90s realism": unlit shading and very low-poly geometry with low-res textures that rely on hand-painted or baked lighting. This art style appeals to me because of the deep nostalgia that I feel when I work on it. It is actually more immersive to me than modern photorealistic games because it leaves more to the imagination. It also means that the game data is small enough to download and render quickly.
This game currently represents the target minimum viable product for the Kireji Web Framework's integrated game engine. I probably won't implement a lot of physics in this game. Just a basic walkable collision area with static and sometimes interactive props and maybe collectables or perhaps puzzles with doors and keys. Design is still under way.
The Importance of Collision
The philosophy underpinning the Kireji Web Framework is that every single valid app state is directly addressable by URL and that no invalid states can be reached. That means there can't be a URL that links to the player character interpenetrating the wall. As a result, the player's position cannot simply be give by an { x, y, z } tuple.
Instead, the world must be quantized. The volume in which the player can roam must be turned into discrete points. Then, a two-way minimal perfect hash function must exist which can efficiently address all of those points and no others. I used one inch as the smallest unit of precision for the player's location. This means every inch of the valid, walkable space is assigned a unique natural number with no gaps or duplicates. This results in the most efficient possible way to store the player's location.
Figuring out how to implement this in my framework was a challenge that I largely solved while creating another game, a 2D top-down pixel art game called Glowstick. Oddly enough, the most challenging aspect turned out not to be quantizing the walkable space. Instead, it turned out that enabling wall sliding (so the character doesn't just freeze or get stuck when they reach a wall) was the hardest part of the process. The solution ended up being to use ray casting to simulate physical interactions between the character and the collision mesh.
It turned out to be a cinch to extend the existing 2D game collision part used by Glowstick into a 3D collision mesh part. And testing the collision in Orbital turned out to be far easier than it was in Glowstick. Now that I have glTF support, I don't have to manually plot collision mesh triangles and then rebuild the game in order to find out if they look the way I imagined them in my mind. Instead, I'm modelling whole game levels in Blender (both collision and render geometry) and can one-click export it all as a single glTF package that contains all of the data for that level.
Conclusion
Look forward to steady updates as I decide what the story and mechanics of the game will be! Will there be achievements? Will there be enemies? Will there be hidden collectables? You'll find out when I do.