Projects

This page is an overview of some of the major gamedev related projects I have finished, still work on, or have abandoned, as a sort of portfolio.

Pure Gauge

My main passion project, Pure Gauge: A 3D Action RPG inspired by The Elder Scrolls and Dark Souls. In my first blog post I went into some detail on the concept and motivation behind it. It is the first major game project I have worked on and has been my testbed for learning and experimentation. My focus so far has been on prototyping systems and mechanics, to make sure both I and Godot are up to the task of fulfilling my vision. As such almost every asset you see is still a placeholder - as the systems begin to mature and the workflow is settling in I will shift to creating enough content to publish a small demo. Here is a non-exhaustive list of features implemented so far:

• Souls-like, animation-driven third person character controller

• Skyrim-style inventory and equipment system, with items as physical objects in the game world

• Custom mod loading mechanism, allowing for multiple mods to change the same scene with conflicts being resolved gracefully when possible

• Swimming, diving, climbing ladders, and the pinnacle of gamedev achievements: functional doors

• Creatures and NPCs with AI, capable of navigating the levels (and open doors!)

• Flexible quest system

• Dialogue system based on a visual graph and integrated with the quest system

• Melee combat

• Spells and alchemical effects

• In-game developer's console

• Save system, allowing the player to save and load at any time, and which can easily save the state of any game object

• Level transition system with caching

• And more...

I intend to go into more details on most of these in separate blog posts, which I will link here once they are out. If you are interested in any particular one you would like to hear more about next, shoot me a message on Mastodon or Bluesky!

Custom game engine

I love Godot. It got me interested in game development as the first viable fully open source game engine I found for making larger-scale 3D games. I first tried it sometime in 2020 or 2021 when it was still in its 3.x version and was struggling with 3D, but once 4.0 came out it seemed like my dream was finally in reach. There still are several rough edges, but they are continuously being ironed out and I will continue to stick to Godot for the foreseeable future.

But I discovered that besides making games, I also really enjoy working on game engines (especially when it comes to graphics programming). It all started by being nerd-sniped into following the famous Learn OpenGL tutorial, and snowballed when I took a class on rendering techniques with Vulkan at my university. The result: for a few weeks I was obsessed with making my own game/rendering engine from scratch in C++. Since I used Vulkan, I thought Prosper would be a fitting name.

Further development is currently on hold, but it is technically in a semi-usable state, although far from convenient to use or optimally performant. Some features include:

• Loading and 3D rendering of glTF scenes

• Normal mapping

• Directional and point lights

• Deferred shading

• MSAA

• Skeletal animation

• Integrated the third party Jolt physics engine

• Using modern Vulkan features such as buffer device addresses, dynamic rendering, and shader objects

Here is a little showcase of Prosper in action, with a focus on the skeletal animation:

It was a fun experiment in writing larger C++ applications, and I may return to it in the future. I would like to at least make one actual game with it at some point, just something tiny to demonstrate what it can do.

This website

I have posted many progress updates about my game over on Mastodon, and shared several of the things I learned on my gamedev journey there. But microblogging is transient and not the best way to convey details - I can't count the number of times I thought "this would be a great topic to write a blog post about". At some point I had to give in and actually create a blog. But where to start?

I like the idea of the smol web, i.e. websites designed to run as efficiently and with as little code as possible. Plus, I like to really understand my tech stack, so I avoid third party frameworks whenever possible. I knew that 99% of things I'd want on my website can be done with pure HTML and CSS, and so I decided to go for statically generated sites (instead of dynamically creating the content with PHP or Javascript, languages I've mostly had enough of at school.) Jekyll is a static site generator I've seen recommended many times, so I gave it a shot. But I quickly realized I did not enjoy learning a framework as much as I enjoy doing things from the ground up.

And so I began by writing the HTML and CSS by hand. There were just a couple of repetitve steps required when creating a new post:

1. Copy/paste the header and footer code into the blog post's HTML file.

2. Create an entry for the post on the landing page, copying the title, summary, and linking to the cover image.

3. Add the entry to the Atom feed.

Not only are these steps tedious, they're also error-prone and make it easy to create inconsistencies, especially when I later want to update the header's content or edit a post's title. This is why people use static site generators whose role is to automate exactly that, but because I didn't want to become dependent on any specific one I made my own: scrigen. In addition to the three steps listed above, it also makes it possible for me to use Markdown for writing blog posts thanks to the awesome markdown crate which can convert it to HTML.

Usually I would go for Python when hacking something like this together, but I chose Rust as the programming language this time in order to practice using it. I'm certainly not an evangalist, but so far I mostly really enjoy it. To my surprise, the additional restrictions Rust imposes were almost no obstacle when writing scrigen, and the ecosystem leaves nothing to be desired over Python's. Most importantly, cargo has been much more robust in my experience than pip. (And don't get me started on CMake, but I digress...)

In the end, the website probably does not look as professional and is not as responsive than it would had I used something like Jekyll with a pre-made template, but there is something very zen about caring for your own little website with handcrafted CSS. Please do not view this as criticism of such tools - it's amazing that there are so many great options out there for making websites! Rather, I would like to encourage you to just make websites with whatever tools you're comfortable with. You do not need to learn a million frameworks (but you can if that's your cup of tea!) - a simple, barebones HTML file created in Notepad and uploaded to a Codeberg page is all you need to get your thoughts onto the smol web, outside the walled gardens of social media.

Open source contributions

• godot#90425: Modding support for Pure Gauge is very import to me. In Godot, the intended way to load additional data and/or overwrite original game files at runtime is to use resource packs. However, the method ProjectSettings.load_resource_pack caused an unintended side effect: usually, you would be able to list the contents of a resource directory with DirAccess.get_files_at. But after loading a .pck file, this method only returns the contents of the resource pack in some circumstances. Due to how the resource management system works behind the scenes, this issue appeared when launching a game from within the Godot editor (making it difficult to test modding support during development), and in exported Android builds. My PR does not solve the root issue, which would require a major refactoring of parts of the engine's core filesystem management, but it puts a bandaid on the symptoms at the cost of longer loading times when loading a pck for the first time during the project's runtime.

• godot#93324: As part of a university assignment I took a look at Godot's Reinhard tone mapping implementation and happened to discover that over the course of multiple refactors of the relevant code, a few mistakes snuck in which had led to the image being too bright. This PR addressed the issues.

• godot#96730, godot#99030, godot#99176: In most video games, NPCs navigate the scene by using a so-called navigation meshes, a mesh which defines the area actors can walk on and which is used to calculate the shortest valid path to a given destination. In Godot, this mesh can be generated in the editor based on the scene's static geometry. Sometimes you would like to have objects that cut out a hole into the navigation mesh - for example, treasure chests should be obstacles to be avoided. You could include them in the static geometry used to calculate the navigation mesh, but depending on the obstacle's shape this can lead to parts of the navigation mesh to be placed on top of the object. The proper way to handle such cases is with navigation obstacle nodes. These allow you to define the outline of the object and carve out that region from the navigation mesh. However, there was a big usability problem with this approach: due to special limitations and restrictions which apply to navigation meshes, these obstacle nodes were unaffected by transformations. This meant I could not define a treasture chest's outline once in its scene file but would have had to manually add a NavigationObstacle3D node to each chest in the level and draw its outline based on that chest's orientation. After some long discussions with the engine maintainers we came up with an accaptable approach for having these nodes be affected by rotations and scalings after all. The tricky part was ensuring they would only take into account rotations around the vertical UP axis and would ignore non-uniform scales.

• godot#101961: In my most recent PR I try to fix a strange artefact of Godot's screen space ambient occlusion effect. It is still a work in progress and I hope I can find the time to look into it once more.

Jam games

Game jams are a great way to get to know new people with similar hobbies, and also to force yourself to actually finish and ship a project. In no particular order, here are some of the jam games I have contributed to over the years.

Worlanwv

Besides Godot I am also really interested in Bevy, a game engine written in Rust. I had been eying its progress for a long time, and the fifth Bevy game jam in 2024 was the perfect opportunity to finally give it a real try.

This jam was particularly challenging - it was the first and only one I did solo, it was a new engine for me, the first time I wrote substatial amounts of code in Rust outside of tutorials, and it was the first time I had to write shader code in WGSL. Luckily it ran for over a week!

The result was Worlanwv, a janky walking simulator with light puzzle elements. The theme of the jam was cycles, so I made the cycle of civilizations the main mechanic. It's not particularly "good", mostly because you can easily get stuck inside geometry due to a major design flaw on my part. But if you want to try it anyway, my personal best time is 156,000 years, let me know if you can beat it!

AssassinCon

We were brainstorming for hours in an oxygen-deprived room when we came up with the concept for AssassinCon and it shows. In this short 2D adventure game you play as a jester, tasked with infiltrating the annual convention for assassins to recruit some of them to quit their profession and become a clown themselves.

The experience I gained by writing the dialogue system for AssassinCon inspired me to eventually for a graph based approach for Pure Gauge, but more on that in a future blog post.

Whispers of Saints

In Whispers of Saints: Bathhouse, you explore a bathhouse haunted by monsters in order to find your missing brother. Use bubble dimensions to get past enemies, collect poems, find the missing map piece, and get to the exit.

Into Darkness

Into Darkness was the first game I ever helped make for a game jam, the 2022 GoGodot Jam. The goal is simple: Use a stellar engine to push the solar system into the giant black hole at the center of the galaxy to advance to the next universe. However, building up momentum takes time, and so does slowing down. This makes it extremely difficult to maneuver around the other stars swarming around the galactic core and endangering your sun's planets.