SUBOPTIMAL Banner Image

SUBOPTIMAL

OVERVIEW

SUBOPTIMAL Promo Image

Dive into the ocean depths with a submarine and some friends to find a lost treasure!

  • Designer Icon

    Technical / Systems Designer / Scrum Master

  • Prototype Icon

    4 Weeks (2025)

  • Person Icon

    8

Unreal Unreal Unreal Unreal
Online Co-op Multiplayer Goofy 3D Steam

My Contributions

DEVELOPMENT

Project Timeline

Week 1 | Ideation & Core

Prototyping, submarine iterations, multiplayer setup

Week 2 | Pre-Alpha

Player systems, level iterations, multiplayer mechanics

Week 3 | Feature Freeze

UI/UX design, core gameplay loop refinement

Week 4 | Polishing

Playtesting, SFX, VFX, bug fixing

Project Goals and Agile Dev Pipeline

Wanting to create a fun, online multiplayer co-op experience with friends, we focused on two primary design goals:

  • A challenge that requires teamwork and communication
  • Funny moments that arise from player and environment interactions

We took a lot of inspiration from PEAK, however, our USP is the emphasis on communication within the submarine and the tasks needed to operate/maintain it effectively.

My Role as Scrum Master

I was also in charge of the development pipeline, keeping track of our progress through Jira mainly. I led brief stand-up meetings each morning to sync the team, identify blockers, and review progress against our sprint goals. If a ticket didn't exist for someone's intended task, we would agree to create one before starting on it.

Midway through the project, I introduced a new Jira column for priority to reduce task confusion and ensure the team always focused on the most critical path items. In the future, I would introduce this from the start, and I would have tickets be far more detailed.

The best practice we had was a Discord channel called 'Task Updates' where you say what you were working on throughout the day. This made it easier to track, but also to coordinate so two people wouldn't work on the same task by accident.

Suboptimal Design Image

Online Multiplayer Architecture

The core technical challenge was ensuring a stable, low-latency 4-player cooperative experience. We built the entire game using a Server-Authoritative networking model.

Authority and Session Management

For every game-critical action our logic runs exclusively on the server, keeping the true state of the game world to prevent cheating (although it is co-op, so this isn't a huge deal).

For the platform layer, I set up the Advanced Sessions plugin and Steam Online Subsystem to manage all player connections and implement the listen server setup. This integration also allowed us to include a proximity chat using VOIP with sound attenuation based on distance.


Communication: RPCs & RepNotifies

We managed network traffic by using two methods for execution requests and visual synchronization (anything outside of Unreal's transform syncs).

Remote Procedure Calls (RPCs) were used for client input and requests. A client would use an RPC (Runs on Server) call to ask the server to perform an action (like an interaction) and check that it is valid to do so.

Replication Notifications (RepNotifies) were used for broadcasting results. Once the server validated the RPC, it would update a replicated property and the OnRepNotify function would trigger the resulting cosmetic or state effects (animation, audio, sometimes collision) on all clients.


Local Input & Shared Player Data

We processed all direct, local player inputs (movement, camera control, UI interactions, etc.) primarily on the PlayerController class. This is because it only exists locally on the owning client and the server, ensuring minimal latency for the player's immediate actions.

We used the PlayerState class to reliably hold data that needs to be replicated to all players, regardless of their connection status. This included the player's custom color and nametag.


View PlayerController Blueprint (Input Example) ↗

Our Submarine Solution

The online multiplayer submarine was the project's greatest technical hurdle. We needed a reliable four-player vehicle with a window for exploration, the ability for players to move, and detect collisions with the environment. To maintain net stability and performance, we had to pivot away from conventional Unreal Engine vehicle approaches.

Failed Paths & Trade Offs

We began by testing two major concepts that ultimately proved unsustainable for multiplayer stability and performance. The iterations below were created by my fellow technical designer, while I did the work to replicate them.

1. Physics-Based Movement
This worked well at first for the host, but it quickly became a replication nightmare across clients. Minor server-client discrepancies resulted in excessive jitter and desync, making player control unreliable. For the time and experience we had, it was unrealistic to expect for us to create our own system for client-side prediction.

2. A Fake Interior Submarine
Our second attempt used a "fake" interior where players were teleported into a separate space. This solved the replicated movement issues, however, creating realistic window views required using Scene Capture Components. The cost of running multiple high-resolution captures (one for every viewport) caused an extreme performance hit, proving this approach was immediately unsustainable.

Our successful pivot was to treat the submarine not as a vehicle, but as a replicated Character class. Players enter the submarine by swapping their collision channels upon entering. This clever workaround allowed us to leverage Unreal's Character Movement Component (CMC) and its inherent client prediction and net stability, ensuring low bandwidth usage and reliable movement. Crucially, this stability let us retain the large window, a critical element for underwater exploration.

View Submarine Blueprint (My Functions) ↗

Player State Management

The player had several different states that needed differentiating between for certain circumstances. The main ones included:

  • Normal / Land
  • Swimming
  • Inside the Submarine
  • Knocked / Unconscious
  • Dead / Spectator

Initially, I often encountered complex replication issues on the client, particularly when using generic Server RPCs called from different server-owned objects (such as triggers or overlaps).

With the help of a team programmer, we refined the approach, relying instead on updating replicated properties directly inside the Player or PlayerController classes, using the associated RepNotifies to consistently trigger state changes and visual effects on all clients.

Example State Changes

One good example of this is when entering the submarine, the player transitions from either swimming or normal mode to in the submarine. It occurs when interacting with the submarine door, which teleports the player on the server, before changing its collision type and movement mode in the RepNotify. It is triggered by the door, but also by a volume inside the submarine in case of clipping or other glitches.

Another example, as seen in the video above, is when a player loses all their health. They become knocked and have a timer that counts down before they die completely and move to spectator mode. Most of this is done in the PlayerController class as it should be local changes that they see (the player who died). However, there are replicated state variables that allow other players to come and revive them if they are knocked, for example.


View Spectator State Change Blueprint ↗

Reducing Jitter for the Client Players

When players were inside the submarine, they experienced heavy movement jitter. We used Unreal Insights to profile and test numerous builds, finding the root cause was net bandwidth spikes due to mismatched replication rates on internal components. We also found the host's performance had a direct impact on the client's network experience.

The average FPS increased from 28 to 60, and network bandwidth warnings stopped occurring in packaged builds.

Breakdown: Fixes

1. Checked every replicated mesh and standardized its Net Update Frequency to replicate predictably and consistently, eliminating concurrent data floods.

2. Lowered the parent Submarine Actor's overall Net Update Frequency to the minimum rate required for smooth movement, drastically reducing the total network data load.

3. While I focused on network and collision fixes (skeletal meshes), teammates addressed optimization solutions with lighting and graphics to further stabilize host performance.

Unreal Insights

Initial Playtest on Client (Before Jitter Fixes)

Final Day Playtest on Client (After Jitter Fixes)

Interactions & Held Items

I added two functions to the interaction interface.

  1. 'GetPrompt' was used to give each interactable a distinct UI hover display, providing more details to the player before interaction.
  2. 'CanInteract' was used on each object to determine the circumstances in which a player could actually interact with the object. This was mainly used so players couldn't interact with the ship controls at the same time, or take a hammer from each other...

I used a Server RPC called from the player's local PlayerController class in order to make each interaction called on the server. Then, I could use RepNotifies or Multicasts inside the interactable's class, depending on what was needed. An example is to the left.

View Interactables in PlayerController Blueprint ↗
View Example Interactable (Throttle) Blueprint ↗

I worked closely with our other technical designer to create a held item base class that we could use for any held item. This system re-uses the interaction interface to standardize usage, ensuring any new tool can be added instantly without modifying player logic. I specifically handled the replication of their properties, their animation implementations, and the proper socket locations.

These two videos show the hammer and squeegee, our two held items that are direct solutions to two of our environmental hazards.

  • The hammer is used for repairing the submarine after collisions.
  • The squeegee can clean the glass after a squid inks you!

View Held Item Base Class Blueprint ↗
View Food Held Item Blueprint ↗

Other Features I Worked On

  • Player Oxygen & Health
  • Oxygen Cable
  • Oxygen Burst Design
  • Algae-Submarine Interaction

More Info Below...

Player Oxygen & Health

Originally we had oxygen and hunger as the two stats for the player, but quickly realized the hunger was pointless. It slowed the player down in a way we didn't like, and it didn't feel connected to the oxygen. We also noticed the oxygen felt punishing as you would die as soon as it hit zero.

Our solution was switching to an oxygen and health combo, where health would determine being knocked out. Health also made more sense for the environmental enemies and hazards. To be less punishing when swimming, the oxygen could go to zero, and only then you would start losing health.

I implemented these with actor components that I attached to the player, each with their own functions to be called from other blueprints.


View Health Component Blueprint ↗ View OnRep_CurrentOxygen Blueprint ↗
Oxygen Cable

We wanted the players to have a reason to go outside the submarine more often, and we also thought it would be fun to guide the players controlling it from the outside (like a person helping another park their car).

I was excited about an 'oxygen cable' design I came up with, where the player could attach themselves to the submarine for infinite oxygen and not get out of range. It made it so they could communicate with others at the front of the ship while being outside and having a better angled view of the surrounding landscape.

To simulate the realistic 'pull' back on the player, I utilized a cable component to manage the attachment and set the player's velocity accordingly when the length limit was reached. A programmer did the replication for this feature.

Oxygen Burst Design

Nearing the end of the project, we had a need for something to counter environmental enemies, but we didn't want combat. We also needed a fast way of navigating the underwater environment, so I designed the oxygen burst.

This mechanic is a directional blast of compressed bubbles that creates a reactive knockback effect, propelling the player rapidly in the opposite direction. It doubles as a way to stun the shark in the bottom of the ocean. And for some player-to-player interaction, we made it affect your fellow divers too.

Lastly, it has a cooldown and costs you oxygen for each burst so that it cannot be overused and requires some tactical thinking. I only did the design for this feature, a programmer did the implementation.

Algae-Submarine Interaction

A programmer made the feature of algae and trigger boxes to spawn it on the submarine's propeller in certain areas of the map. My job was to ensure the engine toggled properly when the algae was spawned and cleaned.

For the player cleaning the algae from the propeller, I added the interactable interface to make it simple and save time. I also added a function to damage and knockback the player if the propeller hit them while spinning.

REFLECTION

This project was a fantastic learning experience, allowing me to grow significantly as a designer and developer. I gained valuable experience collaborating with various disciplines, how online multiplayer architecture functions, and methods for debugging and analyzing network/optimization issues. I also improved my skills in Unreal Engine, particularly with Blueprints and some C++ implementation.