This project intends to be a review of both current and new models
used in video games for speculative evaluation of data across a
network. Many video games are real-time games. This means users must
make decisions about how to progress in the game in real time. For
instance, chess is not a real time game - moves may be chosen at any
time from any given board state. However, a game such as Quake or
Unreal Tournament requires the user to make split-second decisions
based upon the current state of the game. These games also differ
from games such as chess in that any subset of players in the game may
make a move at any time (unlike chess in which there are only two
players, only one of which may make the next decision).
Allowing for multiplayer gaming can be a large problem for such a
game. Both Quake and Unreal Tournament use a client-server based
model to handle multiplayer games. Quake clients send information
about the position of the player, as well as other interactions caused
by the user (such as firing a weapon). For security reasons, the
amount of information trusted to a client is kept to a minimum.
Otherwise, cheating would become easier.
If Quake was to use a traditional model, the state of other clients in
the game would not be updated until information was received from
other nodes by the server, and then propagated to other clients in the
game. For this to be effective, latency between the two connections
must be very low. However, that is not the case for the most part.
To mitigate the effects of latency, video games use speculative state
to predict the effects other players may have on the state of the
game. Once the true change in state of the other players (and any
effects such changes may have) is determined, the client changes its
current state as well.
Note that in Quake, the server is said to be the 'correct' state. For
instance, should two players run for the same item, speculative state
in each of the clients may say that both of them got to the item
first. The server arbitrates such contention and may overrule a
client's decision.
This project seeks to characterize the error generated by such a
model. Each game state can be classified as either speculative or
non-speculative. Non-speculative game state is said to be the correct
state of the game at a particular point in time. We assume that, for
each point in time, there is a correct state of the game. Speculative
game state may or may not be equivalent to the correct state. For
each discrete element of the speculative game state (i.e. position,
velocity, etc.), we can define an error between the speculative and
non-speculative versions. This error can be summed (or
weighted-summed) to produce an overall error. This is the error we
seek to characterize.
Usually, the client has approximately 16 milliseconds to do whatever
it likes between frames the user sees. This results in a framerate of
60fps. This 16 ms includes the time needed for rendering, simulation,
measuring user input, as well as processing audio and video elements.
Hence, we can clearly denote that the speculative model that the
client employs can not be very detailed. For instance, a simple
linear model with history may be used. The server on the other hand,
can implement a much more detailed model than the client - it must
only organize data connections and arbitrate contention among
resources in the game.
Beyond characterizing error produced by previous speculative models,
we seek to create a better speculative model in which the server
proactively uses latency information to make its own prediction about
the state of a game on a particular client. Since this prediction is
better than the one the client will create, the client can use the
state to recalculate its current state.