Parallelization and performance of interactive multiplayer game servers

Abstract

An important application domain for online services is interactive, multiplayer games. An essential component for realizing these services is game servers that can support large numbers of simultaneous users in a single game world. In this work, we use a popular, 3D, interactive, multiplayer game server, Quake, to study this important class of applications. We present the design and implementation of a multithreaded version of the server. We examine the challenges in scaling this class of applications to large numbers of users, mainly task decomposition and synchronization. We present preliminary performance results for a server with up to eight processors. We find that: (i) Scaling interactive, multiplayer games that exhibit fine-grain interactions in a detailed 3D world to large numbers of players is a challenging task. (ii) The main bottlenecks are lock synchronization during request processing and high wait times due to fine grain workload imbalances at global synchronization points. (iii) Significant future improvements are possible using techniques that take advantage of game-specific knowledge.

Towards Transactional Memory for OpenMP

“…Usually they are based on the use of software implementations of transactional memory, with varying results in terms of performance. Examples of such efforts include Delaunay triangulation [10], minimum spanning forest of sparse graphs [11] Lee routing algorithm [12], multiplayer game servers such as QuakeTM [13] and Atomic Quake [14] (based on a lock-based version of Quake [15]) and SynQuake [16]; or benchmarks (STMBench7 [17], STAMP [18] and RMS-TM [19], all of them composed of a number of applications representative of a variety of application domains.…”

“…Game code is typically complex, and can include use of spatial data structures for collision detection, as well as other dynamic artifacts that require conservative synchronization. The nature of the code may thus induce substantial contention due to false sharing, as well as true sharing between threads, in a parallel lock-based game implementation [15]. Each Quake player action usually includes dynamically evolving sub-actions; a person may move while shifting items in their backpack, throwing an object at a distance, grabbing a nearby object, and/or shooting, which together constitute a single player action.…”

Investigating informative performance metrics for a multicore game world server

“…In further work, Abdelkhalek and Bilas [25] implemented a parallel version of the QuakeWorld server. The response processing and reply phases were processed by concurrent threads running on separate cores of a quadcore CPU.…”

“…We conclude Experiment Two by considering an alternative metric, interframe wait time (IFWT), used by Abdelkhalek and Bilas to analyze threads in their parallel implementation [25]. Whereas workload is an estimated measure of processing weight, IFWT is a direct measure of the actual distribution of processing time.…”

Demonstrating Hundreds of AIs in One Scene

“…The character reads input from the network, performs updates on itself according to the input, and updates other elements with the results of its actions. All this makes parallel execution tricky and modifications to this approach such as [1] show only limited success, implying a need for a system designed from the ground up with parallelism in mind. The LEARS architecture is described in detail in papers [4] and [5].…”