HornedLizardStudios
patreon
Devlog 22/04/2022 - The player and combat rework
🕑 Added 2022-04-22 10:06:26 +0000 UTCGreetings everyone! It's me, Vero / Tib! I wanted to share some progress I've made for the past few days since we released! I got a lot of feedback, a lot of positive, and quite a few negative, and I'm very grateful for all of those! I thought I'd go through what I got out of all the feedback and how I'll continue going forward with the updates! It'll be somewhat technical but of course, I will provide some in-game videos too to illustrate what I'm talking about!
So, for this devlog, let's talk about...
The player and player movement
From all the feedback I got, including the crash reports I got (Thank you for those who sent it back!), it was clear that I made a mistake when designing the player object. There are a couple of key issues with the current implementation.
- Too many objects depend on the player object being present, and vice versa, the player object depends on too many other objects to function without a crash.
- The state machine I made, while decent, was very, very difficult to see through, hard to follow, and it required me to change the state manually anytime it needed to change, and sometimes that change happened OUTSIDE the player object, which is bad.
- Because of the not-so-ideal implementation of states, animations didn't really sync up properly, some of them we didn't even implement, and transitioning between them was rough and uneven, sometimes even choppy and inaccurate.
Now, the first and most important change I need to make is to completely isolate the player object from everything else in the game, make it independent, and only change it's state using a few public functions, and not directly addressing the player object, but rather, using a reference to it returned by another built-in function in GMS2. This will eliminate crashes that happened because an object tried to change a variable inside the player object, but the player object was disabled or didn't exist at the time. This will be true for other objects later on, but right now I wanted to focus on the most important bits.
Now, what's the solution exactly?
I've started using a really amazing state machine implementation called SnowState which helped me build a much smoother player object. How did it help? For starters, each state can now have an "enter" and "leave" event, which is a huge deal, it means I can quite easily chain animations together and make things look more consistent. As an example, I started by reworking the crouch, crawl and standup states.
Here's how the old implementation looked:
And now, with SnowState, here's how the new implementation looks:
(Ignore the speed difference of her movement, it's all placeholder stuff)
So as you can probably see, there's quite a big difference between the two implementations, and the code behind it is much, much cleaner too! What I then started to do, is re-think the combat. Currently, it's not very fun, it's mostly just trying to dodge away from the enemy even if you're in a corner, and it's just overall very clunky. I didn't get to the AI just yet, however, I did start to implement a few fun things to the player! First, we'll add a block ability. And with it, a few different ways the player could go down. One of those possibilities is running out of stamina. Blocking an attack will consume some stamina, and if the enemy uses a heavy attack when the player has very little stamina, OR if the player is not blocking during a heavy attack at all, this will happen:
Sephra is working on slightly reworking these animations so they can chain together even better, but you get the general idea!
I will be posting devlogs more often now to keep everyone up to date, and give everyone an opportunity to tell us if something looks / feels good or should be changed!
So feel free to tell us what you think, and once again, thank you so much for all the support and feedback, both positive and negative, we really appreciate it and it helps us keep going!
-Vero/Tib
