This was my first glimpse at multiplayer logic: I was eager to delve into using the new UNet multiplayer system (which is no longer used). The promise of using the same code for single-player experiences and networked ones was appealing. Furthermore, the ability to self-host in the first player’s client meant I didn’t need to host a dedicated server on the internet.
Since this was a framework/concept it had just the core functionality: a main menu to host/connect, a lobby, and the actual bare-bones gameplay scene. The lobby would admit up to six players. The goal of the game was easy: survive for as long as possible. Inspired by other cooperative shooters, the player could upgrade his gear, revive fallen teammates, and combat the infinitely harder waves of vicious creatures.
Buying weapons was fairly straightforward: a point system, that would increase every time the player killed an enemy, would let him purchase new equipment and weapons. I designed this system to be modular so implementing new upgrades would be easy.
If a player died, they could be revived by another player that was still alive. However, I didn’t want this mechanic to be particularly easy to use all the time, so I implemented a 5-second timer where one player couldn’t shoot or move to revive the downed player.
The networking components would sync everything: the third-person player, the shooting, the animations, the enemies, and their respective animations and positions. Even the angle of aim was mimicked in the third-person character of the other player.
I was particularly proud of this system since I didn’t use any additional packages or plugins beyond Unity’s built-in multiplayer API. The end result surprised me, even though it took a large learning curve to learn and code games meant to be synced in multiple clients, on how relatively “straightforward” it is to create a multiplayer game.