U.S. Pat. No. 8,758,104

DETAILED DESCRIPTION

Now, exemplary embodiments will be described in detail with reference to the annexed drawings. In the drawings, the same or similar elements are denoted by the same reference numerals even though they are depicted in different drawings. In the following description, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

A system and method for transmitting P2P messages in a P2P-based multi-access online game system will hereinafter be described in detail.

FIG. 1is a block diagram illustrating a multi-access online game system based on a system and method for transmitting/receiving a P2P message according to one embodiment.

Preliminarily, it should be noted that the P2P message transmission system and method can be applied to a variety of multi-access online games, andFIG. 1shows but one example of the multi-access online game system capable of being applied to the embodiments described herein.

The embodiments exemplarily described herein can be applied to a variety of multi-access online games. Specifically, the effects of the embodiments exemplarily described herein can be maximized in the case of a multi-access online role-playing game in which a fast moving player character moves to transmit a plurality of messages.

For the convenience of description and better understanding, an exemplary case in which the above-mentioned P2P message transmission system and method is applied to the multi-access online role-playing racing game will hereinafter be described in detail. However, it should be noted that the scope and spirit of the present invention, as defined by the claims, is not applied to only the above-mentioned example, but can also be applied to not only a multi-access online role-playing racing game but also a variety of multi-access online games capable of enabling player characters to exchange their status information with each other.

Referring toFIG. 1, the multi-access online game system to which the above-mentioned P2P message transmission system and method is applied may include an authentication server100, a game server102, a database (DB) server104, and a plurality of real-time message processing servers106.

The authentication server100authenticates whether a user who desires to access the game system is an authorized user who has the authority of accessing the game system.

The authentication sever100receives authentication request information from the user client108, and determines whether the authentication request of the user client108is valid or not. The authentication request information may, for example, include a user ID and a password, and the authentication server100determines whether the ID and password contained in the authentication request information is valid or not.

In order to determine whether the ID and password of the user is valid, the authentication server100may communicate with the DB server104, or may communicate with other DBs (not shown) storing authentication information.

In order to perform the aforementioned authentication between the user client108and the authentication server100, not only the above-mentioned authentication based on the ID/password information, but also a variety of authentication methods well known to those skilled in the art, can also be employed.

If it is determined that the authentication request information of the user client108is valid, the authentication server100permits a corresponding user client108to access the game server102.

The game server102processes game messages of the user client108, and controls the progression of game. The game server102receives a variety of game messages, for example, game command messages such as attack or moving messages of player characters, chatting messages between user clients108, quest messages such as quest-acceptance or completion, and status information messages such as level-up or item acquisition of the player characters, so that the game server102conducts the received game messages according to a predetermined game logic.

For example, upon receiving the attack message against a specific object from the user client108, the game server102transmits attack information against the specific object to other user clients108.

In another example, upon receiving the status information message such as the level-up message of each player, the game server102transmits the level-up information of the user to the DB server104, so that it updates level information of the corresponding user with new information.

In the case of the multi-access online racing game, the game server102may provide simulation information of situations encountered during the game. For example, if player character cars collide with each other or an unexpected collision between the character car and the NPC (None Player Character) car occurs, the game server102provides associated user clients108with simulation information caused by the collision.

Specifically, the game server102transmits event information created by a specific user to other user clients, so that a plurality of users can share a variety of events (e.g., status change-, attack-, collide-, and moving-messages of the player characters) encountered during the game with each other.

For example, if the player character car collides with the NPC car within a specific area, the game server102calculates simulation caused by the collision, and transmits the simulation calculation information to not only the user client108of the collided player character car, but also other user clients108of peripheral character cars capable of viewing the collision situation.

In other words, the game server102must transmit events created in specific player characters to the user clients108of peripheral player characters, so that it transmits event creation information associated with a single event to N user clients108. This event creation information is one of the important factors aggravating a load of the game server102.

Several real-time message processing servers106perform processing of messages needed to be real-time processed from among messages transmitted from the user clients108.

According to one embodiment, information messages (e.g., character status information such as a character level-up or quest information) having the low necessity of being real-time transmitted to peripheral user characters, but which must be stored in the DB server104, are processed by the game server102.

For example, in the case of a specific game in which the character car moves fast as in the racing game and the collision between the character cars frequently occurs, provided that the moving message and the collision message are conducted by the real-time message processing server106, the message-processing efficiency can be maximized.

In other words, the game server102and the real-time message processing server106share messages according to message categories, so that the messages can be effectively distributed to the game server102and the real-time message processing server106.

However, the above-mentioned system and method for transmitting the P2P message in a multi-access online game described above is not limited to only the message-distributed processing system, but can also be applied to the system capable of conducting messages by a single game server.

The DB server104stores information associated with the game, replies to the request of the game server102or the user client108, and provides the stored information to the game server102or the user client108.

The DB server104may store status information of player characters, item information, and quest information, etc. If the DB server104receives character status-, item-, and quest-information from the game server102, it stores corresponding information.

The game application for executing the game is installed into each user client108which gains access to the game system over the network. The user client108may include all kinds of devices, which can communicate with a target object over the network and can execute the game application. For example, the user client108may include personal terminals (e.g., a general PC, a notebook computer, a PDA, and a mobile phone, etc.).

As described above, most loads encountered by the online game are created by messages transmitted from the servers102and106to the user client108, and there is needed a method for minimizing the number of message packets transmitted from the servers102and106to the client108, and the size of the message packets.

According to some embodiments, predetermined messages from among messages relayed by the real-time message processing server106are directly exchanged between the user clients according to the P2P scheme.

In one embodiment, the directly-exchanged messages between the user clients108according to the P2P scheme is mainly processed by the real-time message processing server106so that the directly-exchanged messages are considered to be the highly real-time processing necessity by the real-time message processing server106.

For example, the moving messages or collision messages created during the online racing game may be directly exchanged between the user clients108according to the P2P communication scheme. However, it should be noted that the scope and spirit of the P2P-based exchanged messages exemplarily described herein are not limited to the above-mentioned example, and it will be appreciated by those skilled in the art that the P2P-based exchanged message categories may become more diverse as necessary.

In order to more correctly display the moving status of a specific character car during the online racing game, the moving messages must be transmitted to a destination at intervals of a short period of time. However, due to the load problems of the game server102or the real-time message processing server106, the game server102or the real-time message processing server106may have difficulty in transmitting the moving messages at intervals of a short period of time.

In the case of using the P2P message transmission, although the moving message which has been delivered at intervals of 0.5 second is delivered at intervals of 0.1 second, the game server102or the real-time message processing server106may not encounter excessive load, so that the above-mentioned problem is solved.

The system and method for allowing the P2P message to be exchanged between the user clients108in the online game will hereinafter be described with reference to the annexed drawings.

FIG. 2is a block diagram illustrating modules of a game server according to an embodiment of the present invention.

Referring toFIG. 2, the game server102according to one embodiment may include a plurality of player objects200, a channel manager202, a game logic controller204, a message controller206, an online-user character information manager208, an NPC manager210, a quest manager212, an item manager214, a character manager216, and a guild manager218.

The player object200controls transmission/reception of messages between user clients108accessing the game server102. If a user client108gains access to the game server102, a player object200is created. If the connection between the game server102and the user client108is severed, the player object200disappears.

The player object200transmits game messages received from the user client108to the message controller206. Upon receiving the game messages of the game server102from the message controller206, the player object200transmits the received game messages to the corresponding user client108.

The channel manager202forms a channel via which some users may participate in the multi-access online game, and manages the formed channel. For example, in the case of the multi-access online role-playing game, the channel manager202can create a channel through which some users can enjoy racing with others separately from the simulated environment implemented in the role-playing game.

The message controller206receives game-associated messages created by the user client108from the player object200, and distributes the received messages to constituent components which will deal with the received message.

For example, if a wearing-item change message of a specific user character is received from the player object200, the message controller206transmits the received wearing-item change message to the item manager204and the character manager206. If the received message is a quest acceptance message of a specific user, the message controller206transmits a quest acceptance message to the quest manager212.

If the message controller206desires to transmit a message to the accessed user client108, it transmits the corresponding message to the player object200associated with the corresponding user client108.

For example, if the chatting message for a specific user is received in the message controller206, the message controller206transmits the chatting message to the player object200associated with a receiving user who receives the chatting message, so that the chatting message can be transmitted to the corresponding user client108.

In another example, upon receiving a collision message of a specific user character car, the message controller206determines users of character cars located at points at which the user can view the collision, and transmits the collision scene and the simulation information associated with the collision to the corresponding user clients108.

The online user character information manager208manages character information of online users who access the game server102. The character information of online users may include details information of the characters, for example, location-, level-, and item-information of the online user characters.

The information of the online user character information manager208is used when the message controller determines information of a message receiver. For example, if a specific user changes a current character-wearing item to another item, the wearing-item change information must be transmitted to peripheral users other than the specific user.

In this case, the message controller206extracts peripheral user characters other than the specific user character, who has changed the wearing item to another item, using the information managed by the online user character information manager208, and transmits a wearing-item change message to the player objects200of the corresponding user characters.

In another example, if a specific user character moves to another location, the message controller206extracts peripheral user characters other than the above character has moved from the online user character information manager208, and transmits the moving message to the player object200corresponding to the above user character.

If the message controller206receives status change messages (e.g., moving messages, wearing-item change messages, collision messages, etc.) of a specific user character, it transmits the status change information to the online user character information manager208, such that it manages the status information of the online-mode character.

The NPC manager210manages NPC information appearing in the game. For example, in the case of the racing game, the NPC manager210manages NPC information for quest provision, and information of any traffic car appearing in the game. In the case of a typical multi-access online role-playing game, the NPC manager may include information of any monster appearing in each area.

The quest manager212manages quest information provided to users in the multi-access online game, and also manages quest acceptance- or quest completion-information.

If a specific user accepts a specific quest, the quest acceptance message is transmitted to the message controller206, and the message controller206transmits the quest acceptance message to the quest manager212.

The quest manager212transmits the quest acceptance information to the DB server104, so that the quest acceptance information is reflected in the DB server104. In the case of the quest completion message, the quest completion message is reflected in the DB server104by the quest manager in the same manner as in the above quest acceptance message.

The item manager214manages not only information of items created during the game, but also user-character item change information (e.g., item acquisition or item drop) of the user character.

If a specific user character acquires the item, the item acquisition message is transmitted to the message controller206, and the message controller206transmits the item acquisition message to the item manager204. The item manager214transmits the item acquisition information to the DB server104, so that the item acquisition information can be reflected in the DB server104.

The character manager216manages information of characters created by the users, receives status-change messages of the characters, and transmits the received status-change messages (e.g., a character level-up message and item acquisition information) to the DB server104.

The guild manager218manages information of a guild created by the multi-access online game users. The guild manager218receives guild-associated messages, for example, registration/withdrawal messages of guild members and level-change messages of the guild members. And, the guild manager218transmits the guild-associated information contained in the received message to the DB server104. If there is guild-associated quest information such as a guild-member status or guild-member name, the guild manager218communicates with the DB server104to provide guild information.

FIG. 3is a block diagram illustrating a real-time message processing server according to one embodiment.

Referring toFIG. 3, the real-time message processing server106according to one embodiment may include a player object300, a game logic controller302, a message controller304, and an online user information manager306.

As stated above, the real-time message processing server106is adapted to share roles of the game server102, and conducts messages (e.g., collision messages) needed to be immediately transmitted to a destination.

Therefore, the real-time message processing server106may include some parts of constituent components of the game server102. However, the real-time message processing server106may not include the quest manager212, the item manager214, the character manager216, and the guild manager218, which are needed to communicate with the DB server104.

However, the real-time message processing server106may conduct the messages reflected in the DB server104as necessary. In this case, the real-time message processing server106includes all the constituent components, so that it may have the same structure as that of the game server102.

The roles of individual constituent components of the real-time message processing server106are the same as those of the game server102, so that their detailed description will herein be omitted for the convenience of description.

Upon receiving the moving message needed to be processed in real time, the message controller304extracts information of an online user character who will receive the moving message using the information of the online user character information manager306. The message controller304transmits the moving message to the player object300corresponding to the online user who will receive the moving message. The player object300transmits the moving message to the corresponding user.

FIG. 4is a block diagram illustrating a game application installed in a user client according to one embodiment.

Referring toFIG. 4, the game application according to the present invention may include a command interpreter400, a game logic processor402, a server communication unit404, a P2P transceiver406, and a game-data extractor408.

The command interpreter400receives game command information inputted by the user, interprets the game command, and transmits the interpreted information to the game logic processor402. For example, the game command interpreter400determines whether the user-entry game command is a quest acceptance command or a moving command, and transmits the interpreted information to the game logic processor402.

The game logic processor402executes a predetermined game logic according to the game command inputted by the user.

If the game command has no need to be transmitted to the servers102and106as in the game environment setup command, the game logic processor402conducts a game environment setup process in the client.

If the game command is determined to be a specific command needed to be transmitted to the servers102and106as the moving message, the game logic processor402creates a moving message corresponding to the moving command, and transmits the moving message to the server communication unit404.

The server communication unit404transmits the game message created from the game logic processor402to the game server102or the real-time message processing server106. And, the server communication unit404transmits the game message transmitted from the real-time message processing server106to the game logic processor402.

The server communication unit404determines whether the message created from the game logic processor402is a first message to be transmitted to the game server102or a second message to be transmitted to the real-time message processing server106, and transmits the game message to the determined server102or106.

The game data extractor408extracts game data needed to execute the game. For example, upon receiving a control signal of the game logic processor402according to the user's game command, the game data extractor408extracts map data and character information data, and transmits the extracted data to the game logic processor402.

The P2P transceiver406transmits or receives the P2P message to/from other user clients accessing the game. The P2P transceiver406directly transmits the message needed to be immediately transmitted to other user clients as the collision message to a corresponding user client, or receives the P2P message from other user clients.

The P2P transceiver406selects another user client who will receive the messages according to the P2P scheme, and transmits the P2P message to the selected user client to immediately transmit the moving message and so on. Since the moving information of the user character must be managed by the servers102and106, the moving information is transmitted to the servers102and106as the P2P message, and the moving message, and the moving message is transmitted from the server communication unit404to the servers102and106.

If the moving message of the user client “A” is transmitted to another user client “B” according to the P2P scheme, the user client “B” has no need to receive the moving message of the user client A from the servers102and106.

In this case, the P2P transceiver of the game application contained in the user client “B” creates a cutoff request message for blocking transmission of the moving message transmitted from the user client “A”, and transmits the cutoff request message to the servers102and106.

If the servers102and106receive the above-mentioned cutoff request message, the moving message of the user client “A” is not transmitted to the other user client “B”. Therefore, the number of messages for the user clients which encounter the largest load in the servers102and106can be effectively reduced.

Exemplary configurations and operations of the P2P transceiver will hereinafter be described with reference toFIG. 6.

FIG. 6is a block diagram illustrating modules of the P2P transceiver according to one embodiment.

Referring toFIG. 6, the P2P transceiver according to one embodiment may include a P2P-object selector600, a P2P test unit602, a guaranteed-time calculator604, a cutoff request message generator606, and a P2P message generator608.

The P2P-object selector600selects an object client needed to receive the P2P message from among several clients. According to one embodiment, the P2P-object selector600determines user clients of peripheral characters located in the vicinity of the client character transmitting the P2P message as the reception-object clients on the basis of location information of other user characters. A specific character spaced apart from character of the user client transmitting P2P message by a predetermined distance has the low necessity of real-time-viewing the moving- and collision-information of user client transmitting the P2P message, so that the P2P-object selector600primarily selects only the user clients of characters located within a predetermined distance as transmission objects of the P2P message.

The P2P test unit602tests whether the P2P reception object clients selected on the basis of the location information can receive the P2P message. If a firewall is installed or a network address translation (NAT) function is used in the P2P reception object clients, the P2P test unit602may have difficulty in smoothly transmitting the P2P message. In order to cope with the above-mentioned situation, the P2P test unit602tests whether the P2P message can be transmitted or received to/form the primarily selected reception object clients. The P2P test unit602may test whether the P2P message can be received using a method for transmitting a test signal.

The P2P-object selector600primarily selects the P2P reception-object client, and finally selects the P2P reception-object client according to the test result of the P2P test unit602. In other words, the P2P-object selector600selects only some clients, capable of receiving the P2P message by the test of the P2P test unit602, from among the primarily-selected P2P reception-object clients, and finally determines the selected clients to be the P2P reception-object clients.

The guaranteed-time calculator604calculates a guaranteed time of the P2P transmission during transmission of the P2P message. In this case, the guaranteed time indicates a predetermined time which it is guaranteed that the client transmitting the P2P message transmits the P2P message to the client receiving the P2P message.

The client transmitting the P2P message calculates a guaranteed time in consideration of a network connection status between the client transmitting the P2P message and the client receiving the P2P message and other factors, inserts the calculated guaranteed time information into the P2P message, and transmits the resultant P2P message. In this case, the guaranteed time may be denoted by a consumed time such as ˜seconds, or may be denoted by an absolute time such as ˜minutes and ˜hours.

The guaranteed time is used as a time during which the client receiving the P2P message requests the message cutoff action from the servers102and106. The client receiving the P2P message requests that the servers102and106blocks the moving message from being generated from the client transmitting the P2P message by the guaranteed time contained in the P2P message.

If the cutoff request message generator606receives the P2P message from other clients, it generates a cutoff request message using the guaranteed time contained in the P2P message.

FIG. 8is a conceptual diagram illustrating fields of cutoff request message according to one embodiment.

Referring toFIG. 8, the cutoff request message according to the present invention may include a message header field800, a transmission client field802, and a cutoff time field804.

The message header field800includes predetermined identification information via which the servers102and106can identify whether a corresponding message is a cutoff request message.

The transmission client field802includes specific information capable of identifying whether message transmission from any client is blocked or not. The transmission client field may record address information of the transmission client (e.g., IP address), and may record a variety of information capable of identifying other transmission clients.

The guaranteed time information contained in the P2P message is recorded in the cutoff time field804. The servers102and106block transmission of a message supplied from the client recorded in the transmission client field by a predetermined time contained in the cutoff time field.

Referring toFIG. 6, the P2P message generator608generates the P2P message to be transmitted to the P2P reception-object client selected by the P2P-object selector, and then transmits the P2P message.

FIG. 7is a conceptual diagram illustrating fields of a P2P message according to one embodiment.

Referring toFIG. 7, the P2P message according to one embodiment may include a P2P identification header field700, a message header field702, a message data field704, an address field706, and a guaranteed time field708.

The P2P identification header field700includes predetermined ID information capable of identifying whether a corresponding message is directly transmitted by the P2P scheme without passing through the servers102and106.

The message header field702includes predetermined ID information for identifying message category information. For example, ID information for identifying whether the message is a moving message or collision message is recorded in the message header field702.

The message data field704includes data information associated with the message category information. For example, if it is determined that the message is the moving message, coordinate information of a specific point to which the character moves may be contained in the message data field.

ID information of the P2P message transmission client is recorded in the address field706. As described above, the address field706may have address information of the transmission client. The guaranteed-time field708includes guaranteed time information calculated by the guaranteed time calculator604.

Information of the transmission client field706and information of the guaranteed time field708are used when the client receiving the P2P message generates the cutoff request message.

In order to transmit the P2P message to the reception-object client, the user must recognize the address information (e.g., IP address) of the reception-object client. According to one embodiment, the server102or106includes the address information of the reception-object client in the message associated with the reception-object client, such that it can correctly recognize the address information of the reception-object client. Otherwise, the user may request the address information of the reception-object client from the server102or106, and may receive the requested address information from the server102or106, so that the user can recognize the address information of the reception-object client.

According to one embodiment, the P2P message may be a UDP protocol packet. However, the P2P message is not limited to only the UDP protocol packet, and other protocol packets may also be applied to the P2P message.

FIG. 5is a block diagram illustrating modules of the player object according to one embodiment.

Referring toFIG. 5, the player object200or300may include a cutoff request message interpreter500, a cutoff time monitoring unit502, and a message cutoff unit504.

Upon receiving the cutoff request message from the client accessing the server102or106, the cutoff request message interpreter500interprets the received cutoff request message. The cutoff request message interpreter500analyzes the cutoff request message, and extracts a cutoff time and transmission client information for the message cutoff action.

Upon receiving the transmission client message contained in the cutoff request message from the message controller206, the message cutoff unit504blocks a corresponding message.

The cutoff time monitoring unit502checks a cutoff time contained in the cutoff request message, and allows the message to be blocked during only the cutoff time. If the cutoff time is updated by the arrival of a new cutoff request message, the cutoff time monitoring unit502monitors the cutoff time according to the updated cutoff time.

FIG. 9is a flow chart illustrating a method for transmitting the P2P message in an online game according to one embodiment.

Referring toFIG. 9, the game application installed in the user client primarily selects the reception-object client which will receive the message using the P2P scheme at step S900. As described above, the P2P reception-object client can be selected using the location information of other user characters of the game.

If the P2P reception-object client has been primarily selected, it is determined whether the selected reception-object client is able to receive the P2P message at step S902. Thereafter, it is determined whether the test is successful or not at step S904. If it is determined that the P2P test for the reception-object client fails at step S904, the corresponding reception-object client is removed from the P2P reception-object list at step S906.

Otherwise, if the P2P test result for the reception-object client is successful at step S904, the corresponding reception-object client is finally registered in the P2P reception object list at step S908.

If an event for transmitting the P2P message to the P2P reception-object client occurs due to the movement of the transmission client character at step S910, the guaranteed time for the P2P message is calculated at step S912.

If the guaranteed time is calculated at step S912, the P2P message including the guaranteed time is created and is then transmitted to the P2P reception-object clients at step S914.

In order to provide the user with detailed information of moving situation information of the racing game, the P2P message may be transmitted to other user clients at intervals of a predetermined time earlier than a message-providing time of the game server102or the real-time message processing server106.

FIG. 10is a flow chart illustrating a method for transmitting a cutoff request message to the server upon receiving the P2P message, and allowing the server to process the cutoff request message.

Referring toFIG. 10, when the P2P message is received, the game application installed in the client receiving the P2P message extracts transmission client information and guaranteed time information contained in the P2P message at step S1000.

After extracting the transmission client information and the guaranteed time information, the game application generates a cutoff request message (seeFIG. 8) in which the extracted guaranteed time is set to a cutoff time at step S1002.

If the cutoff request message is generated, this cutoff request message is transmitted to the servers102and106at step S1004.

The player object of each server102or106having received the cutoff request message analyzes the cutoff request message, and extracts client information for blocking the message transmission and cutoff time information at step S1006.

The player objects200and300determine whether the transmission of the messages provided from the message controllers206and304should be blocked. If it is determined that the above-mentioned messages of the message controllers206and304are to be transmitted to the client for blocking the message transmission, the player object200and300blocks the transmission of the corresponding messages at step S1008.

As apparent from the above description, the P2P message transmission system exemplarily described above allows user clients to transmit/receive some parts of transmission messages of the game server, resulting in reduction of load of the game server.

Also, the P2P message transmission system exemplarily described above selects some messages needed to be real-time-processed, and enables the selected messages to be exchanged between user clients, so that the efficiency of using the P2P message in the multi-access online game is maximized.

Although the embodiments of the invention have been disclosed above for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, without departing from the scope and spirit of the invention as disclosed in the accompanying claims.