Since the last devlog, I’ve made some pretty big changes to some fundamental elements of the game. The kind of changes that made me sit and contemplate for a good long time about whether I was walking myself into a giant scope creep trap. In the end, though, they were changes I decided were absolutely necessary to get Last Call to where I wanted it, and could be implemented without spinning things completely out of control.
So today I want to walk through the changes, why I made them, and what the impacts are.
Keep It Simple, Stupid
As I mentioned way back at the start of these, Last Call stemmed from a previous design that got a bit too big for its own good. The core of Last Call took several elements from that design and stripped them back to simpler forms with the intent of focusing on perfecting* them.
One of the big changes was to the battle system and how damage worked. I decided I wanted to scale down damage and hit point calculations so everything was (in my mind) very easy for a player to track. So instead of units having 100s of HP ala Final Fantasy, and enemy attacks doing various amounts of damage, everything would reduce down to a few simple hit points.
You can see this version in this screenshot from a while back. The Ardent has 3 HP as shown by their hearts, and the incoming attack from the skeleton is going to do 2 damage.
I liked this system because it was very easy to get the full sense of what was going on in a round at a quick glance. There wasn’t really any need for a player to have to do math, and the iconography was quick to read.
As I continued to build out the rest of the game’s systems and tested battle after battle with newly designed enemies and skills, things felt pretty good! It was quick, clear, and didn’t ask much from the player.
But the closer I came to finishing up the construction of the first “tier” of the game, the more I began to realize I’d set a trap for myself.
Everything felt great for a single run through a few battles with early, easier enemies. But Last Call isn’t about a single run through a single zone of a dungeon - it’s a roguelite with a long-term metaprogression, as well as in-run improvement. Sketching out how that growth looked over the longer term, and with more powerful skills and enemies, I started to hit a rather large problem.
Scale Fail
If you hadn’t already guessed from the title of this devlog, the problem was one of scale.
As characters grew more powerful and enemies grew stronger, having the core numbers as reduced as I had began to create some pretty severe limitations, as well as some spillover UX problems.
The Ardent, for instance, started with 3 HP. The intent for the class’s role is primarily as a healer, but with a slight ability to stand tough when needed as a mid-range unit. Contrast this to the Gallant’s 5 HP (and 1 inherent DEF) who is meant as a front-line fighter. In those terms, things feel more or less in line. As the units leveled up, however, things started to get messy. Giving the Ardent a single additional HP or DEF suddenly put them almost on par with the Cutpurse (another front-line unit). Alternatively, giving the Cutpurse or the Gallant additional HP and DEF made them decisively more powerful against most tier one enemies. Scaling up enemy damage wasn’t the solution, as that made the other units feel too weak.
Where things really started to rear their ugly head was as I put together one of the bosses for the first tier of the tower. Obviously, as a boss, the enemy had to be a challenge. Part of the difficulty right off the bat was giving the boss enough HP to make the party have to work at it. So whereas the toughest individual enemies encountered previously had a maximum of 6 or 7 HP, the boss had 20, plus several points of DEF.
This sounds good on paper, but in practice quickly revealed a few issues. Along with the increased HP/DEF, the boss needed to have strong enough attacks to be a real threat to the party. But with such a narrow range of HP among the player’s units, “weak” attacks that were strong enough to be a threat to the Gallant had to be strong enough to one-shot the Ardent in most cases. This violated the positional roles I’d been intending, making the Ardent feel much weaker than was intended (or, conversely, making the Gallant feel much stronger than intended).
Without falling too much into a pit of swirling numbers (trust me, I have the spreadsheets), the point was these very simple, small numbers were not scaling well past their initial state. Increasing the base numbers was a possibility, but that lead directly into the second major problem: the UX.
Three or four heart icons and a Shield are easy to read. A boss with twenty heart icons and three shields? That’s not so great. Suddenly the “simple to parse” visuals were getting more and more overwhelming. As the enemies and classes grew more powerful, it would only get worse. Four enemy units with, let’s say, fifteen hearts each isn’t easy to read, it’s an eyesore. Plus, giving units more HP and increasing enemy strength to match just meant the simple damage indicator system wasn’t so simple anymore. The player had to stop and count hearts, which is the exact opposite of a “fast and fun” system.
No, despite my attempts to math my way around it, I knew I had a problem that had to be solved.
Expanding My Surface Area
There was a good series of threads recently on Bluesky discussing the concept of “surface area” in game design. Basically, how much possibility space a design creates for a player, and then how much “stuff” needs to be designed to support it. In this case, my feeling was that I had created too little surface area for myself as a designer. By setting the bounds so minimally on where player and enemy stats could reside, I hadn’t created enough room for variation. Even as things got bigger, they felt too flat, making everything feel either far too same-y for the player, or alternatively going the other direction so that things felt massively unbalanced.
I need to give myself some room to play.
Increasing my bounds meant completely rebalancing everything I’d already built, which wasn’t a super exciting prospect but not a terrible one. More critically, it meant redesigning the entire UX to support it. That was scarier, and what had me most concerned about drifting from the essence of what I wanted to create. In short, would things get too math-y.
My fears were assuaged as I looked to a game I deeply enjoy and respect, Slay the Spire. Yes, Spire does require a little counting now and then, but it does a very good job of presenting all the relevant information clearly enough that it doesn’t feel too bad. Working from that as a starting point, I focused on redoing/refining the UI/UX to support the new underlying numbers while at the same time presenting the player with enough information quickly and simply enough to allow them to make informed choices during the course of a round.
To that end, things now look like this:
A big change? Yes.
A necessary change? I really think so.
Since making these updates, I’ve felt a lot better about the direction of the game, and it’s opened up a lot of new avenues to make both the enemies and the progression system more interesting. At the same time, I think the UX is still good (though with lots of room for improvement, still), and the core idea of readability is still intact, and perhaps even improved.
It was a scary move to make, but one I ultimately feel very good about. There are certainly advantages to trying to keep things tight and minimal, but it is possible to wall yourself in too tightly as a designer if you stick to it blindly. Scope creep is bad, but allowing your design to grow naturally into what it needs to become isn’t.
NEXT TIME: I’ll finally talk about the various classes in more detail. For real this time!
*Or, more accurately, just making them really good
PS: Station Zeta is now available on Itch!