Before The Engine

Prototyping Without Code

2025-02-01


Is It Fun?

If you've ever played Slay the Spire or other roguelike deckbuilders, you probably remember runs where you had a really interesting turn or difficult line to solve and doing so lead to you clutching the win. It feels really satisfying. One of my main goals with the game is to try and maximize those moments, not necessarily where you're thinking at max capacity as that could be draining, but I want you to always feel like there are some choices you can make. Even if the line is solved (ie vs a Cultist on floor 1 of Slay the Spire you probably have a good idea of what you'd play with just about every possible hand/deck configuration if you've played enough of the game) I'd like there to be some amount of thinking because in my opinion that's the fun part of the game.

But where am I going with this? Well, mostly that I have an idea of what I want to feel while I'm playing the prototypes. I find it's easier to tell if I'm on the right track if I have a destination in mind, but don't be afraid to change directions if in your experimenting you discover the fun is somewhere different than you expected. Follow it and see what you find!

Believe it or not, my first couple weeks of prototyping were almost entirely in a .txt file. I started with a basic Slay the Spire Ironclad starter deck and the easy pool of enemies, redefined the cards a little for my needs (added secondary effects if played at a secondary cost threshold, eg strike might be 6 mana: 6 damage, 4 mana: 4 damage,  etc), and then played the fights over and over again in text with different mana systems and tweaking numbers (cost, max mana, damage/block, etc) until it felt right and I was having fun playing with the states to get to the lines I wanted. 

I'd include examples, but to be honest I think they'd be completely illegible to anyone but me.

Once I was fairly happy with each of the mana systems - yes each, every character has a unique mana system to give them each their own personalized feel to play - I moved onto prototyping the UI. Don't worry, I'm not going to tell you I did it with ASCII art, I'm not quite that crazy just yet. I used powerpoint for this mostly because it was convenient, but you can use whatever tool you prefer to draw shapes with. 

Is it Clear?

One thing you'll learn about me over the course of these updates is that I am a stickler for UI/UX in games. If all necessary information isn't available to a player at a given time when they'll want/need it then in most cases I think the interface is insufficient. I will cut content before I compromise on the usefulness of the UI. At this point I know vaguely how each turn is going to play but I don't know how to nicely represent this data to the player. 

There are a few things we need to solve here in a way that the player can tell the information at a glance, this includes when the card is not the focus, and so is being obstructed by both the bottom of the screen and other cards:

At this point in development I was planning on having 3 possible effects per card, I cut that pretty quickly when it became clear that the space requirements would be unreasonable and make the cards look very barren when there isn't much text. Now cards typically have 2 possible effects.

For points 1 and 2, the answer is fairly simple, I just have a "container" running along the side of the card to communicate what it actually looks like, the issue with this is that it can be obstructed by the bottom of the screen when it's not the focus. But we can fix that with a simple bit of trig to resize the container such that it always fits fully on the screen.

For point 3, I initially solved this by giving card border and text of the relevant cost/effect a glow with a color to represent the state. 

The issue with this solution is that it's possible for the text to be obscured, so at a glance it's not obvious which fill amount you have when the card glows green.

My current solution no longer makes the text glow and instead added a blue glow for when the card has exactly enough mana for the secondary cost. As seen below (now implemented in game) with this legally distinct strike

Empty - no glow

Has mana, but unplayable - red glow

Exact for secondary effect - blue glow

Playable, but inefficient - yellow glow

Full, primary effect playable - green glow

For point 4, when you click a card with mana it will move to the center of the screen, you can then either play it (if possible) or if you click another card pour mana from one into the other. While hovering you're also shown the future state so as to enable the player to make faster decisions, as shown below. The first clicked card will move across the screen to ensure no necessary data such as tooltips are obscured.

Game Design Documents

People have mixed opinions on GDDs. For myself, it's a place where I can organize my thoughts, have an idea for a character, mechanic, relic, card, etc? Write it down here. The primary value is twofold:

Some people treat GDDs as a guiding document, I don't really use it for that. What I want the game to be lives pretty strongly in my head. As of writing it's currently it's just about 2k lines of various informal ideas and machinations vaguely organized into topics such as "Cards", "Relics" "Events" and "General". It varies from fully fleshed out systems and items/encounters to a couple words to remind me of something I might want to expand upon later, I'll often message myself only a couple words when I think of something away from my computer to later add to the document when I sit down. It doesn't need to be fully fleshed out, just enough to jog my memory on what I was thinking at the time.

regardless of how formal you choose to be with it, I would absolutely recommend any designer have a storage/organization document of some kind, it really helps.