State of the Game, #4

Introduction

Yet another (very!) late edition of State of the Game, but arguably for good reasons - I'd rather delay these by a week or two (or three...), than have more consistent posts that are shorter and less interesting. With my excuses laid out for all to bare, let's focus on what's changed since the last State of the Game.

For the most part, the last few weeks were focused on ensuring that the user experience flow from the main menu, to the lobby, into the game was actually functional and not a nightmare to use. On top of that, I've also added a bunch of moderation options, a permissions system that controls which players can use them, and I re-implemented the teams mechanic from the ground up.

And finally, while fiddling around for hours, trying to get networked physics to work properly for player movement, I made the.. controversial choice to change the networking library that Bus Game uses from Unity's first-party solution, Netcode for GameObjects, to FirstGearGames' Fish-Networking. I have a few reasons for this change, but ultimately the goal is to work with a library that I don't actively need to fight against in order to implement the features that the game needs - and Fish-Net seems up to the task.

Improved Lobby

This update features a few improvements to the Lobby stage of the game, where players can gather before entering an Epoch - including changes to the user interface, and the logic behind it. Here's some screenshots, to showcase the most visible changes - the left (or top) one is the old lobby UI, the right (or bottom) one is the updated UI.

Taste in user interfaces is subjective, but I definitely prefer the new interface over the old one; not only does it look better, but it also provides more functionality - in particular, ways to use the new moderation and team features that were also implemented in this update.

With the code improvements, its also much less likely to break or show inaccurate information. Additional changes and upgrades will be made to it over time, but for now I'm quite satisfied with how the lobby appears and functions.

Moderation Features

While I suspect most people will be playing Bus Game with people they know, it never hurts to have features that make multiplayer gaming a safer and more welcoming place. Or you could use those features to kick or mute your friends during when they least expect it, not that I endorse that sort of behavior. Regardless, multiplayer games should have moderation tools, so now we have them.

With this update, we've implemented the ability to kick, ban, and mute players in your Bus Game session. The host can also promote or demote players, to give them more privileges in the newly implemented permissions system - for now, there's three levels of privilege: default, elevated, and operator. Elevated players are able to create teams (for Epochs that support them), and operators have full access to all permissions.

In the eventual future, the permissions system will be customizable via configuration files on the host/server, using syntax very similar to how permissions are handled on Minecraft servers.

Re-implemented Teams

Technically, the ability for players to create and join teams was first implemented at the very start of the development of Prototype 9, but that solution sucked and needed replacing. So that's what I've done - replaced it with a more sensible implementation, with more functionality and less bugs.

Switching over to the Teams tab, on the Members pane, we're met with a list of created teams and - if you click on one of the teams in the list - a "selected team" display, showing the team's name, color dot, and members list. The buttons at the bottom of the Teams tab are context sensitive, and will change according to the player's permission level and if they have a team selected.

When possible, Bus Game will automatically create teams after the host selects an Epoch to play which requires them. Players will also be randomly assigned to those teams, but they're always free to leave and join another team, or create a new one if they have elevated privileges.

After joining a team, that team's color will be displayed to the left of their name in the Players tab. In-game, their overhead name label will be colored according to the player's team color - this may be changed in the future.

Networking Library Change

As mentioned earlier, Bus Game now utilizes Fish-Networking for multiplayer networking, replacing Unity's first-party Netcode for GameObjects (NGO) as our solution of choice. For a long time, I wanted to stick with NGO and simply workaround the limitations it had for the features I wanted - unfortunately, many of those limitations were not simple to workaround and at the end of the day, Netcode doesn't do anything that other libraries can't do.

Even Unity's various networking services - like Relay and Lobby - can be used with pretty much any other library, since they work on the transport level. So I figured that it's finally time to break free of the sunk-cost fallacy, and move to a library that does the things I need it to do out the box - in comes Fish-Networking, with their most notable features for me being:

• Client-side prediction, out of the box. Yeah, it requires some configuration and changing of scripts, but it's so much easier to implement than any other solution thus far. Read further to learn more about that.
• Addressable scene loading. Again, this needed a bit of scripting on my part, but that's really not a huge deal in comparison to the massive scene management solution I had to write myself to make this work with Netcode.
• Dead simple serialization. No longer will I need to implement INetworkSerializable on all my data types and write my own serialization logic - for the most part, Fish-Net does it all automagically.

I could probably go on and on about the things that Fish-Net does, that make my life easier as a developer. But I'll stop here and end with a recommendation - if you're wanting to make a multiplayer game in Unity, give Fish-Networking a try. It's been lovely so far, and their Discord community is incredibly helpful.

Player Client-side Prediction

Thanks to the transition to Fish-Networking, I've finally been able to implement client-side prediction for players in Bus Game without the experience being a total choppy mess. Here's a quick breakdown of what that means, without a lot of the technical complexity:

• When you're in a multiplayer Bus Game session, all of your movements as a player are simulated on both your local game, and on the server you're connected to.
• The server will use your movement inputs to simulate your player movement on its end, and then send the result back to your game client.
• If the server's simulation of your movement is drastically different from your client's simulation of your movement, the difference will be reconciled - i.e. your client will correct your position to the position that was sent by the server.

All of this was required for game's physics to be better simulated over the network in a multiplayer environment. And, it has the side effect of making potential movement cheats significantly less destructive for other players - not like that matters much, unless Bustle Royale takes off in the competitive scene for whatever reason.

If you're interested in learning more about client-server game architecture, Gabriel Gambetta has a great series of articles all about it, particularly regarding fast-paced multiplayer experiences. They helped a lot in developing my understanding of how this stuff works.

I'd attach a GIF to showcase how client-side prediction looks in-game, but fortunately it's not really something you'd notice unless something's going wrong - as in, high latency or very poor performance on the host. It just looks like normal player movement, and that's not particularly exciting.

Conclusion

And that's all, folks! Once again, I'm hoping this wasn't a super boring total snooze-fest of a read. Going forward, the plan is to revisit Vehicle Interior Simulation - a framework I'm working on to accurately simulate physics within the interiors of moving vehicles - and to generally polish all the changes made since Prototype 8, in anticipation of the completion of Prototype 9 at about the end of August.

After the completion of Prototype 9, I'd love to get a public demo of the game working and released before the end of the year - ideally way earlier than that, even. But in the meantime, you can get hyped up for State of the Game #5, in a week (or two (or three (or four))) from now.

Thanks for reading!

-RB