U.S. patent application number 11/403024 was filed with the patent office on 2006-11-16 for system and method of seamless game world based on server/client.
Invention is credited to Long Cheng, Yi Gil, Ling Shao, Mzng Yz.
Application Number | 20060258462 11/403024 |
Document ID | / |
Family ID | 37077687 |
Filed Date | 2006-11-16 |
United States Patent
Application |
20060258462 |
Kind Code |
A1 |
Cheng; Long ; et
al. |
November 16, 2006 |
System and method of seamless game world based on server/client
Abstract
The present invention provides a seamless game world system in
the field of massively multiplayer online games, comprising a
plurality of game servers and at least a client, each of the game
servers being assigned to a zone in the game world divided into
zones. The seamless game world comprises: a game logic computing
module for computing an avatar's new status; a map controller for
detecting whether an area of interest of the avatar has crossed the
border of a host server of the avatar and spanned neighbor game
servers based on the avatar's new status computed by the avatar
computing module, and determining to make/delete a clone on a
neighbor game server or synchronize the clone's status based on the
detected result; and an avatar status update module for performing
a normal status update on the avatar based on the computed result
of the game logic computing module after the map controller notices
its neighbor game server to delete the clone from an avatar
list.
Inventors: |
Cheng; Long; (Beijing,
CN) ; Gil; Yi; (Beijing, CN) ; Shao; Ling;
(Beijing, CN) ; Yz; Mzng; (Beijing, CN) |
Correspondence
Address: |
ANNE VACHON DOUGHERTY
3173 CEDAR ROAD
YORKTOWN HTS.
NY
10598
US
|
Family ID: |
37077687 |
Appl. No.: |
11/403024 |
Filed: |
April 12, 2006 |
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
A63F 13/69 20140902;
A63F 2300/531 20130101; A63F 13/358 20140902; A63F 2300/534
20130101; G07F 17/32 20130101; A63F 13/12 20130101; A63F 13/352
20140902 |
Class at
Publication: |
463/042 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Foreign Application Data
Date |
Code |
Application Number |
Apr 12, 2005 |
CN |
200510064956.9 |
Claims
1. A seamless game world system, comprising a plurality of game
logic servers and at least one client, each of the game logic
servers being assigned to a zone in the game world divided into
zones for executing all the computations required to manage the
status of the game world, the client signaling an avatar's movement
within the game, the avatar being an entity of the player in the
game world whose status is controlled by user input, comprising: a
game logic computing module for computing status of an avatar
relative to said zones; a map controller for detecting whether an
area of interest of the avatar has crossed the border of the zone
of a host server of the avatar and has spanned one or more zones of
neighbor game servers based on the status computed by the game
logic computing module, for determining one of making a clone,
deleting a clone or synchronizing clone status at a neighbor game
server based on the detected result, the clone representing the
incarnation of a doer avatar on a neighbor server, the doer avatar
being an avatar with a clone avatar, and for notifying neighbor
game servers of said determining; and an avatar status update
module for performing a normal status update on the avatar based on
the computed status.
2. The seamless game world system according to claim 1, wherein the
game logic computing module, the map controller and the avatar
status update module are integrated with a runtime game
application.
3. The seamless game world system according to claim 1, wherein
each doer avatar has more than one clone avatars.
4. The seamless game world system according to claim 1, wherein the
map controller further comprises an avatar migrating processor for,
when the avatar crosses the border of the host server of the avatar
and enters into a zone of an immigrated server, notifying a peer on
the immigrated server, and completing the migration process by
changing the avatar on the host server into a clone avatar and
changing the immigrated server's agent avatar into a doer
avatar.
5. The seamless game world system according to claim 1, wherein the
map controller comprises: a clone detector for receiving the
computed new status of the avatar from the game logic computing
module, and making a decision about whether to make a clone, delete
a clone or synchronize a clone's status according to map-server
table information and an avatar policy; a clone planner for
establishing a clone plan, which includes participant neighbor
servers and the actions of adding a clone, deleting a clone or
updating a clone status; a clone plan sender for reading the
addresses of the clone plan's neighbor game servers, and sending
the action commands to different neighbor game servers; and a clone
plan receiver and manager for collecting the clone plan of all the
neighbor game servers sent by a peer, and for performing the
process of clone adding, deleting or status synchronizing based on
the clone plan information.
6. The seamless game world system according to claim 5, wherein the
clone plan further comprises the new status of an avatar to be
synchronized.
7. The seamless game world system according to claim 6, wherein
each status has several different actions corresponding to
different neighbor game servers.
8. The seamless game world system according to claim 5, further
comprising a map-server table memory for storing the data
describing a server map relationship and neighbor relationships
between zone maps.
9. The seamless game world system according to claim 5, further
comprising a game policy builder for collecting policy layer
information for an avatar, an avatar policy including the view
scope and information for computing the avatar's area of
interest.
10. The seamless game world system according to claim 9, further
comprising an avatar policy database memory for storing an avatar
policy database describing a server map relationship and neighbor
relationships between zone maps.
11. A method for realizing a seamless game world for every player
of a game world, the game world being divided into zones, each zone
being assigned to a game server for management, a player
controlling a client to accept commands input from a remote game
server, render the player's view of the game world, and send
keystroke, mouse or controller commands across the network to
signal an avatar's move within the game, the avatar being an entity
of the player in the game world whose status is controlled by user
input, characterized in that the method comprises the steps of:
computing status of an avatar relative to said zones; detecting
whether an area of interest of the avatar has crossed the zone
border of a host server of the avatar and spanned one or more zones
of neighbor game servers based on the computed status; determining
one of making a clone, deleting a clone or synchronizing clone
status at a neighbor game server based on the detected result, the
clone representing the incarnation of a doer avatar on a neighbor
server; notifying neighbor game servers of a result of said
determining; and performing a status update on the avatar.
12. The method according to claim 11, wherein each doer avatar has
more than one clone avatar.
13. The method according to claim 11, wherein, when the avatar
crosses the zone border of the host server of the avatar and enters
into a zone of an immigrated server, said method further
comprising: notifying a peer on the immigrated server; changing the
avatar on the host server into a clone avatar, and changing the
immigrated server's agent avatar into a doer avatar.
14. The method according to claim 11 wherein said determining
comprises the steps of: making a decision about whether to make a
clone, delete a clone or synchronize a clone's status according to
the computed status of the avatar, map-server table information,
and an avatar policy; establishing a clone plan when it is
determined to make a clone, delete a clone or synchronize a clone's
status, the clone plan including participant neighbor servers and
the actions of adding a clone, deleting a clone or updating a clone
status; reading the addresses of the neighbor game servers in said
clone plan and sending the action commands to said neighbor game
servers; and collecting the clone plans of all neighbor game
servers sent by a peer, and performing the process of clone adding,
deleting or status synchronizing based on the clone plan
information.
15. The method according to claim 14, wherein the clone plan
further comprises the new status of an avatar to be
synchronized.
16. The method according to claim 15, wherein each status has
several different actions corresponding to different neighbor game
servers.
17. The method according to claim 14, further comprising collecting
avatar policy layer information to build an avatar policy, the
avatar policy including the avatar's view scope and other
information for computing the avatar's area of interest.
18. The method according to claim 14, wherein said making a
decision comprises the steps of: monitoring the status change of an
avatar, and detecting whether the avatar's area of interest crosses
the zone border of the host server and spans to a neighbor server;
and determining the status of the avatar computed by the doer
server; updating the status if it is detected that the avatar's
area of interest is inside the border; and determining to establish
a clone on the neighbor server according to each avatar's area of
interest and other private policies if it is detected that the
avatar's area of interest crosses the zone border of the avatar's
host server and spans to a neighbor server.
19. The method according to claim 18, further comprising: detecting
whether the avatar's area of interest crosses a server map and
enters into the zone of an immigrated server; notifying the
neighbor game server to delete a clone from an avatar game server
if it is detected that the avatar's area of interest no longer
crosses the server map border,; and notifying a peer on the
immigrated server if it is detected that the avatar's area of
interest crosses the zone border of its host server and enters into
the zone of an immigrated server; and changing the avatar on the
original server into a clone avatar and changing the immigrated
server's agent avatar into a doer avatar; and computing the
avatar's status in the immigrated server.
20. The method according to claim 11, wherein said detecting
comprises the steps of: monitoring the status change of an avatar,
and detecting whether or not the avatar's area of interest crosses
the zone border of the avatar's host server and spans to a neighbor
server; computing the avatar's new status by the doer server and
updating the avatar's status if it is detected that the avatar's
area of interest is inside the border; determining to establish a
clone on the neighbor server according to each avatar's area of
interest and other private policies if it is detected that the
avatar's area of interest crosses the zone border of the avatar's
host server and spans to a neighbor server; computing the avatar's
new status and synchronizing the clone's status by the doer server;
performing a status update on the same avatar by the doer server
and the neighbor server; detecting whether the avatar's area of
interest spans the server map and enters into the zone of the
immigrated server; notifying the neighbor game server to delete the
clone from the avatar list if it is detected that the avatar's area
of interest no longer spans the map border of the server; notifying
a peer on the immigrated server; changing the avatar on the
original server into a clone avatar and changing the immigrated
server's agent avatar into a doer avatar if it is detected that the
avatar crosses the zone border of its host server and enters into
the zone of the immigrated server; and computing the avatar's
status in the immigrated server.
21. The method according to claim 11, wherein when the avatar's
area of interest spans the zone of the neighbor server, the
commands of the player are sent to the doer server and, during the
update of the neighbor game server, are sent to the clone avatar to
make a clone avatar in the neighbor game server, and the status of
the clone avatar and that of the doer server are synchronized.
22. A computer readable media containing instructions for executing
the steps of the method according to claim 11.
Description
FIELD OF THE INVENTION
[0001] The present invention generally relates to a computer system
for online gaming and the method thereof, in particularly to a
seamless game world system for chaining a game world partition
divided into several small-scale game worlds in massive multiplayer
online games based on client/server architecture to form a whole
game world, and method thereof.
BACKGROUND OF THE INVENTION
[0002] With the advent of the Internet and wireless communication,
massively multiplayer online games (MMOG) are becoming more popular
in recent years. While P2P architecture has been discussed in
academic fields for some time, and there are some games implemented
in P2P manner, most commercially operated MMOG are provided in a
typical client/server architecture for game security and management
purposes.
[0003] In the MMOG in the form of client/server architecture,
players run a client program on their local game hardware
(typically a PC or a game console) that acts only as an
input/output device. The local machine accepts commands input from
a remote game server and renders the player's view of the game
world, sending keystrokes, mouse movements or controller commands
across the network to signal the player's action within the game.
Every player is represented in the game world by an entity called
"avatar", whose state is controlled by the user input. Most or all
of the processing required to manage the game world's state is
handled by the game logic executing on a remote server.
[0004] The game logic server typically performs all computation
needed to manage the game world state. In large-scale online games,
because the whole game world is very large and no single server can
support all the activities in game world alone, the game world is
normally divided into several small ones and a cluster of game
servers serve the participating game world together. Since the
single server architecture (a single server serving the whole
world) is very simple, it is the technology of multi-server
architecture that will be addressed.
[0005] In MMOG, the structured diagram is mapped onto distinct
server clusters. Such a kind of map is introduced in Jarett A,
Estanislao J, Dunin E, MacLean J, Robbins B, Rohrl D, Welch J and
Valadares J, "(2003) IGDA Online Games White Paper", pp63-64, 2003.
In this document, the most common means for partitioning of the
game world is to divide distinct geographical regions within a game
world into zones, assigning one zone to a game server. Every zone
is composed of many cells which are the basic map units. Neighbor
cells are chained together to compose the zone, and then neighbor
zones on different servers are chained together to form the whole
game world.
[0006] Referring to FIG. 1, an example of the game world is shown.
In FIG. 1, the game world is composed of 4 zones, which are Zone 1,
Zone 2, Zone 3 and Zone 4, respectively. Zone 1 is composed of 16
basic map units, i.e. cells, Zone 2 is composed of 24 cells, Zone 3
is composed of 24 cells, and Zone 4 is composed of 36 cells. Zone
1, Zone 2, Zone 3 and Zone 4 are assigned to Computer 1, Computer
2, Computer 3 and Computer 4 as servers, respectively.
[0007] To increase the number of simultaneous participants by
reducing network bandwidth requirements, the entities usually
disseminate update packets only to those nodes relevant to them,
which are in the so-called AOI (area of interest). In multi-server
MMOG, the avatar's AOI may cross the border. So, according to the
zone interaction and AOI management method, the multi-server MMOG
can be divided into two kinds. One of the two kinds of online game
is a discrete game world. In this architecture, game worlds are
zoned and each zoned has a boundary to prohibit players from being
aware of events occurred outside. Switching between zones can be
done only through switching a connection from a current game server
to the one that serves the target zone.
[0008] The discrete game world has three major shortcomings, the
first of which is that there is an obvious interruption of
game-playing felt when switching between two zones served by
different servers. In fact, switching between two zones is
implemented by the game logic discharging the avatar from the
original server first and then performing logins it to another
server. So the player will have the serious problem of abrupt
visual effect on the client site. A second shortcoming is that the
border of a zone prohibits the player from seeing another side of
the game world, which in turn reduces the interaction and fun of
the game. The third shortcoming is that the difficulty of dynamic
load balancing among game server farms is increased (i.e. batch
movement of avatar without influence on the business-as-usual (BAU)
of game servers is a very challenging task.) Another kind of MMOG
is a continuous or seamless game world. In contrast to the discrete
game world, in zoned game worlds, MMOG can be designed to create
seamless worlds in which a player can do whatever he does in the
discrete game world without the boundary limitation. The player may
interact with objects, computer-controlled characters or other
players that are themselves executing on servers other than the
player's. There are a number of benefits to the use of seamless
game world design for MMOG.
[0009] In the continuous or seamless game world, game designers can
plan their game content on a larger and continual game world, which
enables them to design more complicated/comprehensive contents. As
the scale of the game world is becoming larger and more players are
in the game world, the amounts of interaction will be increased and
thus trigger some more advanced playing style--like more complicate
organized communities and more transactions of virtual assets,
which will increase the fun of gaming. In addition, the granularity
of dynamic load balance could be adjusted according to real load
rather than the static game world partition.
[0010] For the advantages of the seamless game world, the way of
forming a seamless game world system is important. To form a
continuous game world: first, when the AOI (or visual range) of an
avatar on a game server crosses other servers, he can be aware of
entities on other servers which are still in his aura. Second,
avatars can migrate from one server into another seamlessly and
smoothly with a very small cost, and the continuity of the game
experience of the avatars is guaranteed.
[0011] Existing systems which provide this functionality use a
buffer zone method. By overlapping the cells on the border of the
region managed by a server with its adjacent server, the border
cells are used as the buffer zone. Once an avatar enters the border
zone, both servers will have a copy of an instance. This kind of
method is disclosed by Jiung-yao Huang,Yi-chang Du and Chien-Min
Wang in "Design of the Server Cluster to Support Avatar Migration"
(Proceedings of IEEE Virtual Reality 2003(VR'03), pp7-14, 2003).
For the complexity of this method, it always requires the map to be
regularly partitioned into a fixed size and shape beforehand, and
then chained with an interleaved-squaring method.
[0012] The main weaknesses of the buffered zone solution are: the
game map needs to be reconstructed, the map cell's shape and size
are also limited, and there is a paradox in dealing with the
dynamically changing AOI. If the maximum AOI is adopted as the
scope of overlapped area, it will increase the redundant computing
and communication load of them and reduce the overall resource
usage rate of the game server farm.
SUMMARY OF THE INVENTION
[0013] Therefore, an object of the present invention is to provide
a seamless game world system in which all players have a consistent
seamless game world view, and the operation method thereof, so that
when the AOI of an avatar on a game serve crosses other servers, he
can be aware of entities on other servers which are still in his
aura, and he can also migrate from one server into another
seamlessly.
[0014] In order to achieve the above and other objects of the
present invention, according to one aspect of the present
invention, a seamless game world system comprising a plurality of
game servers and at least a client is provided, each said game
logic server being assigned to a zone in the game world divided
into zones for executing all the computations required to manage
the status of the game world, said client being controlled by a
player to accept commands input from a remote game server, render
the player's view of the game world, and send keystroke, mouse or
controller commands across the network to signal an avatar's move
within the game, said avatar being an entity of the player in the
game world whose status is controlled by the user input,
characterized in that said seamless game world comprises: a game
logic computing module for computing an avatar's new status; a map
controller for detecting whether an area of interest of the avatar
has crossed the border of a host server of the avatar and spanned
neighbor game servers based on the avatar's new status computed by
said game logic computing module, and determining to make/delete a
clone on a neighbor game server or synchronize the clone's status
based on the detected result, said clone representing the
incarnation of a doer avatar on a neighbor server, said doer avatar
being an avatar with a clone avatar; and an avatar status update
module for performing a normal status update on the avatar based on
the computed result of the game logic computing module after the
map controller notices its neighbor game server to delete the clone
from an avatar list.
[0015] According to one aspect of the present invention, a method
for realizing a seamless game world for every player of a game
world, the game world being divided into zones, each zone being
assigned to a game server for management, a player controlling a
client to accept commands input from a remote game server, render
the player's view of the game world, and send keystroke, mouse or
controller commands across the network to signal an avatar's move
within the game, said avatar being an entity of the player in the
game world whose status is controlled by the user input,
characterized in that said method comprises the steps of: computing
an avatar's new status; detecting whether an area of interest of
the avatar has crossed the zone border of a host server of the
avatar and spanned neighbor game servers based on the computed
avatar's new status; determining to make/delete a clone on a
neighbor game server or synchronize the clone's status based on the
detected result, said clone representing the incarnation of a doer
avatar on a neighbor server, said doer avatar being an avatar with
a clone avatar; and performing a normal status update on the avatar
based on the computed result after deleting the clone from an
avatar list.
[0016] According to one aspect of the present invention, a computer
readable media containing instructions for executing the above
method is also provided.
[0017] The map controller can be implemented as a module which has
the responsibility to manage the clone and acts as the "hidden
hand" between the game application and players, so there is no
special requirement for the legacy game system, and different
avatar's view scopes can be changed flexibly and there is no
redundant clone avatar. In addition, the method according to the
present invention has no limitation on the map structure. It can be
easily adopted in the improvement of legacy games.
BRIEF DESCRIPTION OF THE DRAWINGS
[0018] Those skilled in the art can understand the present
invention better by referring to the drawings wherein like
reference numbers indicate similar or the same element(s)
throughout the drawings, in which:
[0019] FIG. 1 shows an example of a game world;
[0020] FIG. 2 shows a block diagram of the seamless game world
system according to the present invention;
[0021] FIG. 3 shows a block diagram of map controller 210 according
to the present invention;
[0022] FIG. 4 is a flowchart showing the complete status update of
the map controller 210 according to the present invention;
[0023] FIG. 5 is a schematic diagram showing, when an avatar's area
of interest spans a game server, a different game server updates a
corresponding area of interest to a client; and
[0024] FIG. 6 is a flowchart illustrating the operation of the map
controller 210.
DETAILED DESCRIPTION OF THE INVENTION
[0025] The following description is used to provide a detailed
depiction of an example of the present invention, and should not be
used to limit the present invention. In contrast, any number of
changes of the present invention may all fall into the invention
scope defined by the claims appended to the specification.
[0026] FIG. 2 shows a block diagram of a game server in the
seamless game world system using a map controller according to the
present invention. Referring to FIG. 2, the seamless game world
system using a map controller according to the present invention
comprises a plurality of game servers and at least one client (not
shown). The seamless game world system further comprises a game
logic computing module 200, a map controller 210 and a avatar
status update module 220. The map controller 210 is positioned
between a normal game logic computing module 200 and a player's
avatar status update module 220, and is integrated with the game
application runtime.
[0027] In the above seamless game world system using the map
controller 210 according to the present invention, to facilitate
the smooth avatar migration, when the AOI of an avatar moves out of
its zone and enters into one or more zones served by adjacent game
servers, clones of the avatar are created on the servers
corresponding to these zones. By the term "clone", the present
invention means the incarnation of the doer avatar on another
server. Actually, the doer avatar and its clone cannot be perceived
by a player, and are considered as the same object. The incarnation
is called "a clone" only for convenience of description.
[0028] Hereinafter, an avatar (doer avatar) that has a clone avatar
is called a doer. The main difference between a doer and a clone
lies in the following two aspects. On one hand, a doer is a
conventional avatar for which its host server computes its status
change and updates it to the client by using the game logic
computing module 200. The map controller 210 then updates its clone
avatar according to the computed new status. According to the map
neighboring relation, a doer avatar can have several clone
avatars.
[0029] On the other hand, a clone is a representative of a doer and
its host server does not compute its status by using the game logic
computing module 200. The host server for a clone only updates it
according to its new status received from the doer's host server.
The clone's host server also adds the clone to its player list, and
uses a tag to identify that it is a clone. In the status update
cycle, the clone avatar's host server updates the entities in the
clone's AOI to the client by using the map controller 210.
[0030] It should be noted that any change of status on a doer will
be synchronized to the clone(s) through the network protocol or
under the support of communication middleware.
[0031] To implement the function of the seamless game world system
of the present invention, the game logic computing module 200
computes an avatar's new status. After the game logic module 200
computes out the avatar's new status, the map controller 210 will
take the responsibility of handling the avatar's AOI change based
on the computation result of the game logic computing module 200.
The map controller 210 further has the capability of keeping a
unique status view for every avatar according to the policy of the
game world. To achieve this, the map controller 210 will monitor
the status change of an avatar, and detect whether or not the
avatar's AOI crosses the border of the avatar's host server and
spans to a neighbor server. Moreover, different from the way that
prescribes an overlap zone as the buffer zone, the map controller
210 makes clone avatars at neighbor servers according to the
individual avatar's AOI and other private policies. After making
clone avatars at neighbor servers, the map controller 210 will be
responsible for updating any change of the avatar to all clones.
Specifically, the doer avatar's host server computes out the
avatar's new status by using the game logic computing module 200,
and the map controller 210 will update it to all the clones. In the
doer avatar's update cycle, the server will update the avatar's AOI
on it to the client, and the neighbor server will also compute the
clone's AOI on it to the client. The detail of this process will be
explained later in conjunction with FIG. 5.
[0032] Once the avatar's AOI is no longer spanning the map of
neighboring servers, then the map controller 210 of the doer server
will notify its neighbors to delete the clone from the avatar list.
Then the avatar goes back to the normal computing and updating
status.
[0033] Once the avatar crosses the map border of its host server
and goes into the map of an immigrated server, then the map
controller 210 of the doer server will notice its peer on the
immigrated server, and the migration process is completed by
changing the avatar on the original into a clone avatar and
changing the immigrated server's agent avatar into a doer avatar.
When the avatar eventually migrates into the immigrated server, it
is then taken over by the immigrated server immediately since its
information already exists at the immigrated server.
[0034] FIG. 3 shows the block diagram of the map controller 210
according to the present invention. Referring to FIG. 3, the map
controller 210 consists of a clone detector 320, a clone planner
340, a clone plan sender 350, a clone plan receiver and manager 360
and a map information pool (i.e. a map-server table memory)
330.
[0035] The clone detector 320 is responsible for detecting whether
to make a clone, delete a clone or synchronize a clone's status.
Specifically, the clone detector 320 receives the avatar's newest
status from the game logic computing module 200 and makes a
decision about whether to make a clone, delete a clone or
synchronize a clone's status according to the information and
avatar setting in the map-server table memory 330.
[0036] If the clone detector 320 decides to make a clone, delete a
clone or update a clone's status, then the clone planner 340
generates a clone plan, which includes the participant neighbors
(destination) and the action(s) of: (1) adding a clone, (2)
deleting a clone, or (3) updating a clone status. To update a clone
status, the clone plan also includes the avatar's newest status to
be synchronized. Here every status has several different actions
corresponding to different neighbor game servers.
[0037] If the clone detector 320 decides not to make a clone,
delete a clone or update a clone's status, then no action of clone
adding, deleting or clone's status synchronizing is done, that is
to say, the clone planner 340 will do nothing in this case.
[0038] The clone plan sender 350 is responsible for sending action
commands to its neighbors. Specifically, the clone plan sender 350
first reads the plan's destination item (the neighbor's address),
then sends commands to different destinations through the network
protocol or via communication middleware.
[0039] The clone plan receiver and manager 360 is responsible for
collecting all its neighbor game server's clone plans sent by its
peers, and then doing the clone adding, deleting or status
synchronizing process according to the clone plan information.
[0040] The map-server table memory 330 is a persistent or temporary
storage that describes the server-map relationship and the neighbor
relationship between zone maps.
[0041] In an embodiment of the present invention, the map
controller 210 further comprises a game policy builder 310 and an
avatar policy database memory 315. The policy builder 310 collects
an avatar's policy layer information negotiated by the game logic
module 200 to build an avatar policy and store it in the avatar
policy database memory 315. The avatar policy includes the avatar's
view scope and other special information (such as landscape etc.)
which can be used to compute the avatar's AOI.
[0042] The map controller 210 is running on the same game
application runtime. The game application runtime supports the
avatar game logic process being executed as designed by the game
application. The map controller 210 begins its operation after the
avatar status computing module 200 computes the result, and does
not end the operation until the avatar status update module 220
begins to operate. The map controller 210 realizes the seamless
game world for every player of the game world.
[0043] The above functions of the map controller 210 can be
implemented by making it execute the steps shown in FIG. 4. FIG. 4
is a flowchart showing a complete status update. Referring to FIG.
4, at step S410, the map controller 210 monitors the status change
of an avatar, and detects whether or not the avatar's AOI crosses
the border of the avatar's host server and spans to neighbor game
servers.
[0044] If it is detected at step S410 that the avatar's AOI is
inside the border, i.e. the avatar's AOI does not cross the border
and does not span to neighbor game servers, then the process
proceeds to step S420, at which the map controller 210 notifies the
doer server to update the avatar's status according to the new
status of the avatar computed by the game logic computing module
200.
[0045] If it is detected at step S410 that the avatar's AOI crosses
the zone border of its host server and spans to neighbor game
servers, then the process proceeds to step S430, at which the map
controller 210 makes clones at neighbor servers according to the
individual avatar's AOI and other privacy policies.
[0046] Then the process proceeds to step S440, at which the doer
server computes out the avatar's new status by using the game logic
computing module 200, and synchronizes the clone's status by using
the map controller 210.
[0047] Next, the process proceeds to step S450, at which the doer
server and the neighbor game servers perform status updates on the
same avatar.
[0048] Next, the process proceeds to step S465, at which the map
controller 210 detects whether the avatar's AOI spans the map of
the one server and enters into the zone of an immigrated server. If
it is detected at step S465 that the avatar's AOI is no longer
spanning the map of the one server, then the process proceeds to
step S460, at which the map controller 210 will notify the neighbor
game servers to delete the clone from the avatar list. Then the
process returns to step S420.
[0049] If it is detected at step S465 that the avatar crosses the
zone border of its host server and goes into the zone of the
immigrated server, then the process proceeds to step S470, at which
the map controller 210 will notify its peer on the immigrated
server, and the migration process is completed by changing the
avatar that was the doer avatar into a clone avatar and changing
the immigrated server's agent avatar into a doer avatar.
[0050] Then the process proceeds to step S480, at which the
avatar's status is computed in the immigrated server and the status
update process is completed.
[0051] The detail of forming a seamless game world view by a player
will be described with respect to FIG. 5. FIG. 5 is a schematic
diagram showing, when an avatar's AOI spans a server, a different
server updates a corresponding AOI to a client. Referring to FIG.
5, once the map controller 210 finds that one avatar's AOI is out
of its zone, it then notifies the related neighbor peers to make a
clone.
[0052] The process that, in a doer avatar's update period, a server
updates an avatar's AOI on it to a client and a neighbor game
server computes a clone's AOI on it to the client will be described
in detail in conjunction with FIG. 5.
[0053] As shown in FIG. 5, the zone controlled by server A as a
doer server is indicated by a blank block, and the zone controlled
by sever B as a neighbor game server is indicated by a hatched
block.
[0054] Reference number 500 indicates a schematic diagram showing
that an avatar's AOI spans a server. In this schematic diagram,
zone 510 indicates the AOI of a player at position P1, and when the
player moves from position P1 to position P2, the AOI of the player
at position P2 is indicated by zone 520. It can be seen from the
diagram shown by reference number 500 that the AOI of the player at
position P2 spans the zone of the neighbor game server. In this
case, the map controller 210 will make a clone avatar in the
neighbor game server (server B), and synchronize the clone avatar's
status with the doer avatar's status.
[0055] In order to make a clone and synchronize a clone's status,
when a player moves from position P1 to position P2 and the AOI of
the player spans the zone of a neighbor game server, the commands
of the player will still be sent to server A.
[0056] Reference number 500' indicates a schematic diagram
illustrating the making of a clone and the synchronizing of a
clone's status. In this schematic diagram, zone 530 indicates the
part of an avatar's AOI in the zone controlled by server A, and
zone 540 indicates the part of the avatar's AOI in the zone
controlled by server B. Zone 530 is operated by a doer avatar, and
zone 540 is operated by a clone avatar. The player sends his
commands to server A. Server A processes the commands sent by the
player based on game logic and sends its status update message to
the doer avatar (a part of the view). In addition, during the
update of server B, the status update message is also sent to the
clone avatar (another part of the view), thereby to achieve the
object of updating a new avatar's AOI to a client. By the above
process, the client has a continuous view which is controlled by
server A and server B, respectively.
[0057] The method adopted by the map controller 210 is described in
detail in conjunction with FIG. 6 as follows. FIG. 6 is a flowchart
illustrating the operation of the map controller 210. Referring to
FIG. 6, at step S610, the map controller 210 calls the clone
detector 320 after the game logic computing module 200 receives a
player's command and computes the avatar's new status, so as to
make a decision on whether to make a clone, delete a clone or
synchronize a clone's status according to the computed avatar's
current status, its policies and the map-server table.
[0058] If it is decided at step S610 to make a clone, delete a
clone or update an existing clone's status, then the process
proceeds to step S620, at which the clone planner 340 generates a
clone plan, which includes the participant neighbors (destination)
and the action(s) of: (1) adding a clone, (2) deleting a clone, or
(3) updating a clone status. For the updating action, it also
includes the avatar's newest status that needs to be synchronized.
Every plan may have several different action items corresponding to
different neighbor game servers. Then the process proceeds to step
S630.
[0059] If it is decided at step S610 not to make a clone, delete a
clone, or update an existing clone's status, then the process goes
directly to step S640, at which the neighbor plan collecting and
handling process is done so as to collect the neighbor's clone
plans and perform corresponding processing according to the
commands of the collected clone plans.
[0060] At step S630, the clone plan sender 350 sends action
commands of the clone plans to its neighbors according to the
plans' destination items (of the neighbors) through network
protocol or via communication middleware. Then the process proceeds
to step S640.
[0061] Next at step S640, the plan receiver and manager 360
collects all its neighbor's plans sent by its peers, does the clone
adding, deleting or status synchronizing process according to the
clone plans. Then the process proceeds to step S650.
[0062] Next at step S650, after all the clone plans are executed at
step S640, in the doer's update cycle, its server updates the
avatar's AOI on it to the client, the clone server will also
compute the clone's AOI on it and update the information to the
client.
[0063] It can be seen from the description of the above embodiment
according to the present invention that, by adding the map
controller 210 between the game logic computing module 200 and the
avatar status updating module 220 of the legacy MMOG system, the
present invention enables all players to have a consistent seamless
game world view. When the AOI of an avatar spans the doer's server
of a non-player and arrives at other servers, the player can be
aware of avatars on other servers which are still in his aura. The
avatar can also migrate from one server into another
seamlessly.
[0064] The system and method according to the present invention can
support changeable and different avatar view scopes very flexibly
without a redundant clone avatar. Therefore it has less computing
and communication load than the legacy overlap zone approach.
[0065] The method according to the present invention also has no
limitation on the map structure. It can be easily adopted in the
improvement of legacy games.
[0066] In addition, the map controller 210 can be implemented as a
module which has the responsibility to manage the clone and acts as
the "hidden hand" between the game application and players, so
there are no special requirements for the legacy game system.
[0067] While the preferred embodiment of the present invention has
been described with respect to a hardware structure or method steps
in the above, the operation method of the MMOG system according to
the present invention can be implemented as computer program
software. For example, the method according to an exemplary
embodiment of the present invention can be embodied as a computer
program product, which enables a computer to execute one or more
exemplified methods. The computer program product may comprise a
computer readable medium containing computer program logic or codes
thereon for enabling the MMOG system to execute the MMOG according
to one or more exemplified methods.
[0068] The computer readable storage medium can be a built-in
medium in the computer body or a movable medium that can be
arranged so that it can be detached from the computer body.
Examples of the built-in medium include but are not limited to a
rewritable non-volatile memory, such as an RAM, an ROM, a flash
memory and a hard disk. Examples of the movable medium can include
but are not limited to an optical media such as CD-ROM and DVD; a
magneto-optic storage media such as MO; a magnetic storage media
such as a floppy disk (trademark), a cassette and a movable hard
disk; and a media with a built-in ROM such as an ROM box.
[0069] The program of the method according to the present invention
can also be provided in the form of externally-provided broadcast
signals and/or computer data signals included in a carrier wave.
The computer data signals embodied as one or more instructions or
functions of the exemplary method can be carried on the carrier
wave sent and/or received by the entity for executing the
instructions or functions of the exemplary method. Moreover, such a
program can be stored and distributed easily when recorded on a
computer readable storage media.
[0070] The above description is illustrative. Therefore any changes
without departing from the essence of the present invention are
intended to be within the scope of the present invention. Such
changes are not considered as departing from the spirit and scope
of the present invention as set forth on the appended claims.
* * * * *