I said last week that we’d have “proper combat with working enemies” to show off—a 90s back-of-box feature if ever there was one—and here it is:
I’m not much of a streamer. Next time I might connect a mic and give a bit more context to what I’m showing. That would probably save me from feeling the need to do so in these posts.
First, I want to say how pleased I am that we’ve gotten Magical Spell Masters to this state. We made a huge amount of progress just this past week in bringing the systems together, and our plans mostly worked out with relatively few errors. As I’ve said before: these systems are highly generic. The only difference between the player and the enemies is that the former constructs spell attacks based on the content of the spelled word; enemy spell attacks are authored in the inspector. Huge shout out to Fred, my programmer in arms, for his ability to keep all this stuff organised in his head. I’ve learned a tonne working with him.
Anyway, the combat needs a few more doodads. Our elemental status effects (frozen, damage-over-time, etc.) still don’t do anything. But it’s now in a position where our designers, Finn and Sean, can grab it and dial in some nice variations of rune frequency, enemy types, health pools, letter frequency, and all the other variables we’ve exposed.
This current build is surprisingly fun to play. The lower player health pool leaves you vulnerable and, without the various weakening/freezing effects in play, you really need to make use of the nature runes to heal yourself. I don’t think we’ll want them to heal quite so much, but we’ve only just begun the slow work of balancing all the runes.
Our next steps for alpha are:
- adding level loading; completing the game loop
- adding win/loss state
- adding ‘story’ panels between battles
- implementing data tracking
- implementing saving/loading
- adding tooltips
- adding a tutorial
- implementing boss mechanics
- getting all our blockout assets (models, textures, sounds, particles) in there
There are a few specific problems that are weighing on me. We need to neaten up the overall UI. I originally liked the idea of having the runes floating in the scene, but the more I play this build, the more I see the wisdom of having a ‘traditional’ background for the rune grid and drop zone. Something like this mockup from Sean:
This might make it easier to find places for our buttons, upcoming letters, and spell property UI elements. I don’t think we can have a background element for the drop zone due to the way we’ve designed that class, but the book concept has grown on me.
I’m also a little concerned about our spell property icons. It all stems from the fact that we’re wanting to link spell property strengths directly to the score of the spelled word. This stands in contrast to Slay the Spire or Monster Train, where status effects have fixed strengths and are merely stacked by the player. In those games, poison effects perform [STACKS] damage per turn. Strength boosts damage by a fixed percentage and, again, is just stacked.
In Magical Spell Masters, it’s a little more complex. Here:
The player spells ‘duly’ with the above runes.
The base damage is 8. Two electric runes boost the base damage by 25% each, giving us a modified damage score of 12. One nature rune will heal the player for 25% of the modified damage and, when it’s working, the ice rune on the right will apply one stack of frozen to the target, preventing them from performing an action next turn. (There are no percentages associated with the frozen property.)
This makes enough sense to explain here, but the trick is how we get all this info in the UI and onboard the player during the tutorial. The 25% figures I mentioned above are magic numbers; Fed and I actually want to have a customisable scaling function that lowers the effectiveness of multiple runes as you combine them in a word. But do we add these strengths to the property icons? We already need room for the ‘stack’ value on the icon. The poison property, for example, will need to display both. Suffice to say, these icons will need to be bigger than those in Slay the Spire. We’ve also talked about not using iconography (skulls, leaves, etc.) to give more space for numbers. We could instead use the elemental materials as a background to these UI icons. So our water/weakness icon might look like this:
Anyway, it’s a tricky problem. We can obviously surface more information in tooltips, but we need to get it in the surface UI if possible.
I’m also concerned about how arbitrary a lot of these numbers end up feeling. Stacks makes sense: two runes gets you two stacks. But these percentages are fairly abstract. Will players be able to process all of this info to the extent that they can make plans and strategise? Will enemies end up accumulating too many status effects? We need to test this thoroughly.
Let’s finish off with a few bits and bobs. Sean has been texturing our player and boss models:
Lookin’ good. And here are a couple of GIFs of our enemies dying. We just apply forces to the rigidbodies based on how much ‘overkill’ damage they take. It was only ever meant as a temporary death behaviour, but we find it kinda funny:
Aaaaand stuff going wrong:
Nice.
I feel like we’re making real progress now. Completing the combat loop this week was a significant achievement. Next week, we’ll have spell properties/status effects properly in place, and hopefully a better looking blockout scene, with more sound and VFX.