top of page

Knockback Kings

Project Description

A third year solo student project for Falmouth University, objective is to make a portfolio piece

Stage 1 - Scene Setup

  • Setup Static Camera

  • Setup Arena Area

  • Setup Character VFX

Stage 2 - Multiplayer Setup

  • Main Menu

  • Host/Join System

  • Wining Functionality

Stage 3 - Ability Setup

  • Stand-in Abilities

  • Static Input Setup

  • Shared Ability Pool

  • Randomizing Input

Stage 4 - Stretch Goals

  • Multithreading

  • Bouncy Wall Ability

Ability System

What is it?

The goal of the game is to stand uncontested on the rock for 30 seconds. Unfortunately for you, you play against an opponent with the same goal. 

​

How do you deal with them? Simple, push them off using abilities. You'll have 2 melee type abilities which physically knock your opponent back. You'll also have 2 projectile abilities which upon impact will affect their movement and screen in some way.

​

What's the catch? You and your opponent share the same ability pool. Meaning if they use an ability before you, both of you are locked out from using it again until its off cooldown.

Not only do you share the same ability pool, but the inputs required to activate these abilities are randomized meaning this game requires quick reflexes and solid ability management skills to emerge victorious.

AbilitySystemUMLClassDiagram.jpg

So how does this actually work?

Good question! Starting with a key feature which can't be easily represented in the diagram above, the ability manager is actually only spawned on the host's machine and isn't replicated to the client. Why? This game is setup as a listen server, meaning the host is a server to which the client joins. Having the ability manager, which is responsible for keeping track of unassigned inputs and ability references, only exist in one instance of the game, makes the system more manageable. This is because the client doesn't actually need any data from it. 

​

But how, doesn't the client have UI which displays cooldowns and the randomized assigned inputs for each ability?

​

This is due to the fact that my game mode stores a reference to both the host's and client's player controllers (at blueprint level). Why is this important? Because starting from the ability, which stores the data we want to display such as how long the ability will go on cooldown for, it'll broadcast delegates notifying and passing the data up to the ability manager, which in turn will broadcast its own delegates and pass the data up to the game mode. The game mode has display functions which are blueprint implementable and pass the data on to its blueprint object. Here, finally the blueprint game manager passes this information down to both player controllers which are responsible for managing widgets since they also only exist locally for both players. 

​

This pipeline is great at passing data from abilities to both of the players screens, but the pipeline works in both ways. The player controller has an event which fires off every time the player presses any button on their keyboard, and passes this key as well as a reference to itself to the game mode which first checks if the keys are WASD in which case it rejects it. Otherwise, it'll pass the data on to the ability manager which will compare the key against all the assigned keys of the abilities and if they match it'll activate the appropriate ability and pass the player controller to it for potential gameplay purposes like playing animations, ignoring overlaps, transforms, etc.

​

This pipeline is also what syncs up the objective UI for both players as the game mode spawns in the objective area when the match starts, and therefore can act as a middle man for passing data between widgets on the player controllers and the spawned objective. However, this time the objective is replicated as it needs to be physically seen by both players.

AAbility.ccp
AAbilityCPP.PNG

Melee Abilities

MeleeAbility.PNG

Since both melee abilities work exactly the same, with the only difference's being what animation is played when activating and the knockback distance, I've left it as a single class and make two separate blueprint classes with different default values

Projectile Abilities

Projectiles abilities are interesting as the bulk of their implementation doesn't actually sit in their ability but within the actual projectile implementations. Most of the default movement behaviour of the projectiles is implemented in the projectile class, and then ability specific behaviours are mostly implemented through the character interface and the specific ability projectiles call those behaviours.

Projectile Ability
ProjectileAbility.PNG

Lobby System

Here you can see how the game mode stores the player controllers allowing for the data pipeline in the ability system to exist. Every player controller on begin play calls the event shown below and passes themselves. The event is able to kick players in case a third player joins by accident which actually is possible if two or more people try to join the same host at the same time. 

I implemented the lobby system mostly in blueprints as this was my first multiplayer game and my focus was to learn structuring gameplay code in a multiplayer game rather than trying to make a solid multiplayer experience. Using blueprints allowed me to both warm up to how replication and RPC's work, and allowed me to implement a lobby system rather quickly without much struggle so that I could focus on the bits more important to me. Also a large portion of the lobby system is related to UI as buttons appear, text changes, etc, and I prefer to implement UI in blueprints along with anything else aesthetic like animation montages or audio.

GM_BP.PNG

Final words

All code was designed and implemented by me and me only. Links to environment art, the character and the font l used in this project can be found in the GitHub repository below.

​

I'm very happy with what I've managed to learn and produce as a result of this project. Before starting the project I wouldn't even understand what replication meant and now I feel much more prepared for facing future multiplayer projects and learning even more. 

​

Thanks for taking your time to read through this page, I hope it provided good insight into how I work, if you need any clarifications be sure to get in contact with me through LinkedIn which can be found in the About Me section

Try it out yourself!

You can check out my game on itch and play it yourself, or check out my git to browse through the code

bottom of page