Threads

Analytical Perspectives in Game Design
Threads
[ Home ] [ Up ] [ Architecture ] [ Commands ] [ Communication ] [ Lag ] [ Object Model ] [ Persistence ] [ Scenarios ] [ Source Code ] [ Threads ]

Threads are used through out the game to allow for parallel processing of commands.

Summary of all the threads.

Thread	Priority	Type	Purpose
User Interface Processor	MAXPRIORITY	normal	This is the thread that runs the user interface.
GameCore	NORMALPRIORITY	normal	This is the thread that handles the thing processing.
DataLoad(0)	(MAXPRIORITY + NORMALPRIORITY) /2	daemon	DataLoad(0) is a data load for the current user context.
DataLoad(>0)	NORMALPRIORITY - Data Load Number + 1	daemon	DataLoad(>0) is a data load for contexts that are removed from the current context by the number indicated. The user would have to execute the number of steps indicated to reach the context.

Reasons for threads and contention control.

There are a couple of reasons why threads and the associated contention control mechanisms are used.

Threads are used to allow sections of the program to work in parallel. This allows better responsiveness to the user by allowing things to happen in the background. The main benefit here is the data loading can occur in parallel for multiple files and pre-fetching of data, at a low priority can be performed.

Parallel loading of data files across the Internet should dramatically improve speed. This is performed in conjunction with some local caching of specifications to minimise the transfer of data across the internet.

Pre-fetching of data in the next available context allows the program to respond more quickly to player actions by removing the need to transfer data from the immediate action being performed by the player.

All of this has a detrimental impact on concurrence. When there are multiple clients, increasing the amount of data loaded cached locally increases the load on synchronising data between applications. An IP router style of protocol is used to try and keep the various, and completely separate clients in sync.

Lock tokens are used to request a lock on a game thing or state machine. When a player tries to execute a command, depending on the circumstances, a lock is requested in a flood broadcast. The respondee has only a certain amount of time to respond to the request before it is assumed that the lock can be used. (Silence is treated as agreement to cede the lock.) The client then proceeds with executing the command and sends a copy of the command to all other clients to get them to up-date their state models.

A lock request can fail because a lock request could be received from another player in the guard time, indicating that two players want to action the same item at once. In this case the controller may choose to proceed with the action or baulk and respond appropriately to the user. The appropriate action here is really up to the game world designer and controlled from the data files.

Consider a door. 2 players could try to open or close the door simultaneously. If the door is a sliding door, then this could work. If it is a pushable, swinging door and the players are on the same side of the door, then it would work, but if they are on opposite sides of the door it would not work. If was a pullable swinging door and the players are on the same side then one would succeed and the other might fall over.

Another thread that is required for synchronisation of data. This occurs when a player is first getting data, say when they join a game already in play, or enter a part of the game that others are already playing.

21/11/99