Now that I have AOE cards working, I have nothing I can use to put off making proper run-start and run-end menus.

This week has been mostly working on behind-the-scenes things. I got cards that swap positions working:

And I also reused the battle-log code for status logs that appear above units' heads, so now it's clearer when a ton of things happen at once:

I feel encouraged to start using more complex combinations of statuses in enemy design now that the information can be conveyed clearly. Sometimes style is required for substance.

I've implemented card rewards after each battle! It feels nice to be approaching a proper vertical slice. (does having a Roll card officially qualify my game as a soulslike?)

I've also made a battle log system so players can review what happened.

Designing the card reward mechanic was an interesting challenge -- we have two characters, each with two decks of cards. How do we let the player incrementally build these decks while not overwhelming them with complexity?

My goals were to:

• Lean towards many simple choices, rather than few complex choices -- let depth emerge from the sum.
• Not overwhelm the player with too many choices in a row, because that feels the same as making a single overly-complex choice.
• Encourage balance in how much each character is developed.

I could think of three ways to handle it.

1. Shamelessly Copy Slay the Spire, But Four Times

It would certainly ensure that characters are developed equally, but even thinking about this many choices in a row makes my head hurt. Would we need to make four choices after each fight? Would we only get to make these choices after every 4 fights? Would these choices rotate in a round-robin format, and potentially rob the player of a critical choice if they happened upon a boss battle at the wrong time in the cycle?

None of these options seemed appealing.

2. Shamelessly Copy Slay the Spire, But Twice

I could see an advantage to separating Actions and Gambits; it would make sense to gain a Gambit every battle, but less so an Action every battle, because they'd rapidly clog your hand. I could reserve Actions as boss-battle rewards, or maybe an option at a rest event.

However, because Mighties rely more on Actions, doing so would leave them to stagnate between these "big" events. It would also reduce the excitement of each draft if you really wanted a new Action and knew you wouldn't ever get one, and it would increase the frustration of finally arriving at an Action draft and disliking every choice.

3. Shamelessly Copy Slay the Spire, But Once

By mixing all four decks into the pile, I'd have to manage some probabilities to encourage balance:

• The left card has a high chance of being a Mighty card, while the right card has a high chance of being a Magical card. The middle card is equally likely to be either.
• Whoever has drafted fewer cards has an increased chance for their cards to appear in any slot.
• Actions are much less likely to appear than Gambits, but they could potentially appear any time.

The result of this tuning is that if cards were picked entirely at random, the heroes would fairly split how many cards they each get to draft, and they'd each have a healthy division of Actions to Gambits. But, if the player really wanted to, they could create an absurdly off-kilter build -- and isn't that part of the fun of a roguelike?

By managing probabilities on the game side, I can spare the player much of the complexity, while still being able to tune the card spread behind the scenes. Anyone who wants to get super deep into the mechanics can still get a "feel" for how cards are rewarded, but the player's mental load is lowered significantly by only showing the information they need in the moment.

This system also dovetails easily into other event types -- I'm planning on having ones that let you specifically mulligan your Actions, and other ways to fine-tune your build.

Roguelike dungeon generation is ultimately a pacing mechanism -- a well-generated dungeon is one that creates a good rhythm of rising and falling tension when exploring it. Since my setting works on dream logic, I thought it'd be fun to have the player go through the dungeon as it's being generated, rather than afterwards.

This conveniently makes it easier for me to pace the run, since we can decide in the moment where the next paths go.

To that end I've been rewriting the map generation system, moving away from separate algorithms for each area to one very parameterized algorithm and different "chunks" for each area. Eventually I'll have animations for new tiles coming in and old tiles falling out.