Insight into Chrono-Drive’s Networking

Greetings, I’m Chase Hutchens the Network Game Engineer developing in Blunderbuss on our game Chrono-Drive.

I’m going to go over a high level of the network infrastructure that has been in the works. I hope someone out there will find it interesting.

When I was first beginning this adventure I pondered back on my experiences using dedicated server applications for various games. Specifically how I used dedicated server applications for hosting on my local machine for both Network and LAN play. Such as within the early Medal of Honor series, Call of Duty, various Steam games, Minecraft and others.

The essential first piece of our own networked system revolves around our dedicated server application and game server creation process. Upon the dedicated server launching, this game server communicates with our master server about it’s existence to allow for other players to be able to connect to this particular host.
From the other player’s perspective they will choose to join our game server that is in progress. For them to join, their client also communicates with our master server which tells this client which game servers are alive. Allowing the player to choose the game server they are wanting to play on.
After our host has been established, any connected client will be able to create a game if they want to. When we request to the game server that we are creating a game we send a message that looks like this:

Followed by a response from the game server that the game has been created, with our player object’s associated netID that he will utilize:

Once our main host has loaded into their game space, now they need to tell the game server about the network game objects that exist within this particular level. For each networked object we send a corresponding message for being able to store this information on the game server:

If a player chooses to join a game, a message is first sent to the server on a refresh that requests the games that are in session:

The response received from the game server about the game information & games that exist looks similar to the create game message we saw above:

After the player knows what games exist and chooses to join a game we send a message to the game server requesting to join that game:

Followed by either a failed to join or successfully joined message with the player object’s associated netID that it’ll utilize, from the game server:

At the time of this occurring the players that are within the game that is being joined are presented with a message telling them about the new player that is joining:

After the player has loaded into the game they are joining game’s space, they also need to be told about the existence of the various network objects that exist within the present state of this game world. This new player lets the game server know they are ready to receive the information about the network game objects that exist:

Whether other players, enemies, switches, level transitions or anything else, the game server then sends this player the information about the network game objects that currently exist in this particular game:

From here, we are greeted by our tried & true Boxman, the manifestation of the other player.

One of the most influential aspects of this system has been the utilization of sending & receiving relay messages between the networked objects across multiple clients. Doing so has allowed for being able to toggle network events within our game scripts to relay over the network to the other corresponding client’s perspective. This has also allowed for a significant optimization in particular situations for executing client side code to execute behavior instead of multiple constant messages.

Such as how we’re able to inject this SmartObjectData network event into our player’s normal shoot functionality to allow for it’s corresponding Boxman – NetPlayer object, to appear to be shooting for the other client:

Similarly we are able to just send a net stop firing relay into the player’s stop shooting functionality:

Within our NetPlayer object there is a NetPlayerShoot script that contains a SetInitData network event that listens for the various relays that were sent from it’s true client representation, in this case we have it setup so “UpdateFireState” corresponds to either the “NetPlayerBeginFire” & “NetPlayerEndFire”:

However, there are still prerequisites needed to setup our relays on our C++ side for the particular network game object. This is how we are connecting together the associated message relays:

Upon the relay being triggered to execute, an associated message will be sent for relaying to all other clients except the client that sent the original message, that is in the form:

Once we receive our relay network message from our game server from the network object that triggered the relay, we also have to make sure to create the data and link the pieces together:

Which eventually the particular relay is determined in need of update, dispatching it’s SetInitData event:

The NetPlayerObject definitely being one of the simpler relay setups due to only utilizing a single integer for it’s relay initialization.

Overall, I’m still in the process of generalizing this further, ideally to make it so the relays can be linked within our game scripts and then dispatched accordingly without having to recompile our code-base. Even then, I’m pleased with the current state of the relay system in unison with the network game objects. Being able to execute an array of client side code in-favor of not having to send multiple network messages to do the same thing is fantastic.

Leave a Reply

Your email address will not be published.