Table of Contents
This section explains general concepts and issues relevant to the design.
There are four main locations for the active data of an object:
-
Associated with the cell part of an entity.
-
Associated with the base part of an entity.
-
In the persistent world database.
-
On the client.
Data associated with an entity on a cell can be categorised as:
-
Internal data
Used and stored only on the cell in which it lives.
-
Server (or ghosted) data
Available to other entities on the server.
-
Client data
Available to (at least some) client machines.
From the client's perspective, there are conceptually four types of action:
-
Server action
This is an unsolicited action that comes from the server, and is not generated by this client.
For example, another avatar jumping.
-
Local action
This is an action that only occurs locally on the client, and does not need to be communicated to the server or other clients.
For example, special effects like particles bouncing or a flame slightly flaring.
-
Undoable action
This is an action that the client takes immediately, under the assumption that it is correct, and then communicates to the server. The server has the ability to disallow the action and make the client rollback the action.
For example, the client stepping forward.
-
Server-confirmed action
This is an action that needs to receive confirmation from the server to be performed on the client.
For example, the player wanting to shake hands with another player. Another example may be hitting a player (and thinking that it is dead) but not showing this until the server has confirmed it (this has some similarity to the Server action, except that the origin of the action was from this client).
The game designer needs to hide the latency from the player using as many latency-hiding tricks as possible. There are two main sources of latency:
-
Internet latency
All information that travels between clients goes via the server, and so must have two trips on the Internet.
-
Server latency
This is the time between information being received by the server, processing it, and responding back to the client. In an MMOG environment with large numbers of players, bandwidth is a precious resource, so not all new information can be sent out immediately. In BigWorld, the Priority Queue manages this.
The Priority Queue can be tuned to reduce the latency on critical information caused by the server. This does not affect the Internet latency, though.
Latency can also be introduced on the client side. This can occur if the developer allows a delay between receiving data and sending it to the server, or between receiving data and displaying it.
The game world is made up of multiple spaces. Each space is a continuous Euclidean region, spanned by a single coordinate system.
Spaces may be always present, or be dynamically created to enable a group of one or more players to adventure in isolation from other players. There may be many instances of a given space running the same geometry simultaneously and independently.
Visualisation of spaces and division in cells (cell boundaries marked in dotted lines)
The space is a logical concept, dealt with in game script.
Cells exist at a more physical level. They divide large game spaces geometrically, for the purpose of load balancing across multiple CellApps.
A large space divided into cells
For a small space, a single cell is enough to cover it.
A small space covered by only one cell
BigWorld uses a left-hand coordinate system. The x-axis points "left", the y-axis points "up" and the z-axis points "forward".
yaw is rotation around the y-axis. Positive is to the right, negative is to the left.
pitch is rotation around the x-axis. Positive is nose pointing down, negative is nose pointing up.
roll is rotation around the z-axis. Positive is to the left, negative is to the right.