Frog Bath – Learning Unreal Multiplayer

Share on facebook
Share on linkedin
Share on twitter
Share on reddit

Welcome back to another Frog Bath development update! These past two weeks have been extremely productive on the multiplayer front. Last week, I focused on integrating the Steam Online Subsystem into my test Unreal Project. After linking up Steam, I spent a lot of time learning about Unreal’s replicating system and its features. In the past few days, I’ve learned how to handle physics movement, client prediction to combat lag, and cubic-interpolation to alleviate jitteriness. Over the coming weeks, I’m excited to implement these ideas into Frog Bath!

Steam Integration

The first notable change since the last development update is the switch from IP addresses to Steam hosting. Using Steam allows Frog Bath to host game sessions online in a pretty seamless fashion. It also frees players from having to type in an IP address every time they want to play online. Previously, a host would have to open their port and notify all clients of their IP address. This approach works, but it’s clunky and makes it unnecessarily hard for players to connect online with each other. Thankfully, it is a straightforward process to integrate Steam’s Online Subsystem into Unreal. Now with that all set up, players can host and join games with their Steam friends.

Hosting a Server

Joining a Server

Physics Movement

For Laughterburn Studios, the biggest issue with networking last semester was getting movement to work correctly. Characters’ locations would become wildly inaccurate after only a few seconds of gameplay. This past week, my goal was to understand why this had been happening. Luckily, the final section in the Unreal Multiplayer Course I’ve been following explains how to fix this exact problem.

The issue stems from the server and client not updating at the same time. Since both have varying update loops, subtle differences start to emerge when using the different delta times for physics on the client and server. These inconsistencies become amplified the longer a play session is active. To remedy this, we can simulate everything with a fixed time step. Using a fixed time step will still produce error in the integration code, but at least the error is consistent for everyone. Consistent error means all characters will appear in the correct spot on everyone’s computer!

Interpolation

After I learned how to fixed movement inconsistencies, interpolating client positions was next. Without interpolating other player’s locations, all other players will seem to move in a jerky fashion. This problem stems from network lag and not having the most up-to-date input of other players available to use. Interpolating allows us to smoothly transition between previous positions to give the user a nicer experience. The only caveat with this is that you’ll be seeing all other user’s an update behind where they actually are.

Position Prediction

One way to fix this is to update other user’s collision boxes to their accurate positions while interpolating their models each frame. Doing so allows for clients to experience up-to-date collision info while also enjoying smooth movement.

Client Experience (Right Car)

In the video above, the car is moving reasonably smoothly, right? What if I told you the server is only sending one update packet per second? Even with only one update per second, the moving player still interpolates amazingly well with the information it’s working with. The collision box is jumping around every second every time it receives a new update from the server. These two systems working together allows for accurate collision detection and a seemingly lag-less user experience.

Server Experience (Left Car)

The server experiences the game a little bit differently. Still, with only one update packet each second, the server is bound to be way behind where the client actually thinks they are. When the client sends its movement packet to the server, we add a timestamp. Using this timestamp when received on the server later on, we can predict where the client might be on their local machine. Doing so enables the local client to always be one step ahead of the server without the worry of getting teleported back to an old position. Collision boxes are also up-to-date and don’t jump around because the server is in control of where everyone is in the game.

The Future

I learned a lot these past two weeks, and I’m ready to jump into the Frog Bath source code. It’s going to be super exciting to apply all of these ideas and get some players hopping on screen together. Stay tuned, and see you in the next one!

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Andrew Rimpici Portfolio
Copyright © 2020