#multiplayer game development

There's been a lot of fascinating drama around Stop Killing Games. Go read the initiative here:

It is a good initiative, and anyone who is a consumer that can, should absolutely go support it.

Jason "Thor" Hall, CEO of Pirate Software, recently had a few, let's say, "takes" on the matter (I'm trying and failing to remain neutral), which began on a stream. The stream's VOD has since deleted on his YouTube channel.

Louis Rossmann, who you might know as the largest Right to Repair activist in the US, made a response to a section of the releevant stream here:

Thor, CEO of Pirate Software, made two videos to clarify his points:

There is an argument in the video at the 2:08 mark that I will reference later.

(I recommend watching all these videos on 2x speed. You will get the same info out of them all, because especially video 2 is a lot of repetition)

Now, as mentioned above, there is one particular technical argument that bugs me about what Thor, CEO of Pirate Software, is making. Here is the full quote:

How would you keep League of Legends in a functional, playable state? You'd have to rearchitect the entire game. The game is what is called "client-server". So, in client-server models, there's a server, there's a client, and all of the math, all of the game, everything happens on the server. The client just displays it. And the reason we want to do it that way is so that you can't teleport around and do a billion damage. You don't trust the client. You trust the server. The client just displays what it's told. Right? So, if we wanted to rearchitect this, we would have to take all of that server logic, push it back out into the client, and somehow make that playable in a multiplayer-only video game. That doesn't make sense to me. So this doesn't work for all games. Why is [the initiative] calling out all games?

So, first off, yes, most games do client-server architecture for multiplayer logic, because you do trust the servers. It is an important step to curbing an entire class of cheats. It doesn't necessarily mean the client isn't malicious (for example, there are cheats for League of Legends that show a growing circle when an enemy leaves the fog of war in the minimap). However, it does mean the client doesn't know 100% of the game at any time when information is selectively fed to each client based on something like the fog of war. That's awesome.

Some games, like PlanetSide (rest in peace) and Overwatch (2) use what's called client-side hit detection. Some games, like Halo 1, employ more selective hit detection models, where only certain weapons use client-side hit detection (see https://c20.reclaimers.net/h1/engine/netcode/). Client-side versus server-side hit detection can change the overall feel of a game, and it's one of the things game developers decide on in multiplayer-only games that require it. In the case of an massively multiplayer online first person shooter (MMOFPS) like PlanetSide (2), the server simply can't calculate thousands of people's math in a reasonable amount of time, because otherwise the hit detection would otherwise feel very crappy to play, and so the math is offloaded to the client and the client says "hit" when they hit.

However, there are a few counterexamples to the specific technical argument that keeping the game playable after end-of-lifing it requires rearchitecting:

Games with dedicated servers exist - Command & Conquer: Renegade, Starsiege: TRIBES

Games where one client also hosts the multiplayer server exist - Half Life 2, Warhammer 40k: Space Marine

Private server hosting exists - World of Warcraft

Some of these games, particularly the examples with dedicated servers that can be run on user hardware, can also run as the second example.

To say keeping a multiplayer-only online game requires rearchitecting a game like League of Legends means a lack of imagination. More relevantly, it means a lack of systems thinking.

To me, it is very strange for someone such as Thor, CEO of Pirate Software, who is self-described as being a 20 year veteran of the games industry to say. I won't say skill issue, because I think there is an ulterior motive at play.

Just to hammer the point home, I drew up some crappy diagrams in Inkscape because this extremely wrong technical argument bugged me so, so much.

Here is what a client-server model looks like:

Here, you have 10 clients, each being a player of the game. Then, you have the server, run by Riot, the developer and maintainer of League of Legends.

Here is the imagination of Thor, CEO of Pirate Software, had to say on the matter on the required way rearchitect it:

Those who know their network models would understand this looks very much like a mesh network, or a peer-to-peer model. And, to be fair, some games might attempt it.

However, this isn't *usually* how games described using a peer-to-peer (P2P) model work. Most peer-to-peer models, like the architecture used in Space Marines, are often used for matchmaking. Once you are in a game, one of the clients also serves as the host (selecting by some algorithm, like randomly or whoever has the best hardware).

P2P is nice, because the company doesn't have to run servers for matchmaking at all during their lifespan (and sometimes a matchmaking server might be spun up to serve as a relay to help with network issues or help other clients find clients quickly). As we'll get into later, a client machine will also serve as the host machine. It is a perfectly fair and valid, although it comes with it's frustrations (mainly in the realm of network address translation (NAT) traversal, because your computer behind a router is not usually exposed to the wider Internet, though sometimes routers have universal plug-and-play (UPnP) set up, which makes NAT traversal much easier here).

If you've ever seen a message in the game "migrating host" because the host left, they likely use P2P matchmaking, but still use a client-server model. They can just migrate the game data to a new host using the data on the other clients as a seed for the data.

This is likely their setup for actual gameplay:

One of the clients now has a server on the same machine. Sometimes, this could be the game itself that would serve in singleplayer. However, most often, this is just a server that's lightweight enough for the client to connect to and they play that way (it's also really nice to develop and QA this way, because many server bugs will also be seen by the client).

Now, one of the disadvantages here is: Can all remote clients connect to the host that the server (and one of the clients) is running on? Again, NAT traversal issues usually play a role here. In the first few days of any game that uses this, and only this, there will likely be a lot of issues with connectivity.

Another disadvantage: The host won't have latency issues. This is why in the case of, for example, Among Us, the client host can see certain things happening (like someone is dead the moment they hit a button or reported a body), but remote player hosts might not.

Okay, so, maybe it's not possible to rearchitect something like League of Legends like this. It could reasonably be a lot of work. Here is another solution:

Looks very similar to the first architecture, doesn't it? It is! The difference is that the text "Riot" was changed to "not Riot".

This is how World of Warcraft and Pokemon Go private servers work.

There are several approaches and techniques I can think of that will help mitigate the sting of losing.

Losing players should still get rewarded. Battle Royale games have only one ultimate winner, but they hand out rewards to all participants. Those who survive longer get better rewards, even if they don't win. Many games have achievements and secondary goals that grant rewards even if you don't win the match.

Losing will always sting, but we don't have to let it fester. We can, instead, offer the loser a quick exit and an option to get into a new game quickly. Most battle royale games offer the ability to spectate or start queueing for a new game immediately upon game loss.

Losing can be an opportunity to learn and improve. Not a lot of games do this, but I really like how fighting games have replays of your matches where you can go back and see the inputs and the events that transpired. Several of them even have instantaneous takeover, where the player can let the replay go until they start inputting new commands and see what would have happened if they had done something different.

Losing feels less bad if there are things built into the game that can share/take the blame. Think about how many players in MOBA games like League and DotA complain about their teammates, rather than look inward for reasons they lose. Similarly, randomized elements like not drawing enough (or too many) lands in Magic: the Gathering can give players a convenient "release valve" for their frustration and let them continue playing without needing to harm their own egos.

I think that it's important to recognize that the importance of victory is mostly determined by the stakes involved in the game. If we reward players primarily for victory, then winning will feel better and losing will feel worse. If you don't grant heavy rewards for victory, then the losing doesn't feel worse and the winning won't feel as good. Still, through judicious reward placement and some vents for frustration, we can make mitigate the worst of the sting of losing for most players.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

They’re really different beasts that have their own benefits and drawbacks. 

User-run dedicated servers provide some additional flexibility that matchmaking can’t, like playing specific map pools, special server rules, or server-allowed mods and such. They allow for more of a customized experience and the fostering of a smaller community within the greater playerbase. Playing on a local server you like increases your chances of playing with the same players again, building relationships and establishing a community. Having dedicated servers directly caused the creation and development of gaming clans.

Unfortunately, this can also be a double-edged sword. Dedicated servers don’t control for player qualities like skill level. Going to a dedicated server with players at vastly different skill levels often results in curb stomps, which really aren’t a fun experience. Most players don’t want to sift through a list of servers for one with good ping, a good ruleset/mapset, enough players, and a reasonable skill level; they just want to play. We can also add additional potential player-facing issues like servers where the admins are ok with hate speech or bullying and you can see why dedicated servers might not be such a great player experience.

Using a matchmaking system instead of dedicated servers smoothes out many of the dedicated servers’ rough edges. Since the matchmaking system is administrated by the developer and publisher, bad behaviors like hate speech are not tolerated and bad actors are actioned. Matchmaking purposely optimizes for qualities like ping and player skill, meaning feels-bad curbstomp games are less likely to happen. The tradeoff is that matchmaking also suppresses customization and the chance of building a community with other players. You could make reasonable arguments for both, but the benefits of dedicated servers to publishers have mostly been eclipsed by their drawbacks, which is why so many multiplayer games today favor a matchmaking system instead.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Players generally play in the way they have fun, even if that isn’t the best way to win the match. When a player is new to a game, it usually takes a while to learn the particulars of the game and how to play. During that learning process, we build in understandable simpler lower-order goals that are designed to be enjoyable (e.g. killing opponents) and gameplay that builds on those simpler goals (e.g. kill streaks). As skill levels rise, most players either grow out of kill counting and embrace team gameplay, hit a wall at a skill level where kill counting still works and stay there, or churn out of the game because it just doesn’t align with their interests as well as other games do. Our design goal is usually to make the gameplay experience fun and engaging at as many (experience) levels for as many players as we can. That also includes new players and players with different goals, though the priority at which we devote development resources to these different player groups will naturally vary.

It’s an unfortunate misalignment of incentives when we match players who aren’t as incentivized to win the match with those who are because it causes a lot of frustration to their teammates. It is a problem that we, as designers, are perpetually trying to improve. Usually we help by offering different gameplay modes to allow players to choose what kind of game they like to play (e.g. deathmatch for those who just want to kill opponents, ARAM, etc.) and tweak our skill-based matchmaking so that the newer players are naturally separated from the more experienced players looking for a good match. However, these protections don’t necessarily mean that we’ll catch everybody all the time (especially because sometimes you just want to kill some fools), but we do catch most of them this way.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

There are a lot of layers of decision-making to answer this question, and it’s a question every dev team has to consider when building a game. This tends to touch on all sorts of aspects of game development, because the decision is a pretty big one. It’s also one of the earliest decisions we have to make, because the number of players supported in multiplayer has very far-reaching consequences in some of the fields that require the most time to build - engineering and environments.

The first major constraint on player count supported is technical. Being able to have ten players playing at once in the same game is difficult. Supporting a hundred players concurrently is really difficult. The constraints of the technology (especially if you’re using an off-the-shelf engine) may limit the number of players the game can support. Furthermore, increasing the number of players in the game also requires adequate systems to help players find the game they want to join, as well as keep the community from fragmenting.  This means you need some sort of matchmaking service, game browsers, some way to handle player-to-player communication, and so on. These sorts of systems have to be approached differently if you’re handling a lot of players - a team of five might be fine with unrestricted voice communication, but you probably don’t want it on a team of 50.

The second major constraint on player count is the size of the environments. Environments take a really long time to build. Large team games need large environments to play in, and that means more landmarks, more control points, more defensive positions, more areas to fight in, and so on. Building maps with a cohesive sense of flow that make sense is really time-consuming. This can’t be automated either - it has to be built with the intention of being fought over by players and we really don’t have that kind of technology yet. The larger the player count, the bigger the map you have to build. Most battle royale games have just one map for this reason - it takes a long time to build a map that big.

The third major constraint is just the team leadership’s vision for the game. The team’s creative leadership has a vision for how the game plays and that affects how many players are on a team. Overwatch is essentially a game about near-future superheroes. Having 50+ superheroes on a team at once doesn’t let them really shine as such. Similarly, Siege is about elite operators in a breach situation. The fiction doesn’t match - you don’t often have massive teams in those situations. In order to make each player feel like a superhero or elite hostage rescue operator, you need to give players abilities that make them feel special, like they are making a big difference in the game. On the other hand, the fiction of Battlefront or Battlefield - being a single soldier taking part in a big battle - make it entirely intentional for big team play. Playing in a Battle Royale is more about skill and savvy, where it’s less about the fiction of being super special.

I don’t really think that we’re focusing more on small-team experiences to the exclusion of large-team experiences. The most popular game mode in the world right now is Battle Royale after all. It’s just that there are some major technical and developmental hurdles that must be addressed and planned for early on. The size of the player team affects the sort of gameplay experience that the players have. We usually go into development with a specific idea of what the player experience is for the game, and that includes how the team size affects that experience.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Unity 3D is one of the most powerful and user-friendly game development platforms available today. Whether you’re a beginner or an experienced developer, Unity provides everything you need to create immersive games for all platforms.