NATS Unreal Plugin

GBS NATS

Since I’m going to be using NATS for the server side service bus then I’ve started making an Unreal Plugin that will integrate NATS with Unreal.

I’ve made a lot of progress; it was a lot easier to make the plugin than I thought.

I hit some significant issues getting the nats.c dependencies to build on Windows, but since I really only need this for the game servers to communicate with the back-end micro services then that shouldn’t cause me any problems.

I think I can still implement the editor portion of the plugin for Windows, which will make it so that I can use the Unreal Editor on Windows to create the Blueprints, but all of the actual implementation of the integration will be conditionally compiled and only build on Linux.

Saving Construction

One of the uses for a service bus is to save the buildings constructed by players.

Granted, Unreal has a good way of saving games, but the challenge is saving incrementally in a multi-player persistent world.

Any time a persistent event is executed, the game server publishes that event to the service bus. The service bus persists that event and then publishes to other listeners.

The responsibility of one of the micro services is to listen to the construction events and save a cache of the current view. This cache can be completely rebuilt by re-playing all of the events, but that can be expensive, so when a server starts then it sends a request to the construction cache service to load all of the current constructions, and then subscribes starting with the last event applied to the cache.

A nifty advantage of this is that a game server can start running and loading all of the data before the server which it is replacing is shut down. It’s not exactly a hot standby, but at least it’s a warm standby.

Also, in the event of a game server crash, none of the data that has been committed will get lost. Using single events to combine the “cost” of the construction along with the construction itself, the player won’t get “charged” for constructing something that doesn’t get constructed.

Defects will happen, and sometimes they cause imbalances in the game. Saving the events will allow the game logic to be corrected and the events re-played to correct the errors… or, if the logic cannot be corrected fairly then the offending events can be discarded as if they never took place.

Client Optimization

I’ve not implemented this yet, but the same basic idea can be applied to clients.

When a client first connects, it will have a cache of the most recent version of the constructed items, along with a cursor pointing to the last event applied to the cache. This could be in a per zone / map / level instance, or it could be broken down even further into map partitions.

As the player approaches a partition, in the background it begins downloading the updates, either as a complete replacement of the cached data, or as a series of events… hopefully whichever is most efficient.

Other Uses

This architecture will make other things such as cross-server chat, cross server markets, etc be easier to implement.

Well, that’s enough of an update for this weekend. See ya in a few days.

– Sgt. Flame