The list below is not complete, but may help you quickly come to terms with much of the confusing and conflicting jargon that is in use. Terms that DemonWare has standardized on are marked with the text "[DW]".

Client/Server [DW]
This refers to a particular configuration of a computer system, in which one component has the responsibility of driving the logic. In games, client/server is a popular configuration, especially for multiplayer first-person shooters. For more details on this, see the game networking overview.

Peer-to-Peer [DW]
This refers to another configuration of a computer system in which components communicate directly with each other, often without any coordination. In games, this is a very popular network topology. For more information see the game networking overview.

Game server [DW]
In a client/server game, this is the game instance that communicates game state to each client. Care should be taken to distinguish between a "server" that is a physical machine, and a "server" that is a program (a game server is a program). It is easy to confuse different uses of the word, e.g., some people use it to refer to a matchmaking server. "Server" is sometimes also used when talking about peer-to-peer games, but "host" is a more common term in this context.

Host [DW]
A host is normally used to refer to a particular peer in a peer-to-peer game, which maintains session-related information. Normally, the peer that starts the session becomes the
host. Some people use this term interchangably with "server".

Host Migration [DW]
This refers to a technique of quickly appointing an existing peer as the new host, in the event of the old host disconnecting from a peer-to-peer session. This is possible in peer-to-peer because all peers (even the host) have exactly the same state.
It is possible to perform a similar technique in client/server, however this is more properly referred to as server migration. It is more difficult to migrate a server because no client has a completely up-to-date state.

User Commands [DW]
Sometimes just called "player input", this refers to data that describes the state of the input device being used by a player. For example, a user command may represent which buttons have been pressed on the player's gamepad or keyboard. The primary purpose of a user command is that it can be sent across the network. For example, in a client/server game, clients send user commands to the server. In a peer-to-peer game, peers send user commands to each other.

Game State [DW]
Game state refers to the various data that represents game entities. The next state of a game is generally computed by applying user commands and game logic to the current game state. In client/server games, the server usually sends an game state to the clients.

Avatar [DW]
An avatar is the entity in a game that a player controls. Some games, such as puzzle games and RTS games, do not have any particular avatars. In games that do, it may take the form of a human character, a vehicle, or any other entity distinguishable from the game world. Games that have avatars tend to be suitable for algorithms such as client-side prediction and selective updating.

Latency [DW]
Latency, sometimes called "lag" refers to the delay between a piece of data being sent on a network, and that piece of data being received. Latency may be affected by various algorithms
that act on the data in order to get it to its destination. For example, if a piece of data is lost on the network, it will eventually be retransmitted after a certain amount of time. From the receiver's point of view, this amount of time increases the latency. From the point of view of a piece of code in a computer game, latency may also be increased by the rate at which the game loop runs. For example, if a game runs at 30 Hz, it can only send and receive data at intervals of one thirtieth of a second. This may add up to a total of an extra 60 milliseconds latency from the point of view of the sending and receiving code.

Quantization Error
This is sometimes called "sampling error". For bandwidth conservation purposes, it is common practice to reduce the precision with which you send data values. For example, you may represent the avatar's camera angles with 8-bit values instead of with 32-bit values. The quantization error present in a value is the difference between its original value and its value after it has been quantized to a lower precision value.
The term "Quantization Error" is sometimes used to mean the same thing as integration error, which may be valid from the point of view of a hypothetically continuous game state being sampled at discrete intervals, however, for clarity this definition is avoided in DemonWare.

Integration Error [DW]
Simulation-based games generally calculate entity state in conjunction with some physics code. This may be as simple as calculating an object's new position based on its velocity, or may be as complex as a full vehicle representation in a specialized engine, such as Havok. In either case, the calculation can be viewed as a numerical integration method. For example, you may integrate an object's velocity over time to find it's new position, i.e.,
Unfortunately, the results of these kinds of methods may diverge depending on the granularity at which you run them. If you simulate two initially identical physics objects at 10 Hz and at 20 Hz, they will end up in different states. This is true for any object whose physics is of higher than order(1) with respect to simulation time. For example, if we added acceleration to the object that previously had a constant velocity, we will cause integration error. In generation, higher order physics leads to a greater amount of integration error. Integration error always exists in comparision to the hypothetical "real" state, which would have to be calculated with infinitely small granularity. It is only problematic in games where the discrepancy may be noticed. Games in which different computers simulate at different rates (e.g., PC games) are an example.

Delta Compression [DW]
Delta compression is a technique that can be applied to network data to reduce it in size. It works by sending only changes in game state, rather than the full game state. This capitalizes on an understanding of the data to produce effective compression with next-to-no CPU overhead. However it requires that a baseline state can be agreed to send deltas with respect to. Due to network latencies and timeliness constraints, this means that delta compression constitutes a trade-off between bandwidth and memory (for storing previous full-states as potential baselines). Although this results in a complicated system, and can be tricky to operate in conjunction with other optimization algorithms, it remains a key technique for efficient use of bandwidth.

Client-Side Prediction [DW]
Sometimes just called "prediction", this technique allows a player's computer to predict game events in an attempt to minimize the effects of network latency. It is normally used in the context of client/server game, in which it refers to clients that optimistically predict the server's response to user commands. This mostly eliminates latency that would otherwise be perceptible to the player. When predicting an object (such as the player's own avatar) the client mimics the operations that the server performs when it receives client commands. This might include the application of user commands to the predicted objects, and stepping the simulation forward in time. When the player eventually receives an update about its avatar from the server, it must merge the update with its own predicted view of the world. Under the best case scenario, the client and server predictions will always be subject to divergence, due at the very least to integration error, introduced by their differing simulation rates. Prediction is further complicated because the predicted entities are simulated into the future with respect to game time (i.e. server time), and that when updates are received from the server, they describe state with respect to some time in the past. Prediction is usually a necessary technique in a real-time game, however its implementation interacts with many other netcode features, and a great deal of testing is generally necessary to verify that the implementation will work under real network conditions, and deliver the best results possible. Prediction can also be performed in peer-to-peer games, in which event each player's computer predicts their own avatar beyond the official agreed state of the game.

Interpolation [DW]
This is sometimes referred to as "smoothing" or "blending". It is a technique that enables players that are updated at discrete intervals about each other's state to render the transition smoothly. In games where player movement is due mainly to player input as opposed to the passing of time (e.g., player movement in an FPS), interpolation is often used as the primary method by which to move avatars. In this case, the each avatar is interpolated towards a target state over the average update interval. This requires very regular updates, and results in interpolated entities being rendered one update cycle in the past. However, interpolation produces a correct (if slightly old) rendering of highly unpredictable entity movement. Interpolation also has an important role to play when applying updates to extrapolated entities. Small errors are inevitable (due to integration error), and interpolation algorithms can be re-used to perform a blending of the two states, avoiding perceptible state “snaps”.

Selective Updating [DW]
Most 3D games implement either Level-of-Detail or BSP algorithm (or both) to improve the performance of the renderer. Where possible, these algorithms should be re-used to improve networking performance. For example, a Level-of-Detail algorithm could be used to reduce the frequency of updates about distant entities, or entities that are not of great interest. Similarly a space-partitioning algorithm could be used to avoid sending update about entities that are neither visible nor audible. Such algorithms significantly increase network scalability and efficiency, however they complicate the implementation of delta compression, because they result in different base-line states from which any deltas must be calculated.

[back to top]