Wow, I started writing this post around April 2021 and never published it. More updates to come…
I’m working on a card game! About 18 months ago, I started with a Ruby text-based prototype based on the Slay the Spire combat system. (I am aware that STS is derived from Dominion, but have never played it.) Very rudimentary, supporting none of the complexity of the original.
User Interface
I abandoned the Ruby prototype due to the perceived effort of buidling a GUI in Ruby. Among other things, I tried setting up Tk, which meant installing Cygwin — it didn’t work out of the box, and (based on past experience) was unlikely to be quick or simple.
Since the only thing I had built thus far was a tiny piece of the game logic, I considered porting this to a C# console application, but the only advantage to building a GUI application with Windows frameworks is that it’s native.
At this point I took another look at Unity. I had always been frustrated with Unity development in the past, mainly because I didn’t understand how the authoring system interacted with the code. One of my co-workers reminded me that I wasn’t incapable of understanding it — it just had a steep learning curve. After reading some tutorials, it started to fit together.
Events
The thing I find most appealing about STS combat is its chain reactions. For example, playing “Purity” allows you to exhaust cards in your hand. If you have the “Dark Embrace” power, exhausting cards will in turn cause another card to be drawn. If you draw a “Dazed” card, and have the “Fire Breathing” power, this will deal additional damage to all enemies. And so on. When you have dozens of triggers in play, the results can be surprising and serendipitous.
That’s one of the key things I want to replicate in my own game — that sense of surprise, even with purely deterministic rules. The variations in play come largely through the random choice of cards and relics available while building your deck.
Something I realized early on was that designing a game like Slay the Spire is more challenging in some ways than building it. What’s the fun in playing a predictable game? The combinations of effects and triggers were the key to interesting chain reactions. So I wanted to include a card editor that would allow the creation of new cards without code changes. My aspiration was to make it flexible enough to support every card in the original game.
I initially fought hard against using MonoBehaviours where not absolutely necessary, because it felt impure somehow to have objects that couldn’t exist without being attached to a GameObject. But explicit message passing with SendMessage was easier to understand at first than a true publish and subscribe system. I switched back and forth on this a couple of times before ending up with a bare-bones event manager from Gosh Darn Games.