UPDATES FROM THE TEAM
LILIAN
This week, I completed the camera and parallax settings for the cloudy mountains scene. Parallax makes the environment feel much more alive and dynamic. As this is a multiplayer game, the camera was programmed to always be centred at the average of all the characters. There were also some subtleties like ensuring the camera didn’t exit the boundaries of the backdrop and ignoring players who are supposed to be dead (off-field).
CHUYUE
This week was recess week! I worked on displaying the other players in the room as well as showing the players what level their friends have selected. Working on this actually revealed a bug that we had never found while trying the game. Using Actor Numbers in Photon to determine spawn points and player indexes won’t work because Actor Numbers will never be reused, meaning if there are already 4 players, and subsequently one leaves and another player joins, the new player will be assigned as Actor Number 5 and hence would not be able to spawn on one of the 4 spawn points. Lucky I was working on this or else I would never have caught that.
ZHI HANG
To improve the look and feel of the Cactus animations, I referred to this video. It talks about the principle of Squash and Stretch, stating that animated objects can be drawn to look longer or flatter to emphasise their speed, momentum, weight and mass.
The more (less) squash and stretch, the softer (stiffer) the object. Applying the concept to the Cactus character, whenever it is falling down, I could stretch its figure due to the speed it’s falling. Then squash it upon landing (not implemented yet).
I have also added additional frames to generate some anticipation of the Cactus’ actions. The ending result would allow the Cactus to move smoother.
Aik Peng has referred to me a very useful reference website: The Spritiers Resource. It hosts a large variety of sprite sheets of characters from popular video games. These references are extremely useful to see how other professionals drew certain actions for their characters. I looked up some Mega Man references to gain some ideas on how to draw the charged animations. I’ve decided to draw a glowing silhouette or an outline (that changes colour based on the charge progress) to signify the Cactus’ charging animation.
Next, Aik Peng and I are going to draw out some independent effect animations such as dust clouds and hit impacts. These frames are to be drawn separately so that we only need to draw them once and use game code to render them in-game during appropriate times.
Applying all these concepts I’ve learnt so far, hopefully, I am able to draw out more refined animation frames for the next character - the Penguin!
AIK PENG
I finished importing the crane animations (including the hitboxes!), as well as touching up some of the animations to make them flow better. On the surface, it doesn’t look like much done, but I think most of my foundations are better now, and when I polish up the sprites for the crane, it shouldn’t be too difficult to do. At the end of the day, I’m really happy with how the crane animations turned out! I probably need to figure out if there’s a better way to create sprite sheets though, but if it works it works I guess.
Other than that, I also made some minor tweaks to the UI mockup in accordance with feedback from my teammates.
ROBIN
I’ve managed to add the recovery and dashing states for the player characters. Recovery only works while the player is midair, and there is a variable to allow the player to perform the recovery multiple times before landing on the floor. This will be useful since the cactus can make one big jump to recover, while the crane can only make several smaller jumps.
For the dashing state, we are debating whether we should let the character jump mid-dash, or finish the dash animation first before jumping. We will be testing it out via a playtest to see which version of the dash is more suitable in the game.
YU CHUN
To play our game, players would have to
Enter their name
Enter the room name
Click join room
Select their character
Select the level they want to play
This seemingly normal procedure to play a multiplayer game becomes a nightmare for our entire team, who needs to go through this procedure twice to load two instances of the game to test locally. Being a lazy programmer, this is too time-consuming, so I populate the fields automatically when the player first joins, and add 2 buttons to skip through all the steps to test our game. The feature I liked most was the auto-filling of the room name. I want a way for 2 instances of my game to join the same room without touching the keyboard and with as few clicks as possible. I can set the room name to random letters (but 2 instances can’t join the same room) or set a fixed room name when the player joins (but my teammates might also enter the same room causing unexpected errors and glitches). By using the current time (the screenshot is taken at 2.00 pm), it ensures my game instances are joining into the same room since they are often opened consecutively, and my teammates would unlikely enter my room while I am testing (unless we coincidentally test our game at the same time, assuming working time of 9 am-9 pm there’s 1/720 chance to join the same room). P.s. a nicer lobby background coming soon :)
While I was at it, I also worked on implementing the base UI by following the Figma designed by Aik Peng. And I’m happy to say it's almost functional now. We are currently lacking ways to know if other players are connected or the maps other players selected.
GABRIEL
I’m making small progress on adding polish to the game!
Currently testing out different VFX for our mascot Cactus. For example, here are some updated move-sets for our Cactus:
Currently, I am thinking about how to make the VFX more exciting for the player. Maybe they will feel better when I add SFX next week. In the meantime, I will continue analysing the types of VFX used in other games, and see if I can replicate them.
Also, I’ve started designing a test level for artists to design the characters without worrying about modifying any scripts. This should help to make it less painful for them to merge in their features.