Olympunch: Week 08

καλή μέρα (“kalí méra”) or good day! Welcome back to yet another update on the progress of Olympunch! 

Sound Effects

This week we finally had time to start looking for and implementing sound effects! Sadly we cannot share these through text or pictures, but you can rest assured that the game will be filled with fun sounds! 

The Character

Our artists then dedicated themselves to the creation of our main character: a god that will be throwing hands on the grounds of olympus! It is still far from finished, however, we can gladly share a work in progress of our champions!

As you might have already noticed, the characters are not…very detailed. And this is fine! The characters will only be visible from a far away distance, and while moving, which makes the smaller details less important. We are instead focusing on the overall main volumes of the characters to be spot on! This improves the visibility of the character in the games. For example, the beard is gigantic in comparison to the whole body. And the feet and hands are very small. This is because the beard and head are the closest thing to the camera at all times, making it very important to be visible. On the other hand (get it? because we are talking about hands…i’m sorry) the hands and feet are smaller, since they are less critical from a top-down view. You may now ask “Why are the hands less critical? You are supposed to punch each other!” Don’t worry, the answer to this is in the works, but we can’t reveal them just yet. Just a little more patience!

Additional Assets

Moving on from characters to environment, to bring to life the arena, we’ll be adding additional smaller assets. This is to make sure that the ground plane doesn’t remain lifeless and has some dimension! This week, our artists sculpted some bulky little plants and rocks. Take a look!

The Barrier

Aside from the highly important work of the character, we worked on the barrier as well, which will spawn outside the arena. It will become one of the main mechanics in the game, and therefore should have a very special look apart from all the other assets. We, of course, made sure to keep it in the art style and theme! 

As you can see, the border material has various parameters which let us customize the barrier at will! We still consider building upon it further, but for now we just don’t see the need. We will have to see how it looks in the actual scene later this week!

Particles

Just like the previous weeks, we also worked further on the particles. And what is a punching game without particles for getting hit by the punches? Since there are multiple strengths for the punches, the particle systems for getting hit reflect this.

We will start by showing you the effect of getting hit by a punch without any extra strength behind it. 

Next we have the particle that will show the punch strength with just a little extra “umpf” behind it.

In balance with the strength of the punch, there will be more lightning sparks! So for the next tier of strength, we naturally added even more sparks.

And then for the full power punch, you can see the energy behind it reflected in the particle system.

From the above shown gifs, you cannot really see the difference in scale, so below you can find a gif that shows the effects next to each other.

In the game, players will have the ability to parry their opponents' punches by striking their fists simultaneously. To visually demonstrate this action, we created a fitting effect: lightning sparks in neutral colors, with power lines that burst out in a combination of red and blue.

The last particle system we worked on this week is to showcase the player's dash move. When the player triggers the dash, sparks will fly from the character, accompanied by a trail of dust clouds that follow the character throughout the move. 

User Interface

For the UI we decided to focus on the functionality. This also included the implementation of the animation for the scroll.

We then made it so that the start/resume game buttons would close the menu for the main menu, the settings menu and the pause menu. The Exit Game button on the other hand will close the game.

The arena settings now also have the extra option to change the amount of lives the players will start out with.

In the game, players have the option to start the game from within the arena settings. When the player presses the according button, both the settings menu and the main menu will close, allowing for a seamless transition into the game. If the player wishes to return to the main menu, only the settings menu will close, providing easy navigation back to the main menu. 

Sound Manager Class

To start, it was created in the player a design of this class. We designed a singleton for a Sound Manager. The reason for this choice was that it was a manager. Instead of having each class that may deal with sounds, have their own USound or Music, a single manager that would contain all is far more efficient while preventing sounds from being created more than once. For instance, both players have a punch sound. Now instead of each player holding that sound, they simply call the function to play that sound. 

How is that done? A “blackboard” type implementation was the go to choice for it. This is very beneficial for the developers, because it helps us create better code, but also to read it better, but also helps the artist in case their input needs to change. However, we are currently having some problems with the sound manager. For starters, we cannot call a Populate map from the constructor. That means that, wherever we wish to call the sound manager, first we will always have to call the populate map function. To avoid extra problems, we made sure to include a check so that the populate map, no matter what, only gets called once. We still need to call it from outside the class. We want to class it from the constructor but we get errors. we gave up on this matter and wish to ask about it in class in order to avoid more time waste

Moreover, the sound still does not actually play. We do not know why. We included print functions on screen. They do print, they get called. But the sound does not play. A huge amount of time was spent on this. Would really love to come to class and show the implementation of this functionality, but weI just won't be able to. We need help, and so We will be asking in the next class

Hook Actor

We were able to implement the mesh into the hook actor. However, unlike other actors in the game, this one is a c++ with the mesh added from the blueprint. We kept trying to find ways to go around the problems previously found at the Sprint 1, but we were unable to. Nonetheless, the mesh is there and added to the game.

Now visually it is very difficult to notice that the hook is supposed to help the player rotate. With the simple meshes, you had a visual representation of the rotation. Not anymore. A discussion will be needed to help solve this particular issue.

Hook Mechanic

While working on other mechanics and game implementations, without being aware, the hook mechanic had been interfered with. It stopped working and had to be fixed

After a thorough investigation over the code and other perforce files, we were able to pinpoint the problem. It took copying old code and past it. See what worked and what did not. Printing messages in log and on screen, but finally the cooprint in the code was found and it is now fixed. Fortunately it was something somewhat small and did not relate much with other code sections. On the other hand, it was disappointing to spend a considerable amount of time in such matter.

Player Respawn

The respawn was implemented using the same logic as in the prototype. First, we check if the player has reached a specific point below the arena, and then we make the player invisible and set their velocity to zero. After a brief delay we randomly respawn the player at a location within the arena.

Respawn Camera Focus Shift 

To make respawning more interesting, the camera now shifts to the player who is still alive while the respawn delay is active. Once the delay is finished, the camera shifts back to a shared view.

Punch Power Scale  

The power of the player's punch is now relative to the distance it has traveled in relation to the punch socket. The closer the player is to the enemy, and thus the smaller the distance the punch has traveled, the more powerful the punch will be. This rewards the player for getting closer to the enemy.

Player Stunned State

We have implemented a feature similar to the prototype where the player is unable to move for a certain period of time after being hit. This can be adjusted in the blueprint of the player character along with other variables related to the player. When the player is in a stunned state, input is disabled. Next week, we plan to add a semi-invisible barrier around the map to prevent players from falling off and losing the game that way. If a player gets punched in a stunned state and moves through the barrier, they will fall to their defeat.

Punch Aim Assist

During the prototyping phase, we determined that aiming at high speeds was relatively difficult and concluded that an aim assist was necessary. We implemented aim assist by using the dot product of the angle of the aim arrow and the angle between the player and the other player. If the result of the dot product is less than the angle threshold, aim assist is activated. The threshold is a variable value that can be adjusted.

Well that's all for now, see you next week!