VR Mech Battle Arena

This game was made in 3 weeks as a final project for our game technologies class.

Introduction:

This final project aimed to demonstrate our comprehension of the concepts taught in class, showcasing our ability to implement them with expertise and a deep understanding of the subject matter. Our initial concept revolved around creating a virtual reality (VR) game. The original idea involved two players connecting locally, engaging in interactive gameplay that required networking for seamless interactions. This introduced numerous network calls to simulate player interactions. As our project evolved, we incorporated a crafting system as our main mechanic. Unlike traditional inventory-based systems like Minecraft, our crafting system was designed to be interactive. Given that crafting became a focal point of the game, it brought Advanced Software Systems into play as another crucial element of our project.

After several revisions, we settled on a two-player cooperative game. In this setup, one player engages in combat, battling hordes of enemies, while the other focuses on resource management, crafting, and coordinating the movements of both players. The distribution of item drops and crafted items became a shared responsibility between the two players.

Gun Play and Mech Control:

The gunplay in our game is designed to be simple, allowing players to shoot the gun with corresponding audio feedback based on the weapon type. Damage is inflicted if an enemy is in front of the weapon. We opted for simplicity in gunplay, recognizing it as the primary focus for the Pilot Player (Player 1). Given its crucial role in survival and combat, the mechanics are kept straightforward and intuitive. To initiate gunplay and gain a strategic view of the battlefield, the player takes control of the robot by grabbing two orbs positioned in front of it. Once both orbs are acquired, the pilot's room disappears, providing a clear view of the arena. Moving the orbs allows the player to control each mech arm, creating an immersive playing experience as the robot.

Controlling the mech introduces a level of complexity. The Smith (Player 2), who is locked inside a room within the mech, manages its movements. To convey Smith's vulnerability when attacked while located elsewhere in the scene, the player's screen will shake. Communication between the two players is essential for proper positioning, as the Smith dictates the mech's direction. This collaborative gameplay adds depth and coordination to the overall experience.

Combining and Crafting:

The crafting system primarily falls under the responsibility of the Smith player, who focuses on crafting items delegated by the Pilot and creating weapons from them. The Smith's pivotal role significantly influences the game, as the items they craft shape the Pilot's gameplay throughout the weapon's duration. Crafting involves the Smith receiving resources from the Pilot and engaging in minor mini-games, such as microwaving the resources for the right duration, along with managing two to three other stations for various tasks and creating different components. The player then physically combines these components, crafting them into something usable by the Pilot. This core aspect of the Smith's role is designed to be both enjoyable and challenging, adding an element of fun and stress. On top of this, our gun crafting system is completely modular resulting in multiple gun combinations that the Smith could play with. Resource management and careful planning are essential for the Smith's gameplay experience.

Player to Player Interaction:

As the two players operate in isolation, their primary mode of communication is through face-to-face conversation, discussing their respective needs, and strategizing their next steps. Additionally, a pipe serves as the only other means of interaction between them. This pipe facilitates the exchange of items, enabling the Pilot to send resources to the Smith, who in turn crafts weapons for the Pilot to utilize and provide to the mech. This limited yet crucial method of interaction adds a layer of coordination and dependency, emphasizing the necessity for effective communication and resource sharing between the two players.

Networking:

In terms of networking, synchronizing characters and their actions wasn't a concern since the players wouldn't have visibility of each other. The only elements requiring synchronization are the robot's movements, the radar, the robot’s health, and the content transferred via the pipe. Beyond these aspects, there's minimal need for synchronization between the players. But somehow this part is what the game comes together. Problems and Unimplemented Content:

Due to the time constraints of our one-month deadline, production was rushed, resulting in the incomplete implementation of several features. Presently, our networking features are partially implemented, and it is anticipated that bugs may occur. Functions such as connecting, sending and receiving items, and sharing data such as health and mech movement might exhibit issues during gameplay. While time may aid in resolving these problems, our limited experience with Unity and networking may make implementing bug fixes more time-consuming than anticipated. For a while, our VR interactable Main Menu was not functioning as intended, despite the buttons being correctly linked to actions like connecting to the host, creating a server, and quitting the game. In the absence of the main menu, we've incorporated a functional interactable GUI on the main computer screen, accessible only with a mouse. Furthermore, a major challenge we encountered was related to rotating the robot in Mech Mode. When the player rotated, the mech experienced desynchronization, leading to the hands being distorted. Despite numerous attempts to find solutions, progress was hindered by issues arising either from problems with rotating the room or persistent desync that resisted resolution. Although we have a working version in a scene called MainLevelScene, we resorted to not using it due to complications. We had small prototype implementations that allowed us to dismember parts of a Kaiju enemy, but we couldn't finish it. Also losing the game doesn't redirect to the main menu; players must manually restart the game to try again.