DIABOTICAL ROGUE

UNRELEASED PROJECT

GPU PARTICLE SYSTEM

SOLAR UPRISING

SPITE: DIVINE DESCENT

VILSE

THE LICHS' GRIMOIRE

Touched by a spectre

A BUGS' QUEST

Frenemies

Diabotical Rogue was a fast-paced, team-driven project that I was part of from inception to release. As one of six gameplay programmers, I played a central role in both designing and implementing a wide range of features and systems. With a rapid and productive workflow, we delivered a tightly tuned roguelike experience with competitive multiplayer elements.On this page, I’ll showcase a selection of the features and systems I contributed to, from under-the-hood architecture to surface-level implementations of skills and mechanics.

Hookshot Design Overview

The Hookshot was a central ability for the Scout class in Diabotical Rogue, a highly mobile, high-damage character with low survivability. Designed for both precision control and expressive movement, the Hookshot allowed players to make sharp combat repositions or pull off dramatic plays across the map.To support a range of playstyles, it was also tightly integrated with the game's roguelike upgrade system, giving players the tools to specialize and expand the Hookshot’s functionality mid-run.

Final Thoughts

The Hookshot became one of the most central and versatile abilities in Diabotical Rogue. It offered both depth and accessibility, feeling immediately useful while rewarding deeper mastery. It also served as a showcase of our design philosophy: giving players tools that scale with their creativity and skill, while maintaining a fair and competitive balance.

Skill System

The skill system was designed to empower rapid iteration and expressive design in a co-op roguelite context. The goal was to allow content creators, who in this studio act as both designers and programmers, to define new skills entirely through scripting, while abstracting away boilerplate and networking concerns.This was achieved by creating a declarative, data-driven C++ system where each skill is represented by a registered script ID tied to logic through a callback architecture. The system handles core logic such as damage, effects, targeting, and animation triggers, while exposing high-level hooks for customization. It also integrates tightly with a bespoke event-based networking layer, enabling server-authoritative multiplayer behavior with minimal overhead for the script author.

Final Notes

• Back

Introduction

Goal and purpose

To challenge myself further, I aimed to optimize the editor to handle millions of particles simultaneously. The best way to achieve this was by moving the simulation to the GPU, which also gave me an excellent opportunity to learn about compute shaders and GPU debugging. Besides performance, I wanted the editor to remain user-friendly and versatile, allowing a variety of effects to be created easily. In summary, my main objective was to create a particle editor capable of stable FPS with millions of particles, while still being accessible and powerful.

Implementation

Why Compute Shaders?

My entry point for this project was to not only make a particle editor, but to make a particle editor with support for massive amounts. And as I had been told, there was only one way, as of now, to achieve this; Compute Shaders.Previous to this, I had almost never heard of Compute Shaders, much less how they work. So you could say this was unknown territory for me. And who knows, it might be for you as well? So let me quickly explain how a compute shader works, and its benefits, in a way that even I would have understood.A compute shader is basically a shader that performs general computation on any arbitrary data you would like, but on the GPU instead of the CPU. And why is this a big deal? Well to put it simply, it is due to the graphics cards optimisation for parallel processing. The ability to process millions of tasks in parallel significantly reduces time and resources needed for computationally intensive tasks.This, of course, made compute shaders a very good fit for my goal of simulating particles on a massive scale, since I wanted to be able to have as many as possible without negatively impacting performance.

Performance

To stress test the system, I decided on three million particles. Initially, I got around 60 fps, with a few drops here and there. The main reason for dropping this low seemed to be the GPU stalling unexpectedly. After some debugging I identified one probable cause.

Issue

The emitter buffer, allowed for CPU write access which I would have liked to avoid since this can lead to resource contention and stalls if both the CPU and GPU try to operate on the buffer simultaneously.

Solution

To fix this, I had to rethink how I was supposed to update the buffer without allowing CPU access. The solution I came up with was to utilize a staging buffer. These are buffers optimized for the sole purpose of communicating with the CPU, and as such, it would make perfect sense to make use of this.So, to properly update the emitter buffer, I made sure to have a staging buffer with the exact same size and structure as the emitter buffer, which was first written to by the CPU with the new values. I then copied this staging buffer to the emitter buffer on the GPU, effectively updating it without direct CPU-GPU access. An extra perk of this is that this allowed copying the data to the GPU using an asynchronous transfer, which basically meant that this step took place entirely independently from the CPU, not causing any stalls in the process.

Result

After addressing this, my frame rate became much more stable and managed to stay between 70-100 fps, depending on how many particles were being culled. Before the fix, the frame rate would not go above 60 fps even with all particles culled (all simulation, no rendering). But after the fix, I kept a stable frame rate above 100 fps, and it would only drop to about 70-80 fps with all particles on screen. This basically meant that the biggest area for improving performance was now the rendering, and not the compute pass.

Ease Of Use

My second goal with this project was that almost anyone (with at least a basic understanding) would be able to create effects easily with my editor. Therefore i tried to keep the complexity on face level as low as possible, to ensure that it was easily comprehensible.Over the course of the project, I would say that this got a bit overlooked at times due to other areas taking priority. In spite of this I feel like the finished product turned out all right.You can see the some example videos of how to use the editor in the showcase at the bottom of the page.

Features

Closing Thoughts

Obstacles Along The Way

One of the biggest challenges of this project (at least initially) was debugging my code, since so much of it took place on the GPU. This led to me spending countless of hours in programs like RenderDoc, tearing my hair over some buffer not being written to correctly.

What I Have Learned

I have gotten more familiar with debugging the GPU using third party software like RenderDoc and Nvidia Nsight. Though a struggle at first, they proved to be an invaluable resource for me, trying to find my way around all the shaders, pixels and buffers.I have also gained a valuable understanding of GPU Parallel Computing and the power it possesses. The possibility of simulating millions of particles without significant performance issues, is to me, quite extraordinary. And I am pleased that I managed to achieve this, even if I would have liked to do even more.

Moving Forward

Had I continued with this project, there are definitely things I would like to improve.My first cause of action would be to further polish the editor to make is as user-friendly as possible. Restructuring it and writing custom tool tips guiding the user through the process.I would also like to extend my feature library to include things like emitting from meshes, force fields, and custom property curves.Performance wise there is still some work to be done, such as switching to tiled rendering instead of rasterization, which would let me draw the particles in parallel, allowing for a further performance boost.

Editor Showcase