Summary

Lines of Sleight was my first major game project at UC Santa Cruz. I worked with a team of four other members on the game with a timeline of five weeks from the ideating phase to release. Given this short timespan we attempted to create a prototype to test out core systems and test the viability and "fun" of mechanics. I served as a game designer and programmer during this project as well as helping to manage the team.

Procedural Generation

Taking inspiration from dungeon crawlers such as the Binding of Isaac, I implemented a grid-based dungeon generation system. The underlying data structure for the rooms is a four-way linked list, where each room is linked to adjacent rooms in each cardinal direction. This choice made getting a reference to adjacent rooms easy, but complicated room generation as each room added needed to update the references of multiple room objects. It was originally planned for there to be multiple room types, so my generator chooses from a list of room types defined in scriptable objects. Though the content was not implemented, the system still supports room variety and adjustable room sizes.

The basic rundown of the generation algorithm is a random walk from a starting room that is influenced by set parameters and the distance from the starting room. The two parameters were the branching factor and centering value. As the distance from the starting room increases, it increases the branching weight. The centering value resets the walk to the starting room after the same number of rooms have been generated. A higher centering value results in a more centralized and dense dungeon. Increasing the branching factor results in a more random dungeon while a low factor meant that the walk would tend to create more defined branches, following a more defined direction as the walk grew further from the center.

After this initial generation pass, the boss room was created by choosing the furthest room from the start. Then, doors were created based on the adjacent rooms. Door spawning was aided by a dictionary indexed by a grid position which made finding adjacent rooms trivial. Lastly, enemies were initialized by choosing random spawn points within the room and then fetching a list of enemies from the enemy manager singleton.

An unexpected difficulty in this process was creating the 2D navigation meshes for each room after creating the dungeon. The Unity version we were using did not support 2D nav-meshes well, so it took a significant amount of time and effort to solve the problem. I ended up using Navmesh Plus to bake the maps during room generation as implementing a custom 2D nav-mesh was not worth the time investment.

Mechanic Design

We were given a theme of dexterity and the most intriguing action that came to me during a brainstorm was rapidly swapping cards in and out of your hand. As a D&D player, dexterity makes me think of sleight of hand. And, what's more associated with sleight of hand than playing cards? I am a big fan of card drawing mechanics and deck-building / composition systems in games, so I thought it would be interesting to center a rogue-like around a customizable ability kit. Instead of gathering loot as you progressed, you would draft a build from a deck of cards presented to you at the start of the game.

In my original design, cards would be active abilities that you used and then swapped back into your hand for another card. The combat is fast-twitch with a player fantasy of being the dexterous rogue with a quick counter to every attack. Imagine quickly pulling out a parry card to deflect a hit from a boss and then swapping in a slash card to damage the boss while it recovers from the parry's stun.

To fulfill this fantasy, the interface should involve a tactile feeling of rapid movement. I enabled this by having the player use their mouse to drag cards in and out of their hand. I identified a potential difficulty with swapping cards while also battling enemies, so I proposed a "bullet time" effect where time would slow while you pulled out your deck of cards. Slowed time would allow for a more accessible skill floor while the need to drag the cards in the interface would give the space for dexterous play.

Unfortunately, we were not able to implement this system in the final prototype of the game as the other members of my team was unfamiliar with Unity, and I was extremely limited in time due to conflicting concurrent projects. Instead, we had a heavily pared down version that utilized cooldown timers on cards and a grid-based inventory system. This represented a failure to meet design goals and the end gameplay suffered due to a lack of mechanical depth. I hope to fully realize and test my combat system in a future prototype.