Last updated on 13/06/2019
Last week, I had started to work on the battle system for my RPG. I laid out a laundry list of work that still needed to be done to get to where I wanted to be. This week, I’ve been able to tackle:
- Port over the turn taking logic
- Port over weapon definitions
- Port over to hit, damage calculations
- Add in the basis of hit, evade animations
- Port over skill / spell definitions
Again, things were a lot harder than I had anticipated. Porting over the logic was pretty straight forward. Python and the language inside of gamemaker are really similar to one another. I could, largely, just copy and paste the relevant formulas around for damage, turn taking, and so on.
What was hard was that I’d forgotten a lot about the state that the system was in. There were lots of things I knew I had touched on that I thought were more complete than they were. For example:
- I’d half set up the character equipment system, so I had to finish that before a character could hold a weapon.
- Objects in the battler were constructed, but they couldn’t easily interact without a lot of pushing references around.
- I had designed, but not yet used, the state machine for the battler
- The default battle action menu was just a stub list of menu elements, rather than being pulled from the active character
Additionally, I hadn’t realized I would need to represent the animations I wanted to do as a result of a hit, miss, or spell as some sort of object. That was just a silly oversight. So, the bulk of my work this week was carrying things the distance between where they would draw on the screen and to where they could successfully interact with one another. Then there was a little green-field work in animating the battle damage, including animating the text.
Animating the text for the battle damage was a fun little piece of work. It works by slicing the string up character by character, and then repeatedly moving them through a bounce animation with a lower peak each time. Characters are animated independently, and there’s a lag time between when a given character appears and when the next character, the one to it’s left, appears.
I’m not 100% happy with how it looks today, but the concept is more or less there in total. It won’t be hard to refactor this class into a general “ease text in” class that can do different kinds of animations for different kinds of situations or damage. In particular, it’ll be easy because the character ‘step’ calculation above is totally separate from the painting of the character below. Changing the kind of animation that happens is just a matter of replacing the ‘bounce’ animation below with something else, either in a childClass or by storing different sorts of text easement scripts in the animated label and invoking those on draw
I did a little debugging infrastructure work when setting up the battle damage animation. And I’ve done exactly this thing often enough to think of it as a sort of pattern:
- I set up a room specifically to test an object or a small set of objects
- I don’t fully implement the logic of the object, I just have it step through animation steps
- I hop directly to the room rather than the debug hub world while working out the object’s animation
- Once I’m ok with how the object animates, I hook up its logic
- Then I re-point the game back at the debug hub rather than the animation debug room
- I move the debug room into a group of animation debug rooms for later use
Here’s what I want to accomplish in the next bit of work on the battler:
- Do for Skills / Spells what I’ve done for attack
- Enable the “Defend” action
- Handle the win / loss transitions
That notably leaves “Items” unfinished. That needs tackled, but I don’t have an inventory system in the game yet. It’s sort of hard to use items in combat without a working party inventory. So, barring immense success or drawbacks, that will be the last week of June: stub out the party inventory system and populate it with a few items to kick the tires on the battle systems.
Getting ‘done’ with the battle system will really only mean that the moving parts are all in place. I’ll be able to draw an attack and deal damage to some enemies. The pieces that handle combat spinning up and tearing down will all work. I’ll be able to use a skill or an item in combat. But I won’t have done all skills, and I won’t have done all items. All enemies won’t be in either. So, I’m thinking of ‘done’ as more of a ‘feature complete’ rather than ‘feature and assets complete’. I think I’m still on track for that by the end of June.