Handbook of Multimedia for Digital Entertainment and Arts- P7

Handbook of Multimedia for Digital Entertainment and Arts- P7: The advances in computer entertainment, multi-player and online games,
technology-enabled art, culture and performance have created a new form of entertainment
and art, which attracts and absorbs their participants. The fantastic success
of this new field has influenced the development of the new digital entertainment
industry and related products and services, which has impacted every aspect of our
lives.

7 Countermeasures for Time-Cheat Detection in Multiplayer Online Games 169
be accomplished based on estimations of network latencies and by exploiting the
information contained within transmitted messages [17, 18].
The scheme is called Algorithm for Cheating Detection by Cheating (AC/DC)
[16, 17]. To brieﬂy outline the idea behind the scheme, AC/DC consists on the
exploitation of a counterattack to be performed against a suspected node, in order to
verify if such a peer can be recognized as a cheater.
More speciﬁcally, at a given time only one peer is enabled to perform the coun-
terattack. We call such peer the leader peer pl . Of course, mechanisms should be
enabled to make sure that eventually a node chosen as a leader is not a cheater.
Hence, such role should be passed among peers, as discussed more in detail in the
following.
Once the leader pl wants to control a suspected node, pl increases the trans-
mission latency of events generated at pl for pi . pl starts the counterattack by
continuously computing a measure of the average latency from pi to pl . Such mea-
i
sure is obtained by taking into account values of •il ek for events coming from pi ,
ıil ek D WT rec ek C driftil
i
l
i
WT i c ek :
i
(8)
In (8), W T rec ek represents the time of reception of ek at pl , WT i c ek is the
l
i i i
i
(possibly cheated) wallclock time at which (pi claims that) ek has been generated,
i
and driftli is the drift between physical clocks of the two peers. Such values •il ek
can be averaged (or manipulated through a low-pass ﬁlter to smooth the variable
behaviour of latencies [20, 22, 25, 28]) so as to have a value of the latency from the
suspected node to the leader.
The counterattack that pl exploits against pi consists in the delay of the trans-
mission of each novel event e l generated by pl towards pi . Such transmission is
i
delayed for an amount of time œ. Concurrently, new latency values •il ek are col-
lected at pl , for a given time interval. These measurements are averaged to obtain
a novel estimation of the average latency from pi to pl . The new measure •il is
compared with the old value •il to understand if a statistically signiﬁcant difference
among the two values exists. In particular, when •il is signiﬁcantly larger than •il ,
then the hypothesis that the two measured values are equal must be rejected and
hence pl suspects pi as a cheater. Conversely, the value of œ is progressively in-
creased and the cheating counterattack mentioned above is iteratively repeated until
an upper bound value equal to  for •il + œ is exceeded, where
 UB C TlW .s/ C maxfgapil ; pj 2 …l g: (9)
If such upper bound  is reached while a signiﬁcant difference between •il and
•il has not been noticed, then pi cannot be considered as a cheater.
The use of such a bound on the increment of œ is due to several reasons. The
need to reach UB is due to guarantee that eventually pl is the peer with the higher
(cheated) transmission latency to reach pi i.e. •li C œ > UB •ji , 8 pj 2 …i;l .
Moreover, cases may arise where some game events e j , subsequent to e l but

170 S. Ferretti
1. pi = peer to control
2. assume δli = δil /*assumption of symmetry*/
3. λ = init value /*init value > 0*/
4. while ((δli + λ ≤ Δ) ^ (pi is not suspected))
5. set additional delaying time = λ
6. observe δil* of received game events
7. if (δil* significantly larger than δil)
8. suspect pi
9. else
10. λ = increase(λ)
Fig. 8 AC/DC Pseudocode
i
still within W ek , can be generated by other peers in …i;l . With this in view,
the second term TlW .s/ accounts for those events e j 2 W ek with simula-
i
tion ˚times higher than « l but within a time interval of range s. The third term
e
max gapj l ; pj 2 …il , instead, accounts for those peers pj with gapj l > 0. Put
in other words, it may happen that pl and pj generate event s with same simulation
times at different real times and pj reaches such simulation times after pl . Based
on this consideration, the progressive increment of œ, bounded as mentioned above,
i
is meant to guarantee that eventually no event in W .ek / is received by pi later than
l
e . Thus, when the considered peer pi is a cheater, performing a look-ahead cheat,
pi will eventually stop to wait for game events generated by pl .
The algorithm related to the scheme described above is reported in Figure 8. Such
algorithm is performed at the leader peer.
As mentioned in the pseudo-code, the leader must assume that network latencies
between itself and the suspected node are symmetric (i.e., •li D •il ). Needless
to say, to account for a delay jitter that usually occurs in best-effort networks, a
properly tuned number of measurements is needed in order to obtain an accurate
value of •il . Moreover, the increment of œ, mentioned with a call of a hypothetical
function increase() should be implemented using, for instance, a constant increment
of œ or some kind of linear growth. Of course, the use of a progressive increment of
the value of œ allows a smoother and less intrusive counterattack, since the leader
could be able to identify a cheater even before reaching the upper bound for œ [16].
A point worth of mention is that different methods can be devised to suspect
a peer for cheating. Probably, a good approach could be to exploit come heuristics
based on the combination of diverse factors such that, for instance, i) the degradation
of latencies between pl and pi , ii) the observation that other peers in the same
geographical area of pi have latencies smaller than pi , iii) a player that always wins
and hence, he is very skilled or he is cheating.
An important assumption is the independence of the generation of game events
by a honest peer with those at other peers. In other words, even if certain game
events, generated by some peer, will certainly inﬂuence the semantics of subse-
quent game events generated by others (by deﬁnition of interactivity in MOGs),
in general, the pace of event generation at a given player is mainly inﬂuenced by

7 Countermeasures for Time-Cheat Detection in Multiplayer Online Games 171
autonomous decisions. From a communication point of view, this means that a hon-
est player generates its own events mostly regardless of the amount, rate and latency
of the messages he/she receives. This assumption is supported by the typical use of
techniques such as dead reckoning and/or optimistic synchronization, exploited to
hide latencies on notiﬁcations and local losses of availability on updated informa-
tion, which provide players with the possibility of independently advance the game
[8, 19].
As mentioned, the role of leader should be carefully assigned and managed
among peers. First of all, only one leader must be present at a time in the P2P
system. In fact, suppose two peers concurrently elect themselves as leaders, and
suppose they decide to control each other. In this case, both peers will delay trans-
mission of game events towards the other one. Thus, both peers may erroneously
suspect each other. Moreover, each peer should become leader only for a limited
amount of time, then another node should be elected. To do this, a token-based
scheme should be utilized to determine which is the leader at a given time, i.e. every
time a process receives the token, it becomes the leader. A time deadline is set so
that each peer is forced to eventually release the token. Thus, after such time dead-
line the leader could randomly select another peer to be the next leader, pass the
token to it and reveal itself to all others. This way, other peers know that a leader as
done its job and that it passed the token to another host. However, also in this case,
additional mechanisms should be employed in order to guarantee that eventually all
peers become leaders, in order to diminish the probability that cheaters collude and,
once gained the token, they pass that token only among themselves, thus preventing
honest peers to detect cheaters.
Upon identiﬁcation of a cheater pi , the leader could pass the token to another,
randomly selected peer (not pi , of course), informing it of its pi0 s suspicion. Then,
the novel peer will in turn control pi . Once a majority of peers suspects pi , then
such peer can be considered as a cheater. This solution enables agreement among
honest peers (on cheaters detection). Moreover, such a cooperative approach makes
harder for the cheater to detect if some other node is monitoring his behavior. Thus,
it results more difﬁcult for the cheater to dynamically switch off its cheat as soon as
he detects he is being examined.
Just to provide the reader with an idea of the efﬁcacy of a detection scheme to
cope with time cheats in a P2P scenario, we report in Figure 9 the percentage of
cheaters identiﬁed based on the use of AC/DC. In particular, results were based on a
simulation performed to mimic a P2P fully connected gaming architecture built over
a best effort, reliable network. Based on the literature [3, 13, 16, 19], transmission
latencies were based on a lognormal distribution, whose average network latency
was set to 100 msec. We varied the value of the delay jitter between 10 and 100 msec,
since this parameter may affect the efﬁcacy of our detection schemes.
Starting with an initial estimation of the average latency to reach the controlled
peer, the leader was in charge to assess whether, during the counterattack, the newly
measured average delay (from the cheater to the leader) grew signiﬁcantly. It is
clear that this initial estimation plays an important role in AC/DC. Indeed, during the
game evolution, measured latencies from the cheater to the leader are affected by the

172 S. Ferretti
Look-Ahead Detection with AC/DC
110
Δ ≥ 300 msec
100
Δ = 290 msec
Δ = 280 msec
Detection (%)
Δ = 270 msec
90
Δ = 260 msec
80
Δ = 250 msec
70
Δ = 240 msec
60
50
10 20 30 40 50 60 70 80 90 100
dev std (msec)
Fig. 9 Look-Ahead Detection Through AC/DC
look-ahead cheat. Thus, if the cheater alters its initialization protocol (where the ﬁrst
estimation of the average latency is measured), the leader may start the counterattack
with a delay measure which is higher than the real one [16]. To evaluate the impact
of this possible fallacy, we simulated different scenarios with very diverse initial
estimations of the average latency from the leader to the peer. Here, we report on
the adverse case where the leader starts the counterattack with a false estimation
of the average latency, equal to 2•li , i.e. the round trip time from the leader to the
cheater. Needless to say, with lower values of the initial estimation, it was easier
for our scheme to detect cheaters. The value of œ was initialized to 10 msec and let
grow till reaching (if needed) the upper bound . Each curve refers to a different
choice of .
For each scenario, 30 different simulations have been run. During each simula-
tion, measurements for different message transmissions were employed to make
a statistical test. Among the possible choices on the statistical tests to be em-
ployed, due to our interest for measuring average delays and due to the need for
viable choices, easily executable on different peers, we decided to employ a classic
one-sided t-test .’ D 0:05/. For each test, the number of measurements was set to
40 game events.
As shown in the Figure, while AC/DC detected all cheaters in most of the con-
sidered scenarios (all the scenarios when  was set greater than 300 msec), some
percentage of false negatives (i.e., cheaters not detected) was obtained when high
jitters and relatively low upper bounds were set. However, these results suggest that
it sufﬁces to augment the upper bound  to detect those cheaters.
It is important to notice that no false positives were obtained through AC/DC,
even with very high values of the delay jitter (e.g., std.dev. set equal to 100 msec).
In other words, no honest peers were erroneously identiﬁed as cheaters.

Chapter 8
Zoning Issues and Area of Interest Management
in Massively Multiplayer Online Games
Dewan Tanvir Ahmed and Shervin Shirmohammadi
Introduction
Game is a way of entertainment, a means for excitement, fun and socialization.
Online games have achieved popularity due to increasing broadband adoption
among consumers. Relatively cheap bandwidth Internet connections allow large
number of players to play together. Since the introduction of Network Virtual Envi-
ronment (NVE) in 1980s for military simulation, many interesting applications have
been evolved over the past few decades. Massively multiplayer online (role-playing)
game, MMOG or MMORPG, is a new genre of online games that has emerged with
the introduction of Ultima since 1997. It is a kind of online computer game with the
participation of hundreds of thousands of players in a virtual world.
Nowadays multiplayer online games are very popular. An MMOG could have
millions of subscribers such as World of Warcraft, or Quest. Interesting is that all
subscribers do not play with each other in the same space at the same time. As a
consequence, the virtual world is divided into realms or kingdoms which are the
clones of the original virtual world, each hosting several thousand registered play-
ers. Technically, the realms are geographically distributed across the world. Thus,
players from a particular region play together in the same realm. To accommodate
millions of subscribers, gaming companies provide many realms across the world as
needed. Realms are further divided into separate areas, also known as a zone. Zones
can have different themes and different levels of difﬁculties holding inexperienced
players advancing into the next hard level.
MMOGs are similar to generic massively multiuser simulations that have existed
for decades, most notably combat training simulations used by Departments of De-
fense (DoD) around the world, and more recently, disaster management applications,
emergency planning simulators, etc. These have reached their current state because
of their signiﬁcant impact on virtual training in high-risk situations as well as their
D.T. Ahmed and S. Shirmohammadi ( )
School of Information Technology and Engineering University of Ottawa, Ottawa,
Ontario, Canada
e-mail: dahmed@discover.uottawa.ca
B. Furht (ed.), Handbook of Multimedia for Digital Entertainment and Arts, 175
DOI 10.1007/978-0-387-89024-1 8, c Springer Science+Business Media, LLC 2009

176 D.T. Ahmed and S. Shirmohammadi
ability to interpret the real and the simulated results in extraordinary circumstances
such as natural disasters or terrorist attacks.
Commercial MMOGs use the client-server architecture with a single authentic
server designed for to support the game logic. The server pool regulates game trafﬁc
using the zoning concept and makes its implementation more convenient. Practi-
cally, the communication structure within a zone is similar to the Internet multicast
structure, not client-server, because of the players’ common interest in the game
logic. IP multicast, which was originally proposed for group communication, can
be an ideal solution for this purpose. But it is a well-known fact that IP Multicast is
not deployable on the wide-scale Internet, even in future with IPv6 [1]. Thus, current
practices heavily rely on centralized architectures that cause scalability bottlenecks.
In addition, the models are costly to adopt and install. Current designs (research ori-
ented), however, try to incorporate client and server side resources in a peer-to-peer
fashion to address its different challenges such as scalability, responsiveness, and
persistence [2][3].
Challenges and Requirements
The development of an MMOG faces many challenges. A fundamental requirement
of any real-time application tool is the exchange of regular update messages among
the participants. It is a challenging task while keeping a low data rate without affect-
ing the gaming experience. Scalability is another important concern when designed
for large-scale simulators or virtual environments and MMOGs, as it is the function
of other gaming components related to the system. However, the amount of data
that needs to be exchanged among participants is bounded by server-side resources
and other technical conditions such as network bandwidth, processing power and
network latencies.
Network Bandwidth - The bandwidth is the amount of data that can be trans-
mitted over a network in a ﬁxed time-slot. It is set by the underlying hardware that
connects to the computers. The user’s connection to its Internet Service Provider
(ISP) and the ISP’s hardware and software infrastructures also affect available band-
width. Practically MMOG players have non-uniform bandwidth. Thus, the amount
of data that can be exchanged between two computers is restricted by the bandwidth
of the players.
Processing Power - The processing power expresses the computation capability -
the amount of computations/instructions executed by a computer in a ﬁxed time-slot.
For gaming, higher processing power is required for multiple reasons like physics
engine, collision detection, graphic rendering, artiﬁcial intelligence, and to send and
receive network messages for networked games. But the processing power of all
users is not homogenous. Thus, the amount of information that can be exchanged
between two computers and the quality of perception also depends on their CPU
resources.

8 Zoning Issues and Area of Interest Management 177
Network Latency - Latency is the amount of time a message takes to travel over
a network from a source to a destination. The physical limitation of the underlying
hardware like routers and switches, and network congestion make it variant from
time-to-time. The interaction details of an MMOG player must be sent to all other
active participants in time. Because of the networking limitations and the trafﬁc
conditions, some of these updates can be lost or delayed. Thus, latency issue cannot
be ignored. The updated game states must be forwarded within a time limit so that
the responsiveness of game play is maintained. Generally, latency acceptance varies
from game-to-game and is restricted to a value between 100ms to 1000ms for online
games [4]. The acceptable latency depends on game perspectives (i.e. First-person
or Third-person), game genres (i.e. racing or role playing game), and the sensitivity
of actions.
MMOG Architecture – An Overview
To accommodate a large number of players, the map is logically divided into mul-
tiple zones where each zone encompasses the players that are in the same vicinity.
Each zone has a master (e.g. server) that coordinates the interactions of the zone
members in a multicast fashion. A set of master nodes regulates the operation of the
MMOG and provides overlay services in client-server model. On the other hand, hy-
brid model incorporates the participation of the players. The system is hybrid as it
combines the beneﬁts of both centralized and distributed systems. To overcome the
functionality limitations of the IP multicast, application layer multicasting (ALM)
can be chosen for intra zonal communication [5].
MMOG Classiﬁcation
There are many types of massively multiplayer online games. Some popular types
are given in the Table 1.
Communication Architecture
The right communication structure is very important for interest management as
it regulates message transmission and controls network resource usage. Different
packet delivery methods can be used for data communication in multiplayer games.
This includes basic unicast communication which is the most popular choice, but
broadcast and multicast communications are sometimes also useful.
The proper choice of TCP or UDP protocol for standard unicast communica-
tion is important for online games. UDP is a simple best-effort procedure that
offers no reliability and no guaranteed packet ordering. On the other hand, it has

178 D.T. Ahmed and S. Shirmohammadi
Table 1 Types of MMOGs and examples
Types of
MMOG Characteristics Example
MMORPG Massively multiplayer online role EverQuest, Star war galaxies
playing games
MMOFPS Massively multiplayer online ﬁrst World War II Online World:
person shooters Battleground Europe, 10SIX (known
as Project Visitor)
MMORTS Massively multiplayer online real-time Ballerium, Time of Deﬁance, Shattered
strategy Galaxy
MMOR Massively multiplayer online racing Darkwind: War on Wheels, Trackmania,
games Test Drive Unlimited
MMOTG Massively multiplayer online tycoon Starpeace, Industry Player
games
MMOSG Massively multiplayer online sports Second Life
games/social game
MMOMG Massively multiplayer online manager Hattrick
games
little overhead, making it appropriate for highly interactive games (e.g., ﬁrst-person
shooter, car racing) where fast packet delivery is more important. On the other hand,
TCP guarantees ordered packet delivery and simpliﬁes programming with additional
overhead. Most importantly, TCP can work more transparently across ﬁrewalls.
Thus, many commercial MMOGs (e.g., EVE Online, Lineage II, and World of War-
craft) use TCP for their communication.
Local area networks (LANs) can be restrictively conﬁgured to allow broad-
cast. This can make state dissemination much simpler and efﬁcient. Unfortunately,
MMOGs are not able to take the advantages of broadcast in an Internet setting as it
is not typically supported across the router boundaries. Another technique is mul-
ticast which provides group-based packet delivery. A host can subscribe to one or
multiple multicast addresses and receive all messages sent to those addresses. It is
usually much more efﬁcient than multiple unicast operations. However, multicas-
ting is not widely available on the global Internet due to technical, business, and
practical reasons [1] and is therefore not a practical solution for MMOGs.
There are two general types of MMOG architectures: client-server and peer-to-
peer. There are also hybrid architectures that are between these two main paradigms.
In client-server architecture, each client has a single connection with the server
(Figure 1a). The server is responsible to relay the game states between clients. The
main advantage of the client-server architecture is the easy controller which is cen-
tralized and autonomous. As a solution for resource limitations multiple servers are
deployed. The architecture also facilitates easy implementation of load balancing,
fault tolerance, security, and many other concerns. But in client-server architecture,
the server is an architectural bottleneck and limits the scalability of the system. Still
it is the most popular and practiced approach in the gaming industry.
Commercial NVEs use the client-server architecture which is expensive to de-
ploy and cumbersome to maintain. For example, the virtual world of Second Life

8 Zoning Issues and Area of Interest Management 179
Fig. 1 (a) Client-server architecture (b) Peer-to-peer architecture
has approximately 5000 servers. Such expensive deployment issue as well as the
need for regular maintenance stirs us to an alternative solution. The P2P architec-
ture has a self scalability property, but considering business oriented and practical
issues such as quality, cheating, and distributed game logic, it seems that a pure
P2P architecture (Figure 1b) is an infeasible and impractical solution. Recently, the
hybrid P2P architecture is considered as a good solution both for vendors and end
users [6][7]. The P2P community strongly believes that online games over hybrid
peer-to-peer architecture have promising prospects considering deployment cost and
performance in some sense through reduced latencies.
Virtual Space Decomposition - Zoning
The genre of MMOG is relatively new but popular. The development of MMOGs
encompasses many technical challenges. Some of the challenges are
Ensuring consistency
Providing fault-tolerance
Administration of servers and players
Preventing cheating
Providing scalability and many others
To achieve these, the concept of zoning is typically used. This is what we will de-
scribe next.
Zone Deﬁnition
For easy state administration, the virtual space is divided into multiple adjacent
areas technically called zones. But on what perspective a zone is constructed, is

180 D.T. Ahmed and S. Shirmohammadi
subject to speciﬁc implementation. From networking perspective, each LAN can
be considered as a zone where several LANs are connected through the Internet
forming the whole world. A LAN provides high bandwidth, so it could be easy for
the server, i.e. the master, responsible for a zone to construct the overlay network if
required, maintain its state, and manage new comers and early leavers. However, this
is not a sufﬁcient requirement: other factors such as virtual distance and visibility,
and logical partitions need to be taken into consideration when deﬁning a zone. In a
nutshell, a zone is a logical partitioning which is usually transparent to the players
in the game space.
Multiple Zones and its Space
At its simplest, a zone can be represented by a square or a triangle. Multiple zone
deﬁnition can be adopted while deﬁning the map of a game space. To accommodate
many players, the map is logically divided into multiple zones. Each zone encom-
passes the players that are in the same vicinity. Henceforth, when a player moves
from one zone to another, it gets disconnected from one server and joined to another
server. If this multiple-zone layout is considered, more connections and disconnec-
tions can be encountered for the same path traversal scenario (Figure 2). Triangular
and hexagonal shapes have advantages over other shapes. For example, unlike cir-
cles, triangular and hexagonal shapes stick together and maintain regular shapes
(Figure 3).
Fig. 2 Two versus multiple zones layout, with a player moving across zones
Fig. 3 Hexagonal and circular zone shapes

8 Zoning Issues and Area of Interest Management 181
Area of Interest Management
For online games, Area of Interest Management (AoIM) is a technique to reduce
communication overhead. AoIM is a method used to determine useful information
for a speciﬁc player and block all other information. For example, the area of interest
of an avatar in an MMOG is the set of avatars and non-playing components (NPC)
with whom it interacts with in its neighborhood. Since the virtual world is large,
ﬁltering out irrelevant information is a fundament requirement for a scalable system.
There are two approaches to model AoIM for MMOGs. The ﬁrst one is static
geographical partitioning implemented at the initialization phase of a simulation.
This is practical as it describes the structure of a virtual world. For example, a
virtual world consists of multiple cities where each city deﬁnes a geographical par-
tition: it is the area where most of the interactions take place, and in most cases,
the participants are not captivated on what is happening in other cities. Second Life
has adopted such approach [8]. The virtual world offers uninteresting items around
the borders, like cities separated by empty forests or wilderness where players do
not want to stay long. Although the static geographic partitioning is good for some
cases, it might not be a general solution for all virtual simulators.
The second approach for AoIM is behavioral modeling. In military simulations,
two different units such as a jeep and an aircraft have different distinctiveness in
terms of how fast they can move, how far they can see, and the scope of the interac-
tion space (a jet launching a missile has a larger area of inﬂuence than a jeep patrol).
Lu et al. argue that, as the mapping of processing resources to the geographic re-
gionalization is straightforward and uncomplicated, the behavioral approach has not
been deeply explored [9]. One of the limitations of a geographic regionalization is
its unintelligence to prevent inter-server communications. This is because the ge-
ographic regionalization does not give enough importance to players’ interactions.
Even though behavioral modeling is the ideal approach to manage interest of the
parties, geographic regionalization is not without merits. Thus, geographic region-
alization can be augmented by behavior-based communications for better interest
management.
Interest Management Models
An MMOG deals with plenty of information keeping each player’s activities and
tracking its location. Rationally a player does not need state information of the entire
virtual world which is too large. Thus, determining information appropriate to each
player is a fundamental requirement of online games. From this perspective, an
interest management is a way of determining functional details of a player. So, the
performance of a virtual world depends on the cost and effectiveness of an AoIM
approach deployed.

182 D.T. Ahmed and S. Shirmohammadi
Publisher-Subscriber Model
Interest management for an MMOG can be abstracted using a publish-subscribe
model. The concept is publishers create events and subscribers consume events. In
this model, interest management consists of determining when an avatar registers
to or gracefully/ungracefully bows out from a publisher’s (avatar’s) updates. Gen-
erally, interest management for online games can have multiple domains. The most
common domain is the visibility, although other domains like audible range and
radar are also possible. Each interest domain has special properties for the transmis-
sion and reception of data, so different sets of publisher-subscribers model might be
needed.
Space Model
Interest management can also be categorized into two general groups: space-based
and class-based. Space-based interest management can be deﬁned based on the rel-
ative position of avatars in a virtual world, while class-based can be determined
from an avatar’s attributes. Space-based interest management is the most useful for
MMOGs because of the relevant information of a player is usually closely related
to its position in the environment and is typically based on proximity which can be
realized in terms of the aura-nimbus information model given in Figure 4. Aura is
the area that bounds the existence of an avatar in space, while nimbus, i.e. area of
interest, is the space in which an object can perceive other objects. In the simplest
form, both aura and nimbus are usually represented by circles around the avatar.
This model is more appropriate when a server keeps a connection with each client.
The drawback of a pure aura-nimbus model is scalability because of the computing
cost associated with the determination of intersection between the nimbus and the
auras of a large number of players.
Fig. 4 The aura nimbus model

8 Zoning Issues and Area of Interest Management 183
Fig. 5 Region-based area of interest
Region Model
Region-based interest management partitions the game space into several ﬁxed re-
gions. The interest management scheme then determines the regions which intersect
with the expression of interest of the players. Thus, an area of interest becomes the
union of the intersected regions with respect to the expression of interest as shown
in Figure 5. It is an approximation of the true expression-of-interest and generally
cheaper to compute but less precise than a pure aura-nimbus model.
Implementation Intelligence
Message Aggregation
Message aggregation is a technique to address MMOG resource limitations [10].
It reduces the overall message update rate by aggregating multiple game messages
into a single message. Thus, it rationalizes bandwidth usage by removing redundant
message information like the message header. Message aggregation introduces some
delay. However updates are piggybacked and could limit game performance if not
designed properly.
Message Compression
Simple message compression techniques can be used as a means against strict band-
width requirement [10]. Although the method is expensive, considering resource
constraints it is not without merit.

184 D.T. Ahmed and S. Shirmohammadi
Dead Reckoning
This method tries to predict the movement of players to help a player take an expert
guess in terms of where others players will be in the next short while. Say a player
moves from a point P 1 to another point P 2 . Each and every discrete step on the
path P 1 P 2 is required for appropriate rendering as well as for collision detection.
If we consider a frame rate of 30 steps per second, which is typical movie quality,
each step corresponds to a unique state that needs to be shared among the interested
players in every 1=30th of a second. Thus, for a large number of moving objects, the
total volume of data being shared is high and creates a huge load on network.
Dead reckoning (DR) is a procedure of approximating a player’s current position
based upon the last known position and velocity, and advancing that position based
upon elapsed time. In MMOGs, dead reckoning predicts a remote object’s trajectory
and locally calculates the next movement to reduce network load.
Interest Management Algorithms
There are several types of interest management algorithms which can be classiﬁed
into three broad categories: proximity-based, visibility-based, and reachability-
based which are explained next.
Proximity Algorithms
Proximity-based interest management algorithms are solely based on the Euclidean
distance between publishers and subscribers. This type of algorithm ignores the
presence of obstacles which could occlude parts of the game space. Algorithms
like Euclidean Distance, Square Tiles, and Hexagonal Tiles are some examples
of proximity-based interest management. Euclidean Distance Algorithm (Figure 6)
is purely based on the Euclidean distance among objects while the other two are
the approximations that use partitioning concept. In Figure 6, the area of interest is
shown with respect to the men at the center of the circle.
Square Tiles Algorithm is a simple region-based interest management where the
virtual world is divided into equal-sized squares. Technically, the size of squares is
set according to the radius of interest of the players. So, at any location, the sub-
scriber is interested in at most nine tiles: the subscriber’s current tile and the eight
or less surrounding tiles (Figure 7). Whenever a player performs an action, the ac-
tion is shared among all players subscribed to the square where the action has taken
place.
Like Square Tiles algorithm, Hexagonal Tiles algorithm partitions the virtual
world into equal-sized hexagons. If a player’s radius of interest intersects a tile,
the player subscribes to objects in the tiles. So, at any location, the subscriber is

8 Zoning Issues and Area of Interest Management 185
Fig. 6 Euclidean distance algorithm for interest management
Fig. 7 Square tile algorithm for interest management
interested in at most seven tiles: the subscriber’s current tile and the six or less
surrounding tiles (Figure 8). For each subscriber the algorithm performs a search
from its current tile to ﬁnd all tiles based on the subscriber’s radius of interest.
The player subscribes to all publishers contained within those tiles. The algorithm
could nicely be implemented using a depth-ﬁrst search, and is perhaps the most
commonly-used proximity-based algorithm for virtual environments and games.

186 D.T. Ahmed and S. Shirmohammadi
Fig. 8 Hexagonal tile algorithm for interest management
Comparison of Euclidean Distance and Hexagonal Tile Algorithms
Euclidean Distance Algorithm
Pros
Easy to implement
Computationally inexpensive
No partitions of the virtual world
Cons
Less realistic as it does not consider obstacles
High complexity
Hexagonal Tile Algorithm
Pros
Easy to implement
Computationally inexpensive
A good benchmark

8 Zoning Issues and Area of Interest Management 187
Cons
Less realistic as it does not consider obstacles
High complexity
Visibility Algorithms
Visibility-based algorithms consider the occlusion created by obstacles in the virtual
world. Theoretically, the area of interest is only limited to the player’s visibility
scope. In visibility-based algorithms, if a player is out of sight from another player,
they are not in the same interest group even if they are physically close. Ray Visibility
and Tile Visibility are two examples of this class. Ray Visibility computes the exact
visibility between two objects; on the other hand, Tile Visibility uses approximation
to compute the visibility between static regions.
In Ray Visibility, the area of interest is uncovered with respect to the players’
visibility scope (Figure 9). To determine an object is visible to a player, it traces a
line from the position of the player to the position of the object. If the line does not
intersect with any obstacle in the world, they are visible to each other. Ray Visibility
is a precise interest management algorithm as it accurately determines the area of
Fig. 9 Ray visibility algorithm for interest management

188 D.T. Ahmed and S. Shirmohammadi
interest of a player. The main advantage is that it provides the lower bound on the
number of messages that need to be exchanged between players.
Tile Visibility algorithm is based on the visibility between tiles. The algorithm
pre-computes the visibility relationship between each pair of tiles, and the area of
interest is projected after the tile visibility for each tile has been pre-computed.
A player’s area-of-interest is the set of tiles visible from the tile it currently stays.
Comparison of Ray and Tile Visibility Approach
Ray visibility
Pros
Accurately determines area of interest
Exchange minimum number of messages between two players
Efﬁcient approach
Cons
Harder to implement
Computationally expensive
Tile visibility
Pros
Simple as tile visibility relationships are pre-computed
More realistic than proximity based
Cons
Dynamic zone shaping is not possible
Requires supporting algorithms to handle obstacles
Reachability Algorithms
Reachability-based algorithms deﬁne area of interest with respect to reachability
even though one or more regions are out of sight due to obstacles. It is somewhat
similar to proximity-based algorithms, but it discards objects that are unreachable.
Unlike visibility-based algorithms, an object that is not visible (e.g., behind an ob-
stacle) may be in the area of interest if there is a path to reach that object within its
radius of interest. Tile Distance and Tile Neighbor algorithms fall into this category.
Tile Distance algorithm uses Euclidean distance between a player and a trian-
gular tile. It runs a breadth ﬁrst search (BFS) algorithm from the current tile to