Synchronized Simulation Scale
With a large world, a lot of what has to be activated from their multiple systems depends on where players are on the map. The players are trusted client authorities and multiplayer games are set up where ownership of the total world is shared across multiple players. Soaring Pixel Games was able to accomplish this because of the way they designed their game architecture for single player.
“Many of our possible network problems were already addressed in the single player because of the design of our game,” said Heckinger.
Because of their sophisticated level-of-detail and spatial relevancy systems, the team was able to determine for multiplayer what mattered for the simulation or directly affected the players immediate gameplay area.
This allowed them to design what from their world simulation required network components, as not everything requires a network component. Objects aren’t standalone network entities, and objects of interest that don’t have network components might instead be registered to a system that does have its own addressable network component. These components can then map to the object of interest across the shared simulation, helping mitigate against synchronizing too much of the total simulation.
Latency tolerance
Breakwaters has a gameplay style that isn’t reliant on low-latency, twitch input. Also, since Soaring Pixel Games decided to trust their clients with authority, much of their systems allow for client-side state changes to happen without the need of a network message (remote procedure call) for state change permission.
“Our game interaction allows a lot more latency than some other styles of games – it’s not a huge concern,” said Heckinger.
Additionally, experienced and seasoned in making games, the Soaring Pixel Games engineers were able to optimize what good data size segmentation was for transmission and were able to create a system that allowed events to be marked okay if needed to be delayed by up-to half of a second. Soaring Pixels Games’ philosophy is that players will understand if they choose to do something nonoptimal, non-optimal outcomes may result.
They’ve chosen not to restrict their players from being able to connect to each other, regardless of where they are in the real world and play with high latencies because of that distance. They also won’t stop players from cutting down and dropping 1,000 trees in one location. Phillip acknowledged that latency and multiplayer gameplay optimizations would be better with dedicated hosting solutions, which leads us to our next factor.
Cost
In terms of budget and cost, Soaring Pixels Games felt that client-hosted listen-servers are the most cost-effective option that their team could initially implement. They would have preferred using dedicated servers even though many of their factor preferences are compatible with client-hosted, listen-servers. Ultimately, the large factor for the decision came down to business and cost.
“We would use a server hosted solution if the world didn’t charge so much for it,” said Heckinger. “We don’t believe a hosted server solution is cost effective for our situation but do intend to offer users the ability to host their own servers at a future date to allow them more world persistence in their experience.”
Lock-in
Of all the factors, the one that Soaring Pixel Games seemed to care most about was lock-In. Heckinger mentioned they often asked themselves: “What’s the most reasonably affordable way to not take dependency on a single system?”
For the Breakwaters team, they were aware they would need to ship for several different platforms, with a range of different requirements for each. It was important to them that they found solutions that would have easy integration points so that they could abstract and wrap to make their game code more easily portable across different services and stacks.
Instead of marrying themselves to one solution, they decided to built their own custom netcode layer that was a C# abstraction for both the client side and host/server side.
The decision
Avoiding lock-in and considering the other factors, Soaring Pixels Games was pointed strongly towards using a client-server network model, especially given that they built similar patterns to client-server in their base game architecture. They chose to use a client-server network model expressed as a listen-server, where one of their players is the session host, although they allow for their players to share authority across different parts of the shared simulation.
This also allows them the option to one day move hosting and server functionality to dedicated servers when their business needs justify it. This allows them to keep their game development flexible and allow their server model to change at a later date based on the success of the game and needs of the players.
Do your game requirements match Breakwaters? Looking into a client-server solution with a listen-server server model might be the right path for you.
Source: Unity Technologies Blog