This week presented another collection of issues related to limitations in what the Godot game engine is able to do. My starting goal this week felt like a simple one: get the bow draw animation functioning and the ability to shoot an arrow. I anticipated this might take me a few hours. Oh, how naive of me.
But before I could actually start on that goal, I had to fix an issue I had from last week. When I implemented the mouse detection, I couldn’t for the life of me figure out how to register the center of the screen (the player) as position (0, 0). Instead, (0, 0) was always the top-left pixel of the screen. Then one night as I struggled to sleep it hit me… I could just take the Vector and subtract it by half the width and half the height. Sure enough, this got me the result I was looking for (negative values represent the left and up direction).
It’s amazing how often this happens to me while coding. Spending hours looking up information and being utterly stuck on something only to realize the next day the solution was plainly obvious and I was just looking too deep.
Anyway, once I was able to get that going I added the bow draw animation to the game. It was simple enough to get a bow draw setup going, but nothing worked quite how I wanted it to. Ideally, when the character drew the bow, he would hold it at the ready and be able to change directions aiming it. But I was having an issue where every time I turned directions, it would trigger a new animation (because he was now facing a different direction) and thus do the bow draw animation again.
I spent hours trying to find a solution for this. And this is where the Godot limitation showed severely. The solution was conceptually simple. I wanted the animation to play and hold on the last frame, and I wanted it so that if I changed direction it remembered which frame I was on and started the next animation on that frame (this would give the added benefit of letting me turn mid-draw and it continuing it seamlessly. However, because the system I was using was an animation tree blend space, it was not technically using the animation system. And while the animation system itself had the ability to start an animation on any frame, the animation tree blend space did not. Even more frustratingly, it had the ability to retrieve the frame I was on, but not start on it.
Eventually, with much support from the Godot discord, I used a slightly more patchwork solution of having the final frame be its own animation node and instead of ending on the last frame, I automatically transferred from the bow drawing animation node to this animation of a single frame. This let me freely move my position around since it didn’t matter if it reset the single frame animation. Thus, I had this:
Looks great, right? Sure, in this carefully curated demonstration. But what you don’t see here is that if I rotate mid animation, it was still resetting the animation and if I rotated fast enough the character would never finish the draw. If I was fine with it then it would have been over. But what fun would that be? Surely there had to be a way to fix this.
Long story short, I spent the next 6 or 7 hours working with different people in the Godot discord and trying out different theories to get the functionality that I wanted. It seemed so straightforward, but there was no one system that would just do it for me. Which would be fine, but, it also just felt like I knew where to look if there was a solution. But Godot just didn’t have it.
In the end, the problem solving went like this:
- Identify a feature that wasn’t working
- Find something that fixed that feature, but broke another feature
- Repeat
Eventually, I was able to get together 3 or 4 different systems in a cocktail that got the functionality I wanted. Oh, and I got the arrow shooting, too!
All in all, it’s a great learning process despite my frustration.
