← Back to projects
AquaStrike: Foundational Multiplayer Game Development in Unity featured image

AquaStrike: Foundational Multiplayer Game Development in Unity

An early game development project from 8th grade, AquaStrike was a multiplayer underwater survival shooter built with C# and Unity, tackling complex challenges like network synchronization and player input.

Overview

AquaStrike was an ambitious, foundational game development project I undertook in 8th grade, born from the idea of merging the survival and crafting mechanics of Subnautica with the build-and-battle gameplay of Fortnite. The concept was a multiplayer, underwater survival shooter where players would gather resources, construct bases, and engage in combat against both environmental threats and other players.

While the game was never fully realized, it served as a critical early foray into complex software engineering challenges. The project’s primary goal was to build a functional multiplayer environment from the ground up. It became a practical lesson in game state management, network synchronization, and object-oriented programming, laying the groundwork for many of the more advanced skills I’ve developed throughout my career.

Key Features

  • Multiplayer Gameplay Foundation: Implemented a core multiplayer framework using Photon Unity Networking (PUN), enabling multiple players to connect to a shared game world, see each other move in real-time, and interact with the same environment.
  • Synchronized Inventory System: Developed a networked inventory system where players could pick up items from the game world. The state change (item disappearing from the world, appearing in inventory) was successfully synchronized across all clients, ensuring a consistent experience for everyone.
  • Dedicated Player Input Handling: Engineered the control system to correctly distinguish between the local player and remote players. This ensured that keyboard and mouse inputs for movement and aiming only affected the user’s own character, a fundamental challenge in multiplayer game development.
  • Basic Account System: A rudimentary account system was implemented to manage player identity within the game sessions.

Technologies & Implementation

The project was built entirely within the Unity game engine using C# as the primary programming language.

  • Unity & C#: Unity was chosen for its comprehensive suite of tools, including a physics engine, rendering pipeline, and robust C# API, which provided an accessible yet powerful platform for a solo developer.
  • Photon Unity Networking (PUN): To tackle the complexities of real-time multiplayer, I integrated PUN. This middleware simplified the process of managing network sessions, synchronizing player data and object states, and handling Remote Procedure Calls (RPCs), allowing me to focus on game logic rather than low-level networking protocols.
graph TD
    A["Player 1 (Client)"] -- "Input Commands" --> B["PUN Cloud"]
    C["Player 2 (Client)"] -- "Input Commands" --> B
    B -- "Synchronized State" --> A
    B -- "Synchronized State" --> C
    A -- "Renders Game World" --> D["Player 1's Screen"]
    C -- "Renders Game World" --> E["Player 2's Screen"]

Challenges & Solutions

The primary difficulties in this project revolved around creating a coherent multiplayer experience.

  • Challenge: Networked Inventory Synchronization

    • Problem: When one player picked up an item, that action needed to be instantly and reliably communicated to all other players to prevent inconsistencies, such as multiple players picking up the same single-use item.
    • Solution: I implemented a system where the client initiating the pickup would send an RPC to the master client (or all other clients) to destroy the item object and update the player’s inventory data. While my early implementation relied on nested if-else blocks, it was a functional solution that taught me the fundamentals of managing shared state across a network.

  • Challenge: Isolating Player Controls

    • Problem: By default in Unity, a single input script could erroneously affect every player character object in the scene. It was critical to ensure a player’s controls only manipulated their own avatar.
    • Solution: I developed a script attached to the player prefab that included a simple but crucial check: isMine. This boolean, provided by the PUN library, verifies if the component instance belongs to the local player. All input-processing code was wrapped in this check, effectively isolating controls to the correct character and creating a playable multiplayer environment.

Results & Impact

AquaStrike was a formative project that provided my first hands-on experience with the core challenges of networked applications. Although it remained a prototype, the project was a success in its primary goal: to learn.

  • Foundational Skill Development: This project was my introduction to C#, object-oriented programming, and the client-server networking model. The challenges I solved, particularly in state management and input handling, were invaluable lessons.
  • Ignited Passion for Backend Systems: Grappling with the logic of how multiple clients communicate and stay in sync sparked my interest in backend systems and distributed architecture, a passion that has defined my subsequent academic and professional career.

{TODO: Add screenshot of the AquaStrike game environment or gameplay}