Multi-player Consistency in Physics Games

Matt Fritz December 15, 2011

Table of Contents
Part I Initial Analysis................................................................. Part II Mitigation....................................................................... One-to-Many............................................................................ One-to-Many-to-One............................................................... One-to-One.............................................................................. Part III Requirements................................................................ One-to-One Solution............................................................... Part IV Conclusion.................................................................... 2 3 3 4 5 7 8 9

Fritz - 1

Part I - Initial Analysis

Problem
Devise a way for an arbitrary number of players to work together toward a single goal in a physics-based game. The typical physics-based game involves situations in which a single player uses projectiles to destroy a structure or earn an item.

Considerations
Multi-player functionality in physics-based games shares a common tie to other types of games that allow an arbitrary number of players to function at once in the same context. Any multi-player game that is converted from a typical single-player game has the same primary issue: how does one go about implementing a reliable way for several players to interact with each other within the same game world? However, physics-based games also pose a special problem that the other types of games do not have to consider. Most physics functionality libraries that are both efficient and realistic are nondeterministic. Non-determinism means absolutely nothing to the player since it adds that fun factor of randomization and a let's see if this works style of game-play; for the end-user, as long as the responses to impulses seem about right, everything is fine. Unfortunately, this same factor creates a huge problem for the game developer. To the programmer, non-determinism means that there are several different possible outcomes for a given physics interaction at any time step in the game world; just because a block fell to the left when it hit a pyramid has no bearing on whether it will fall to the left again the next time this interaction takes place. Non-determinism, therefore, can have a detrimental effect on consistency when taking into account an arbitrary number of players using different physical machines to cooperate in a single game level. In short, a physics interaction on one screen for one player may not produce the same result on any of the other screens despite it being the exact same interaction (i.e. consistency problems).

Mitigation
We'll look at three different methods of mitigating the effects of non-determinism and creating a consistent multi-player experience: One-to-many screen-player relationship One-to-many-to-one screen-player relationship One-to-one screen-player relationship

Fritz - 2

Part II Mitigation: One-to-Many

Overview
A one-to-many screen-player relationship is the archetypal multi-player mode. This method of turn-based trading-off of the game was the first method devised before real multi-player mode with several controllers or other input devices was built directly into a game. Why does this method still persist to this day even though actual multi-player modes exist? It exists for one simple reason: it's fun and there is a greater sense of cooperation when everyone working towards the same goal is in the same room huddled around the same screen. Advantages Only one screen is required for cooperation Only one copy/installation of the game is required Each physics interaction only needs to happen on one screen, meaning that there will still be consistency without any additional work Greater sense of cooperation among the players

Disadvantages Only players that are physically close in distance or can otherwise meet in the same physical location can cooperate this way The players themselves must enforce the turns and keep track of the trading-off of control themselves; this can lead to problems down the line

Typical Gameplay
Let's devise a typical gameplay situation involving three players huddled around a single screen with a single input device/controller: 1) Player 1 begins and takes his turn, destroying part of the structure. He then passes the input device to Player 2. 2) Player 2 takes his turn, destroying the remaining portion of the structure. He then passes the input device to Player 3. 3) Player 3 takes his turn, earning the level's special item and completing the level. Had he missed earning the special item, he would have passed the input device back to Player 1 so he could try. All players are looking at a single screen and only a single copy of the game is running so the effects of non-determinism do not matter. Consistency only needs to take place on a single screen even though multiple players are participating. The above turn-based sequence continues until the level is complete, theoretically enabling all players to participate in the action.

Fritz - 3

Part II Mitigation: One-to-Many-to-One

Overview
A one-to-many-to-one screen-player relationship works on a similar concept as the one-to-many relationship but there is one difference in the initial set-up. Instead of players passing around a single input device so each one can have a turn one-after-the-other, each player has his own input device that is his exclusively. The players still only use a single display screen to view the game, however. Advantages Only one display screen is required and shared by all players Only one copy/installation of the game is required Every physics interaction again only happens on one screen High sense of cooperation among the players The game decides when trade-offs will occur regarding players taking turns to promote objective fairness as opposed to the players making the decision amongst themselves

Disadvantages Only players that are physically close in proximity can cooperate during the game Each player having control over his own input device can lead to the come on already mentality if one player is taking too long; having physical possession of the game's controller can create higher levels of anticipation that impact the experience negatively

Typical Gameplay
Let's now look at a situation with three players huddled around a single screen but who all have physical possession of their own input devices: 1) The game begins by locking all three players' input devices and then unlocks the first one 2) Player 1 begins and destroys part of the structure. The game then locks his input device. 3) The game transfers control to Player 2 and unlocks his device. He takes his turn and destroys the rest of the structure. The game then locks his device. 4) The game transfers control to Player 3 and unlocks his device. He takes his turn and earns the special item to complete the level. If he misses instead, his input device is then locked and the game transfers control back to Player 1 and unlocks his device so he can have a chance. The turn trade-off loop then continues until the level is completed. As with the one-to-many relationship, all players are looking at the same display screen and only one copy of the game is running so all physics interactions take place within the same instance of the program. Consistency is again enforced since there are multiple players but only one instance of the game that is ever manipulated so only one display needs to be updated.

Fritz - 4

Part II Mitigation: One-to-One

Overview
A one-to-one screen-player relationship is the typical set-up for modern networked multi-player games. This method does not require cooperating players to be in the same physical location and offers different possibilities in terms of achieving a level goal. However, more care needs to be taken with a one-to-one relationship than a one-to-many relationship. Advantages Resolves physical proximity limitations; players across the country can cooperate now Each player has his own screen to himself so he can look at any part of the level he chooses during his turn The game decides when turn trade-offs will occur in order to promote objective fairness

Disadvantages Each player must have his own separate copy/installation of the game Similarly to one-to-many-to-one, each player has possession of his own input device so the potential for the come on already anticipation mentality to occur is high especially since players are not collocated and they can't see each other The same physics interaction is occurring on multiple screens and multiple copies of the game, making non-determinism have a potentially significant and inconsistent effect on gameplay

Typical Gameplay
Let's consider a situation with three remote players all cooperating on a single level from their own machines: 1) The game begins by locking all three players' input devices and then unlocks the first one 2) Player 1 begins and destroys part of the structure. The game then locks his input device. 3) The game transfers control to Player 2 and unlocks his device. He takes his turn and destroys the rest of the structure. The game then locks his device. 4) The game transfers control to Player 3 and unlocks his device. He takes his turn and earns the special item to complete the level. If he misses instead, his input device is then locked and the game transfers control back to Player 1 and unlocks his device so he can have a chance. The turn trade-off loop then continues until the level is completed. The above sequence should look exactly the same as the one-to-many-to-one gameplay sequence on a generalized level. However, there are significant low-level differences when the notion of remote players is recognized. In addition to providing turn trade-offs, the game must also communicate to all remote players the current state of the level before a player's turn begins. Special Fritz - 5

consideration must now be taken to make sure non-determinism does not impact the game by providing inconsistent turn results among players. For example, during the first turn Player 1 and Player 3 might see 40% of the structure destroyed while Player 2 sees only 30% of the structure destroyed because of the way the physics interaction was evaluated in his instance of the game on his screen. When Player 2 goes to take his turn, he would see a different initial state than the other two players. Therefore, he could potentially be shooting at a target that exists on his screen but his turn would look like a complete miss on the screens of the other two players. For consistency in a one-to-one relationship, we can implement one of the following algorithms below. Greedy Consistency This can also be called the lenient or the don't-be-a-dick algorithm. In general, it examines the current state of the level for all players at the end of any player's turn. After examining all states, it chooses the one that moves the players the closest to their goal (such as highest overall destruction, items earned, points earned, etc.) Once it picks one, it reports that best state to all players before the next turn begins so the next player is working with the same state that everyone now sees. This is the algorithm to implement for an easier overall level difficulty. Strict Consistency This can also be called the old-school or the total-dick algorithm. In general, it examines the current state of the level for all players at the end of any player's turn. From there, it chooses the one that puts the players furthest away from their goal (such as lowest overall destruction, least items earned, least points earned, etc.) Once it picks one, it reports that worst state to all players before the next turn begins so the next player is working with the same state that everyone now sees. This is the algorithm to implement for a harder overall level difficulty.

Fritz - 6

Part III Requirements

Overview
In order to resolve the problem of consistency and still have a fun gameplay experience we have the three mitigation set-ups as previously described. The first two techniques both require physical proximity for the cooperating players but are the easiest to implement since non-determinism doesn't have a noticeable effect on progress when there is only one instance of the game running. In essence, the effect of inconsistency for multiple players is already mitigated. Each player will always see the same thing since they are all looking at the same physical screen in the same room. The third technique does not require physical proximity but allows for the greatest variety in players since anyone in the world can cooperate with anyone else. Unfortunately, the trade-off here is a higher level of difficulty in keeping consistency among physics interactions for multiple remote instances of the game running at the same time.

Decision
Because anything worth doing is rarely simple, we want to go with the third option (one-to-one) to have the largest possible variety of players with the least emphasis on physical proximity. Our set of remote multi-player users to choose from can be nearly infinite, leading to a huge number of possible combinations, meaning that we now have to come up with a set of requirements to keep gameplay consistent for any given set of cooperating players.

Fritz - 7

Part III Requirements: One-to-One Solution

Below is a small general set of tangible requirements (system functionality) and non-tangible requirements (high-level system characteristics) that should be implemented when providing a one-toone multi-player solution.

Tangible Requirements
The system must... report the current state of the level to every player prior to the beginning of any player's turn ensure that all players are seeing the same level state when a player begins to manipulate it lock the input device of any player who is not currently taking a turn unlock a player's input device when it is his turn figure out the next player that should take a turn when the previous turn has been completed provide visual notification to a player when it is his turn allow a player to look at any part of the level when it is his turn recognize when a level has been completed and report the completion to all players so the next level can be loaded

Non-tangible Requirements
The system should... communicate data among remote players reliably ensure fairness in the way turns are taken among players provide a consistent experience for all players not take away from the overall game experience

Fritz - 8

Part IV Conclusion
Final Thoughts
As fun as single-player physics-based games are, adding multi-player functionality to them can open up an entirely new set of problems. It is for this reason that we have considered three different player set-ups and the different techniques used to mitigate the negative effects of non-determinism in physics engines. For small games that are not meant to be played around the world, either a one-tomany or a one-to-many-to-one relationship would suffice since it would allow for a small group of players in a single physical location. However, for a game that is meant to have a large user-base the one-to-one relationship would be the best choice since it completely removes the limit of physical proximity for players to cooperate. The techniques and set-ups discussed here are of course not representative of the entire problem domain but rather just a small subset since we are merely focusing on fixing issues brought about by physics inconsistencies. Other aspects within the domain such as implementation of reliable communications or force/impulse calculations are important but are outside the scope of the initial high-level problem description.

Fritz - 9