Project Ping is an in-progress general-purpose plug-and-play networked multiplayer asset in Unreal 5 that uses Steam for matchmaking. It started as a project for an Independent Study class in Tools Development, and I have since continued to expand on it. As this is my formal introduction to networking in Unreal, I documented my processes with the hopes of them someday coming in handy to anyone going down the same rabbit holes I did. I wrote with the average computing college student in mind, and assume basic knowledge of networking in the engine.

Fast Facts

Role: Sole Developer, Networking and Multiplayer Programming
Timeframe: 10 weeks (currently in progress)
Engine: Unreal 5.0
Plugins: AdvancedSteamSessions, SteamSockets
Languages: C++, Blueprints Visual Scripting

Networking Features

• Creating and joining sessions for up to 4 players via a session browser menu:
• Sessions are created through the use of a listen server.
• Matchmaking uses Steam with the help of AdvancedSteamSessions and SteamSockets plugins.
• Replication of movement across all connected machines via the ThirdPersonCharacter Blueprint.
• Server starts the game once players have joined via logic in the Game Mode class.
• Use of seamless travel to allow server and clients to move across levels.
• Each player keeps track of their score within their own Player State class, which then persists across levels during seamless travel.
• Session destruction logic:
• If a client leaves a game, the session is destroyed on their machine and they are returned to the menu.
• If the server leaves a game, sessions are destroyed on all machines (including the server). All players are returned to the menu.

Prioritising Flexibility and Scalability

As one of the goals of this project was to create a general-purpose networked multiplayer asset, I developed with flexibility in mind, and added minimal gameplay logic to test the systems I was developing. That way, any bugs I ran into would most likely be coming from netcode and not gameplay code. Furthermore, this meant the asset would also allow logic for many kinds of games to be slapped on top of it.

I gained experience creating and documenting a codebase for scalability, since this project would need to support longer-term development (not just for a semester). Additionally, playing around with source code and extending Unreal's classes has given me more experience working with C++. I also learned about how Unreal's gameplay classes work (like the Game Instance and Player State), and how they fit into the networking framework.

Looking Under the Hood

Throughout development, I needed to continuously get a better understanding of what was happening under the hood. This was particularly true when I was testing implementations that depended on Steam, which required the program to be run as a standalone process, and not within the editor. This meant that I, sadly, did not have access to Unreal's Blueprints debugger.

I was stuck logging text to the screen for a while, until I came across a forum post about how to open a separate log window for a game running standalone. Additionally, after some digging around, I figured out how to attach the Visual Studio debugger to a standalone game. These two discoveries were exactly what I needed to get a better picture of the program flow when running in standalone mode. Combining them, I was able to improve my productivity in effectively diagnosing and fixing issues as they arose.

Next Steps

Addressing Edge Cases

At the moment, if a player (either server or client) gets involuntarily disconnected during a game, the session isn't destroyed on their machine, preventing them from joining/hosting sessions again until they restart the program. The current implementation also does not handle the scenario where the client loads into a map faster than the server when travelling across levels. This can cause issues with level initialisation, since all related logic is placed in the Game Mode class, which runs exclusively on the server.

Migrating Implementations over to C++

With some of the program's functionality prototyped and working, implementing it in C++ will lead to performance gains. Second, and perhaps just as important, this will allow for standalone games to be debugged via Visual Studio (as mentioned above), saving time on fixing issues.

Adding More Functionality

Looking ahead, I'd like to work on adding features like a lobby, scoreboards, and in-game chat, to name a few. Continuing to look at games across various genres will be helpful in identifying common features someone would expect to find in a networked multiplayer game.

Link to Repo

Click the button below to access the project's repository:

Project Ping Repo

Link to Documentation

Click the button below to access the documentation associated with this project:

Project Ping documentation