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

Let's take a step back for a moment. The purpose of a matchmaking system isn't to keep players at a 50% win rate, it's to match players of roughly equal skill with each other in order to make for engaging games. The primary goal of matchmaking is to reduce the number of curb stomp games where the winners are bored and the losers are salty, because neither side really enjoys the experience all that much. This usually ends up stratifying players into skill bands, where the players within that band are generally able to give each other a decent challenge and minimize the number of lopsided games. Having a win rate close to 50% is a result of such a system but is not necessarily a goal.

Matchmaking systems can't ensure every player has a 50% win rate because it breaks down when there are very small numbers of players within a skill band. Let's examine an extreme example of this at work. Imagine the best player in the world, Neelo. The only player on Earth she cannot handily defeat is her rival Noriko. Between the two of them, Neelo has a slight edge and wins 55/45. If Noriko is online, Noriko can only ever be matched against Neelo and Neelo will win 55% of the time. If Noriko is not online, then no one can beat Neelo and she wins 100% of the time. There is no way a matchmaking system can ensure a 50% win rate for Neelo in such a situation.

This isn't an issue for most skill bands because there's often hundreds or even thousands of players playing in those bands at any given time for a sufficiently popular game. However, the very top echelons of player skill often run into issues with matchmaking because of the availability of qualified opponents. Professional competitive players playing normally online will tend to win more than they lose because there just aren't enough players of their skill level online at any given time to match them with. Since there aren't enough players that skilled to make matches, the matchmaking algorithms will necessarily widen the search as time passes and often match them with less skilled players often with fairly predictable results.

[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

Consider what it is matchmaking does - it spins up a new game and directs chosen players from a player pool into that new game. The matchmaker has to consider various factors to determine who among the players in the pool are the best choice for putting into the game. Each factor that the matchmaker uses to determine whether the players are eligible for the game reduces the size of the player pool to choose from. If the player pools don't have enough players in them, the matchmaker might not be able to find enough players to start a game and thus be forced to wait for new players to join the pool. The more factors the matchmaker has to optimize for, the longer the process usually takes.

The fastest way of matchmaking is just throwing every single player into the same pool, and then firing up a new game whenever there are enough players to start. The only thing the players have to wait on is there being enough players in the queue to start the game. Let's say that a typical game requires four players to spin up - a two on two game. This means that the highest number of players waiting in the queue will be three - every fourth player that enters the queue will fire up a new game. However, this completely ignores gameplay factors like map choice, team composition, player skill and experience, character power level, and so on. This can often result in lopsided games and curbstomp multiplayer sessions... but it will be fast.

Let's say that we now give players their choice to queue up between two maps - Alpha Map and Omega Map. Now we've split our pool in two - players who queue for Alpha and players who queue for Omega. Now the maximum number of waiting players is six - we can have three waiting on Alpha and three waiting on Omega. The next player that joins will have to choose either Alpha or Omega and the appropriate game will spin up. We have, however, doubled the maximum number of players waiting. If no one else queues for Omega, those three waiting Omega players will be waiting forever (or at least until they give up).

We can add the option to queue for either, in which case we can pull from three pools (and hopefully the Either pool is popular enough), but this also starts its own set of potential issues - what if Alpha is just way more popular than Omega? In this case, players who want to play Omega specifically will be in for longer wait times as well, since there will always be players looking for Alpha games, which will not only pull from the Alpha pool, but also the Either pool. This still keeps our maximum number of players waiting at six (three Alpha-only, three Omega-only) in the worst case, but usually fires games more quickly on average because both Alpha and Omega games can pull from the Either bucket. 

This kind of player pool distribution is then extrapolated for every factor we want the matchmaker to consider - player skill, character power level, ranking, map preference, multiplayer game type preference, etc. - and then all of these are balanced against queue time. Most matchmakers will start removing consideration factors as wait time increases because our general thought is "a player would rather play a game that isn't ideal than wait a long time for one that is". We try to ensure that the removed factors will still result in a play experience as close as we can to the desired one, but that isn't always the case. "Assemble four players to play" is generally a lot easier and quicker than "Assemble a tank, a healer, one ranged DPS, one melee DPS, and a support that all want to go to Wombat Dungeon II: Wombat Forever for time attack mode that are all diamond rank".

[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

Yes, that’s actually pretty normal. If you want online play, you need some amount of input lag to serve as a buffer so that both players will get the same results at the same time. The amount of lag will vary depending on the game, but it’s pretty normal to have some amount of input lag to provide a buffer in order to allow for fair gameplay. Let me show you what I mean. Normally, when Ryu presses the roundhouse button, the signal from Ryu’s controller goes in, gets processed by the machine, then the move starts. In a lagless environment, this is a timeline example of what would happen:

However, when Ryu is fighting Ken online, there’s not one single timeline, but actually three separate timelines - one for what Ryu sees, one for what the server sees, and one for what Ken sees. The difference is that these are not synchronous by any means, because it takes time for Ryu’s game to tell the server that he pressed the roundhouse button, and then it takes time for the server to tell Ken that Ryu pressed the roundhouse button. So it actually looks something like this:

If it takes 50 milliseconds (3 frames) to transmit data from Ryu to the server, and another 50 milliseconds to transmit data from the server to Ken, then Ken won’t register Ryu’s roundhouse button press until 6 frames after Ryu pushed the button. Ryu likewise would also not see Ken’s moves until 6 frames later. Obviously, this isn’t so good. 

Imagine this scenario. Ryu and Ken are right next to each other. At frame 0, Ryu presses roundhouse (startup time: 5 frames). This means that Ryu’s roundhouse will hit on frame 5. At frame 1, Ken presses jab (startup time: 3 frames), hitting on frame 4. In a lagless environment, Ken’s jab would hit before Ryu’s roundhouse on frame 4. But what if this were online with 3 frames of latency between each player and the server? 

If this happens online, Ryu’s roundhouse button press signal wouldn’t reach Ken until frame 6 (pressed on frame 0 + 3 frames of signal travel time from Ryu to server + 3 frames travel time from server to Ken). Ken’s jab signal wouldn’t reach Ryu until frame 7 (six frames of total signal travel time), and suddenly you have three different stories going on. Ryu believes his roundhouse (pressed on frame 0, hitting on frame 5) cleanly beats the jab that was pressed on frame 8. Ken thinks that his jab (pressed on frame 1, hitting on frame 4) cleanly beats Ryu’s roundhouse (pressed on frame 6, hitting on frame 11). The server receives Ryu’s roundhouse at frame 3 (0 + 3 frames travel time), Ken’s jab at frame 4 (1 + 3 frames travel time), and thinks that Ken’s jab actually stuffs Ryu out of his roundhouse at frame 7 (1 + 3 frames startup + 3 frames travel time). If the server is authoritative (as it should be), that means that it sends the signal to both Ryu and Ken that Ken’s jab beat Ryu’s roundhouse, which will then happen on frame 10 for both of them (server says it happens on frame 7, but it takes 3 frames of travel time for the signal to reach both of them). This is probably super annoying for Ryu, who pressed the roundhouse button 10 frames ago and still gets stuffed by the jab he didn’t get until 7 frames later, when the server decides that Ken’s jab won.

Now let’s assume that there’s an input delay of 8 frames. The same input timing happens - Ryu presses roundhouse on frame 0, Ken presses jab on frame 1. What changes? Because there’s the delay in the moves actually starting, all three parties now have enough time to synchronize the events before anyone expects the attacks to happen. This means all three will see the same events play out on the same frame numbers.

With an input delay of 8 frames, Ryu knows his roundhouse won’t register until frame 8, and won’t go active until frame 13. Ken knows his jab pressed at frame 1 won’t register until frame 9, and won’t go active until frame 12. The server has enough time to receive the input data from both fighters and then update them both with enough time to spare so that both Ryu and Ken will see the exact same thing happen on their screens exactly eight frames after they pressed the button. This input delay allows the server to keep them both in sync. The better the connection, the fewer frames of input delay there has to be in order to arrive at the same result. In this particular example, we could probably shorten it to 6 or 7 frames of input delay to maintain parity. If we could decrease the latency between Ryu and Ken, the input delay could be reduced further.

So yeah. That’s how online play works for almost all games played in real time. Synchronization is hard. Signals aren’t instantaneous; it takes a non-trivial amount of time to transmit data across vast distances. The only real way to handle that is by keeping enough of a time buffer. There are various (and similar) other ways of handling this; the famous GGPO method actually stores the last few frames of the game that have already passed, and retroactively inserts button inputs into the past and recalculates the game state in order to make the present synchronize up. This is what causes GGPO’s weird false positives, such as your game thinking you KOed somebody (and playing the sound effect for it), only to receive game data that retroactively undoes that event and keeps the fight going.

“But why not keep offline play without any input lag and just keep it for online play?” you might ask. They did that in past games. Unfortunately, this means that the online play is a fundamentally different experience than offline play. That’s not good if you want to foster an active global competitive community, because it means that anyone who can’t get local competition will be at a huge disadvantage. Keeping the experience consistent for everyone online and off will allow all players to practice and improve at the same game.

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Building bots requires a lot of resources, due to the nebulous nature of how they are supposed to behave (especially in situations where goals or good strategy are less well-defined), and because problems with bots can be difficult to reproduce and test. Building a bot isn’t trivial - it requires a lot of engineering and level design time, because the AI needs information in order to function.

So… why do they act this way? Probably because bots are supposed to be:

Adjustable (Can be set to different levels)

Scalable (can work either alone or in larger numbers)

Effective (can win the game)

Not overshadow the players (e.g. you don’t want the bot to get Play of the Game)

These ideas basically require some design and engineering time just to figure out how these will actually work. However, these requirements must be built on top of the game’s fundamentals, such as:

Navigating the map

Recognizing important locations and/or powerups

Achieving objectives

Non-deterministic (will not always do the same routine)

Using weapons and powers that aren’t just “shoot the opponent”

Recognizing the game mode’s rules (capture the flag vs capture point vs death match vs …)

So in order to do this, each map will need:

A navigation map so that the bots know how to traverse the map (including special traversals, like jumpable gaps marked as such).

Points of interest marked with some way to tell which is more valuable at the moment.

Objective locations marked with some sort of algorithm to determine whether to go for the objective (e.g. consider the amount of danger present in relation to the objective), as well as stuff to actually tell the bot to stand in place and activate the objective.

And, the bot AI itself will need:

Some sort of prioritization system to decide what objectives or points of interest to chase, especially based on game mode. Typically, they’d take factors into account like distance, number of teammates nearby, number of teammates heading in that direction, number of enemies nearby, number of enemies heading in that direction, and relative value of the objective into account when determining this.

Behavior for recognizing how weapons are used, and (optionally) maps marked with areas for specific environmental use. So, for example, you’d have areas or objects on the map specifically marked as “pushing weapons can be used to shove enemies off of ledges here”, “explosive object here”, and so on for enemies to utilize specific effects to their best ability.

Some algorithm to decide what objective to pursue. One can make use of randomization, or one can decide to split things up by determining how many teammates or players are going to a specific objective or point of interest, and then choose a target based on that. Then you just need to figure out how often it needs to happen - does it happen on death? On objective captured/achieved? On some sort of other event, like a player leaving or arriving at a capture point?

You need to remember that this is all done in addition to the rest of the gameplay - interacting with objectives, shooting each other, different weapon behavior, environment art, level design, matchmaking, game modes, etc. This is all built on top of those. Then you need to start thinking about how to test this behavior, and constructing the environments in which you test them. Individual behaviors need testing, and aggregate behaviors need testing in order to make sure that the individual pieces can work together. This also necessitates useful debugging tools, such as showing the behaviors that the bot is currently running such as what it wants to do, where it wants to go, and how it plans to get there.

The biggest issue, as you may have noticed, is just how much these different systems are really interdependent on each other and how dependent they are on the map itself. There’s no way for a bot to understand what happens on a map without actively marking elements of it as such so that the bot understands how to move around. Even a small map change can cause bots to break if the navigation map isn’t properly updated. A lot of things that we understand intuitively (due to our brains being very good at parsing information) must be explicitly broken down for the AI in order for the bots to use that information. Creating functional bots requires an enormous commitment of resources, and it is a fragile system due to the sheer number of dependencies bots have. This is why many games don’t have them - they just require too much commitment in terms of resources to build.

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

The vast majority of players out there won't play local multiplayer, and only a tiny fraction of those that do will have multiple screens set up to work with a single console. It's certainly doable (Japanese arcade cabinets for Street Fighter 4 have a variation of this, for example), but most of the time the producers would rather the engineer work on stuff like "make it run at 60 frames per second at 1080p" or "fix the shader problems".