U.S. Pat. No. 7,806,768

BEST MODE FOR CARRYING OUT THE INVENTION

Overall Configuration:

FIG. 1is a block diagram showing a communication system that is provided with a game system according to an embodiment of the present invention. The communication system has a large number of game devices1, a large number of cards2, a game server device3connected to the Internet5, and a large number of terminal devices4. This game system has plural game devices1, from among the large number of game devices1, that are mutually associated with one another as participants of a game with multiple players, and the game system has the game server device3. In the game system, the plural game devices1mutually communicate with one another, so that the players of the game devices are able to play a game with multiple players.

Game device1is a terminal that enables a player to play a predetermined game by paying a fee. Game device1is connected to the Internet5and is capable of performing data communication with game server device3through the Internet5. One or more game devices1are installed at a shop or a venue (game arcade) where visitors are able to use game devices1. A player operates a game device1that the player is using, to thereby play a game with multiple players.

Card2is a portable information recording medium that magnetically records information, and it records a card ID (identification information) identifying the card itself. Although described later in detail, the card ID is read by game device1and is used at game server device3. A player can own one or more cards2and can select one of that player's own cards2for use in a play of a game with multiple players.

Game server device3is a computer that retains individual information of players. Although described later in detail, individual information includes message information representing contents of messages such as quotes used by a player in a game with multiple players. Game server device3may include a single computer or plural functionally dispersed, network-connected computers. Game server device3is capable of performing data communication with a correspondent device via the Internet5.

Terminal device4is a computer that, by being operated by a player, edits and updates message information retained at game server device3, and the terminal4functions as a portable telephone capable of using, via base stations (BS)61, a mobile communication network6which provides data communication and telephone communication services. Base stations61are dispersed so as to cover a service area of mobile communication network6in cooperation with one another, and each base station61is capable of wirelessly communicating with terminal device4located within an area which each base station61covers. Mobile communication network6is connected to the Internet5through a gateway7and is capable of providing a mobile internet access service. The “mobile internet access service” is a service that enables interactive communication between a mobile communication terminal such as a portable telephone service and a website on the Internet. According to this service, a mobile communication terminal is able to display characters and images provided from the site on its display and also to download an application program from the site. Examples of mobile internet access services include, for example, an “i-mode®” service developed by NTT DoCoMo Inc., Tokyo, Japan, and a service in accordance with a “WAP (Wireless Application Protocol)” developed by the WAP Forum. Gateway7converts a communication protocol of mobile communication network6into that of the Internet5, and vice versa. Specifically, gateway7is, for example, an i-mode server in the i-mode service or a WAP proxy (WAP gateway) in the WAP service. Each terminal device4is capable of performing data communication with game server device3via mobile communication network6and the Internet5.

Overview:

FIG. 2is a state transition diagram showing operations of the communication system ofFIG. 1in a simplified manner.

As described above, there is retained message information in game server device3, and a player is able to use terminal device4of the player and to edit and update message information of the player. There is shown in the figure an example of Player A's editing message information of the player. The editing can be performed in an optional period as long as relevant message information is retained in game server device3. The editable period varies depending on operations of game device1and game server device3. In the following, description will be given of the operations, focusing on a case in which Players A to C play the same game with multiple players.

Before the start of the game with multiple players, message information of Player A retained in game server device3is delivered to game device1used by Player A for storage therein. The message information is then delivered from Player A's game device1to each of game devices1used by the other two players so as to be stored in each game device1. In the same way, message information of Player B is shared among the three game devices1, and message information of Player C is shared among the three game devices1. Thus, message information respectively of Players A to C is shared among the three game devices1.

After the game with multiple players is started, each game device1attempts to detect various events that are predetermined. It is now assumed that one of the events is detected at game device1used by Player A. This game device1displays a message represented by message information of Player A stored therein, whereas the game device1requests the other two game devices1to display the same message. Each of the other two game devices1, upon receiving the request, displays the message represented by message information of Player A stored therein. The message of Player A is thus conveyed to Players B and C.

Configuration of Game Server Device3:

FIG. 3is a block diagram showing a configuration of game server device3.

Game server device3manages individual information of players and has a CPU (central processing unit)31, a communication interface32, and a storage unit33. Communication interface32relays data between processor31and the Internet5, and processor31communicates with game device1through communication interface32. Storage unit33has a ROM (Read Only Memory) in which an IPL (Initial Program Loader) is written, has a RAM (Random Access Memory) used as a work area, and has a hard disk in which an individual information table T and an entry list L are stored. On the hard disk, there has been written a program that guides various processes described below. Processor31reads the IPL from ROM for execution, to thereby read the program from the hard disk for execution. In the following description on operations, it is assumed that the program has already been executed.

FIG. 4is a diagram showing a data structure of the information table T stored in the game server device ofFIG. 3.

There have been stored in the information table T a pair of a player ID (integrated identification information) and a card ID in association with individual information. The player ID is an identifier unique to a player and is assigned to the player by a game operator in advance. Individual information is associated with a pair of a player ID and a card ID so as to enable a single player to use more than one card. A plurality of card IDs therefore can be associated with one player ID. It is certainly possible to configure the system so that a single card ID is associated with a single player ID. In this case, either a player ID or a card ID alone may be used. In either case, the fact remains that a card ID is information identifying a player because a player ID is uniquely determined when a single card ID is identified. Individual information is information relating to a player and includes a card name, an image identifier, and message information M. The card name may be a nickname which the player has given to the card and is used as a player name in the game with multiple players. The image identifier may be an identifier of a character image which is displayed as a visual image of the player in the game with multiple players, and the image identifier is specified by the player in advance.

FIG. 5is a diagram showing a data structure of message information M for one card ID in the individual information table ofFIG. 4.

Message information M for one card ID has a structure in which plural message data units are associated with message IDs identifying each of the plurality of message data units. Each message data unit is text data representing contents of a message and is used when displaying the message. In the present embodiment, the number of messages contained in the message information M for one card ID is 7, which is the same as the number of types of events described later.

Configuration of Game Device1:

FIG. 6is a block diagram showing a configuration of game device1of the communication system ofFIG. 1. Game device1has a processor11, a coin hopper12, a card reading device (reader)13, an input device (inputter)14, a display device15, a speaker16, and a communication interface17, and a storage unit18.

Coin hopper12distinguishes coins inserted through a coin acceptance slot (not shown) formed on a body of game device1, and the hopper accepts a coin if the coin is of a predetermined type and supplies a coin acceptance signal to processor11. The predetermined type of coin is something which has a value corresponding to a game play charge with one or more pieces and is, for example, hard currency (money).

There is formed in card reading device13a card acceptance slot (not shown) for inserting a card2. Card reading device13, when card2is inserted from the card acceptance slot, reads a card ID from card2to supply a signal indicating the card ID to processor11.

Input device14has plural operators, and when an operator is operated, supplies processor11with a signal that is unique to the operator.

Display device15displays a game start screen and a game screen after receiving image data from processor11. Description will now be given of the game start screen and the game screen.

FIG. 7is a diagram showing an example of a game start screen displayed on display device15.

The game start screen is a screen that is displayed at the start of a game with multiple players, and the start screen has an area for each of players who will play a game with multiple players about to be started. In each area, a player name, a reduced image of a character image, and a self-introduction message are positioned. The player name is a name of a player and is identical to a card name of card2used in the play. The self-introduction message is a type of a message and is displayed upon detecting the start of a game with multiple players.

FIG. 8is an example of a game screen displayed on display device15.

A play of a game with multiple players starts when a play of a music piece is started, and the game ends when the music ends. There is positioned, in a central portion of the game screen displayed during the play, an image showing how objects OB appear in an upper portion of the figure, fall, and disappear in a lower portion of the figure to the music. There exists, slightly above a point at which objects OB disappear, a horizontal line HL orthogonal to a falling direction of objects OB. A player should operate a play button corresponding to a current position of an object OB at a time in which the object OB overlaps with the horizontal line HL, and in a case in which the player does so, this game device1outputs a sound corresponding to the object OB. A selected music piece is more accurately reproduced if a player's operation is performed at a more suitable timing and with a more suitable content.

In the lower portion of the game screen, there are shown images indicating current conditions of a play such as the player's score. The score is increased when an appropriate operation is performed at an appropriate timing. Specifically, the score increases if, when an object OB overlaps with the horizontal line HL, an operation corresponding to the object OB is performed. In a case in which a particular type of an object OB overlaps the horizontal line HL and an operation corresponding to the object OB is performed, an attack (interference) is made on an opponent participant, the type of the attack corresponding to current or previous situations of the play.

In the left portion of the game screen, there is shown a character image selected from among a prepared set of plural candidates, the selection being made by a current player of the game device. In the right portion of the game screen, an area is reserved for displaying a player name, a current score, a current quote, and a partial image of a character image for each of the player and the other players of the game that is being played. In a case in which the above message is a quote, a player's message is displayed in an area reserved for the same player. A partial image of the character image is obtained by clipping a part from a reduced image of a character image selected by a participant of a game being played.

The description now returns to the configuration of game device1.

Speaker16outputs sounds after receiving music sound signals from processor11.

Communication interface17is connected to the Internet5directly or via a relay device such as a router and relays data between processor11and the Internet5.

Storage unit18has a nonvolatile memory such as a ROM (Read Only Memory) and has a rewritable memory such as a RAM (Random Access Memory).

In the rewritable memory, there are held a personal information storage area181, an opponent information storage area182, an address area, and a message ID area184. Personal information storage area181is a memory area for storing individual information of a player currently using this game device1. Opponent information storage area182is a memory area for storing individual information of an opponent participant and for storing a communication address of game device1that is being used by the another player. Address area183is a memory area for storing a communication address of this game device1. For example, an IP (Internet Protocol) address and a port number are used as a communication address. In a case in which a fixed IP address is assigned, address area183should be reserved in a nonvolatile memory. Message ID area185is a storage area for storing, for each of the other participants, a message ID to be displayed and to be transmitted.

There has been written in the nonvolatile memory a conversion table184. Conversion table184associates an event ID for identifying each of plural predetermined types of events with the above message ID. A message ID is uniquely determined when one event ID is specified. Predetermined events to be detected at game device1include an event in which a game with multiple players was started, an event in which a player of this game device1played well, an event in which the player played poorly, an event in which the player made an attack, an event in which the player was attacked and damaged, an event in which the player won the game, and an event in which the player lost the game.

There has been written in the nonvolatile memory a game program186. Processor11executes game program186, so as to thereby guide an authentication process, a message identifying process, a message displaying process, a transmission process, and a receiving process, which will be described later in the specification. In a game with multiple players, the above conversion table184is used to convert an event ID into a message ID. In the description of operations below, it is assumed that game program18has already been executed.

Configuration of Terminal Device4:

FIG. 9is a block diagram showing a configuration of terminal device4of the communication system ofFIG. 1.

Terminal device4has a processor41, a microphone42, a speaker43, an input device (inputter)44, a display device (display)45, a wireless communication interface46, and a storage unit47. It should be noted that this configuration is adopted because terminal device4functions as a portable telephone as described above. The present invention can be implemented in an embodiment in which another computer (e.g., a personal computer) is used as a terminal device. In this case, the configuration of the terminal device is not entirely the same as the above configuration of terminal device4in which it is a portable phone.

Microphone42is used for voice communication, and it picks up voice sounds of a user and supplies the picked up sounds to processor41.

Speaker43is used for voice communication, and it outputs sounds after receiving voice sound signals from processor41.

Input device44has plural buttons operated by a user, and when a button is pressed down, it supplies a signal unique to the pressed button to processor41. The plurality of buttons includes a button used for inputting data and a button used for inputting instructions.

Display device45displays an edit screen after receiving image data from processor41.

Wireless communication interface46relays data between processor41and base stations61. Communication paths between wireless communication interface46and base stations61are wireless communication paths.

Storage unit47has a RAM, ROM, and EEPROM (Electrically Erasable Programmable ROM). There is stored in the ROM an operating system of terminal device4, and the operating system is executed when terminal device4is started. This operating system is for providing terminal device4with a telephone communication function and a data communication function, a function of downloading other programs from the Internet5, and a function of executing a downloaded program. There is reserved in EEPROM a program area471for storing downloaded programs. In program area471, a control program that guides an edit process described below is stored. In the description of operations below, it is assumed that the control program has already been executed. Examples of control programs that can be downloaded by the mobile internet access service and that can be executed by a portable telephone terminal are as follows: i-appli® for i-mode compatible portable terminals, an application program operable at a portable terminal in accordance with BREW® (Binary Runtime Environment for Wireless) developed by Qualcomm Incorporated, San Diego, Calif., USA, and an application program operable at a portable terminal in accordance with MIDP (Mobile Information Device Profile) for J2ME® CLDC (Java® 2 Micro Edition Connected Limited Device Configuration).

Operations:

In the following, description will be given of operations of the communication system having the above configuration.

Description will first be given of an operation performed in a case in which a single player edits and updates individual information (message information M) retained in game server device3, and subsequently of an operation performed in a case in which Players A to C play the same game with multiple players. In the description of the former case, it is assumed that individual information is edited and updated for a card ID which has already been registered at game server device3.

Operations for Editing and Updating:

FIG. 10is a diagram showing a flow of an operation for editing and updating individual information, the operation being performed at game server device3and one terminal device4of the communication system ofFIG. 1.

Processor41of terminal device4transmits to game server device3an access request containing a player ID and requesting transmission of a card list as a response. The player ID contained in the access request is registered in advance in game server device3by a player when a program is downloaded from game server device3to program area471. Processor31of game server device3, upon receiving the access request, reads from individual information table T all the card IDs and card names that are associated with the player ID contained in the access request, generates a card list showing pairs of card IDs and card names that have been read, and replying to terminal device4with an access response containing the card list and being a response to the access request.

Processor41of terminal device4, upon receiving the access response, causes pairs of a card ID and a card name contained in the access response to be displayed on display device45, for prompting the player to specify one of the card IDs. When the player then operates input device44to input an instruction of specifying a card ID, processor41transmits a card specification notification containing the specified card ID to game server device3. Processor31of game server device3, upon receiving the card specification notification, reads from individual information table T individual information corresponding to the card ID contained in the card specification notification, to transmit an individual information notification containing the individual information to terminal device4.

Processor41of terminal device4performs an edit process upon receiving the individual information notification. Specifically, an edit screen for editing message information M contained in the individual information notification is caused to be displayed at display device45, the edit screen prompting the player to edit and update individual information.

FIG. 11shows an example of an edit screen displayed at a terminal device ofFIG. 9. On the editing screen, types of events and messages represented by message data units are displayed in association with each other, the types of events and the messages data units corresponding to the message ID of the message information M.

After the above editing process is performed, when the player operates input device44to input an instruction by selecting an “OK” button, processor41regards individual information containing post-edit message information as update information, and transmits to game server device3an individual information updating request containing the updated information and requesting the updating of individual information. Processor31of game server device3, upon receiving the individual information updating request, overwrites the corresponding individual information with the update information contained in the individual information updating request. The individual information is thus updated.

Operations for Playing a Game with Multiple Players:

Operations for playing a game with multiple players are broadly divided into an operation of each game device1for obtaining individual information, a subsequent operation up to the start of a game with multiple players, and a subsequent operation up to the end of the game with multiple players.

Operation of Each Game Device1for Obtaining Individual Information:

FIG. 12is a diagram showing an operation of each game device1for obtaining individual information from game server device3. This operation is actualized by processor11of each game device1performing a process ofFIG. 13and by processor31of game server device3performing a process ofFIG. 14.FIG. 13is a flow chart showing an authentication process, andFIG. 14is a flow chart showing a process for one or both of authentication and registration.

In this operation, Player A first inserts one card2in the card acceptance slot of game device1and inserts a coin in the coin acceptance slot. At game device1(hereinafter referred to as “Player A's game device1”), card reading device13then reads from card2a card ID which is to be supplied to processor11. Processor11, when it receives the supply of the card ID, transmits to game server device3an authentication request containing the supplied card ID (Step SA1ofFIG. 13).

In the meantime, processor31of game server device3repeats a determination as to whether it has received a request from a game device (Step SB1ofFIG. 14) until it receives such a request. Processor31receives a request from Player A's game device1in the repeat process. Upon receiving a request, a result of the determination of Step SB1changes to “YES”, and processor11determines whether the received request is an authentication request (Step SB2). Provided that the received request is an authentication request, processor11subsequently determines whether a card relating to the received authentication request is registered (Step SB3). Specifically, a card ID contained in the received authentication request is searched in individual information table T. It is determined that the card is registered in a case in which the number of hit records is 1 or more, whereas it is determined that the card is not registered in a case in which the number of hit records is 0.

In this case, it is assumed that a result of the determination changes to “YES”. Processor31then reads individual information that is associated with the card ID from individual information table T, and replies to Player A's game device1with an authentication result containing the read individual information (Step SB4). “To reply” means to transmit information to a device having a communication address designated by the sender information contained in the received request. Subsequently, the process of game server device3returns to Step SB1.

Processor11of Player A's game device1, after it transmits the authentication request, repeats a determination as to whether it has received an authentication result (Step SA2ofFIG. 13) until it receives the authentication result. Processor11receives an authentication result from game server device3during the repeat process. When the authentication result is received, a result of the determination of Step SA2changes to “YES”. Processor11then determines whether the received authentication result shows that the card is unregistered (Step SA3). Provided that information contained in the received authentication result is not information showing that the card is unregistered but is individual information (i.e., Player A's individual information including message information), the result of the determination changes to “NO”. As a result, processor11writes the individual information contained in the received authentication result into personal information storage area181(Step SA7). The authentication process is thus completed.

Hereinafter, Player B's game device1and Player C's game device1each performs the above authentication process, to thereby obtain individual information. In a case in which it is assumed that card2used by Player C is unregistered, processor31of game server device3, when it receives an authentication request from Player C's game device1, determines that a card with respect to this authentication request is unregistered and replies to Player C's game device1with an authentication result containing information showing the card being unregistered (Steps SB1to SB3, and SB5ofFIG. 14). The process at game server device3then returns to Step SB1.

On the other hand, processor11of Player C's game device1, when it receives the authentication result from game server device3after transmitting the authentication request in Step SA1, determines that the received authentication result shows the card being unregistered and obtains information to be registered (Steps SA1to SA4). The information to be registered is broadly divided into three units of information. The first unit of information is a card ID, the card ID having been supplied from card reading device13. The second unit of information is a player ID, and the third is a card name. Although the second and the third units of information can be obtained in any manner, game device1causes display device15to display an image prompting a player to input information, and in accordance with what are displayed, input signals supplied from input device14are used to generate and obtain the second and the third units of information. Processor11then transmits a card registration request containing the obtained information to game server device3(Step SA5).

The card registration request is received by processor31of game server device3. The result of the determination of Step SB1ofFIG. 14then changes to “YES”, and the result of the determination of Step SB2changes to “NO” at game server device3. Processor31then determines whether the received request is a card registration request (Step SB1, SB2, and SB6). Since a result of this determination changes to “YES”, processor31registers the card with respect to the received card registration request (Step SB7). Specifically, the above three units of information contained in the received card registration request are stored in association with one another in individual information table T. In this case, from among individual information to be stored, information (e.g., message information M) other than the card name corresponds to an initial value that is predetermined.

Processor31then reads, from individual information table T, individual information that is associated with the card ID contained in the received card registration request to reply to Player C's game device1with an authentication result containing the read individual information (Step SB4). The routine at game server device3then returns to Step SB1. Processor11of Player C's game device1writes the individual information contained in the received authentication result into personal information storage area181(Step SA7). The authentication process is thus completed.

Operation Up to the Start of the Game with Multiple Players:

After the authentication process is completed, a screen is displayed on a display device of game device1, the screen for prompting a player to select one of plural game modes. The plurality of game modes includes a mode with multiple players for enabling a game with multiple players.

FIG. 15is a diagram showing an operation from the time each game device1obtains individual information until a game with multiple players is started in the communication system ofFIG. 1. In this communication system, a game device performs a master-slave communication until the game is started. Specifically, one game device that first shows willingness to participate in a game acts as a master, and one or more other game devices that shows willingness to participate in the game at a subsequent time acts as a slave and only communicates with the master game device. This master-slave relationship is eventually dissolved, so that participating game devices have an equal relationship, i.e., each game device is then able to communicate with any other device. The game is then started.

First, when a mode for multiple players is selected at Player A's game device1, processor11of this game device1transmits, to game server device3, an entry list request requesting that an entry list be transmitted as a response. Processor31of game server device3, when it receives the entry list request, reads from storage unit33an entry list L (FIG. 3) for transmission to game device1as a response. The entry list L is for storing a communication address of one or more master game devices1from which a game participation request is currently being accepted. Nothing has been written in the entry list L in an initial state (i.e., the list is empty.) Processor11of Player A's game device1, after receiving the entry list L, determines whether this game device1should act as a master or as a slave. Since the entry list L is empty at this point in time, processor11recognizes that this game device1should act as a master, and transmits to game server device3an entry record request for registering a communication address of this game device1in the entry list L, to wait for a game participation request from another game device1. That is, the first game device having transmitted an entry list request acts as a master from then on. Processor31of game server device3, when it receives the entry registration request, registers the communication address contained in the entry registration request in the entry list L.

As shown inFIG. 15, while processor11of Player A's game device1is waiting for a game participation request, a mode for multiple players is selected at Player B's game device1, whereby an entry list request and an entry list are transmitted and received between Player B's game device1and game server device3. Processor11of this game device1recognizes that it should act as a slave, given that the communication address of Player A's game device1has been registered in the received entry list L. Processor11then generates opponent information containing individual information stored in personal information storage area181and a communication address of this game device1, to transmit to Player A's game device1a game participation request containing the opponent information and requesting that this game device1be an opponent participant.

Processor11of Player A's game device1, when it receives a game participation request from Player B's game device1, recognizes Player B's game device1as an opponent participant. Processor11then writes the opponent information contained in the game participation request in opponent information storage area182, generates opponent information containing individual information stored in personal information storage area181and a communication address of this game device1, and replies to Player B's game device1with a participation permission notification containing the generated opponent information and permitting Player B's game device1to become an opponent participant. Processor11then waits for another game participation request. Processor11of Player B's game device1, when it receives the participation permission notification, writes the opponent information contained in the participation permission notification into opponent information storage area182and waits for shared information (described below) or a game start instruction (described below).

As shown inFIG. 15, while processor11of Player A's game device1and Player B's game device1are performing the above process, a multi-player mode is selected at Player C's game device1, whereby an entry list request and an entry list are transmitted and received between Player C's game device1and game server device3. Processor11of this game device1recognizes that it should act as a slave, given that the communication address of Player A's game device1has been registered in the received entry list L. Processor11then generates opponent information containing individual information stored in personal information storage area181and a communication address of this game device1, to transmit to Player A's game device1a game participation request containing the opponent information and requesting that this game device1be an opponent participant.

Processor11of Player A's game device1, upon receiving the game participation request from Player C's game device1, recognizes Player C's game device1as an opponent participant and writes the opponent information contained in this game participation request into opponent information storage area182. Processor11generates opponent information containing individual information stored in personal information storage area181and a communication address of this game device1itself and reads the opponent information from opponent information storage area182. Processor11replies to Player C's game device1with a participation permission notification containing the generated opponent information and the read opponent information and permitting Player C's game device1to become an opponent participant. Processor11of Player C's game device1, upon receiving the participation permission notification, writes the opponent information contained in the participation permission notification to opponent information storage area182, and waits for a game start instruction described below.

Subsequently, processor11of Player A's game device1reads from opponent information storage area182opponent information (opponent information of Player C's game device1) that has not been provided to a game device1(Player B's game device1) which only has opponent information on the master's game device1, to transmit shared information containing the opponent information to the game device1which only has opponent information on the master game device1. When the shared information is received, processor11of Player B's game device1writes the opponent information contained in the shared information into opponent information storage area182, and waits for the game start instruction described below.

Processor11of Player A's game device1, since the number of participants including this game device1reaches the maximum number of three, transmits to game server device3an entry deletion request requesting that the communication address of this game device1be deleted from the entry list L. Processor31of game server device3, when it receives this entry deletion request, deletes from the entry list L the communication address of the sender of this entry deletion request. As a result, the entry list L becomes empty.

Processor11of Player A's game device1then transmits a game start instruction to other participant game devices (i.e., Player B's game device1and Player C's game device1), the game start instruction instructing that a game be started. In Player A's game device1, the transmission of the game start instruction is a condition for starting a game with multiple players, whereas in Player B and C's game devices1, the receipt of the game start instruction is a condition for starting the game.

Although in the above operation the transmission of a game start instruction is triggered by the number of the participants reaching the maximum number, it may be such that even if the number of participants does not reach the maximum number, a game start instruction is transmitted when a predetermined timer has run out.

Operation from Start to End of Game with Multiple Players:

FIG. 16is a diagram showing operations of game devices from the start to the end of a game with multiple players in the communication system ofFIG. 1.

This operation is actualized when processors11of game devices of Players A to C perform processes shown inFIGS. 17 to 20in parallel.FIG. 17is a flow chart showing a message specifying process.FIG. 18is a flow chart showing a message display process.FIG. 19is a flow chart showing a transmission process.FIG. 20is a flow chart showing a receiving process. In this operation, there is no master-slave relationship among game devices1. That is, processor11of each game device1functions as a shifter that dissolves the master-slave relationship when a game start instruction is transmitted (master) or when a game start instruction is received (slave) and that shifts a communication mode with other game devices to an individual control mode.

In the message specifying process ofFIG. 17, each processor11of Players A to C's game devices1(hereinafter referred to simply as “each processor11”) determines whether a predetermined event has been detected (Step SC1). In a case in which a result of this determination changes to “NO”, the routine returns to Step SC1. There are seven types of predetermined events as described above. Criteria for detection will be described in the following for each type of event. The event in which a game with multiple players was started is detected in a case in which a game start instruction is transmitted or received. The event in which a player of this game device1is playing well is detected in a case in which, for example, appropriate operations are performed at appropriate timings5consecutive times. The event in which the player is playing poorly is detected in a case in which, for example, inappropriate operations are performed at inappropriate timings3consecutive times. The event in which the player of this game device1made an attack is detected in a case in which, when a particular object overlaps a line, an operation corresponding to this object is performed. The event in which the player was attacked and damaged is detected in a case in which, for example, an operation is performed at an inappropriate timing or an inappropriate operation is performed before a predetermined attack period (e.g. 10 seconds) elapses since the attacked time. The event in which the player has won the game is detected in a case in which there is no other player who has gained a score that is higher than that of the player at the end of the play. The event in which the player lost the game is detected in a case in which another player has gained a score that is higher than that of the player at the end of the play.

During a stage in which a play has not been started, the event in which a game with multiple players has been started is the only event that is detected. When this event is detected, the determination of Step SC1changes to “YES”. Each processor11then specifies an event ID of the detected event (Step SC2) and refers to conversion table184to convert the event ID to a message ID (Step SC3). Each processor11then overwrites what is written in message ID area185with the detected message ID in association with every participant including its own game device1(Step SC4). The routine then returns to Step SC1.

On the other hand, each processor11, in the message display process ofFIG. 18, determines whether there is an updated message ID in message ID area185(Step SD1). Because a message ID in message ID area185is overwritten only when a predetermined event is detected, a result of the determination changes to “NO” if no predetermined event is detected, and the routine returns to Step SD1.

On the other hand, in a case in which the event in which a game with multiple players has been started is detected, a determination result of Step SD1changes to “YES”. Each processor11then reads a message data unit corresponding to the updated message ID and starts a process of displaying a message represented by the message data for a period that is predetermined depending on a message ID (Step SD2). At this point in time, each processor11is displaying a game start screen on display device15. Also at this point in time, message IDs have been updated for all the participants, and the message IDs correspond to self-introduction messages. Therefore, a game start screen as shown inFIG. 7is displayed at each game device1of Players A to C. As a result, each of Players A to C is able to view self-introduction messages of all the participants including the player's own message. The routine then returns to Step SD1.

In a case in which a predetermined period elapses from the time the displaying of self-introduction messages is started, each processor11causes a game screen to be displayed on display device15, to enable the player to play a game with multiple players. In the meantime, each processor11performs the transmission process ofFIG. 19and the receiving process ofFIG. 20.

In the transmission process, each processor11clears what is stored in a sending area (not shown) reserved for each of the other participants in storage unit18(Step SE1), and processor11starts a timer that runs out in 0.5 seconds (Step SE2). Each processor11then performs a determination as to whether a game with multiple players has ended (Step SE3), a determination as to whether an attack event has been detected (Step SE4), a determination as to whether a predetermined event has been detected (Step SE5), and a determination as to whether a timer has run out (Step SE6) repeatedly in the listed order until the timer runs out.

In an operational example ofFIG. 16, the timer first runs out, and the determination of Step SE6changes to “YES”. Each processor11then determines whether the play of the game with multiple players has ended (Step SE7). A result of the determination changes to “NO” in this case. As a result, each processor11reads a score from a predetermined area of storage unit18to write the score into the above two sending areas (Step SE8). The information within each of the sending areas is then transmitted to a corresponding one of the other participant game devices1(Step SE9). The routine then returns to Step SE1.

Hereinafter, the same process as above is repeated. At a certain point in time, processor11of Player A's game device1detects an attack event. As a result, the above message specifying process and the above message display process are performed, so that a message displayed on game devices of Players A to C will change to what is shown in the top row ofFIG. 21. That is, Player A's message is displayed only on Player A's game device1.

FIG. 21is a state transition diagram showing changes in message groups displayed at plural game devices during a play. In this figure, states of message groups change from an upper row to a lower row. In each message group, three messages in the left column are to be displayed at Player A's game device1, three messages in the right column are to be displayed at Player C's game device1, and three messages in the center column are to be displayed at Player B's game device1.

In a case in which processor11of Player A's game device1detects an attack event, a result of the determination of Step SE4changes to “YES” in the transmission process ofFIG. 19. Processor11then determines an attack identifier and an attack object in accordance with game situations (Step SE10). An attack identifier and an attack object can be determined in any way and can be determined, for example, at random. InFIG. 16, Player B's game device1is determined as an attack object, and processor11of Player A's game device1writes a determined attack identifier to a sending area corresponding to an attack object (Step SE11). The routine then proceeds to Step SE5.

Since an attack event is a predetermined event, a result of the determination of Step SE5changes to “YES”. Processor11then reads a message ID from an own message ID area for processor11itself (Step SE12) to write the read message ID to sending areas of the other participants (Step SE13). The routine then proceeds to Step SE6.

In a case in which a timer runs out at a subsequent time, processor11writes a score to the sending areas for the other participants and transmits the information in each sending area to a destination (Steps SE6to SE9). As a result, a score, an attack identifier, and a message ID are transmitted to Player B's game device1, and a score and a message ID are transmitted to Player C's game device1.

In the meantime, in the receiving process, each processor11repeats the following processes (α) to (δ) sequentially until the game with multiple players ends.(α) Processor11determines whether it has received an attack identifier (Step SF1), and; only in a case in which it is determined that an attack identifier has been received, processor11performs an attack of a type which is designated by the received attack identifier (Step SF2). Specifically, processor11controls its game device1so that the play of a player using the game device1is disturbed. More specifically, at least one of the width of a game screen that is being displayed is narrowed, the displayed screen is darkened or swung, the volume of music sounds output from speaker16is decreased, and an output timing of output music sounds is delayed, so as to thereby increase the degree of difficulty.(β) Processor11determines whether it has received a score (Step SF3), and only in a case in which it is determined that a score has been received, the received score is written in a score area (not shown) reserved for each of the other participants for storage therein (Step SF4). A score thus stored is displayed in a corresponding area.(γ) Processor11determines whether it has received a message ID (Step SF5), and, only in a case in which it is determined that a message ID has been received, processor11overwrites the received message ID in association with a sender game device1with what is written in message ID area185(Step SF6).(δ) Processor11determines whether the game with multiple players has ended (Step SF7).

In a case in which processor11of Player B's game device1receives a score, an attack identifier, and a message ID from Player A's game device1, determination results of Steps SF1, SF3, and SF5all change to “YES”. Therefore, processor11performs an attack of a type indicated by the attack identifier, overwrites the score with what is written in a score area corresponding to Player A, and overwrites the message ID in association with Player A's game device with what is written in message ID area185. In the meantime, the same process as above is performed at Player C's game device1, except that an attack is not performed since the determination result of Step SF1changes to “NO”. After these processes and the message display process are performed, the message groups displayed on game devices1of Players A to C will change to those which are shown in the second row from the top ofFIG. 21. That is, in each of Players A to C's game devices, a message of Player A is displayed in a position corresponding to Player A. When a period predetermined in accordance with the above message ID elapses, message groups displayed on Players A to C's game devices1will be those which are shown in the third row from the top ofFIG. 21. That is, the display of the message is ended.

InFIG. 16, at a subsequent time, an event in which the player has been attacked and damaged is detected at Player B's game device1. The operation performed in this case is the same as the above except that no attack identifier is transmitted. In this case, since it is Player B's game device1that has detected this event, message groups displayed on Players A to C's game devices will first be those which are shown in the fourth row from the top and then be those which are shown in the fifth row from the top ofFIG. 21. An operation of a case in which an event in which a player of this game device1is playing well is detected and an operation of a case in which the player is playing poorly is detected is obvious from the above description, and therefore, the description thereof will be omitted.

As shown inFIG. 16, when the music ends and the play of the game with multiple players ends, an event in which the player has won the game or an event in which the player has lost the game is detected in each game device1of Players A to C. The operation in this case will be the same as the above except that, since the play has already ended, a result of the determination of Step SE7changes to “YES”, and only a message ID will be transmitted. Thus, messages of Players A to C, each message corresponding to one of the above two events, are displayed at Players A to C's game devices1.