US20060258462A1

US20060258462A1 - System and method of seamless game world based on server/client

Info

Publication number: US20060258462A1
Application number: US11/403,024
Authority: US
Inventors: Long Cheng; Yi Gil; Ling Shao; Mzng Yz
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2005-04-12
Filing date: 2006-04-12
Publication date: 2006-11-16
Also published as: CN1848124A; CN100492382C

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.

Description

FIELD OF THE INVENTION

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

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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

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.
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.
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.
According to one aspect of the present invention, a computer readable media containing instructions for executing the above method is also provided.
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

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:
FIG. 1 shows an example of a game world;
FIG. 2 shows a block diagram of the seamless game world system according to the present invention;
FIG. 3 shows a block diagram of map controller 210 according to the present invention;
FIG. 4 is a flowchart showing the complete status update of the map controller 210 according to the present invention;
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
FIG. 6 is a flowchart illustrating the operation of the map controller 210.

DETAILED DESCRIPTION OF THE INVENTION

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Next, the process proceeds to step S450, at which the doer server and the neighbor game servers perform status updates on the same avatar.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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.