Welcome back to another Frog Bath development update! The past two weeks were all about integrating multiplayer into the Frog Bath build. The first week was all about exploring the blueprints and getting a feel for the architecture of the build. After I got more acquainted with the build, I started planning how I wanted to tackle the multiplayer frog movement.

First Week Road blocks

I quickly learned implementing multiplayer to an already developed game is going to be a considerable challenge. The project has massive tech debt due to the time crunch over the previous semester. Many of the blueprints couple tightly with one another and the frog blueprint acts as a hub for gameplay code. These two factors alone make it very hard to expand upon without breaking something. Overall, the code needs to change, and thankfully, one of our programmers Jacob, dedicated these past few weeks to clean it up.

Another roadblock I ran into was C++ and Unreal Engine being finicky in the Frog Bath Project. Since Frog Bath started as a blueprint project, I decided to convert the project to a C++ one. Doing so allows me to add back end multiplayer support in code while exposing useful functions for designers in the blueprints. The project did not like being converted to C++, and it was a challenge to make sure there were no errors on anyone’s copy of the project.

First Week Progress

Pushing past the road blocks, I was able to integrate the simple networked UI menu from my test project into Frog Bath!

Players can now join into the game and see their friends all connected through steam’s multiplayer network. After completing this, my next goal was to look into getting player movement to work online.

Second Week Road Blocks

Getting unusual frog physics movement to work over the network is no simple feat. This past week I had planned on adding movement syncing online but ran into some issues in the engine along the way. After wrestling with Unreal for tens of hours, I finally had a simple movement system in the game!

The only problem standing in my way is a bizarre bug. Only after the C++ code gets compiled, when Unreal gets closed and reopened, all of the cable components in all of the blueprints disappear. Whether I caused this or if someone else did is currently unknown. After hours of debugging, I was at a loss. I finally decided to reset my repository, at the cost of losing all my work, in hopes of ridding the editor of this strange missing-component bug. Unfortunately, even after rolling back my workspace and losing my work, the bug is still present.

Lessons Learned

I learned a valuable lesson this past week. Always keep a backup of your work before rolling back changes! I was so sure I had caused the missing-component bug that I thought resetting my changes would fix the problem, but it was still there afterwards. It shouldn’t take too long to re-implement what I had. I am more worried about what is causing the missing-component glitch, though.

The Future

My next primary task is to find a solution for this missing-component bug. Without being able to compile the C++ code, I won’t be able to implement the back end multiplayer system I had planned. Worst case, I move everything over to blueprint, but I’m hoping we won’t have to get to that point.

Thanks for reading this far! I’ll hopefully have a solution to this bug in the next post, so stay tuned and see you in the next one!