Note: All the animations are placeholder for the purpose of its pipeline.

At the bottom of the page I have linked a document with my reflections and thoughts about this project, my obstacles and insights.

Combo system

The combo system i went with is what i like to call an “IntBased” system, which means that each time the player presses an attack button, a number will increase, and the move the player character does is dependent on the players input and the integers value. This gives room for freeform exploration between the attacks and it makes the combolist easily expandable (although at risk of it being a bit overwhelming). It also makes it efficient since all the moves in the game uses the same set of values. I kept the scope small, but as you can see in the picture below, there is alot of room for expanding the list of attacks and combos. The maximum combo amount is three, so you can totally chain three attacks, the the IntCounter will reset to zero. And depending on the integers value, you can see which attacks that are available.

As I wrote earlier this combo system gives the player the freedom to switch between kick and punches whenever they feel like it, since all of the attacks uses the same Integer value. (see gif below)

Attacks

The attacks themselves took quite some time to create. I wanted to keep the attack function as accesible as possible, so I could reuse parts of it for different attacks. I achieved this by dividing the attack preocess into different smaller events, by building it that way I could easily do small tweaks to individual attacks without rewriting the same block of code each time, saving both time and headaches. This system made it easy to implement new attacks. Even though I have a plunging attack, a kick that launches you up in the air and simple grounded atacks, they are all using the same system. The main difference is damage and animations. Below I have made a flowchart that depicts the steps of the attack functions.

Every attack in the game goes through these steps, even though they may be in different forms of context, and they may look and feel different, they will all be needing this data.

 

Attack Animations

The attack animations are very simple, created them by duplicating the ThirdPersonIdle animation, posing the mesh in the desired position an eyframing it. The result was kind of wonky, but also a bit charming

These animations are very simple, there are only one to four frames in every animation. They are very barebones. One thing i focused on is to make the attacks look snappy, since I wanted it to feel responsive. So the lack of frames really worked in my favor on this one. Although the frames that are there do count. When doing the animation I utilized a structure that is very common in animation. There is a wind up before the attack commences, then there are a fast segment when the player is dealing the damage and then there is the recovery (however the recovery segments where solely handled by the blendspaces in the animation blueprints).

Notifies

(Notifies is a sort fo custom event that yu can trigger within individual animations)

The notifies gave me the ability to really fine tune when somethings is happening in the animation. one thing i did was to implement a time dilation effect that slows down time just a little bit when the attack commences to really give tha attack a punch, and thanks to notifies that works like event one can call upon on a specific frame of animation I could really tweak it and make sure that the time dilation activated at the right time. it’s hardly noticeable that it’s there, but it’s clearly noticable if it’s not there.

 

 

 

Dodge

The dodge works as a defensive move against attacks (now, since this is only a prototype of the moves themself the game itself does not have any hostile AI, which obviously leaves the dodge imperfect, since it’s never truly applied in an optimal solution) and I wanted it to feel controllable, since you are covering alot of ground in a short amount of time, I didn’t want the player to feel that they couldnt trust the dodge mechanic. I wanted it to be constant and predictable. To achieve this this I did not use any physics in the creation of the dodge, since doing that, could easily lead to unpredictable consequences. Below you can see a flowchart that goes through every movement relatable step of the dodge function.

 

Camera Lock On

I decided to implement a Lock On system because when people where playing it, they would miss alot, and the camera would not always cooporate. When designing a lock on system you can do it in several ways. One key descision is to lock on in the direction the player character is faceing, or the direction the player camera is facing. I tried both and found that the camera direction felt more natural, It’s alos easier to decid what object to lock on to, I.e if the player wants to lock on to something above them, it’s alot easier to tilt the camera than the player character.

While the player is locked on, all of the players attacks are automatically directed towards the LockedOn object.

Discussion

This is the part where I reflect upon my degree project (Melee Combat Prototype), what I learned, what obstacles I encountered, how did I overcome them. If you would like to read about my thoughts and reflections about this project, please click this link