Conga Lyne

GluttonyGame is a work-in-progress top-down roguelike built in Unity with C#, with infinitely generated terrain using Herringbone Wang tiles, SMA* pathfinding, a destructible environment, chunk-based loading and a functional biome map.

I really like traditional roguelikes like NetHack, Caves of Qud, Cogmind, and Shattered Pixel Dungeon. I love complex, interwoven worlds, deep lore with worldbuilding, and endlessly replayable game mechanics.

But that draw has always been undermined by the turn-based nature of these games, which often stems the natural flow of panic when a monster enters the screen. The nervous anticipation of being dropped into a dark, foreign environment is initially immersive, but disconnected from the reality of having infinite time to choose my next move.

GluttonyGame is my attempt to build those emotions I first found when playing traditional roguelikes, played in real-time. I want to feel the rollercoaster of panic, joy, dread, and relief within a few minutes, like I did when I first booted up NetHack.

The feature I'm most proud of in GluttonyGame is the chunk handling system. Unlike the pathfinding and tile generation, which implement published algorithms, this is a system I designed from scratch.

Chunk JSON structure: tileData array of tile IDs, where position 0 is the bottom-left tile of the chunk grid. Each chunk is a 32x32 grid holding 1,024 tiles, stored as a flat array of tile IDs; the value is the tile type, and the index is its position in the chunk.

Diagram: when more than 20 chunks are active, the oldest is saved to c.posX.posY.json and unloaded Up to 20 chunks stay loaded around the player. When a 21st loads, the oldest chunk is saved to disk and unloaded, making the eviction policy an LRU cache.

Diagram: scanning the saved chunk files by coordinate to find and load the matching one Chunk files are indexed by coordinate, so loading "-1,0" is a lookup for c.-1.0.json. Plain JSON keeps debugging easy while the schema is still changing.

Biomes sit on top of the same chunk data. Each chunk records which biome it belongs to, and that decides which tiles, enemies and loot can appear there, with chunks near a biome border blending into each other instead of cutting off in a straight line.

The environment is fully destructible. Every tile can be dug out or destroyed, and the change is written straight back into that chunk's data, so if you dig a tunnel through a wall and come back later, the tunnel is still there.

Elsewhere in the game, terrain generation uses Herringbone Wang tiles, a technique that avoids the visible seams of a square grid, and pathfinding uses SMA*, a memory-bounded variant of A* suited to an infinitely generated world.

The way I'm building GluttonyGame comes directly out of an earlier project. Before this I spent a long time on Empyrean, an RPG in Godot, and closed it out once its code sprawl made every new feature more expensive than the last. Two things caused that: I brought people onto the project before there was enough structure for them to build against, and I built content before the systems underneath it were finished, so every change to those systems meant reworking the content on top.

GluttonyGame is built the other way around. Systems come first and content stays at the minimum needed to test them, so foundational changes stay cheap. I won't bring anyone onto the project until I have a clear picture of exactly what I need them to do. Every new system is written to take as little work as possible to extend later, and that scalability is now something I design for from the start rather than something I hope for.

Conga Bot was my first internet-connected program. Building it meant learning the IRC protocol, how Twitch sends and receives data, and how to design a database that could track hundreds of users reliably.

It runs live in chat, responding to commands and events in real time: playing sounds, opening predictions, and keeping long-term records of chatter activity.

Conga Bot is where I learned persistent data storage and the fundamentals of networked software, lessons that fed directly into GluttonyGame.

Hotflags was designed and shipped in 72 hours for a TF2Maps charity event in 2021, loosely based on Semaphore, a beach I visited often growing up. With limited time, I focused on novel gameplay mechanics. The map is split into three zones: the spawn, mid section, and centre point.

The layout of the map allows every class to excel in its niche: open areas for aerial combat, tight corners for close range, and long sight lines for ranged play. Lighting draws the player's eye towards likely enemy approaches, and respawn timers adapt to whichever team holds the point, offsetting the defending team's territorial advantage with longer respawns.

My process for building maps is:

1. Sketching the layout of the map. This creates clear bounds and scope for the rest of the work.
2. Lay out the rough geometry and map logic in Hammer, Team Fortress 2's map editor.
3. Perform initial playtesting and collect feedback.
4. Adjust to feedback and perform an art pass: add textures, props, particle effects, sound effects, etc.
5. Perform further playtesting and tweak layout, art, and logic according to feedback.
6. Once in a good state, enter it as a Release Candidate.

On Facade and Mannufactured, I built map logic to drive wave behaviour, doors, routing, and mission scripting: Facade in particular features a custom bot that switches weapons based on combat range.

Working to others' pipelines for Facade and Mannufactured were great entry points for learning how to fit my work to another team's schedule and standards.