Blaster
About the Project
Blaster was the second project I started in order to learn as much of Unreal Engine 5 as I could, focusing on learning fundamental multiplayer mechanics and maintaining correct server authority whilst simultaneously filling gaps in my existing C++ and UE5 knowledge. To build these valuable skills, I followed a course on Udemy with the goal of understanding everything I was doing, making sure I wasn’t just blindly copying someone else’s work and learning nothing.
This turned out to be a very effective learning style and resulted in a multiplayer shooter game with multiple game modes, and a standalone, re-usable multiplayer plugin that seamlessly works with Steam. Finally, a big focus in this project was learning to code the right way, learning to write code that doesn’t just compile, but to craft clean, efficient, and maintainable code.
I would also like to thank Stephen Ulibarri for creating such a thought out course.
Development Overview
Multiplayer Plugin
In an effort to understand exactly how my entire project worked and gain insight and experience into how multiplayer games work, I decided to learn how to code a multiplayer plugin first. This meant making my own multiplayer sessions subsystem which I based off of the game instance for persistent sessions, safe server travel, correct lifetime and easy access through the game instance.
Delegate & Async Communication
The subsystem also taught my how to create dynamic multicast delegates as well as their importance in cases where there could be delays in retrieving necessary information. For example when a player clicks the join button on the main menu, that calls a function on the subsystem that searches for suitable sessions through the online session interface, which broadcasts the result of that search once complete, a broadcast that is bound to by another function in the subsystem, which broadcasts the results with a custom delegate back to the menu that can correctly select and join a session.
Matchmaking & Session Filtering
The menu is where all of the match type information is stored and game mode selection takes place after the find session delegate has been broadcast. Here, all the the search results are filtered through until one is found with a match type that matches the desired game mode, which is automatically joined. After this process, if no suitable session is found and joined, the join button is enabled allowing players to search again.
Steam Integration & Networking
Furthermore, I decided to make my plugin work using Steam and its network features, meaning my game doesn’t rely on peer to peer connections. This means that not only does it automatically use peoples steam usernames rather than needing separate account creation, as well as significantly more security for players and their IP addresses.
Finally, I ensured that this plugin was disconnected from any game specific logic making it fully re-usable with scalable architecture if required for future projects.
Lag Compensation
A big problem in multiplayer games, especially fast-paced shooters, is lag. This simply means a delay between the players local actions and the server receiving information about those actions because of network travel time. In shooters, this can mean lining up your crosshairs, clicking to take a shot, however the shot is delayed and the target has moved by the time it is fired. This leads to a very poor experience for the player and in extreme cases can make the game impossible to play.
Server Side Rewind
However, there are a number of ways to reduce or even eliminate these issues, one of which is server side rewind. This is where the player tells the server what time it requested an action, allowing the server to look back in time and see if it would have been successful had there been no delay. For firing a weapon, this means the server keeps a custom frame package containing time and location, as well as an array of hitboxes for every player every frame. This allows it to compare the players hit location with the hit boxes for the provided time of impact and check whether there was a valid target before applying damage.
Interpolation, Hit Validation and Scatter Replication
To make this system even more accurate the server doesn’t just compare the hit location to the frame package with the closest time, it interpolates the correct amount between the two closest frames to recreate the hitboxes as accurately as possible without relying on client information that could be fakes by cheaters. In a further effort to stop cheaters, the hit location is also calculated by the server wither with its own line trace or projectile path prediction depending on weapon types. Finally, this includes scatter replication for weapons like SMGs or shotguns, where calculating a different scatter direction could cause incorrect hit validation leading to a bad player experience.
Client Side Prediction
Client side prediction is another method to make the game more responsive by reacting to the players inputs immediately, and then allowing the server to correct it later if necessary. In Blaster this came in the form of playing fire effects and animations as soon as the input was received, as well as instantly updating the ammo count in the HUD, all to make the game feel more responsive for players. However since this is not controlled by the authoritative server, it is not used on anything that alters gameplay like damage to minimise the methods possible to cheat with.
Gameplay - creation and design of shooter elimnts, server control, different game modes
multiple weapons with projectile and hitscan and scatter, health & shield, powerups, gun specific ammo and reloading, TDM and CTF