Overview
BumpyRush is an online multiplayer racing game developed over an eight week period. Built by a team of 7 (3 developers, 4 artists), the project demanded good communication and collaboration.
As a developer on the team, my primary focus was the multiplayer infrastructure, integrating the Steam network backend, and building out the entire UI and lobby systems.
The Challenge
The core objective was to deliver a multiplayer racing experience under a two-month deadline.
Midway through development, we hit a roadblock with our networking architecture. We were initially using the Unity Relay system, but it introduced two distinct hurdles: post-launch costs and annoyances during team playtests, which required manually zipping and sending builds to the entire team each time we needed to test. We needed a solution that solved both of these problems.
Tech Stack
- Engine: Unity
- Language: C#
- Networking: Mirror Networking
- Lobby Relay: Facepunch / Steamworks SDK
Features
- Steam Lobby System: Matchmaking and lobby creation, allowing players to invite friends seamlessly via Steam.
- Synchronous Multiplayer Racing: Real-time vehicle synchronization and positioning with Mirror.
- UI: A user interface designed for handling main menus, player lobby states, and in-game HUD.
- Player Physics: Physics-based bumping mechanics that you can use to disrupt opponents.
Technical Problems & Solutions
1. Architectural Pivot: Migrating from Unity Relay to Steamworks SDK
- The Problem: Unity Relay has potential future costs that we didn’t want to deal with. Furthermore, testing multiplayer builds across a 7-person team was incredibly slow. We had to manually package and distribute builds constantly for even the smallest of tests.
- The Solution: I spearheaded the migration to the Steamworks SDK and Steam Relay network. By routing our Mirror traffic through Steam’s peer-to-peer relay network we bypassed Unity’s potential system costs.
- The Result: No infrastructure overhead and a massive optimization of our testing pipeline. We could utilize Steam’s beta branches to push updates instantly making for easy and quick playtests.
2. Making a Robust Lobby System
- The Problem: Managing player states (ready/not ready, chosen cosmetics, player names) between Steam’s API and Mirror’s network state often caused desyncs, resulting in players getting stuck in the lobby or data not loading correctly.
- The Solution: I built a custom lobby manager that safely bridged Steam’s lobby data with Mirror’s NetworkManager. I implemented a system where the game scene would only load once all client packets confirmed a Success state.
- The Result: A robust pre-game experience with no dropped connections during our final production playtests.
Lessons Learned
- Cross-Disciplinary Pipelines: Working alongside 4 artists taught me the value of making tools and deployment pipelines accessible. Streamlining our build delivery via Steam wouldn’t just save money. It would allow our artists to test our game much more easily and quickly.
- Scoping Networking Early: Building multiplayer in 8 weeks is not an easy undertaking. I learned to prioritize core network stability (like a working lobby and basic position syncing) over more complex features, which was a very good choice.