SALT SWEEPER
A minesweeper-inspired roguelike with fantasy roots — coming to Steam. Authored the GDD, implemented combat mechanics and loot tables, and balanced weapons, enemies, and the economy across 6 playtesting cycles.
>> WISHLIST ON STEAM (opens in new tab) >> GDD (opens in new tab) >> Systems Sheet (opens in new tab)// GAMEPLAY_VIDEO
// FEATURED SYSTEMS_DESIGN
BALANCING THE DIFFICULTY CURVE
Designing with the player in mind means the difficulty curve has to be right. To get it there, I built analysis tools into my balance sheets that compare damage, cost, and drop rates floor by floor. Every number is a live formula, so one change to a weapon or a drop table ripples through every chart the moment I make it, and I can see exactly what to adjust.
The check I lean on most is my damage per round against each enemy's rounds-to-kill. If the gear a floor hands out kills too fast, the game turns easy; too slow, and combat drags against the quick pace of sweeping. Seeing the two side by side tells me which floor needs work, and by how much.
// SHORTS
// KEY_RESPONSIBILITIES
One of my proudest achievements: creating efficient, robust dialogue and inventory systems. Built modular tools and easily editable spreadsheets that allowed me to define item behavior, balance individual statistics, and write NPC dialogue all from single sources.
Minesweeper is fast paced. Turn-based combat can be a slog.
Matching the complexity of the combat to the speed of exploration included many iterations, prototypes, and balances according to testing team feedback.
I drafted and wrote Salt Sweeper's in-depth world building that presents itself in the dialogue and environmental design.
I also wrote each character, from their storyline, to every individual line of dialogue.
Implemented loot tables and balanced weapons, enemies, and the in-game economy across 6 playtesting cycles, tuning drop rates from an editable percentile sheet.
// DESIGN_PROCESS
WRITING THE GDD
All good games begin with an in-depth game design document. Over the years, I have learned that the GDD isn't some place to create the entire game and detail every mechanic. It's somewhere to start and iterate on throughout development.
I began by writing what I knew I needed: a core gameplay loop flowchart, specifics on the world generation, combat specifications, and UI drafts. This gave me a basis to begin my prototype with, and would be iterated on throughout my development.
CREATING THE FLOWCHART
One thing in pre-production I'd like to highlight is the flowchart for the main gameplay. This was the most important thing in the entire document to nail down because it is really a complete overview of the game and gave a basis for development. This was something that I continued to iterate on throughout development.
UI CONCEPT -> REALITY
I mocked up a lot of the UI in aseprite, making everything in rough shapes and titles. IT WAS VERY IMPORTANT TO DO THIS because UI in Gamemaker is notoriously difficult to make edits to (editing would mean a lot of work). With a good plan in place, there shouldn't need to be too many changes made besides general positioning... I made the mistake of not doing this for a couple sections of UI in this game.
SYSTEM DESIGN
I knew that I wanted to have a lot of diverse weapons, items, and spells -- which presents the problem "how did I manage it all?"
To begin, I contemplated working with a json that I could pull from, but I found that it would be simpler and nearly as efficient to just use a .csv to store all the data.
I designed the sheets to be easy to read and edit, making adding new items trivial -- the only thing I actually needed to do in engine was to upload the sprite.
The dialogue system uses the same data-driven approach. I needed to manage hundreds, if not thousands of lines in the final game, so I made an indexing method to keep everything organized. For example, Freya's second story dialogue would be under the index F-1, but an optional event would be indexed F-E1.
Combining this with some cells to host the dialogue choices and to call events, made this system robust, and made the creation of events simple.
Another little bonus that I'm proud of is the item drop calculations. At first I was just using a simple random number generator that would shuffle an array, but that would mean every item has an equal chance of being spawned in a chest. My solution to this was to create an easily editable sheet of percentiles for each item!
COMBAT DESIGN
Turn based combat often feels slow, and that didn't mesh well with the feel of minesweeper. During playtests I learned that players would quickly get really fast at traversing areas, but would be slowed down and have to wait for combat. There was a complete disagreement between the two paces, and I chose to adapt the turn-based combat to a faster pace to compensate for this wanting from the player.
I did this by reducing timers and animations, limiting the player's options, and keeping everything at a relatively low health (keeping the weapons balanced to this so the game wouldn't be too trivial). Typical enemies should be able to be killed within just a couple turns, and bosses might require a little more than 10 on average.
PLAYTESTING
Playtests were conducted for each major build of the game — 6 cycles in total. The build was released to the team, and they played the build with no direction or instruction. Then, they would answer targeted questions and fill out bug report sheets. This allowed me to quickly adapt to player feedback following each build. Later, I scaled this up to group playtests with hundreds of players at expos and conventions (below).
// EXPOS_&_CONVENTIONS
I took Salt Sweeper on the road, running a table at game expos and conventions and putting the game in front of hundreds of players.
RUNNING THE TABLE
A convention table is a level design problem: people walk past in seconds, so the setup has to pull them in and teach the game before they sit down. I brought salt lamps, designed my own signage, and handed out cards and candy to draw in people!
PLAYTESTING WITH HUNDREDS
I put Salt Sweeper in front of complete strangers with zero instructions — no walkthrough from me, just the game.
In under thirty seconds, one player found the move I had never tested. Instead of pressing the retreat button, they simply walked out of combat mid-fight — and the combat UI didn't close. It stacked. Every step opened another layer on top of the last until, by the tenth, we were both staring at a flashing error screen in respectful silence.
Nothing teaches you humility like watching someone break your game in a way you didn't know was possible.
// SCREENSHOT_LOG
