The battery player is a walking battery, responsible for powering the vacuum player, forcing the player that is using the battery character to keep track of the battery levels. When the vacuum uses it's sucking ability, the battery will drain. The Battery player holds a Battery script, which makes it responsible for managing the battery level of the battery player and ensures that it drains or charges when the necessary conditions are met. Since we already had a stamina script that we did not need for two players anymore and came up with the battery idea, we decided to refactor it so that we could reuse the code in order to make the battery script.

The game has Mechanical doors, which are usually locked and can only be opened by making the battery player crawl into tight spaces, where the switch/button is located. We made a very simple script that simply triggers an animation that opens a mechanical door.

For our game, we decided to use Unity's New Input System, because of its ease of use, and since it's easy to make a Universal Scheme for every kind of controller/device it was the best option.

Since the goal of the game is to clean up as much as you can and get to a getaway spot before the timer runs out and the cops catch you, We made the PlayerAreaDetector script. It uses a collider to check whether the amount of players in the area is equal to the total number of current players in the game.

The battery player is equipped with a special UV Flashlight, which makes the player able to expose invisible/hidden filth. While the hidden filth is exposed, the vacuum player will be able to suck it up, adding points to the overall score. The filth will only be able to be picked up while it is exposed by the UV flashlight. If it is not exposed and is hidden, it is impossible to suck it up by the vacuum player. The idea of how we could make this mechanic popped in our heads fairly quickly, we would use the same fov/angle value as the battery characters' light source, along with a set max distance that the hidden props could be exposed at.

The players are connected via a cable/rope, this ensures so that the players always stay together and cannot split up, meaning communication is being forced on the players so that they can navigate the level efficiently. Our first idea was to make the rope physics based with rigidbodies and joints, which turned out to be harder than expected for the reason being very buggy rope physics. After trying and doing multiple tests with multiple physics-based ropes, we decided to keep the rope simpler. The simpler idea involved using a line renderer, rendering a straight line from point a(a player) to point b(another player), the rope script also includes a max rope length with constraints, which allows us to keep the players from moving further away from each other when the rope reaches it's max set length.

For the Co-Op part of our game, we decided to use Unity's Player Input Manager, because it makes it easy to set up any kind of game and make it possible to play it with multiple users on the same device. It also seamlessly works with Unity's Input System.

Because our game needed more than 1 player prefab and spawn point, we had to make a custom script that accompanies the Player Input Manager to make that possible. More information about the PlayerJoinManager below.

We needed to make a script that would accompany Unity's Player Input Manager, so that every player that joins in has a different character/ability, did not spawn on top of each other, and the players would have a "press to join" prompt to start the game. The PlayerJoinManager script is responsible for managing some variables of Unity's Player Input Manager, it changes the PlayerPrefab for each player that joins the game so that every player has their character/ability and changes each player's spawn location so that they do not spawn on top of each other(to prevent bugs). The script also makes use of the Timer Script. Each player has their own "Press to join/play" HUD prompt, once a player joins, their corresponding prompt turns off. Once the required amount of players has joined the game, the script sets the TimerOn bool of the TimerScript to true, so that the timer starts and the game can begin..