I can’t believe how fast summer has come and gone. It seems like yesterday we updated the blog with the last round of updates. A few months have passed and we are excited to show a whole lot more!
The majority of the time spent on art has been adding agile thrusts for our hero and agile weapons. It took a bit of back-and-forth because we were originally rotating the agile weapon at the angle between the holder of the weapon and its target. However, pixel art doesn’t rotate well. After countless hours of trying to solve the problem programmatically without compromising the art quality, we decided to draw out each rotation ourselves.
We decided that thrust animations worked well at 20 degree increments and the actual weapon itself would be rotated at 10 degree increments. As an example, if the hero and its target is at an angle of 22 degrees, the closest thrust animation is the 20 degree animation (choosing between -40, -20, 0, 20 and 40) and the closest weapon animation is also the 20 degree animation (choosing between -40, -30, -20, -10, 0, 10, 20, 30, 40). Therefore, the animation we’d use is the 20 degree thrust animation and the 20 degree weapon animation.
There obviously is a little bit of “precision” lost from a combat standpoint, as in the above example, being off 2 degrees is not exactly equal to the intended target angle. At its worst, the angle could be off 5 degrees. To account for this, we make sure the hitbox of the weapon is within that +-5 degree offset. Therefore, Tony made sure as he was designing the art that the agile weapons’ graphics / hitboxes were big enough to account for this margin of error.
It was very tedious process, but after playing around with the agile weapons, it not only looks great, but feels great to use as well.
Environment
Right at the beginning of the month of August, we worked on a few trees and plants. With all of the updated crops, we couldn’t remember if we were making an action / adventure game, or a farm sim!
Other Notable Updates
As we were updating the agile weapons, we realized that combat was weird with the right swings of the balanced and heavy weapons. We realized that the motion was essentially mirrored and thus when turning the character, the right swings didn’t transition from the up swings, or into the down swings. We ended up reanimating all the right swings for both our hero and the weapons.
Another weapon mechanic functionality we changed is not allowing the player or enemies to change direction mid swing. The player could spam the joystick many directions per second which would make the weapon appear all over the place, being it a bit overpowered. Not only did this solve the overpowered problem, but also fixed and smoothed out the animation between swings.
We also updated a few tilesets / backgrounds. Some palette swap functionality updates are needed, but the mountain region has a new look and feel as well.
There were several minor TODO items we have cleaned up and polished as well as polishing the Soldier enemy AI. There was an issue where the player could hide behind the tree and the enemy wasn’t able to compute a path to the player. This was due to the player’s hitbox colliding in the tree’s hitboxes, which made the tile “walkable” for the enemy (from an A* standpoint). We make the tile the player is standing on a “walkable” tile so the enemy can compute a path to the player. However, the enemy is programmed to not actually walk through the tree. We tweaked the values of the hitboxes as well as a few offsets to fix this.
We had three major components we refactored this time around: Playback / Recorder Input, Going inside Buildings, and the Soundboard. In this post, we introduced the feature of being able to record a player’s input to then playback after a session. This lets us recreate a bug consistently so we can squash it. When we created the Playback / Recorder Input originally, we hardcoded a lot of things in the HumanInput controller, and we wanted to abstract this to be more OOP, where the InputRecorder was an object and the InputPlayback was also a separate object, both doing their own unique things.
Though we’ve had the concept of going inside / outside of buildings for a while, it was half-baked for pretty much everything but the player. This system has been completely revamped to handle just about anything. In our object hierarchy, we added an object type called Renderable that keeps track of what building it is inside of and whether it should be rendered on screen, or fading in / out due to a building transition.
Last, but certainly not least, we refactored the Soundboard object. The Soundboard object has been growing quite a bit since its inception at the top of 2019, but there hasn’t been a lot of cleanup to it. We recently started hardcoding different looping sound effects, like rain and fire, instead of putting them in the Soundboard for it to handle. We’ve now “rewired” this so that it handles a lot more uses cases, and should be much easier to expand down the road.