About
This is a Sample Project representing a minimalistic prototype for a game that plays similar to a "Vampire Survivors" clone. The game is compatible with multiplayer and demonstrates the use of the Gameplay Ability System (GAS) in a small scope project. This is not planned to be a full fledged game, just a minimalistic working example to use as reference. The project may be used as a starting point for a future project, but not until I am content with the base project.
Key Features:
Peer to peer multiplayer gameplay, connecting directly with IP Address.
Multiplayer level up system. All players share an experience bar and level, the server will pause the game and ensure all clients are shown an upgrade selection screen. Player selections are verified against the upgrade selections generated by the server.
Damage Calculations. Damage is dealt through and execution calculation to support the potential for more complex systems such as block, damage types, critical hits, resistances, etc. (Currently not being taken advantage of until the project is in a state where I can prioritize adding content).
Simple lobby system, suspends the game at the start when hosting in multiplayer to allow others to join and won’t start until all joined players have confirmed they are ready to begin.
Project Goal
What was the motivation behind this project? Between my previous project in Unreal Engine and this one, I spent a fair bit of time studying how to properly make use of the engines features. A large chunk of this time was devoted to a Udemy Course teaching how to use the Gameplay Ability System in a realistic scenario. Towards the end of this course, I decided I wanted to work on a project that took most of what I learned, and condensed it into a small scope project resembling a prototype rather than a full game. I felt this would serve me better as reference material, as the project would primarily focus on GAS with less of the bloat that you would expect from to find in a full game. In addition, I also wanted to use this project to further my understanding of multiplayer in unreal beyond just what I learned through making use of GAS.
Besides GAS and multiplayer, I was also interested in making better use of the engine in general. Understanding the Gameplay Framework and how that relates to structuring a game for multiplayer (Or even keeping a game better structure in general). Managing dependencies between different classes, especially in regards to replication, making sure dependencies are replicated before they are used by the dependent. While working on this project, any time I encountered a problem where I happy with my own solution, I would often open Unreal Engines Lyra sample project to see how they dealt with similar issues. Sometimes this would bare fruit, finding events, classes, or functions did not know about, whereas other times their solution may involve introducing another plugin, which would go against my goal of keeping the project minimalized and focused on GAS. Even in those situations, it was nice to learn of those plugins so I can make use of them in future projects.
Media
Here I demonstrate the basic gameplay in the project. The game itself is not extensively fleshed out or balanced, as the current state of the game is only meant to be a foundation to build off of. The current game loop consists of starting a match, then either surviving to the end of 10 minutes to win, or running out of health and experiencing a game over. During the match, enemies will spawn around the player, the number increasing as the match goes on. The UI for the gameplay sections (the health bar and experience bar) are placeholders, whereas the UI in the upgrade selection is much closer to the final design. When a player levels up, the game pauses and they may choose from 3 randomly selected Upgrades.
The controls for the game are simple, WASD to move, point and click to shoot. I did put a little more effort into the camera, as even though this is meant to resemble a prototype, I still wanted it to feel good. The camera does not strictly follow the player character, but rather moves a distance in front of where the character is aiming. That distance increases depending on how far the cursor is from the player. This lets the player to have more control over what they want to see on screen, allowing for fighting enemies at a distance or getting up close in personal and retaining awareness of their surroundings.
Towards the end, you see me lose as soon as the game resumes. I don’t plan on leaving it this way. Once I begin to move towards the next phase of the project (introducing more content, QoL, visual effects, audio, balancing), I plan to have the player execute an ability on level up that will protect them by destroying enemy projectiles in a small radius as well as pushing enemies back and applying a short stun to them.
Under the hood, upgrades are infinite gameplay effects where the magnitude is driven off the level of the effect as a Scalable Float. When the upgrades are presented to the player, it checks to see if the player already has the effect and its current level to determine the next level to be shown and compared with.
Here I showcase connecting to another player using one machine. I have tested this with friends remotely and it works just as well. When hosting a game, the game starts in a lobby state. This gives time for other players to join in. The game will not begin until all connected players have confirmed that they are ready. When playing multiplayer, the levels and experience are shared. This allows upgrade selection to happen simultaneously, instead of having the game constantly pause every time another player gains a level. During the upgrade selection, players may select and deselect the upgrade they want. The game will not resume until every player has selected an upgrade. The selected upgrade is verified against the choices that were generated on the server, preventing clients from potentially selecting upgrades that were not given to them. Multiplayer specific features I would like it implement later include a spectator camera when a player dies, as well as level ups reviving dead players at the cost of the revived players not being granted an upgrade for that level.