Search Unity

The 8 factors of multiplayer gamedev in small-scale cooperative games ft. Breakwaters

October 27, 2021 in Games | 20 min. read
stylized screenshot of beach and water
stylized screenshot of beach and water
Topics covered
Share

Is this article helpful for you?

Thank you for your feedback!

Discover how Breakwaters, an upcoming indie game, chose their model to learn how a studio building a small-scale cooperative game approached their networking.

When it comes to development, multiplayer games can require more up-front work to get running – like specialized expertise, ongoing services like hosting and player communication services, and maintenance costs. 

Below, we cover the eight factors of multiplayer game development you need to consider for building multiplayer games and how they apply to small-scale, cooperative games. Plus, we talked with Phillip Heckinger from Soaring Pixels Games on their upcoming title, Breakwaters, to learn how and why they chose to build their game in the way they did.

The 8 factors of multiplayer game development

There are eight key factors that come into play when choosing or developing multiplayer networking solutions to develop your title. 

  • Latency: The amount of latency tolerable within the game
  • Players per session: The amount of network connected players in each game session
  • Synchronized simulation scale: The amount of the simulation you choose to keep in sync across your connected players
  • Precision: The exactness requirements of the shared experience
  • Cost: The cost to create, maintain, and operate the game
  • Complexity: How complex the networking solution is and how experienced your team would need to be to implement it successfully
  • Cheat mitigation: How important is it to attempt to prevent players from cheating
  • Lock-in: Whether or not the solution is difficult to change in the future.

Considering the eight factors and what each networking model can offer as support, you can begin to narrow in on which model to use and begin your development process.

table of contents explaining the 8 factors of multiplayer development

The 8 factors in small-scale cooperative games

With the sample game, Boss Room, we have the ideal example: It’s small scale in player and simulation and is a cooperative and client hosted game. 

We assessed the factors for Boss Room below:

  • Latency: Up to 200ms of latency would be acceptable (including relay service hops)
  • Players per session: Goal of 10 given a client-host running on a modern PC 
  • Synchronized simulation scale: All player and AI transforms, animations, and activity
  • Precision: Moderate due to the casual combat mechanics
  • Cost: Free to create and maintain, low cost for relay service used during live ops
  • Complexity: Need low complexity to be able to educate multiplayer development principles on to new developers
  • Cheat mitigation: As we’re focusing on cooperative concepts, cheating is not a concern as there is no explicit player gain from it 
  • Lock-in: We want to be able to evolve the sample someday to show how it would like being run with dedicated servers

Read more about how we decided how to create the sample game given these factors in this blog.

It’s important to keep in mind that some small-scale, cooperative games have different needs than others. For example, Team17, the studio behind Overcooked!, initially used a peer-to-peer model but changed during development to use dedicated servers instead.

They did this to accommodate for the estimated demand and total player scale projected for the game’s launch. 

So how do you know what is the right model for your game? We spoke with Phillip Heckinger, owner of Soaring Pixels Games, to understand how they approached networking for their upcoming small-scale cooperative title.

How Breakwaters chose their networking model

Animation of man staring at the ocean parted to reveal a beach path

Breakwaters is an action-adventure game currently in early access that takes place in an oceanic world where players strive to build, craft, and survive. We spoke with Soaring Pixel Games to ask them about how the eight factors influenced their choice in selecting which model to go with for Breakwaters.

table of contents explaining the 8 factors of multiplayer development as it relates to the Breakwaters game

Players per session

The game features an online cooperative mode where friends can work together to explore the waves and defeat titans in groups of four connected players at a time. Soaring Pixels is exploring increasing the amount of players per session depending on how enjoyable people find it. 

 

Complexity 

Breakwaters is an ambitious game that has a demanding water simulation system. In order to maintain smooth gameplay and have low load times for single player, Soaring Pixels Games architected their game to separate simulation between different layers of abstraction. 

They make use of spatial relevancy and distance-based activation for single player, and were able to extend these systems for multiplayer. Simulation, rendering, and artificial intelligence are all handled by systems that are separately activated. For Soaring Pixel Games, not only was this useful for optimizing better performance for players in single player, it also allows them to more easily distribute their simulation and authority across players in multiplayer. 

 

Precision

Breakwaters uses a pseudo-deterministic custom physics engine built on top of PhysX, and the team decided to lock determinism to a certain degree of precision. Many of the game’s systems only need to know generally where something in the world is for their heuristics since lazy evaluation allows them to quickly identify what needs updating which is relevant to an event or player action.

Oftentimes, rotation values don't even matter for their simulation operations. If they need more precision, their systems increase precision with increased update rates. 

 

Cheat mitigation

Because the game is designed to be cooperative, Heckinger said cheat mitigation isn’t currently a priority for them. This allows them more flexibility when it comes to the other factors, such as who can be authoritative in managing the synchronization of the simulation.

“We're not worried about competitive play per se, you know we'll deal with that in the future if the game does well. We're more interested in people having fun and if that means they want to cheat a little bit, it's their game, so they can go right ahead,” added Heckinger.

Screenshot of a 3D game with a man in a glider boat over water

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. 

Unity’s products for small-scale cooperative developers

Building a small-scale cooperative game? Network your game with Netcode for GameObjects and connect your players with Relay and Lobby.

Netcode for GameObjects 

Unity’s new first-party netcode solution, Netcode for GameObjects, focuses on providing streamlined solutions for the creation of client-hosted, cooperative type games – like Breakwaters. These are games that are more tolerant to latency (~200ms), not as strict on cheating, and ones that trend towards moderate-speed interaction gameplay. 

*Those who want to explore other game types can directly access and modify the code base on GitHub as it's open-source and distributed under the MIT license.

 

Relay

When it comes to connecting players in a small-scale cooperative game, a relay service is a great choice that’s cost-effective and secure. Unity’s new Relay service is now in open beta, allowing you to connect your players and provide great multiplayer gaming experiences without the need for a costly dedicated game server. 

 

Lobby

How will your small-scale cooperative game connect players to share a joined game session? Unity’s new Lobby service – now in open beta – may do the trick. Lobbyᴮᴱᵀᴬ allows your players to create public lobbies using simple game attributes which other players can then search, discover, and join. Invite-only lobbies also allow players to create private spaces for select participants only.

Conclusion

Each multiplayer game concept has different needs (and solutions available) for successful development and operation. We will dive into more depth around the factors as well as how they align with different game types in future pieces, so stay tuned for future content on the blog! 

Interested in checking out Breakwaters? It enters early access in November on Steam.

October 27, 2021 in Games | 20 min. read

Is this article helpful for you?

Thank you for your feedback!

Topics covered