Devlog #5 - More Battle Animations and Code Restructuring
Hello everyone, it’s been a while! There are a couple of reasons for that: I got sick yet AGAIN (probably the 5th time this winter), I spent a lot of time doing “invisible” updates to Frostbitten which aren’t easy to show off and finally because life can be unpredictable sometimes (lol). Anyway the only interesting thing to show off today is a new status animation I made but I will pair it with an explanation of the changes I had to make to the game’s code to implement it.
Anyway, first things first. Have a paralysis animation:
(I’m testing all of the status animations on the bleed status haha)
This animation is part of a new system I implemented which allows animations to be more complicated than single sprites! Actually, it was already partially implemented before now but I’ve added more variation to what’s possible. For example: my new system allows animations to be drawn as overlays on top of enemy sprites, something I am using for status up and down effects (think pokemon). This update is not the restructuring I was talking about, though.
When I started thinking about adding these animations into the game, I realised my battle system, as it was, was not very new-feature-friendly and that it would be somewhat difficult to add new features without some kind of change to the general system. You have to understand, the old system was like a trusty old car that had broken down and been fixed several times over so it wasn’t exactly compatible with the newest gadgets. Anyway, the simplest solution was a major restructuring to allow additions to be easier in the future, and that’s what I did.
So, in order to understand the restructuring, I have to first briefly explain how the old system worked. In both the old and the new the vast majority of game logic and rendering is handled by a single object called “battleController” (if you’re unfamiliar with how GameMaker’s objects work, think of it like a class in another language). This object had a bunch of events (sections of code called under predefined trigger points that are automated by GameMaker) that controlled the flow of combat. I’m sure in the beginning this seemed like the simplest way to do things but as time went on and I added more and more features and the different ways that the state of combat could change was not handled very well. They were quite messy. Plenty of very specific outcomes were hard-coded into events rather than represented by a more dynamic system (as you can see in the image above, some of the functions I defined had comments noting that they corresponded with 2 object events, which is only the beginning of the messiness). Due to this, if I wanted to add something as simple as another point in which an animation played, I’d have to create a brand new event or some other way of representing it and slot that in to what was already there. Without realising it, I had created a nightmare and I knew I had to change it before I moved on. Enter: the new system!
It’s not very complicated or clever but it is very effective. Any discreet state that combat can be in is represented by a “phase”. These phases are defined by functions and the battleController can move from phase to phase freely and dynamically. The phases themselves are also far more generalized. E.g: instead of an event that handles specifically the animation of a specific move, now there is a generic animation phase which can animate anything at all (The “animate_status” phase above sets up the generic animating phase so I suppose its actually more like a hybrid approach lol). And if you want to insert another animation phase in between the flow from one phase to another, that’s completely possible without having to change anything else. I think it works somewhat like those animation flowcharts often used in 3d games with lots of different animations that flow in and out of one-another. Anyway, yay status animations! They get slot in at various points depending on the status (if paralysis stops you from moving, its animation plays at the start of the turn, if bleed deals damage, it plays its animation at the end of the turn, etc). This new system will also make it very easy to add in any new combat phase I might want at any point in the future. To be honest, I thought I had already completed the engine aspects of this game but I suppose you don’t always realise what it is you need until content creation forces you to. Perhaps when I start creating level designs for future levels, I’ll realise there’s something missing from the exploration part of my engine (let’s hope not haha).
That’s all for now! Next time: probably more animations, they take forever :’)
