Tuesday, April 5, 2016

Video Game Design: Play Scheduling

When taking about video game design, there are two kind of scheduling.  The kind of scheduling discussed in this article is when players can act.  In other words, we are taking about how turns work.

There are four kinds of play scheduling that have been used in video games.  The first is turns.  A video game that uses turns is called a "turn-based" game.  The second kind of play scheduling is "simultaneous mode."  This is like turn based scheduling, but players give their orders, and once everyone has finished, all the actions occur simultaneously.  I know of only one game that uses this kind of scheduling, and it is optional in that game.  That game is an old DOS ballistic tank game called Scorched Earth (this may also be used in at least one of the Civilization games).  The third kind of play scheduling is real-time.  In real-time games, the game action is continuous.  Everyone can doing things at the same time, and the game does not wait for anyone to take an action.  The last type of scheduling is asynchronous scheduling, which is more popular in web based games.  In asynchronous games, when a player interacts with another player, the second player's part of the interaction is handled by the computer.  Otherwise, the asynchronous games are similar to real-time.

Turn-based

Turn-based scheduling is the single most popular scheduling method for games.  A vast majority of tabletop games use turn-based scheduling.  Many older video games use turn-based scheduling, and even some new ones use it.

The advantage with turn-based scheduling is that everyone has time to think about their decisions.  The game is not always won by the player that can react the fastest.  Turn-based scheduling gives the players time to think before they act, and it does not discriminate against people that need more time to consider their options.

The disadvantage with turn-based scheduling is that it can make the game go slowly.  One slow player can waste the time of everyone else.  When there are more than two players, everyone ends up spending most of their time waiting for other players to complete their turns.  In face-to-face games, players who are waiting can at least interact with each other.  In video games though, this can make the game feel impersonal, and it can make games feel like they are dragging on.  In addition, if one player needs a bathroom break, walks away to make a sandwich, or even has a serious medical issue, other players may not know, and they may end up wasting a lot of time waiting for an inconsiderate player or even for a player that is no longer able to play.  The market for turn-based multiplayer video games is not very big as a result of this.

Simultaneous Mode

Simultaneous mode is a name given to this scheduling method by the old DOS game Scorched Earth.  In the game, this was an optional scheduling method that could be selected instead of turn-based.  Players would take turns lining up their shots and firing, but the shots would not actually be fired until the last person had finished.  Once everyone had taken their turn to setup their shots, all of the tanks would fire at the same time.  This altered the strategy of the game a bit, because a shot that hit a specific tank before another could change the position of that tank, causing the second shot to miss.

Taking turns giving orders is not an essential part of this scheduling method.  This was the result of the limitations of having multiple players using the same input devices.  With simultaneous mode, all players can issue their commands at the same time, if the user interface permits it.  The important part is that all commands are queued until everyone is done issuing commands.  Once everyone is finished, the commands are carried out at the same time.

The biggest advantage with simultaneous mode is that no one has an advantage from going first or a disadvantage from going last.  If players are using different input devices (such as playing over a network), the strategy of the game also changes, because no one knows what commands anyone else has issued until they are executed.  Simultaneous mode is more realistic that turn-based, though it is important to keep in mind that realism is less important than making a game fun.

The disadvantage of simultaneous mode is that it can be technically difficult.  Some games may have situations arise where two players issue commands that ultimately cause some kind of clash.  The game designer or developer has to decide how to handle these cases.  Also, while simultaneous mode can reduce the downtime of players waiting for each other, when done over multiple input devices (like networked computers), everyone else may still end up having to wait for a slow player to finish issuing orders.

Real-time

Real-time scheduling is currently one of the most popular scheduling methods for video games.  With real-time scheduling, there are no turns.  The game advances at a set rate, and players interact dynamically as needed.  If the game does not get any input from a player at a specific time, the game continues to progress, assuming that the player did not want to change anything.

Real-time video games can be easier to design and develop than turn-based video games.  Real-time games lend themselves to mathematical sets of rules that always apply equally (like physics).  Turn-based games tend to encourage context based rules that require a lot of custom coding of game elements (Chess is a good example).  Real-time games reward quick decision making, and they often reward good micromanagement as well.  In a real-time game, no one has to wait for anyone else to provide input.  The games are generally fast paced, and filled with action.  Real-time games are popular because they don't give the players time to get bored.

Real-time games often reward quick decision making and micromanagement more than good strategy.  Statistics show that people who issue commands more frequently tend to do better in real-time games than people who have good strategy.  Real-time games can be limited by the performance of the computer they are being played on.  The constant action without much time to think can be very challenging for new players, and casual gamers tend to prefer turn based games that can be played at a more leisurely pace.  Also, real-time games typically require significantly more animation than other scheduling methods, which can be a burden on graphics budget and development time.

Asynchronous

You won't see this scheduling method discussed a lot, but it is quite popular in browser based multiplayer games.  Asynchronous games generally have some real-time elements, but they handle interaction in a one-sided way.  These games may handle things like building, movement, and resource generation the same way a real-time game would, but when players interact with each other, half of the interaction is handled by the computer, not by the player.  Good examples are combat and trading.  In an asynchronous game, when a player attacks another player, the attacking player controls the combat.  The computer will handle the defending player, generally based on skills, stats, and equipment.  Trading never happens directly in an asynchronous game.  One player will put up goods for sale somewhere, and another player will eventually come and buy the goods.  Interaction occurs whenever one player interacts with another, but the first player controls the interaction, and the second player's part is played by the computer.

The biggest benefit of this scheduling method is that player interaction can occur fairly even when  one player is not present.  It is used commonly in browser based games, because of this.  HTTP is not conducive to direct interaction between people.  In non-game contexts, interaction usually works as informal turns (turns are taken, but there are no rule about order of turns), where one person says or does something, and then someone else (or even the same person) responds.  In settings where fairness is not defined by whether or not everyone has equal chance (email, forums...), this works well.  In games though, equal chance is important.  In a video game though, it is unreasonable to wait for everyone to take their turn when you have hundreds or thousands of players.  Real-time could solve this, except that HTTP does not allow the server to push data to the client.  The client has to ask before the server can send.  This means that the game has to ask for update many times per second, or the client will always display obsolete state data.  Asynchronous games handle this by making the game work more like internet forums.  Players can act when they have time, without needing anyone else to be present in the game.  Fairness is enforced by making all player-to-player interaction asynchronous whether both players are present or not.

The problem with asynchronous scheduling is that it can give one side a disadvantage in some situations.  For example, in combat, an attacking player might be able to attack and retreat at will, allowing him or her to attack, retreat, heal, reload, and then attack again, while the defending player is not present.  This could allow a weaker player to defeat a stronger one, while the stronger player is using the bathroom or away from the game entirely.  One way to mitigate this is to have safe, non-combat zones that players can hide in when they are away.  Some games make player characters disappear when they are logged out to avoid this problem.  Some give players the ability to opt out of PVP.  What is important is that something is done to prevent this.  Another cost is that even with an asynchronous schedule, your client may still need to request updates from the server periodically, because there are still processes that are happening in real-time.


Scheduling often depends on technical limitations.  A game for slower computers (mobile devices, for example) may need to be turn-based or simultaneous mode just to run well on the device.  A networked game using a stateless pull based connection (HTTP) may have to be asynchronous, because the technical limitations would make the game unplayable otherwise (now days, most browsers support websockets, which are two-way push based communication, which allows for real-time games in the browser).  It also depends on the style of game and your target audience.  Players that like constant action will likely not be very interested in anything that is not real-time.  Casual players may prefer anything but real-time.  Desired design and development speed may also play a role.  Turn-based and simultaneous mode games can be more technically challenging than asynchronous or real-time games, while asynchronous and real-time games may be more difficult to debug.  A major factor in choice of scheduling model should also be how you want the game to feel.  A real-time game will feel more immersive.  A turn-based game will often feel more casual.  An asynchronous game can feel like it is limiting the control the player has over his or her own character, but it may also feel like a balance of immersive and casual.  Even the number of players can have an impact on this decision.  Turn-based and asynchronous lose most of their downsides when used with a single player game.

Scheduling is not something to be taken lightly.  It can have a significant impact on the quality of your game.  Scheduling is often predetermined based on the technical limitations of the platform the game will run on, but when you do have a choice, choose carefully.

No comments:

Post a Comment