top of page
The Slayer - A Slay the Spire Mod
The Slayer is a mod I worked on for the 2017 card game rouge-like Slay the Spire. The intent was to create a new, custom character that would fit into the game's current roster: the eponymous Slayer.
The mod was coded in Javascript, the game's native language. As of now, it is currently on hold, due to requiring additional assets which I cannot create at this time.
Status - Suspended
Engine - Javascript
Skills - System Design, Javascript
Design Goals - Familiarity and Cohesion
The Slayer was envisioned as a an addition to Slay the Spire's (STS) base game roster that should fit in as well as possible, to the point where someone should feel that it could have released in the base game as is. The common trend I noticed within its modding scene is that most characters were designed to be as different as possible from the base game. Many feature large numbers of new, complex mechanics, as well as large changes to the core gameplay of STS.
This is all well and good, but it left a notable niche that I wanted to try and fill with The Slayer mod: That of a lower scope class that has the same refined design as STS proper. So, I set out to make it. Partially out of curiosity, but mostly because I thought it would be a fun challenge.
So, I set a few rules for myself.
Rule #1 - No changes to existing content. The character would have to function within the game's current enemy pool, map design, and metagame.
Rule #2 - Expand on existing mechanics instead of adding new ones where possible. New characters in STS often come with a few additional keywords, but much of the base game pool shares keywords where possible, such as Weak, Vulnerable, etc. New keywords were to be added only when strictly necessary.
With these two guiding principals in mind, I set out to design cards. Of course, this process came with quite a few hurdles.
Hurdle #1 - Actual Implementation
The immediate issue with adding new cards and a character was how to actually do it. Slay the Spire does not have any official modding tools. There is a Steam Workshop page for uploading mods, but the actual creation process does not have an official tool. So, this poses an obvious problem.
Luckily, the community had stepped in with the creation of the wonderful "Mod the Spire" and "BaseMod" tools. They were the perfect tools for this project; their express purpose is to standardize the loading and unloading of mods, as well as provide a simple chassis for the creation of custom content so that others do not have to reinvent the wheel.
This relieved much of the technical concerns I had, and allowed me to focus purely on the raw design when possible. While I do know how to program, for my job it is more of a means to an end, rather than my express purpose. I program to prototype and implement my mechanics, including the underlying systems, but I am rarely creating engines from the ground up.
Of course, BaseMod and ModTheSpire don't do everything for me; setting them up was a process of it's own. Not to mention, I still needed the code for STS proper to understand how it worked. Fortunately, STS was coded in Java, which meant that cloning the files and then decompiling the game was a trivial matter.
Using the IntelliJ IDE, I was able to set up a basic frame work with BaseMod, from which I could then export into ModTheSpire, allowing me to quickly create and update mods with just a few clicks.
Hurdle #2 - Deconstructing Design
With the technical matters mostly handled, it was time to get onto the actual design. This presented a unique challenge. Most projects I have been a part of are ones where the design was in it's early infancy; I was often making fundamental decisions and designing mechanics around those. For this project, those decisions have already been set in stone, and I wasn't there when they were made.
So the first step was to attempt to reconstruct those design principles based on the information that I had. Thankfully, all of the information I needed was inside the game itself. I was able to easily transcribe all of the existing game cards into a spreadsheet that I could use for reference, which I could use to then analyze the card design as a whole.
It turned out to be a very rewarding exercise, and made me notice aspects of the game's balance I hadn't considered before. For example, damage is very tightly controlled in relation to a cards energy cost; very few cards of 1 energy cost deal 10 or greater damage without an upgrade. Those that do almost always come with some sort of drawback, increased rarity, or other change to justify their high damage. While such rules may seem trivial and often quite obvious at first glance, they were essential to making sure created cards fit with the game's existing balance.
The base cards were transcribed into a spreadsheet for easy reference.
Game balance was not the only aspect of a card that needed to be understood Another VERY important aspect of card balance was the style of STS' rules text. At it's core, STS is a strategy game which thrives upon clear information. This can be seen in many of it's essential mechanics: the game even goes so far as to have enemies tell you exactly what they will do on the following turn.
As a result, many of the game's strategic decisions rely on the game's rule text being extraordinarily clear and explicit as to how they function; slight changes to the rules text can drastically alter a card's effects. One very good example of this is the Ironclad's "Iron Wave" card: a card that does damage and grants damage reduction (block) upon use.
The effects are listed in the order that they occur. In Iron Wave's case, the block happens before the damage. This may not matter in most fights, but later fights introduce enemies who will deal counter damage upon being struck. The block happening FIRST means that this card can be safely used against those foes without taking return damage.
STS is littered with niche interactions like this. What makes them special is that they can be intuited through the well written and defined rules text; it is written well enough that a player can rely upon it.
Learning and understanding this rules text was essential to my goal for this mod; while players may not consciously recognize what would be different, emulating the writing rules as closely as possible would make cards feel more "right" to use, and was an essential part of understanding the game's design.
Hurdle #3 - Technical Understanding
Unfortunately, I did not have any experience with Java at time of starting this project. The language was completely unknown to me, which posed an interesting question: how does one learn a new coding language in a short time frame? Initially, I just tried to learn the language like I had C++; through careful study of the basics, learning the language from the ground up.
This was objectively a terrible idea. I learned very little, was getting nothing related to the project done, and was mostly going over things I already knew.
The solution was just to not actually bother learning the language. While Java certainly has its own quirks, taking the time to learn it entirely was unnecessary.
Instead, a more productive use of my time was to learn Java in the context of the STS code base. How does it uses java? What are the rules of it's code base? How did the game's developers choose to implement their cards? For a project like this, I think this is the best method to go about it. Tools and coding languages are always changing; attempting to keep up with the treadmill is an exercise in futility.
Once I adopted this mindset, the actual process of learning became much easier. I gathered all of the cards I had designed into a spreadsheet, and used those as my benchmark for what I needed to learn. This is where the data gathered at the start was useful; if a card I designed had an effect that was similar in nature to an existing card, I could look at how STS implemented it, and use that as a guideline for the implementation of my own card.
It was probably the most interesting obstacle to overcome, and really made me think about how I approach problems like this in the future. Being thrown into an existing code base with underlying rules that I don't understand is a situation that I will be in countless times in the future as my career develops. Knowing how to deal with it will undoubtedly be a boon to both myself and those who hire me.
Designing the Slayer - Expanding Existing Mechanics
Once I had a clearer grasp on the game's design and programming principals, it was time to actually design the character. To reiterate, my primary rules were:
1. Character should function within the base game's context.
2. Character mechanics should expand upon or work with existing mechanics as much as possible; adding entirely new mechanics should be kept to a limit.
So, with this in mind, I looked in the base game for a few mechanics that could be more fleshed out. One that stuck out to me was the concept of what I called "Intent" cards. In STS, monsters possess intents, showing what they will do on their turn to help the player plan out their actions.
Enemies have several different intents for different action types.
This mechanic is one of STS's most well known features, to the point where it's many derivatives almost include it one way or another. It's primarily just a method of delivering information, but there are a few cards within the game's pool that change their effect based upon the enemy's intent.
The only cards in the game which use the enemy intent system.
Notably, there's only 3 cards in a game with over 250 unique cards that so much as touch the system. Each of them only interact with a single intent, that being the "attacking" intent. It's such an underused mechanic that the rules text isn't even properly standardized (note how Attack is only capitalized in one of the three cards shown), as it's such a niche mechanic that it likely didn't matter.
This mechanic was ripe for potential expansion. The game already supported it, but the design space for these types of cards had barely been explored. So I decided that would be the Slayer's primary niche: cards which interact with enemy Intents.
It was at this point I started thinking about the class's flavor. I settled on a "monster slayer" type of character, who's primary strength was her adaptability and high level of knowledge about monsters, which fit the intent cards well.
From there, additional side mechanics still needed to be added; an STS character is rarely defined by a single mechanic, instead being an aggregate of multiple mechanics that support a central idea: in this case, adaptability. Intent cards were only one mechanic that would support this idea; more would need to be made.
Designing the Slayer - Oil and Ignition
It was at this point I realized I should probably have at least one new mechanic. Originally, I considered expanding upon another base game mechanic, the Mark keyword present in the watcher. It was a unique keyword which only applied to a single card in the game, Pressure Points.
Pressure Points - The only instance of "Mark" in the entire game.
However, this mechanic wasn't as fitting as the intent mechanic, and it was too tied up in the Watcher's card pool to just transfer over. That, and it wasn't really fitting with the theme, instead just being a scaling damage option. I wanted something that was more of a set up effect, where as pressure points just rewards playing the same card over and over again.
So I took the idea of Mark, and tweaked it slightly. Rather than triggering it's damage EVERY time a card was played, I wanted the player to choose when to trigger it, at which point it would deal it's damage and clear itself. To make this work, I created two new keywords: Oil and Ignite.
The first was a simple debuff that stacked onto enemies. The second was a keyword for targeting attacks: when an ignite card was used on an enemy, any stacks of oil would be removed, doing that much damage to the target. This meant that the entire mechanic revolved around using multiple cards to set up a powerful burst of damage, giving the character interesting combo potential.
Ignite card
Oil and Ignite combo together to damage enemies.
This was enough mechanics to build a character around, with filler cards interacting with more fundamental mechanics which are shared between characters, such as card draw, strength, and dexterity. Overall, I was very happy with the character's design, and implementing cards was rather simple.
Why Abandon This?
So, with such a promising character, why did I ultimately choose to abandon this project? Two reasons.
The first came down to my own limitations. While I could handle the design and programming side, a character mod like this would require custom art, animations, and other things that are beyond my personal capabilities at this time.
The best solution would have been to commission someone to provide those assets for me, but that would have added an extra layer of complication that I did not feel comfortable with, especially as I would not really have the funds to properly compensate them for their time.
The second was entirely due to an unexpected piece of news: Slay the Spire II was announced just this April. While it is not set to come out until sometime in 2025, that immediately put a deadline on the project. While it's release certainly wouldn't outright kill the original STS, it would mean that there would be less of an audience for new characters and new content, as everyone would be focused on the release of STS II.
That was the mod's death knell; a character mod like this would have required a decent amount of user testing in order to refine the mechanics and balance the existing card pool. Without that, the project would likely stall and never reach it's full potential. With that in mind, I made the decision to abandon the project and work on something which had less strenuous art requirements, and wasn't tied to an existing game.
I have considered picking the project up again when STS II does eventually release; a more active modding community for a new game may be a better time to release such a project. For now, the project will simply remain here. The spreadsheet of the cards I did design is provided in the link below.
bottom of page