Connected Game Development Blog #4 (26/04/2026)

After figuring out how to make the Bazooka damage players upon its rocket's collision with a player, I got to work on adding a proper turn system to the game, where the order is decided based on the order in which each player joined the host's game, with the host going first. Once a player has attacked during their turn, they're given 5 more seconds move their character, giving them an opportunity to retreat before the next player's turn.

I also added a proper weapon select menu, where the player is able to select which weapon they want to use during their turn. At the moment, the game only has the Bazooka and Grenade weapons, but I pre-emptively added buttons for the Shotgun, Sniper Rifle.

As for the levels, I was able to fix the Temple level's missing tree textures thanks to the help of its designer and him sending me a new copy of its files to add to the game. Additionally, the designer sent over a new level that's set in a forest with a few cottages dotted throughout the landscape. Unfortunately, the level was scaled to be too big for the player characters to properly maneuver, and I was unable to re-scale the whole level without key components being made off-model or sunk into the ground, so I decided to leave it as-is and play along with its oversized nature by naming it "Giant's Forest". On a slightly more serious note though, maybe I should've made an example level first for the group to be able to properly decipher the size of the player characters before they start making the maps.

A few weeks later, I added a makeshift explosion "effect" to the Bazooka and Grenade weapons, which triggers when the Bazooka rocket impacts the terrain or another player character, and when the Grenade's fuse expires, so that it doesn't just pop out of existence. Unfortunately, the effect doesn't do anything, but I plan to make its explosion radius the effective "hitbox" of the weapon, where anything that it touches is marked as "hit" and has its health points deducted at the end of the turn. As for the other designers, one of them sent over a pack of sound effects, including sound effects for stepping, explosions, gunshots and UI button clicks, as well as a piece of background music to have play in the main menu, and the other sent over a 3D model of a humanoid robot to replace the current cartoony model, which resembles the concept we presented much more closely. The new model also came with a set of animations for actions like walking, jumping, attacking and falling, though, with this being my first online multiplayer game, I'm unsure as to how to add them to the game in a way that will make them visible to both the host and clients online.

Additionally, the new model came with a set of different colour palettes for each player, so that they'll be able to tell each other apart, which I have attempted to implement by linking the order in which each player joined to an array of SkinnedMeshRenderers, but I've had no luck with it thus far. Outside of sights and sounds, another designer has sent over a new level, which is supposedly set within a castle, which is apparent, despite its primitive look (to be fair, this designer has never worked with Unity before, so it's only natural for it to be that way in my opinion!).

I made sure to add the designer to the member list for the project's GitLab repository, which was quite a hassle, but we managed to get them in after creating a new access token. In hindsight, I probably should've sorted this kind of thing out much sooner, instead of relying on the designers to send their assets to me via Discord and having me push all the changes up till now all by myself.

Although I added an in-game weapon menu a while ago, I neglected to mention that it doesn't seem to work at all for any of the client players, who simply have it blink on and off rapidly for both them and the host player, and even if it's on-screen for them, clicking any of the buttons doesn't do anything for them.

As it turns out, this is due to a portion of variables needing to be localised, rather than Networked as I had previously assumed was the case. The weapon menu is a child of the UIManager object, which is a part of the MainMenu scene, which ensures that it's always present, even between scenes. The part that tripped me up most was trying to work out how it would figure out which player is the local player, which led me to try and have it be decided based on which player is active in the Networked PList, which didn't work, having the weapon menu be a part of the Player prefab, which led to confusion and errors due to the presence of two local Canvases at once, and having the player it affects be decided each time a player joined the game, which just led to each player overriding the previous one as the chosen one.

In the end, all that was needed was this:

UIManager.Singleton.LocalPlayer = this;

By doing this when the player spawns in, the UIManager will always know which player is the local player, and will follow their orders of toggling the menu through a private InputAction, rather than a Networked NetInput, and will have its functions point back to identically-named ones in the Player script that contain all the necessary logic, including RPC calls to the host to request their change of weapons.

Speaking of weapons, I also added a new set of inputs that adjusts the fuse of Grenades - Page Up increases it up to 5 seconds, and Page Down decreases it down to 1 second. Although the mechanic isn't the most flashy or complicated thing in the world, it ended up doing wonders for the Grenade's functionality, as the player is now able to adjust when it explodes depending on the type of shot they wish to make.

And speaking of explosions, the Bazooka and Grenade's explosions now physically affect any players within their blast radius! I tried to call AddExplosionForce() during my previous attempts, but since the Player characters make use of KCCs for physics, I ended up needing to use the KCC's AddExternalImpulse instead. I also previous attempted making the sphere colliders of the explosion spheres triggers to try and make any players' colliders that touched it be marked as "hit", but since the online aspect of the game tends to desync that logic more often than not, I changed the explosion sphere's sphere collider to a Physics OverlapSphere instead, which causes any Player components it detects to run a function that sends the Player object flying and marks it as "hit" by its weaponType, which decides whether they were hit by a Bazooka (50 damage) or a Grenade (40 damage).

Since we still only have the Bazooka and Grenade, I'm planning on implementing at least one firearm weapon before the end of development, most likely the Sniper Rifle, since neither weapon allows for much precision. We also did a brief playtest of the game on the evening of 25/04/2026 during an online meeting, which went quite smoothly, which is primarily what reminded me of the fact that I should add one of the planned firearm weapons and player colours.

This afternoon, I added a Game Win state for when either all but one player is left standing or when all players are dead (which could potentially happen if someone blows themselves up along with their target), which allows the players to play another game immediately afterwards. While implementing the music for the main menu, I also added a volume slider in the options menu that adjusts the volume of the music, but since I hadn't added included any PlayerPrefs functionality, the music volume always goes back to default whenever the game is started up again. To fix this issue, I added a Save button to the settings menu to allow players to save their settings, including their BGM volume settings. Finally, I implemented the player walking and jumping sound effects into the game proper, and although there are also sound effects for walking on grass and sand, I'm not sure if there'll be enough time for me to implement that minute detail, since I'd much rather focus on more key components like a firearm weapon or player colours.