Hello and welcome back to another Frog Bath multiplayer development update! These past two weeks have been extremely productive on the multiplayer front. With bug fixes, multiplayer frog updates, split-screen and more, there’s a lot to show, so let’s get into it.

Roadblock fixes

In my previous blog post, I talked about some of the strange roadblocks that had been slowing down development. Thankfully, at the very beginning of last week, I was able to resolve Unreal’s “cable component is missing” glitch. The reason the cable components were missing is due to a glitch in the plugin’s loading phase. That’s why it was hard to debug, because it turned out being an issue with Unreal and not Frog Bath.

Unreal’s build order was initializing the cable component plugin too late, causing it to crash after compiling the C++ code. I fixed this by adding extra metadata to the .uproject file. This metadata tells Unreal to build the cable component plugin during the “PreDefault” phase instead of the “Default” phase. Now with that out of the way, I could start working on other exciting features, like split-screen and multiplayer movement.

Split-screen Local-play

Originally, Frog Bath was meant to be a four-player couch co-op game. But why restrict it to four players? This week, I implemented a system that allows for variable match size, between two and four players, for local co-op games. It was a small change, being only a variable and GUI scaling effect, but adds a lot of flexibility. Here are some in-game screen shots:

Multiplayer Froggy Walking

After implementing split-screen, I shifted gears and started working on replicating our frog’s movement over the network. Normally, this would be an easy task in Unreal as the Character Movement Component comes pre-baked with networking capabilities. Unfortunately, our frog player was implemented by setting velocity directly—which doesn’t get replicated by default. I was unaware of this at first when attempting to replicate movement. After many failed attempts, I came up with this:

Let there be movement! There is an issue though. The host moves fine using this setup, but the client moves extremely fast. To make things worse, sometimes the client even snaps back to a different position.

After some research, I eventually discovered the Character Movement Component doesn’t automatically replicate velocity. The client was snapping back because the server wasn’t agreeing on the player’s position; which makes sense since velocity isn’t replicated by default.

In addition, I discovered there is a whole movement mode system we should be using, but we aren’t. To remedy this, I spent a large portion of last week refactoring the frog player blueprint. After some time experimenting and learning the new system, I got nice smooth walking implementing over the network:

Multiplayer Tongue Movement

Next, I moved onto getting replication to work when the frog is tonguing a surface. This proved to be more challenging than getting walking to work because it requires a custom movement mode. Unfortunately, Unreal has very little documentation on this subject. It also seems like it’s almost not feasible to add a custom mode in pure blueprint. After a few days, I decided to push this feature to next sprint and focus on the literal tongue replication instead:

As you can see, when the client tongues, their frog movement is very jittery. The custom movement mode will help alleviate that.

Multiplayer Particles

After implementing the tongue, I worked on getting particles to replicate over the internet. Opposite from the tongue movement, this proved to be easier than I expected. After sending an event from the client to the server and server to multicast, miraculously the particles just worked:

Player Tracking and Refactoring

As you can see in the above gifs, sometimes the frogs have color and sometimes they don’t. This is because of how we used to track the players. Originally, each player was assigned an ID and then all player materials would be set right afterwards. This breaks in multiplayer because not all players are connected into the game at one time. The old system worked sometimes, but provided inconsistent results in most cases. I set off to fix this once and for all by re-implementing the player tracking system. I changed the tracking to be game-mode independent and network friendly by using replicated variables. After doing so, we haven’t had a player ID/material issue since.

Connecting it all together

One of my favorite features implemented this week is the online lily pad button added to the main menu, by our lead designer Leo. Now it’s officially possible to connect to the internet without using a secret developer hotkey and that makes me very happy. (The hot key is 5 if you were curious):

Right now, the button goes to the old multiplayer GUI. In the future, Leo has an awesome plan to incorporate it into the actual 3D world you see in the gif above.

What’s Next

There’s still a lot of exciting features to implement, including the 3D network GUI, custom frog movement, and actual networked game play. I plan on adding all of these additions, and more, over the next 3 weeks because we want to start QA testing the networking as soon as possible.

Thanks for reading this far! If you’re curious about the future development of Frog Bath, stay tuned and I’ll see you in the next one!