Roguelike Project

While I'm personally not a fan of playing roguelikes, I've always wanted to play around with the procedural generation. Unlike the other project pages, this page acts as an ongoing devlog on this concept's development. I want this project to show my workflow and how I work through encountered problems rather than show the final product like the other pages do.

Engine: Unity

Team Size: Solo

Project Length: Background Development, began June 2026

Role: Programmer, Designer

Focus: Procedural roguelike generation

Like with any beginning project, I set up a playable character first. However, my past methods of creating input systems were overly complicated and got messy fast. Visible in my personal project, I'd end up remaking everything that Unity had already created. For this one, I kept it simple and used the pre-made functions Unity's input system had prepared. All I had to do then was plug in functionality to the event calls. Unfortunately, I can't yet avoid putting continuous input in the Update function. I'd like to keep as much out of Update, but a necessary evil for movement, apparently.

A fun visual bug I had when testing out the final result came from not locking the rigidbody's rotation. I laughed at it for 5 minutes straight before recording it to show to my friends.

Day 2

Pickups

This title is a lie, I actually spent two working sessions on this. The first session set up all of the functionality, but originally, it would add the object's Item script to the player's inventory. The issue that rose there was I couldn't destroy the game object to collect it, since Unity still needed it to assign the designated Item in the inventory. Originally, I just moved the collected items to a faraway coordinate so it appeared like they were "destroyed." However, if I want this roguelike to potentially be infinite, there would be a risk that the player would stumble upon the game object graveyard.

In the second session, I changed the inventory to integers that correlate with the Item's enumerator. It's very simple right now, but the idea is instead of wrangling game objects, I could have a number that represents each pickup needed. Whenever a stored object is used, based on what number it is, it'll let the eventual pickup scripts know which one needs to get fired.

Day 3

Inventory UI

Piggybacking off of Day 2's work, I replicated a similar concept for a UI display that shows what objects the player has stored. It uses the same logic the PlayerInventory script has, where it listens for the AddItem event and sets the displayed sprite based on what integer is sent over. Currently, the UI script has a separate Sprite array from the base items, and if the enumerator's order or display is changed, the UI's components have to be manually changed as well. In the future, I want this to be done all in one place, possibly as an array of structs to hold data, but for now, it works. I'd rather work on other parts of the game than make UI for days on end.

Day 4

Inventory Functionality

Now that the player has items, let's make sure they can actually use their items. In order to do that, I had to fistfight my favorite component in Unity: the event system. My previous work recreating the Deltarune battle UI helped out here. The player can now scroll through their nine inventory slots, which automatically loops back to the start or end of the inventory array if it detects its index is higher than the length or lower than zero. There's currently no visual indication of which UI element is selected, but that can be a problem for future me to deal with. When the player has their selected item at the ready, they can use the item and consume it, which sends out an event to the PlayerInventory and the UI display to reset the values in that specific slot.