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.