Asmodee.net documentation » Guides

Turn-based Online Gaming the Right Way

Running online gaming on Ticket to Ride since 2005, we have cumulated over these past many years a number of ideas and concepts about turn-based online gaming. We think it would be useful to share them. We do not claim to have the truth - maybe some of the following points are really specific to Ticket to Ride - but we tried many different things, and experienced what worked and what did not for us. We also applied and fine-tuned some of these concepts on other games, such as Small World 2 and Memoir ‘44 Online, and learned even more.

The Ticket to Ride online community has always been very active: after 10+ years, there is still a new online game created every 4 to 6 seconds, 24 hours a day. This allowed us to build solid data to backup the concepts described here.

Definitions of Main Concepts

Sorry to start with a list of vocabulary, but this is important.

Turn-based Gaming (as opposed to Simultaneous Gaming)

It is important to understand that the Scalable Server implements Turn-based Gaming. This means that at any given time, there is one (and only one) user playing. This is tightly related to where the “Game State” data are located and which client “owns” these data. As explained in the Scalable Server documentation, there is no notion of “game host” (a client who would have the special role of collecting and controlling all the game data). Instead, the game data are passed from one client to the other by the Scalable Server. At any given time, there is only one client allowed to change the data and to send them back to the server.

This is very similar to some other online gaming services such as Apple Game Center or Google Play.

Note that if you still need to allow players to do things simultaneously in a synchronous game (like the players choosing their tickets at the beginning of a Ticket to Ride game), it is possible using the in-game broadcast messaging system provided by the Scalable Server. So there are workarounds, but you will have to be careful about data consistency. And besides, there are traps in terms of gameplay (see the note about Real Time gaming and Interruptions below).

Asynchronous vs. Synchronous Gaming

This topic is always a subject of hot debates during the game design phase. It boils down to the question: “what happens when a player disconnects?”. There are several possibilities:

  • The game is paused. Other players can also leave the game - even quit the app. They will receive a notification when it’s their turn to play and will be able to resume the game, see what the previous players did, and play their turn. This is Asynchronous Gaming.

  • The game continues. If it’s the turn of the disconnected player to play, after a short time an AI takes over on-the-fly to play for her (this is called Bot Hot-Swap), and the game carries on. This is Synchronous Gaming.

In other words, Asynchronous games can be paused and Synchronous ones cannot: all players are expected to remain in the game until its completion.

You will find later on a complete discussion about the various advantages, disadvantages and traps of each option, and how they can be mixed.

Interruptions, Real Time Gaming

There is a difficulty with some game designs: they need to implement interruptions. This is often found in card games: a player is playing during her turn, and the other player interrupts her by playing one of his card, for example to cancel or counter the ongoing action.

This is a very simple concept that works great in the physical world, but is a nightmare to implement in a turn-based online game because of the possible latency between clients. Granted, you could use the broadcasting messaging system to send the interruption message to the playing client, but it might be too late: the player might have already completed her action when the message arrives. So you will have to implement a synchronization / ask-and-wait system that will slow down the game pace and will be noticed by the players (“ho-ho, the game is slowing down, she must have an interruption card in her hand”).

Try to avoid this type of situation. The Scalable Server can handle interruptions turns, and simultaneous turns. Keep in mind, though, that we are not dealing with purely Real Time Gaming.

Player Clock

In our opinion, the notion of Player Clock is key for a successful implementation of a turn-based game, especially to prevent abuses. It is a fixed amount of time that is allocated to each player at the very beginning of a game for the entire game. For example, 10 minutes for a Synchronous game. Or several days for an Asynchronous game. Think of it as a Chess clock. The Player Clock ticks when it’s her turn to play - whether she is connected or not - and stops when she is done with her turn.

When a player runs out of Player Clock time, a Bot Hot-Swap will happen and the game will continue for the other players. This guarantees that a game will be finished in a preset delay, and prevents abusive players from ruining a game by not playing because they are in a bad situation.

Time Out, Turn Clock

A Time Out is something different from the Player Clock. It is a fixed amount of time allocated for a specific action, which can be a player action or a technical one. For example, rolling a dice or opening a TCP/IP connection.

A Turn Clock is an example of a Time Out: it is a limited amount of time (say, 30 secs) to play a turn. As you will see below, we strongly advise against using a Turn Clock. It is the wrong solution to a difficult problem. Even though it is often a solution suggested by developers, it actually creates a lot of problems, and is more difficult to implement than using a Player Clock - which is a service provided by the platform. More details later in this document.

Disconnecting (accidentally)

A disconnection happens when the player loses the network and is disconnected from the game servers. TCP/IP tries to maintain the connection, but it will gave up after a timeout time. This is why such a disconnection is often described as a “timeout”. The app will have to re-open the connection if this happens (see “Resuming” below).

Forfeiting

A player can decide to definitely leave a game, in which case she Forfeits. Once forfeited, the player is replaced by a robot, and her Karma and ranking is affected (it is considered as losing the game). (Karma is explained below).

Leaving

A player can leave voluntarily an ongoing game, for example to move to another app (or get a phone call), or to switch to another (asynchronous) game in which it’s her turn to play. If the ongoing game was a synchronous one, a bot hot-swap will occur after a short delay, otherwise the game will be paused when her turn comes up.

Resuming

When a player is disconnected from a Synchronous game, she should still be able to jump back into the game and replace the Bot who’s been playing for her since she left. This is called Resuming a game. This term really applies to synchronous games, since going out and back in of asynchronous games is considered a natural feature of that other mode.

Abusive Behaviors

Fighting againt Abusive Behaviors is an important aspect of online gaming. Unfortunately, not everyone behaves in a fair-play manner, even if we should say that we are very lucky in the board game community: most of the time, people play very nicely.

  • Rage Quit happens when a player leaves a game because the situation is turning bad for her.
  • Dragging happens when a player plays very slowly to wear out the other players and make them leave the game. The Player Clock is a good tool against this abusive behavior.
  • Flooding, Harassing, Trolling, Insulting, etc. happens when a player uses the in-game chat to bother the other players and spoil their gaming experience. Here again, the intent is usually to drive the other players away, in order to win the game.

The Lobby

The Lobby is a place in the app where players meet in preparation of online games. Typically, a Lobby provides the following features:

  • A list of the players who are connected to the Lobby (i.e. they are not playing in a game).
  • A chat area allowing people to exchange public messages.
  • A list of open games, waiting for players to join them.
  • The possibility to create a new open game.

There are other features and details that are described in the Lobby section later in this document, such as Buddies management.

So: Synchronous or Asynchronous Gaming?

True Asynchronous gaming involves implementing a lot of features: list of ongoing games, out-of-band invitations, “it’s your turn” notifications, etc. Make sure you implement them all.

Very often, a first implementation is to start with a synchronous gaming implementation, especially if the game is a fast-paced and short game. Asynchronous gaming is more appropriate for games that have long turns that take a lot of thinking and/or actions (think: chess).

In addition to doing synchronous gaming only, developers often think that managing the Player Clock is too complicated, and that a simple fixed per-turn time-out (say, 30 secs) would be good enough. Our experience shows that this shortcut is not such a good idea: it creates significantly more unfinished games. The first online gaming implementation of Splendor was doing exactly this: synchronous gaming only, 30 secs to play your turn, if you run out of time you lose the game right away (but the game continues for the other players thanks to bot hot-swapping). This led to 12% of unfinished games, which is a high level to generate complains from players. As a point of comparison, the ratio of unfinished games in Ticket to Ride is under 4%.

Besides, in terms of game play, a fixed per-turn time-out is not that efficient to limit the amount of time taken by a game. If a game takes many turns to complete, you can end-up with a long game especially if one of the player is dragging her feet. Consider Ticket to Ride, which takes about 40 to 50 turns to play. If one player waits to the last moment of a 30 secs delay, the game is still going to take at least 25 minutes to complete. A 10 minutes Player Clock works much better.

Developers who still want to do only a synchronous game should consider an intermediate approach: doing a synchronous gameplay using a limited asynchronous implementation and a well chosen Player Clock. Sounds weird? Read on…

About pausing

There is an important factor to consider: pausing. Asynchronous allows you to pause the game. But there are two kind of pauses, which happen for very different purposes:

1) short pauses: this is great if you play on the phone and that you are accidentally interrupted by a call. Or if you have a bad connection because you are in a train. We tell players who are in this case that they should create asynchronous games and use a short Player Clock, just like for a synchronous game.

2) long pauses: this is great for “play by mail”-like games. Each player has plenty of time to play her turn, she gets a “it’s your turn” notification, etc. This is the model proposed by Game Center and Google Games for example. You play your turn and (maybe) leave.

Situation #1 is now the default mode proposed by Ticket to Ride, but with a short Player Clock. We don’t even use the words “synchronous” and “asynchronous” with the user, which are too technical. The default Player Clock is 10 minutes and a “Bot takes over in case of disconnection” check box is in fact the disguised toggle between asynchronous and synchronous modes.

With a short Player Clock, people play naturally quickly and remain connected all the way through. They know they are more likely to lose the game if they leave because they’ll run out of Player Clock time. The asynchronous is just there for accidental disconnections, because in reality, they play synchronously.

So to summarize: if the Player Clock is short and the timer clearly indicated in-game, people will actually behave synchronously even with an asynchronous implementation. This is the recommended solution if you have a fast-paced game, with LOTS of short turns (only one or two fast actions). You really don’t want to go the “play by mail” path in that case, otherwise you are going to completely break down the pace and rhythm of the game, and make it extremely boring, because a complete game will seem very long.

About wording

We found it very difficult to explain to the users the differences between Asynchronous and Synchronous gaming. We tried “Single Session” vs “Multi-Sessions” and gave up on these terms - you will still find them in the technical documentation of the Scalable Server, which is why we are mentioning these here. As noted above, we ended up showing a check box that describes what happens in case of disconnection: whether a bot will take over right away or not.

About hot-swap and resuming: the importance of finishing games

We found that many online games that use Synchronous Gaming terminate the game if one of the players is disconnected. We strongly advise against this, this ruins the gaming experience for every one. You need to allow players to go until the end of their game experience, even in the case of two-player games. You want the winning player to receive the reward of her end-of-game screen. This means implementing a good robot hot-swap feature, and have an AI of good quality, so that the game remains interesting. This also means that you need to implement Resuming, so that the disconnected player can jump back in and resume the game.

Common Misconceptions

After a few years working with 3rd party developers, we realized that there were some concepts that were not understood correctly or that were mixed up.

The case for the Player Clock

Several developers thought that using a Player Clock makes sense only for Asynchronous games. IT’S NOT TRUE. The Player Clock is perfectly suitable for Synchronous games too! This is because the Player Clock has nothing to do with the game mode. The only difference is that the default value for a Synchronous game will be usually shorter than the one for a Asynchronous one, but other than that, the Player Clock is an orthogonal concept to the game mode. Last but not least, it provides a much better user experience than a Turn Clock and is also a better solution against abusive behaviors.

Also, if you are implementing the adaptation of a board game, keep in mind that using a Turn Clock will deeply change the gameplay. So it is definitively not a good idea.

Developers who are limited on time or budget often think that the Turn Clock will be easier and faster to implement than a Player Clock, because this is what they are familiar with. This is definitively not true. The Player Clock is a service that you get for free from the platform. Use it. It’s not the job of your game to re-implement a network time-out system, it’s the server’s job.

The case for Asynchronous games

Several developers thought that using Asynchronous gaming implies implementing a whole set of features and user interfaces to deal with multiple games in parallel, a complicated invitation system, etc. IT’S NOT TRUE. You can absolutely use Asynchronous gaming and still limit your player to one game at a time. It’s in fact quite trivial.

This is a strong argument in favor of the hybrid solution described above, i.e. combining a short Player Clock with Asynchronous gaming to implement a Synchronous-like game experience, but without the drawbacks of Synchronous gaming.

It’s easier than you think

On a regular basis we talk to developers who tell us: “We have limited time and budget, so we’ll do only Synchronous gaming, with a Turn Clock”. Think again. You are taking bad decisions for the bad reasons. And you will end up with more work, an inferior design and and a poor game experience. Challenge your assumptions and use the platform services: they are here to help you!

The Importance of the Lobby

At first, the Lobby is often considered as not important by our development partners when discussing about the first designs of a game. Often, we are told that an auto-match feature will be good enough. This may sound fine for a casual game, but we are strongly against it in the case of a more sophisticated game, especially if the ranking is important in the game experience. Players want to have control about the type of game that they will join or create, so you need to show a list of open games with each game settings, who is already in the game, etc. Allowing people to chat in the Lobby will allow them to organize their games with the right parameters, decide if they want do to a 2 or 3-player game, etc. It helps a lot smoothing the organization of games, especially if traffic is low.

The first version of Small World had only auto-match, and it was a disaster. People would wait without knowing if the game was about to start or not, and just staring at a waiting screen without being abe to do anything - not even talk to each other. When the game started against anonymous players, there was no sense of engagement, so rage quit ratio was quite high: 43% of games were unfinished! When we switched to a Lobby-based system, this ratio dropped to 6%.

The Lobby is also a very powerful tool to build your community of players. Players will meet online and make friends. They will organize online tournaments. It is a very effective tool to enforce players attachment and build the bedrock for an active community. So the Lobby should provide tools to add friends to the user’s Buddy List and other similar social features.

So our message is: make sure you build a Lobby, it’s worth it. Sure you can (should!) have a “Quick Play” button that allows the quick or more casual players to join a game quickly (more on this below), but make sure you also have a full-fledged space for people to meet. Check Ticket to Ride for an example of user interface and features.

The Importance of Critical Mass

A key factor for a successful online game is to always have enough players hanging around in the Lobby so that any arriving player finds easily people to play with. On Ticket to Ride, there is a new game created every 4 to 6 seconds, so you can play right away. Achieving this can be quite challenging for a new game.

The nightmare scenario goes like this: a user would arrive in the Lobby and see no one. He would wait for 10 to 20 seconds, then leave. Too bad, there was someone else coming 10 seconds later. So you could have a player arriving every 30 secs and see absolutely no online games happening…

The good news is that in the world of (physical) board games, you don’t start from nothing. You usually already have a community of board game players, so make sure you have a way to contact them when the online game goes live. Better, try to recruit and engage them during the beta testing period. This way you already have some veterans to help new players when the game goes to production, with a Ranking table filled with people and so on.

Encourage players to recruit or help beginners. For example, give them an Achievement or some points when they play and finish a game with a new player (we had a program called “Band of Brothers” for Memoir ‘44 Online that worked really nicely).

Implementing Asynchronous gaming with an invitation system is also a good solution to jump-start the app. Because “buddies” are stored in the user’s Asmodee.net account, a user can easily find her friends, see if they have the app and send them invitations. Small World gives a good example of this.

Show activity: in the Lobby, show the number of ongoing games and the number of connected players and maybe some time stats - if they are not discouraging, of course (don’t say “there is a new game every 1.2 hours” !). People will be willing to wait a little bit in the Lobby if they realize that there are several games already under way and that some of them will end soon, bringing new players to the Lobby. In Ticket to Ride, we even have an Observe feature in the Lobby that shows ongoing games and allow people to watch them. This has a positive side effect of showing that there is activity.

Organize events (or have the core of the community do it for you), like online tournaments. This is very important. Generally speaking, make sure you have a Community Manager that talks to your community through a forum and also in the Lobby chat. If players see that there is activity, they will come (and come back).

Quick Play (vs. Automatch)

We prefer to use the term Quick Play rather than Automatch because we think it describes better our recommended way of doing things: finding a game quickly - as opposed to matching players.

As explained earlier, the Lobby is very important. There is a list of open games to pick from. The Quick Play feature is simply an automated way to pick the best game inside the Lobby. It hides the complexity of creating a new game - which often has lots of parameters -, and browsing through a long list of games with lots of different settings to figure out. The Quick Play is simply a convenience for the more casual (or beginner) player who wants to play right away.

You want the Quick Play mode to have as few options as possible. In Ticket to Ride, you have the map, the number of players and the ranking toggle - and that’s probably too many already.

Then the app should scan the list of open games and put the player in the game that is the most appropriate. The main criteria is to get games started as quickly as possible, so the app should prefer games that are almost full and put the player in one of them. With some luck, if there was just one missing seat, the player will fill it in and the game will start right away!

If no qualifying game is found, then the app should create one and put the player in it. Make sure you set the game options to popular or recommended settings. For example, create a non-ranked game for a beginner. If you do not let the user choose the number of players in the Quick Play UI, create a game with the number of seats that provides the best experience with your game.

Be careful of not adding too many different options in the Quick Play settings. It is not only a matter of showing something as simple as possible to the user, it also helps finding matching games. For example, if you have a “number of players” option with 4 possible values, and a “Ranked Game” checkbox (2 values), you are already dividing your pool of possible games into 4 x 2 = 8 separate groups. This is already a lot.

So the work for a good Quick Play implementation is on the app side, because only the app knows what works best for the player - it is highly gameplay dependent! Think about the options and the picking strategy carefully, Quick Play is an important feature, especially for beginners.

Fighting Abusive Behaviors

Again, we want to fight against Rage Quit. In real life, you don’t leave the table when you play with friends around a table. We think it should be the same online.

If the very early days of Ticket to Ride, we implemented a little feature called Karma, which surprisingly emerged to be much more effective than expected. This is an automatic system to rate the capacity of players for finishing games. A low Karma value would indicate a player with a bad connection and/or a tendency for bad behavior.

A new player starts at 50 karma points. The maximum score is 100. When you finish a game successfully, you earn 1 Karma point. If you are disconnected and don’t resume the game, or if you forfeit, you lose 5 points as a punishment. The Karma value is then divided into 5 groups, from • to •••••.

We found that people pay a lot of attention to their Karma. To the point that from time to time, we get messages from players who lost 5 Karma points because they were disconnected and could not resume the game for some reasons. We have to tell them that going from 100 to 95 is not the end of the world and that they can simply play 5 more games to regain the stainless reputation.

Ranking is another way to motivate people good and fair-play behavior. A player who forfeits will be considered as a automatically losing the game, and so her ranking will be negatively impacted.

Conclusion

Online Gaming is a complicated and challenging feature if you want to do it the right way. The Scalable Server provides a lot of tools and features to help you doing it properly, but you will still have to think hard about your game design, the game options and your user interface. We recommend you do not take quick-and-easy shortcuts, they often backfire. We will be happy to discuss to this matter with you and share our experience to help you make the best decisions for your app.

Online gaming can be a huge attachment feature for players. In Ticket to Ride, we have a number of players who logged over 50,000 finished ranking games since 2005. One of them in 8 years (=17 games a day every day). Another one played 99,724 games in 8 years: that’s 34 games a day - or 346 days of non-stop playing if you consider that a games takes 5 minutes to play on average! Ticket to Ride is important in the life of some of our awesome players.