UPDATES FROM THE TEAM
LILIAN
I have been working on the second map for the final game. This map is supposed to be a contrast to our first cloudy/mountainous map. It’s a totally flat desert and we initially designed it such that the only way for players to die would be to get knocked out from either side of the field. But we thought that was too boring, so we decided to add sandpits that open and close at random intervals.
CHUYUE
This week, I was working on a level selection scene and a level template so we don’t have to create each level from scratch. The level selection scene was simple to implement, and it makes our game feel more complete. Now, we have almost the whole flow of user interaction from beginning to end. My next step would be to show the players how many other people are in the room and what the other players are picking for their characters so that they feel more connected with their friends even though the game is online.
ZHI HANG
With the feedback and suggestions offered by the team, I’ve added some motion lines to all animation frames that reflect motion. While Unity’s automated slicing method is accurate enough to slice out every frame, it separated motion effects/lines from the mainframe (hence some manual editing was required).
The newly-created animation system implemented by Gabriel made the importing process much smoother and more efficient. Once a character model is created (derived from a parent model), I just have to rename it, import the sprite sheet into Unity, create a new Animator Overwrite Controller and assign the frames into their corresponding actions. Once the animation model was done, the next step was to create the Cactus character object, which is just a Prefab Variant of the parent model. After a few adjustments, the model was ready to go.
The animations looked great in-game. But some of the frames were played too briefly (eg. the frames for the charge attack buildup were played so quickly to the point that only the last frame was played). Moreover, the Cactus’ movement feels too “static”. I should add some “squash and stretch” characteristics to its animation to emphasise its motion. I would have to draw some more frames for some of the shorter animation strings to pad them out (perhaps a glowing effect for the charge up).
Moreover, I did not draw the subsequent animation frames immediately after the one with the motion lines. It was strange to still see the motion lines during the entire period of the jump.
AIK PENG
This week, the initial goal was to re-import the Crane animations through sprite sheets, but I ended up doing a bit of ‘reorganising’. As mentioned last week, most of my frames were drawn on Photoshop’s Video Timeline Tool. However, after researching (as well as something breaking in my Photoshop), I realised that I should have used the Frame Animation Tool all along… (I blame the tutorial that I followed D: ) And so, most of my progress this week was figuring out how to transfer my work onto the Frame Animation Tool, and then importing the animations using the sprite sheet. With Gabriel and Zhi Hang’s help, I was able to import the walking animation into Unity and test it out! With the goalpost shifted, I’ll be transferring all the animations that I have created into new files that use the Frame Animation Tool, and finish importing the animations into the Unity Project.
ROBIN
This week I wanted to add the recovery state into our updated and refactored state machine. That proved harder than I expected since we are no longer using force or rigidbody. I realised that I have to retool the current jump velocity and parse in different values to simulate the recovery.
Also, we decided to assign a separate button for recovery and dashing instead of setting them with multiple inputs. The initial plan was to set the recovery movement as the jump plus a special move, but we felt that setting it to a single button press makes it more accessible and easier to utilise. Similarly, dashing was supposed to be activated by double-tapping a directional key, but we decided to have it as a single button press instead to prevent the character from stuttering due to the transition from a run to a dash.
YU CHUN
Figure 1. A cactus getting knocked into the air. Knockback is working again! (kinda)
This week, I managed to fix the knockback after trying many different ways. Knockback occurs whenever a character is attacked by another player. The character is temporarily stunned and knocked backwards into the air. This was a feature that was broken during the migration from the physics controller to the ray cast controller. However, it is still currently in the works as the knockback teleported the player instead, which seems weird. Will need to work on knocking back the player in a more parabolic way.
GABRIEL
Finally finished with the player refactoring. Phew!
I never want to refactor again HAHA.
Feels bad because every time I do a refactor, I add regression bugs to the game. Send my regards to Robin and Yu Chun!
In the process of tidying up the character scripts, I also started reorganising the project to simplify the workflow for our artists. Yay! Now it’s much easier to create player animations, and they don’t have to worry about messing around with the scripts controlling player movement.
Now that I don’t have to do refactoring, I can focus on adding new features! I’ll be focusing on adding more polish to our game, possibly using VFX and SFX. Game music has been put in the backlog for now, but I’ll continue to experiment with any BGM ideas that I think of during the weeks ahead.