JP5162633B2 - Game system - Google Patents

Description

The present invention relates to a game system, comprising in particular for example a plurality of the portable game device capable of radio communication with each other, about the game system.

An example of a conventional game system of this type is disclosed in Non-Patent Document 1 and Non-Patent Document 2. In Non-patent game apparatus disclosed in Document 1 and Non-Patent Document 2, by communicating with another game apparatus, Ru can send and receive game data.

Another example of this type of game system is disclosed in Patent Document 1. The network game disclosed in Patent Document 1 sets card data to be provided and desired card data, and transmits / receives card data when conditions are met.
“Pocket Monster Red, Green and Blue Victory Method” Issued by Futabasha, October 15, 1997, P14-P15 “Pokémon Crystal Version Nintendo Official Guidebook”, published by Shogakukan Co., Ltd., February 10, 2001, P34, P40 JP 2003-23661 A

However, in the case of the former, in the case of a few people who have the same game software in such friend who, acquaintance, would have limited opportunities and capable of transmitting and receiving game data to be transmitted and received, the pleasure of sending and receiving I couldn't say that I could fully enjoy it. In other words, the fun of the game has been reduced.

In the latter case, since it is necessary to connect to a network in order to send and receive game data, it is not possible to send and receive easily at any time, and it is necessary to provide a server for transmission and reception processing. The burden of initial investment and operating costs of the provider was large.

Another object of the present invention may easily send and receive game data, thereby improving the amusement of is to provide a game system.

The invention of claim 1 is a game system that includes a plurality of portable game devices and transmits / receives game data between the game devices, each game device having a game data storage means for storing game data, other gaming device to communicate to the communication means, when it is determined the game data to be transmitted and received ready, by using a communication means, it is searched by the search means and search means for searching the unspecified other game devices other By communicating with the game device, the game data stored in the game data storage means is transmitted to another game device, the game data transmitted from the other game device is received, and the received game data is A game system comprising game data transmission / reception means stored in game data storage means.

In the first aspect of the present invention, the game system includes a plurality of portable game devices (10: reference number corresponding to the embodiment, the same applies hereinafter), and game data between the game devices (10). Send and receive . Each game device (10) is provided with a game data storage means (28 or 44) to store game data. Communication means (14), the other game devices communicate. When the search means (20, S81) determines that the game data can be transmitted and received ("YES" in S7) , the communication means (14) is used to specify another unspecified game device (10). Explore. The game data transmission / reception means (20, S105, S109, S135, S137) communicates with the other game device (10) searched by the search means (20, S81), so that the game data storage means (28 or 44). Is transmitted to the other game device (10), the game data transmitted from the other game device (10) is received, and the received game data is stored in the game data storage means (28). Or 44).

According to the present invention, it is possible to transmit and receive between Dege Mudeta the unspecified other game device, it is possible to easily transmit and receive game data. The communication partner is not limited to acquaintances, it is possible to send and receive many human and game data, it is possible to increase the possibility of transmitting and receiving game data. Et al. Is, since the transmission and reception of the game data on the game device to each other, it is possible to reduce the burden of the initial investment and operating costs such as the server the need for a game providers without providing for the transmission and reception processing.

The invention of claim 2 is dependent on claim 1 , and when the search means determines that the game data can be transmitted and received, the communication means is used to search for an unspecified other game device existing in the predetermined range. Explore.

In claim 2 , when the search means (20, S81) determines that the game data can be transmitted / received, the search means (20, S81) uses the communication means (14) to specify other unspecified other existing in the predetermined range (64). The game device (10) is searched.

According to the invention of claim 2 , since it searches for an unspecified other game device existing in a predetermined range, if it goes to a place where people gather, the possibility of transmitting and receiving game data increases, and the enjoyment of transmission and reception is increased. Can be increased.

Invention 請 Motomeko 3 depends on claim 2, the game apparatus, a game program storage means for storing a game program, and further comprising a game program executing means for executing a game program, game data exchange means, a game program During execution of the game program by the execution means, the search means searches for another unspecified game device existing in a predetermined range and communicates with the searched other game device, so that it is stored in the game data storage means. The received game data is transmitted to the other game device, the game data transmitted from the other game device is received, and the received game data is stored in the game data storage means.
In the invention of claim 3 , the game apparatus (10) further includes a game program storage means (42) for storing the game program and a game program execution means (22) for executing the game program. The game data transmitting / receiving means (20, S105, S109, S135, S137) is another unspecified game device searched by the searching means (20, S81) during execution of the game program by the game program executing means (22). By communicating with (10), the game data stored in the game data storage means (28 or 44) is transmitted to the other game device (10), and the game is transmitted from the other game device (10). Data is received, and the received game data is stored in the game data storage means (28 or 44).
According to the invention of claim 3 , since game data can be transmitted and received even during a game, the player is not bored to simply wait for transmission and reception of game data. In addition, the opportunity of sending and receiving game data during the game is not missed.
The invention of claim 4 is dependent on claim 3 , and the game program causes the processing means included in the game device to generate game data and causes the game data storage means to store the generated game data.
In the invention of claim 4 , the game program causes the processing means (22) included in the game apparatus (10) to generate game data, and the generated game data is stored in the game data storage means (28 or 44). To do.
According to the fourth aspect of the present invention, game data such as character data can be easily transmitted and received, so that the game preference can be improved.
The invention of claim 5 is according to claim 3 or 4, gate Mudeta receiving means, by the game program executing means during the execution of the game program, among the game data stored in the game data storage section, the game program The game data selected as game data to be used for execution is excluded from transmission targets.
In the invention of claim 5, gate Mudeta transmitting and receiving means (20, S105, S109, S135, S137), according to the game program executing means (22) during the execution of the game program, stored in the game data storage means (28 or 44) The game data selected as the game data to be used for executing the game program is excluded from the transmission targets.

The invention of claim 6 is dependent on claim 3 Naiishi 5, the game apparatus, determination means that the progress of the virtual game satisfies a predetermined condition according to a game program executed by the Gate arm program execution means The game data transmission / reception means is activated or disabled when the determination means determines that the predetermined condition is satisfied.

In the invention of claim 6, the game apparatus (10) further comprises a stamp constant means (20, S43). Determine the constant means (20, S43) is the progress of the virtual game according game program executed by the game program executing means (22) determines that the predetermined condition is satisfied. The game data transmission / reception means (20, S105, S109, S135, S137) is activated in response to the determination means (20, S43) determining that the predetermined condition is satisfied (when “YES” in S43, in S69). The exchangeable flag is turned on) or disabled.

According to the invention of claim 6 , game data can be transmitted and received according to the progress of the game.

The invention of claim 25 is a game system including a plurality of portable game devices, and exchanging game data between the game devices, each game device having game data storage means for storing game data, game data A condition setting means for setting condition data for executing the exchange process, a communication means for communicating with other game devices by short-range wireless communication, and a condition based on the condition data set by the condition setting means is determined. Only when it is determined that the condition is satisfied by the determination means and the determination means, the game data stored in the game data storage means is transferred to the other game by communicating with another game device using the communication means. The game data transmitted from the other game device, and the received game data is stored in the game data. Comprising game data exchange means for storing the data storage means, a game system.
In the invention of claim 25, the game system includes a plurality of portable game devices (10), and exchanges game data between the game devices (10). Each game device (10) is provided with a game data storage means (28 or 44) to store game data. The condition setting means (22, 42, 286, exchange start condition data, exchange end condition data in FIG. 4) sets condition data for executing game data exchange processing. The communication means (14) communicates with other game devices by short-range radio. The determination means (20, S89, S95) determines whether the condition based on the condition data set by the condition setting means (22, 42, 286) is satisfied. The game data exchange means (20, S105, S109, S135, S137) is only when the judgment means (20, S89, S95) determines that the condition is satisfied (“YES” in S89 and “YES” in S95). The game data stored in the game data storage means (28, 44) is transmitted to the other game apparatus (10) by communicating with the other game apparatus (10) using the communication means (14). Then, the game data transmitted from the other game device (10) is received, and the received game data is stored in the game data storage means (28 or 44).
According to the invention of claim 25, the game data can be exchanged with other game apparatuses only when the set condition is satisfied, so that the game data can be exchanged easily. In addition, the exchange partner is not limited to acquaintances, and game data can be exchanged with a large number of people, so that the possibility of exchanging game data can be increased. Furthermore, since the portable game device and the short-range wireless are used, the possibility of exchanging game data increases if the user goes to a place where people gather, and the enjoyment of the exchange can be further increased. Furthermore, since game data is exchanged between game devices, it is not necessary to provide a server for exchange processing, and the burden on the game provider, such as initial investment and operation costs, can be reduced.
The invention of claim 26 is a game data exchange method for a game device comprising game data storage means for storing game data and communication means for communicating with other game devices by short-range wireless communication. Condition data for executing the exchange process is set, (b) it is determined whether the condition based on the condition data set in step (a) is satisfied, and (c) the condition is satisfied in step (b). Only when it is determined that the game data stored in the game data storage means is transmitted to the other game device by communicating with the other game device using the communication means. This is a game data exchange method for receiving transmitted game data and storing the received game data in a game data storage means.
In the twenty-sixth aspect, game data can be exchanged easily as in the twenty-fifth aspect.

According to the present invention, since the transmitting and receiving game data in the game device with each other is communication Accordingly connections can transmit and receive easy game data. In addition, because the person you want to send and receive is not limited to friends and acquaintances, etc., the fun of the transmission and reception can be enjoyed fully, therefore, it is possible to improve the playability of the game.

  The above object, other objects, features and advantages of the present invention will become more apparent from the following detailed description of embodiments with reference to the drawings.

FIG. 1 is a block diagram showing an example of a portable game device used in the game system of the present invention. FIG. 2 is an illustrative view showing a memory map of a WRAM provided in the portable game machine shown in FIG. FIG. 3 is an illustrative view showing a memory map of a backup RAM provided in the cartridge shown in FIG. FIG. 4 is an illustrative view showing one example of the contents of the exchange table stored in the exchange table data storage area of the WRAM shown in FIG. FIG. 5 is an illustrative view for explaining an outline of a game system using the portable game apparatus shown in FIG. 1 embodiment. FIG. 6 is an illustrative view for explaining the flow in the case where game data is exchanged between the parent device and the child device in the game system of the present invention. FIG. 7 is a flowchart showing an example of the main flow of the portable game machine shown in FIG. FIG. 8 is a flowchart showing a part of the game processing of the portable game machine shown in FIG. FIG. 9 is a flowchart showing another part of the game processing of the portable game machine shown in FIG. FIG. 10 is a flowchart showing another part of the game processing of the portable game machine shown in FIG. FIG. 11 is a flowchart showing still another part of the game processing of the portable game machine shown in FIG. FIG. 12 is a flowchart showing a part of the character exchange process of the portable game machine shown in FIG. FIG. 13 is a flowchart showing another part of the character exchange process of the portable game machine shown in FIG. FIG. 14 is a flowchart showing another part of the character exchange process of the portable game machine shown in FIG. FIG. 15 is a flowchart showing still another part of the character exchange process of the portable game machine shown in FIG. FIG. 16 is an illustrative view for explaining a method of setting a period of trying to connect as a master unit and a period of trying to connect as a slave unit when the portable game device shown in FIG. 1 searches and connects with a communication partner. . FIG. 17 is an illustrative view showing a base unit packet broadcast from the base unit to the base unit and a base unit packet transmitted from the base unit to the base unit. FIG. 18 is a flowchart showing a communication partner search and connection process (1) of the portable game machine shown in FIG. FIG. 19 is a flowchart showing a part of the communication partner search and connection process (2) of the portable game machine shown in FIG. FIG. 20 is a flowchart showing another part of the communication partner search and connection process (2) of the portable game machine shown in FIG.

As an example, the wireless communication game system to which the present invention is applied uses a portable game apparatus 10 as shown in FIG. In this embodiment, the portable game apparatus 10 includes a portable game machine 12 such as a Game Boy Advance (trade name), a wireless communication unit 14 connected to the communication connector 46 of the portable game machine 12, and a cartridge connector. 40 includes a game cartridge 16 connected to 40. In other words, in this embodiment, the portable game apparatus 10 includes the portable game machine 12, the wireless communication unit 14, and the cartridge 16.

  A portable game machine 12 shown in FIG. 1 includes a processor 20, and the processor 20 includes a CPU core 22, a boot ROM 24, an LCD controller 26, a WRAM (working RAM: hereinafter the same) 28, a VRAM 30 and the like. Peripheral circuit 32. However, the peripheral circuit 32 includes a sound (sound) circuit, a DMA (Direct Memory Access) circuit, a timer circuit, an input / output interface (IO), and the like.

  The LCD 18 provided on the front surface of the portable game machine 12 is provided with a display signal from the processor 20, in this embodiment, an RGB signal, so that the game image is displayed in color on the LCD 18. Then, an audio signal is given from the processor 20 to the sound circuit 34, and sound (sound) such as game music and sound effects is outputted from the speaker 36 by the audio signal. Further, a cross key, a start key, a select key, an A button, and a B button provided on the front surface of the portable game machine 12 with the LCD 18 interposed therebetween are collectively shown as an operation switch 38, and an operation signal from the operation switch 38 is sent to the processor 20. Is input. Therefore, the processor 20 executes processing according to the player's instruction given through the operation switch 38.

  Although illustration is omitted, power is supplied to the LCD 18 from a battery (primary battery or secondary battery), and by setting the value of a predetermined register (LCD power supply register) to 0, power to the LCD 18 is supplied. Supply is stopped. When the value of the register is set to 1, power supply to the LCD 18 is started (resumed). For example, the LCD power supply register is provided in the WRAM 28 and its value is rewritten by the CPU core 22. That is, the CPU core 22 controls the start (on) / stop (off) of power supply.

  The portable game machine 12 has a cartridge connector 40, and the cartridge 16 is connected or inserted into the cartridge connector 40. The cartridge 16 includes a ROM 42 and a backup RAM 44, and a game program for a game (virtual game) to be executed on the portable game machine 12, a game image (including a character image), and the like are set (stored) in the ROM 42 in advance. Has been. Further, the ROM 42 stores identification information (“GameName” to be described later) for identifying a game program stored in the ROM 42. The backup RAM 44 stores (saves) in-game data and game result data.

  When the power of the portable game machine 12 is turned on, the CPU core 22 executes a boot program stored in the boot ROM 24 and performs a boot process of the portable game machine 12. Thereafter, the CPU core 22 executes the game program stored in the ROM 42 of the cartridge 16 and executes the game process while storing the temporary data being executed in the WRAM 28. The image data generated by the CPU core 22 executing the game program is stored in the VRAM 30, and the image data stored in the VRAM 30 is output to the LCD 18 by the LCD controller 26.

  The portable game machine 12 is further provided with a communication connector 46, and a connector 48 of the wireless communication unit 14 is connected to the communication connector 46. The portable game machine 12 used in this embodiment is, for example, Game Boy Advance (trade name). In this case, the above-described cartridge connector 40 is a 32-pin provided on the back side of the upper surface when the LCD 18 is the front surface (front surface). The communication connector 46 is a 6-pin connector provided on the front side of the upper surface.

  The wireless communication unit 14 includes a baseband IC 50, and the baseband IC 50 includes a ROM 52. The ROM 52 contains, for example, an OCD (One-Cartridge Download) program and other programs, and the baseband IC 50 operates according to those programs.

  The one-cartridge download program is an OC mode (one-cartridge mode: a mode in which a game cartridge is attached only to the master unit and the slave unit operates by receiving a slave unit program download from the master unit cartridge). This is a program for downloading a program to the slave unit.

  The wireless communication unit 14 is further provided with an EEPROM 54, and for example, a player name is uniquely set in the EEPROM 54. The base band IC 50 sends game data transferred from the portable game machine 12 via the connectors 46 and 48 and data including the player name of the EEPROM 54 to the RF (Radio Frequency) -IC 56. The RF-IC 56 modulates the data and transmits a radio wave from the antenna 58. However, the radio wave intensity is very weak, and is set to a value that is small enough to be used unlicensed by the user in the Radio Law. The wireless communication unit 14 is provided with a power supply circuit 60. The power supply circuit 60 is typically a battery and supplies direct current power to each component of the wireless communication unit 14.

  In the wireless communication unit, the radio wave transmitted from another portable game device is received by the antenna 58, demodulated by the RF-IC 56, and the demodulated signal is input to the baseband IC 50. Therefore, the baseband IC 50 decodes the demodulated signal, restores the data, and transfers the data to the portable game machine 12 or the WRAM 28 via the connectors 48 and 46.

  FIG. 2 shows a memory map of the WRAM 28. In this embodiment, the WRAM 28 includes a provided character information area 280, an exchange condition data area 282, a character data area 284, and an exchange table storage area 286.

  In the provided character information area 280, among the owned game characters (hereinafter simply referred to as “characters”), the characters selected to be provided to other players or users (hereinafter simply referred to as “players”) are selected. (Character type, level, etc.) are stored. Here, the provided character information 1 is information indicating the type of the provided character, and the provided character information 2 is information indicating the level of the provided character. The data stored in the provided character information area 280 is a copy of the data about the provided character among the data stored in the character data area 284 and is stored in the character data area. If 284 is directly referenced, it is not necessary to separately provide the provided character information storage area.

  A character to be provided to other players among the owned characters is selected by the player using the operation switch 38 to input (specify), or automatically selected based on the progress of the game.

  In the exchange condition data area 282, information (character type, level, etc.) relating to a character desired to be provided by another player is stored as an exchange condition. A character type is set for the exchange condition 1, and a level is set for the exchange condition 2. This exchange condition is input (designated) by the player using the operation switch 38 or is automatically determined based on the progress of the game.

  In the character data area 284, information (character information) about characters owned by the player (in this embodiment, characters such as the character names “Mario”, “Luigi”, “Kuppa”, “Peach”) is stored for each character. Is remembered. In the virtual game world, the player proceeds with the adventure while capturing characters that are present in the game world and making them friends. Information relating to the characters captured or made friends is stored in the character data area 284. As can be seen from FIG. 2, the character information includes the character type, level, and attribute values of the character, that is, life force (life) and attack power (hit points). For example, in this embodiment, the character data area 284 stores first character information data 284a and second character information data 284b. When the player owns three or more characters, third character information data, fourth character information data,... Are stored.

  The character information data (data in the character data area 284) is updated as needed as the game progresses. For example, when a new character is captured, character information about the new character is added. When the level of the already captured character is increased, the level value of the character is updated.

  The character information data is stored (saved) in the backup RAM 44 in accordance with the player's instruction or the progress of the game. Therefore, when the game is started from the last time, the character information data stored in the backup RAM 44 is read and written (loaded) in the character data area 284.

  FIG. 3 shows a memory map of the backup RAM 44. As described above, the backup RAM 44 stores saved game data, that is, character information data. In this embodiment, for example, the backup RAM 44 stores first character information data 284a and second character information data 284b.

  Returning to FIG. 2, the exchange table storage area 286 stores a table for enabling exchange of game data when the progress of the virtual game satisfies a predetermined condition. As shown in FIG. 4, this table stores exchange start conditions, exchange end conditions, provision character designation data, and request character designation data in accordance with the progress of the virtual game. By referring to this table, according to the progress of the virtual game, exchange conditions with the provided character are set, and game data can be exchanged.

  The exchange start condition is a condition for starting exchange of game data. When this condition is satisfied, a predetermined character can be exchanged as described later. For example, in this embodiment, as the exchange start condition, acquisition (acquisition) of a specific item and defeating a specific enemy character (non-player character whose behavior and action are controlled according to the game program regardless of the player's operation) A specific non-player character (non-player character excluding enemy characters) was rescued, or such non-player character's wish was fulfilled, and a specific date (either one is acceptable) And when a specific time has come.

  The exchange end condition corresponds to a specific month and day (any one is possible and is determined according to the exchange start condition), a specific time, and the like. In the exchange table, for items for which horizontal bars (bars) are displayed, it is indicated that there is no particular exchange end condition. However, for those items, the exchange process is completed by exchanging characters. To do.

The provided character designation data is data for setting the provided character and includes items (conditions) of the type and level of the provided character. The type item includes the type of character to be provided (in this embodiment, the character The level of the corresponding character is described in the level item. Based on this description, it is determined whether or not there is a character that satisfies this condition (type and level) among the owned characters. If there is a character that satisfies this condition, the character is selected as the provided character. Information about the character (character type, level, etc.) is stored in the provided character information area 280 described above. However, the character to be provided can be arbitrarily designated by the player. In this case, it is selected as a character provided by the character arbitrarily designated by the player from the owned characters, and information about the character is stored in the provided character information storage area 280 described above.

  In the exchange table, “player optional” is described when the player can arbitrarily specify the type and level, and “unquestioned” is described unless otherwise specified. . The same applies hereinafter.

  The requested character designation data is data for setting exchange conditions, and includes items (conditions) of character types and levels that are requested to be provided to other players. (In this embodiment, the name of the character) is described, and the level of the corresponding character is described in the level item. The exchange condition is determined based on this description. However, the type of character to be requested can be arbitrarily designated by the player. In addition, there is a case where the level is not specified, the level higher than the level of the character to be provided, or the player can arbitrarily specify the level. The exchange conditions determined in this way are stored in the exchange condition data area 282.

  Specifically, referring to the exchange table, in the case of No. 1, the exchange start condition is “acquired a specific item”, and the exchange end condition is not particularly defined. As a condition of the provided character, the type is “Mario”, and the level is “5”. Further, as the request character, the type is “Koppa”, and the level is “5”. That is, when a player character acquires a specific item in the game world, if the player character owns a level 5 Mario, it can be exchanged for a level 5 kuppa owned by another player. In this case, in the provided character information storage area 280, “Mario” is set as the type of provided character, and “5” is set as the level. In the exchange condition data storage area 282, “Kuppa” is set as the type of the requested character, and “5” is set as the level.

  In No. 4, the exchange start condition is “specific month and day (April 10)”, and the exchange end condition is “specific month and day (April 15)” correlated with the exchange start condition. As a condition of the provided character, the type is “Koppa”, and the level is “10 or more”. Further, as the condition of the requested character, the type is “player arbitrary”, and the level is “provided character level or higher”. That is, the portable game machine 12 of this embodiment includes a timer, and the date in the game world is managed by this timer. And, a player who owns a Kuppa level 10 or higher can be exchanged for any character with a Kuppa level or higher between April 10th and April 15th in the game world. Become. For example, a player who owns a level 15 Kuppa may wish to exchange for a level 15 or higher luigi. In this case, in the provided character information storage area 280, “Kuppa” is set as the type of provided character, and “15” is set as the level. In the exchange condition data storage area 282, “Luigi” is set as the type of the requested character, and “15 or more” is set as the level.

Such an exchange table is determined in advance by a developer such as a programmer and is not shown, but is stored in the ROM 42 of the cartridge 16 and may be temporarily or necessary after the main power source of the portable game machine 12 is turned on. In response, it is loaded into the WRAM 28. The provided character and the exchange condition (request character) are automatically set with reference to the exchange table, but the player can arbitrarily set a part or all of them.

  Note that the exchange table shown in FIG. 4 is merely an example, and need not be limited to this.

  For example, in the game system of this embodiment, by using at least two portable game apparatuses 10 as shown in FIG. 1 and communicating with each other, players of each portable game apparatus 10 can enjoy a communication game. That is, the dotted line 64 in FIG. 5 indicates the communicable range of the portable game device 62 of the own device, and the portable game device 62 communicates (wireless communication) with the portable game device existing in the communicable range 64. Can do. The communicable range 64 is a range in which data communication between the parent device and the child device can be performed by the above-described weak radio wave, and any of the plurality of portable game devices existing in the communicable range 64 is. Optionally, it can be a parent machine or a child machine.

  In FIG. 5, portable game devices with user names “Taro”, “Ichiro”, and “Jiro” exist in the communicable range 64 of the own portable game device 62, and the own portable game device 62 has the user name. A state of wireless communication with the portable game device of “Jiro” is shown.

  Regarding the operation of the portable game device for allowing the plurality of game devices to enjoy the communication game by entering the portable game device 62 in another portable game device existing in the communicable range 64, the applicant of the present application applies first. Japanese Patent Application No. 2002-306867, which is disclosed in detail, and is not the essential content of the present application.

  When two or more portable game devices are communicably connected, the player of each portable game device can enjoy a communication game as described above. However, it goes without saying that each player can enjoy the game alone using only his / her portable game device, that is, without communication. In the following, a mode in which a game is played by communication or alone is referred to as a game mode.

  In addition, the portable game device 62 can exchange game data, that is, character information data with another portable game device existing in the communicable range 64. Briefly, in the portable game device 62 of the own device, in a state where the main power is on and the game is not played (the game is not started and the game is ended) That is, when not in the game mode, the character exchange mode is set.

  If the portable game device 62 is in the exchangeable state in the exchange mode, the portable game device 62 searches for another portable game device that exists in the communicable range 64 and is also in the exchangeable state. At this time, the portable game device 62 alternately repeats the process of searching for the child machine as the parent machine and the process of searching for the parent machine as the child machine. When another portable game device capable of communication is searched, an attempt is made to establish a connection state (communication state) by wireless communication. This search and connection process will be described later in detail (see FIGS. 16 to 20).

  When the mobile game device 62 establishes a connection state with another mobile game device, the mobile game device 62 exchanges information on the provided characters (provided character type information and level information) and exchange conditions, and the mutual exchange conditions match (match). ). If the exchange conditions match, the provided character data is exchanged.

FIG. 6 is an illustrative view showing a flow of exchange between two portable game devices (a parent device and a child device) when the exchange conditions match. Referring to FIG. 6, when the connection state is established between the parent device and the child device, the child device transmits its own provided character information 1 and provided character information 2 to the parent device. When receiving the provision character information 1 and the provision character information 2 of the slave unit, the base unit compares it with its own exchange condition 1 and exchange condition 2 and determines whether or not they match. If they match, that is, if provided character information 1 and provided character information 2 of the child device satisfy its own exchange condition 1 and exchange condition 2, the parent device transmits an exchange request to the child device, and further, Provided character information 1 and provided character information 2 are transmitted to the child device.

  When receiving the provided character information 1 and the provided character information 2 of the parent device, the child device compares it with its own exchange condition 1 and exchange condition 2 to determine whether or not they match. If each of them matches, that is, if the provided character information 1 and provided character information 2 of the parent machine satisfy its own exchange condition 1 and exchange condition 2, that is, if the exchange condition is satisfied, the slave unit sends an exchange response. Send to the main unit.

  Then, the base unit receives this exchange response and transmits character information data about its provided character (in FIG. 6, for convenience of description, expressed as “character A”) to the slave unit. Thereafter, the slave unit transmits character information data about its provided character (in FIG. 6, for convenience of description, expressed as “character B”) to the master unit. In this way, character exchange is performed between the parent device and the child device.

  In this embodiment, as shown in FIG. 6, each of the parent device and the child device transmits the provided character information to the communication partner, and whether or not the portable game device that has received the information satisfies the exchange condition However, one portable game device (for example, a child device) transmits its provided character information and exchange conditions to the other portable game device (for example, the parent device), and the parent device However, it may be determined at a time whether or not the replacement condition is satisfied.

  Further, in this embodiment, as shown in FIG. 6, the provided character information is transmitted from the slave unit, and it is determined whether the master unit that has received this information satisfies its own exchange condition, and thus satisfies the condition. In this case, the exchange request is transmitted in order to eliminate useless communication. That is, if the condition is not satisfied, the character exchange is interrupted as it is. That is, the provided character information is not transmitted from the parent device.

  Further, as described above, the image data of each character is stored in the ROM 42 in the cartridge 16, and in this embodiment, in order to reduce the amount of data to be transmitted and received and to increase the time efficiency for communication. When exchanging characters, an identification number for designating the type of character is exchanged, but image data or the like of the character to be exchanged may be exchanged.

  In the embodiment described later with reference to FIG. 7 and subsequent figures, the game mode and the exchange mode are not distinguished, and the exchange process is executed in parallel during the game play. That is, another game device satisfying the exchange condition is searched for while game play is being executed, and game data exchange processing is performed when another game device satisfying the exchange condition is found. By doing so, the game can be played while searching for another game device that satisfies the replacement condition, so that the user is not bored.

Specifically, the processor 20 or the CPU core 22 of the portable game machine 12 performs processing according to the flowchart shown in FIG. When the main power source of the portable game machine 12 is turned on, the CPU core 22 starts processing, and turns off the exchangeable flag (sets it to 0) in step S1. In the subsequent step S3, the attribute values, that is, the level, life force, and attack power of each character (character possessed in the initial state) are initialized. That is, the initial value is set. In addition, the process of step S3 is a process performed only when playing a game for the first time, and is not performed when playing after the 2nd time.

  In the next step S5, game processing (see FIGS. 8 to 11), which will be described in detail later, is executed. In step S7, it is determined whether or not the exchangeable flag is on (= 1). If “NO” in the step S7, that is, if the exchangeable flag is off (= 0), it is determined that the characters cannot be exchanged, and the process returns to the step S5 as it is.

  On the other hand, if “YES” in the step S7, that is, if the exchangeable flag is on (= 1), it is determined that the characters can be exchanged, and in a step S9, a character exchange process described later (FIG. 12). To FIG. 15), and the process returns to step S5.

  As shown in FIG. 8, when the game process is started, it is determined in step S21 whether or not the battle is started. That is, it is determined whether or not the battle scene has been entered. Although illustration is omitted, for example, when a hero character (player character) encounters an opponent character (enemy character), a battle scene is started. If “NO” in the step S21, that is, if the battle is not started, the process proceeds to a step S43 shown in FIG. On the other hand, if “YES” in the step S21, that is, if the battle is started, a battle process is executed in a step S23, and the experience value of the character participating in the battle among the characters owned by the player character in the step S25. Increase.

  Note that some of the plurality of characters stored in the character data area 284 are selected by the player before the game, and the selected character is used in the game processing of FIG.

  Although detailed description is omitted, in the battle process in step S23, for example, characters owned by the player character and the enemy character are made to fight each other. In this battle process, the attack turn is repeated alternately between the player character and the enemy character. Then, when the life force of all characters owned by the player character or enemy character is lost (becomes 0), the battle ends.

  Furthermore, in step S25, the experience value of the character who participated in the battle among the characters owned by the player character is increased because it is assumed that the player character has won the battle. However, if the player character loses the battle in the battle process, the game ends (game over) and the game process ends (returns) as it is.

  In a succeeding step S27, it is determined whether or not the experience value for a certain character is equal to or greater than a predetermined value. That is, it is determined whether or not there is a character whose experience value is equal to or greater than a predetermined value among the characters owned by the player character. Here, the predetermined value is a value set in advance by a developer such as a programmer, and is updated according to the progress of the game or the level of the character.

  If “NO” in the step S27, that is, if the experience value for a certain character is not the predetermined value or more, the process proceeds to a step S38 shown in FIG. 9 as it is. On the other hand, if “YES” in the step S27, that is, if the experience value for a certain character is equal to or greater than a predetermined value, in a step S29, the level for the character is increased, and the life force and the fighting force are increased. That is, the character information data for the character stored in the character data area 284 of the WRAM 28 is updated.

In a succeeding step S31, it is determined whether or not the character is set as a provided character. If “NO” in the step S31, that is, if the character is not set as the providing character, the process proceeds to a step S35 shown in FIG. 9 as it is. However, if “YES” in the step S31, that is, if the character is set as a providing character, the data of the providing character information 2 stored in the providing character information area 280 of the WRAM 28 is updated in a step S33. That is, the level data is updated, and the process proceeds to step S35. This is because it is necessary to change the provided character information in conjunction with the increase in the level of the character set as the provided character.

  In step S35 shown in FIG. 9, it is determined whether or not the exchange condition 2 is based on the provided character information 2. That is, it is determined whether the level of the requested character is determined in relation to the level of the provided character. For example, in this embodiment, the case where the level indicated by the exchange condition 2 matches the level indicated by the provided character information 2 as shown in the exchange table numbers 4 and 5 shown in FIG. To do. If “NO” in the step S35, that is, if the exchange condition 2 is not based on the provided character information 2, the process proceeds to a step S38 as it is. However, if “YES” in the step S35, that is, if the exchange condition 2 is based on the provided character information 2, the data of the exchange condition 2 stored in the exchange condition data storage area 282 of the WRAM 28 is obtained in a step S37. After updating, the process proceeds to step S38. For example, in the case of No. 4, when a Kuppa of level 15 is set as the provided character and this Kuppa is leveled up to level 16, the data of the exchange condition 2 is changed from “level 15 or higher” to “level 16 or higher”. Be changed.

  In step S38, a virtual game process other than the battle process is performed. For example, processing for moving a player character or enemy character in the virtual game world, processing for adding the item to the possessed item list of the player character when the player character obtains an item existing in the game world, A process of generating an event to rescue an existing villager character is performed. After the process of step S38, the process proceeds to step S39.

  In step S39, it is determined whether or not to save game data, that is, character information data. Here, it is determined whether or not to save depending on the player's operation or whether a predetermined event has occurred. If “NO” in the step S39, that is, if the character information data is not saved, the game processing is directly returned. On the other hand, if “YES” in the step S39, that is, if the character information data is to be saved, all the character information data stored in the character data storage area 284 of the WRAM 28 is read out and provided in the cartridge 16 in a step S41. Is written (overwritten) in the backup RAM 44, and the game processing is returned.

  If it is determined in step S21 shown in FIG. 8 that the battle has not started, it is determined in step S43 shown in FIG. 10 whether an exchange event has occurred. That is, it is determined whether or not the progress of the virtual game satisfies any of the exchange start conditions in the exchange table of FIG. If “NO” in the step S43, that is, if any replacement start condition is not satisfied, the process proceeds to a step S71 shown in FIG. 11 as it is.

On the other hand, if “YES” in the step S43, that is, if any of the exchange start conditions is satisfied, the exchange table is referred to in step S45, and the type of the provided character corresponding to the exchange start condition is “player”. Determine if it is "optional". If “YES” in the step S45, that is, if the type of the provided character is “player arbitrary”, in a step S47, the player is made to designate a provided character from among the characters owned by the player, and the process proceeds to a step S59 shown in FIG. move on. For example, in step S47, a selection screen for selecting a provided character by displaying a list of owned characters is displayed on the LCD 18, and the player operates the operation switch 38 by looking at the selection screen to select a desired provided character. Select (specify). Hereinafter, for convenience of explanation, the character selected as the provided character is referred to as “character X”.

  On the other hand, if “NO” in the step S45, that is, if the type of the provided character is not “player optional”, in step S49, the exchange table is referred to, that is, the character designated by the provided character type is owned. Determine if you are. If “NO” in the step S49, that is, if the character specified by the type of the provided character is not owned, it is determined that the character to be exchanged is not owned, and as shown in FIG. The process ends. On the other hand, if “YES” in the step 49, that is, if the character designated by the type of the provided character is owned, the character is set as the character X (ie, designated as the provided character), and the exchange is performed in the step S51. Referring to the table, it is determined whether the level of the provided character is “unquestioned”.

  If “YES” in the step S51, that is, if the level of the provided character is “unquestioned”, the process proceeds to a step S55 as it is. On the other hand, if “NO” in the step S51, that is, if the level of the provided character is not “unquestioned”, it is determined whether or not the character X satisfies the level of the provided character in a step S53. That is, it is determined whether or not the level included in the character information data for the character X is the same as the level of the provided character.

  If “NO” in the step S53, that is, if the character X does not satisfy the level of the provided character, it is determined that the character X cannot be exchanged, and the game processing is directly returned. On the other hand, if “YES” in the step S53, that is, if the character X satisfies the provided character level, the process proceeds to a step S55.

  In step S55, a confirmation message “Do you want to replace character X?” Is displayed on LCD 18. In step S57, it is determined whether or not the player desires to exchange the character X. That is, it is determined whether or not the player has agreed to exchange the character X by operating the operation switch 38.

  If “NO” in the step S57, that is, if the player does not desire to exchange the character X, the game process is ended as it is. On the other hand, if “YES” in the step S57, that is, if the player desires to exchange the character X, the process proceeds to a step S59 shown in FIG.

  In this way, since the player is confirmed whether or not the character X is to be exchanged, it is possible to prevent a character not intended by the player from being exchanged by mistake.

  Next, in step S59, with reference to the exchange table, it is determined whether or not the type of the requested character corresponding to the exchange start condition is “player optional”. If “NO” in the step S59, that is, if the type of the requested character is not “player arbitrary”, the process proceeds to a step S63 as it is. However, if “YES” in the step S59, that is, if the type of the requested character is “player arbitrary”, the player is made to designate the type of the requested character in a step S61, and the process proceeds to the step S63. In step S61, for example, a list of all (or main) characters appearing in the game is displayed, and a selection screen for allowing the player to select an arbitrary character from the list is displayed on the LCD 18. The player views the selection screen. Then, a desired request character is selected (designated).

In step S63, it is determined by referring to the exchange table whether the level of the requested character corresponding to the exchange start condition is “player optional”. If “NO” in the step S63, that is, if the level of the requested character is not “player arbitrary”, the process proceeds to a step S67 as it is. On the other hand, if “YES” in the step 63, that is, if the level of the requested character is “player arbitrary”, in a step S 65, the requested character level is designated by the player, and the process proceeds to a step S 67. The specification of the level of the requested character is almost the same as the specification of the character type in steps S47 and S61 described above, and therefore detailed description thereof will be omitted here.

  In step S67, provided character information 1, provided character information 2, exchange condition 1 and exchange condition 2 are set (confirmed). That is, provided character information 1 and provided character information 2 are stored in provided character information area 280, and exchange condition 1 and exchange condition 2 are stored in exchange condition data area 282. In step S69, the exchangeable flag is turned on (set to 1), and the game process is returned as shown in FIG. In this embodiment, in step S67, the character X type is set in the provided character information 1, the level of the character X is set in the provided character information 2, the requested character type is set in the exchange condition 1, and The level of the requested character is set in the exchange condition 2. That is, the type and level of the provided character and the requested character are set according to the player's designation or according to the definition of the exchange table.

  If it is determined in step S43 shown in FIG. 10 that the replacement start condition is not satisfied, the process proceeds to FIG. 11, and it is determined in step S71 whether the replacement end condition is satisfied. If “NO” in the step S71, that is, if the replacement end condition is not satisfied, the game processing is directly returned. On the other hand, if “YES” in the step S71, that is, if the exchange end condition is satisfied, the provided character information and the exchange condition are cleared in a step S73, and the exchangeable flag is turned off (set to 0) in a step S75. To return to the game process.

  When the character exchange process in step S9 shown in FIG. 7 is started, as shown in FIG. 12, a communication partner search and connection process (FIGS. 18, 19, and 20) described in detail later is executed in step 81. ). In a succeeding step S83, it is determined whether or not the own device is a parent device. That is, it is determined whether or not a connection is established with another portable game device as a parent device according to whether or not the parent device flag is on. Note that the parent machine flag is a flag that is turned on when connected to another portable game device as a parent machine in a communication partner search and connection process described later.

  If “NO” in the step S83, that is, if the own device is not the parent device, it is determined whether or not the own device is a child device in a step S85. That is, as a slave unit, it is determined whether or not a connection is established with another portable game device according to whether or not the slave unit flag is on. Note that the child device flag is a flag that is turned on when connected to another portable game device as a child device in communication partner search and connection processing described later.

  If “YES” in the step 85, that is, if the own machine is a child machine, the process proceeds to a step S117 shown in FIG. On the other hand, if “NO” in the step S85, that is, if the own device is not a child device, it is determined that another portable game device does not exist in the connectable range or the connection with the other portable game device has failed. Then, as shown in FIG. 13, the character exchange process is returned.

If “YES” in the step S83, that is, if the own device is a parent device, the provided character information 1 and the provided character information 2 of the communication partner (slave device) are received in a step S87. In a succeeding step S89, it is determined whether or not the communication partner provided character information 1 satisfies its own exchange condition 1.

  If “NO” in the step S89, that is, if the communication partner provided character information 1 does not satisfy the exchange condition 1 of the communication partner, a non-exchange request is transmitted to the communication partner in a step S91, and the communication is performed in a step S93. Disconnect and return the character exchange process. On the other hand, if “YES” in the step S89, that is, if the communication partner provided character information 1 satisfies its own exchange condition 1, the communication partner provided character information 2 sets its own exchange condition 2 in a step S95. Judge whether to meet.

  If “NO” in the step S95, that is, if the provided character information 2 of the communication partner does not satisfy the exchange condition 2 of the communication partner, the process proceeds to a step S91. On the other hand, if “YES” in the step S95, that is, if the communication partner provided character information 2 satisfies the exchange condition 2 of the communication partner, an exchange request is transmitted to the communication partner in a step S97. Subsequently, in step S99, the provided character information 1 and the provided character information 2 are transmitted to the communication partner.

  In step S101, it is determined whether an exchange response has been received from the communication partner. If “NO” in the step S101, that is, if there is no exchange response from the communication partner, it is determined whether or not a non-exchange response is received from the communication partner in a step S103. If “NO” in the step S103, that is, if there is no non-exchange response from the communication partner, it is determined that there is no response from the communication partner, and the process directly returns to the step S99 to provide the character information 1 of the own device. The provided character information 2 is transmitted again. On the other hand, if “YES” in the step S103, that is, if there is a non-exchange response from the communication partner, the process proceeds to a step S93.

  Note that after step S101, the player may confirm whether or not to exchange, similarly to steps S128 and S129 (see FIG. 14) described later.

  If “YES” in the step S101, that is, if there is an exchange response from the communication partner, in a step S105 shown in FIG. 13, the character X (selected as the provided character in the processing in the above-described steps S45 to S57) is selected. Data) (character information data stored in the WRAM 28) is transmitted, and the data is deleted from each of the WRAM 28 and the backup RAM 44 in step S107. Next, in step S 109, the character data transmitted from the communication partner, that is, character information data is received and newly recorded (registered) in the character data area 284 of the WRAM 28. Note that the character information data is newly recorded in the backup RAM 44 when saving, as shown in steps S39 and S41 of FIG. In this way, character exchange is executed when the own device is the parent device.

  Thereafter, the communication is disconnected in step S111, the exchangeable flag is turned off (set to 0) in step S113, and the provided character information 1, provided character information 2, exchange condition 1, and exchange condition 2 are cleared in step S115. In step S116, the image and attribute data (character name, level, etc.) of the character X deleted in S107 and the fact that the character X has been deleted are displayed, and the character image and attribute data (newly stored in S109) Character name, level, etc.) and the fact that the character has been newly obtained are displayed, and the character exchange process is returned.

  Further, as described above, when it is determined in step S85 that the own device is a slave device, in step S117 shown in FIG. 14, its own provided character information 1 and provided character information 2 are transferred to the communication partner (master device). ). In step S119, it is determined whether an exchange request has been received from the communication partner.

  If “NO” in the step S119, that is, if no exchange request is received from the communication partner, it is determined whether or not a non-exchange request is received from the communication partner in a step S121. If “NO” in the step S121, that is, if a non-exchange request is not received from the communication partner, it is determined that there is no response from the communication partner, and the process returns to the step S117 as it is, and the provided character information 1 of the own device The provided character information 2 is transmitted again. On the other hand, if “YES” in the step S121, that is, if a non-exchange request is received from the communication partner, the communication is disconnected in a step S131, and the character exchange process is returned as shown in FIG.

  On the other hand, if “YES” in the step S119, that is, if an exchange request is received from the communication partner, the provision character information 1 and the provision character information 2 of the communication partner are received in a step S123. It is determined whether the provided character information 1 satisfies its own exchange condition 1 or not. If “NO” in the step S125, that is, if the communication partner provided character information 1 does not satisfy the exchange condition 1 of the communication partner, a non-exchange response is transmitted to the communication partner in a step S130, and then the communication is performed in a step S131. And return to the character exchange process.

  However, if “YES” in the step S125, that is, if the communication partner provided character information 1 satisfies its own exchange condition 1, the communication partner provided character information 2 sets its own exchange condition 2 in a step S127. Judge whether to meet. If “NO” in the step S127, that is, if the provided character information 2 of the communication partner does not satisfy the exchange condition 2 of the communication partner, the process proceeds to a step S130.

  On the other hand, if “YES” in the step S127, that is, if the provided character information 2 of the communication partner satisfies the exchange condition 2 of the communication partner, an intention confirmation whether or not to exchange is performed to the player in a step S128. Specifically, the information (type, level, etc.) of the provided character (character lost by exchange) and the provided character (character obtained by exchange) of the communication partner and the user name (master packet, (Based on UserName included in the handset packet) is displayed on the LCD 18 and the player confirms whether or not to exchange.

  In step S129, it is determined whether or not the player wishes to exchange. In this step S129, when it is determined that the player desires replacement (when it is determined that replacement is selected by the input of the operation switch 38), "YES" is determined, and the step shown in FIG. In S133, an exchange response is transmitted to the communication partner, and in step S135, character data transmitted from the communication partner, that is, character information data, is received and newly stored (registered) in the character data area 284 of the WRAM 28. Note that the character information data is newly registered in the backup RAM 44 when saving, as in the case described above. If it is determined in step S129 that the player does not wish to exchange, “NO” is determined, and the process proceeds to step S130.

In the following step S137, the character X data, that is, the character information data about the character X is transmitted to the communication partner, and the character X data (character information data) is deleted from each of the WRAM 28 and the backup RAM 44 in step S139. In this way, character exchange is executed when the own device is a child device. Then, the communication is disconnected in step S141, the exchangeable flag is turned off (set to 0) in step S143, and provided character information 1, provided character information 2, exchange condition 1 and exchange condition 2 are cleared in step S145. Thereafter, in step S146, the character image and attribute data (character name, level, etc.) newly stored in S135 and the fact that the character has been newly obtained are displayed, and the image and attribute data of character X deleted in S139. (Character name, level, etc.) and the fact that the character X has been deleted are displayed, and the character exchange process is returned.

  As described above, in this embodiment, the provided character information 1 and the provided character information 2 are transmitted to the communication partner portable game device, and the communication partner portable game device that receives them transmits the exchange condition 1 and Although it is determined whether or not the exchange condition 2 is satisfied, the exchange condition 1 and the exchange condition 2 are transmitted to the communication partner portable game apparatus, and the communication partner portable game apparatus that has received the exchange condition 1 supplies the exchange condition 1 and the exchange condition 2. It may be determined whether information 1 and provided character information 2 are satisfied.

  Also, all of the provided character information 1, provided character information 2, exchange condition 1 and exchange condition 2 are transmitted to the communication partner's portable game device, and the communication partner's portable game device that has received them transmits the partner's provided character information. It may be determined whether or not the user's own exchange condition is satisfied and whether or not the provided character information satisfies the other's exchange condition.

  Next, with reference to FIGS. 16 to 20, the communication partner search and connection process in step S81 (FIG. 12) will be described. In this process, the portable game device 10 operates to establish a connection with another portable game device as a parent device or a child device. When trying to establish a connection as a parent device, the mobile game apparatus 10 broadcasts broadcast data including data indicating that connection is possible in order to search for another mobile game apparatus existing in the communicable range 64. If there is a connection request from another portable game device as a child device that has received this broadcast data, portable game device 10 can establish a connection with the child device as the parent device.

  On the other hand, when trying to establish a connection as a child device, the portable game device 10 waits for reception of broadcast data from the parent device. When the broadcast data is received from the parent device, a connection request can be transmitted to the parent device in response to this, thereby establishing a connection with the parent device.

  In such communication partner search and connection processing, each portable game device 10 alternately performs processing that operates as a parent device and searches for a child device, and processing that operates as a child device and receives a search from the parent device. repeat. Specifically, a predetermined period (Tcycle in FIG. 16) is set as one period, a part of each period is operated as a parent machine (Tsp in FIG. 16), and the rest is operated as a child machine (Tsc). And Here, it is possible to connect between a game device operating as a parent device and a game device operating as a child device, a game device operating as a parent device, a game device operating as a parent device, and a child device A game device operating as a machine and a game device operating as a child machine cannot be connected. Therefore, if the period for operating as the master unit and the period for operating as the slave unit are fixed, it is impossible to establish a connection between two game devices that coincide with each other by chance. In order to prevent this, the distribution or arrangement of the period operating as the parent unit and the period operating as the child unit in one cycle is randomly changed. A method for randomly changing the distribution is “communication partner search and connection processing (1)” as shown in FIG. 16A, and a method for randomly changing the arrangement is “communication partner as shown in FIG. 16B”. Search and connection process (2) ".

Referring to FIG. 16A, in the communication partner search and connection process (1), the distribution of Tsp and Tsc is determined at random as described above. The period of this process (one cycle) is a fixed value Tcycle (for example, 4 seconds), the length of Tsc is determined to be a random value between 0 and Tcycle, and the length of Tsp is the remaining period of Tcycle (Tcycle). -Tsc). Tsc and Tsp are set to Tcycle in this order. Since the length of Tsc is determined randomly every time, the length of Tsp is also determined randomly.
This avoids a state in which a connection cannot be established with another portable game device existing in the communicable range 64. However, if Tsp becomes too short, it is not possible to accurately search for another portable game device and a connection cannot be established with another portable game device. If this cannot be secured, Tsc may be determined again.

  In this embodiment, Tcycle is set in the order of Tsc and Tsp, but may be set in the reverse order.

  Referring to FIG. 16B, in the communication partner search and connection process (2), as described above, the arrangement of Tsp and Tsc is randomly determined. In other words, with the Tsp length as a fixed value, the start position of Tsp in the Tcycle is set randomly. More specifically, as shown in FIG. 16B, in the communication partner search and connection process (2), Tcycle (in this embodiment, a fixed value is set to 4 seconds). Tsp determined by a fixed value and Tsc1 and Tsc2 determined at random so as to sandwich this Tsp are provided. That is, Tcycle is provided with Tsc1, Tsp, and Tsc2 in this order. The length of Tsc1 is randomly determined between 0 and (Tcycle-Tsp), and the length of Tsc2 is determined by subtracting Tsc1 and Tsp randomly determined from Tcycle.

  In this embodiment, since the Tcycle is set in the order of Tsc and Tsp, the start position of Tsp is made random. However, when the Tcycle is set in the order of Tsp and Tsc, the start time of Tsc is randomly set. You just have to decide.

  FIG. 17A is a diagram showing details of a parent device packet broadcast from the parent device to the child device. The parent device packet has a field sync for storing synchronization data at the head thereof, and a field PID for storing the identification number PID of the game device (parent device) following the synchronization data field sync. Have Following the field PID, a user name field UserName is formed. In the user name field UserName, a user name (player name) read from the EEPROM 54 (FIG. 1), and in this embodiment, “Taro”, “Ichiro”, and the like are registered.

The base unit packet further includes fields EFlag, GameName, and Payload in order following the user name field UserName. Eflag is data indicating that connection to another portable game device (child device) is possible, and is a flag that is turned on when searching for another portable game device (child device) as a parent device. Yes, this flag is turned off when communicating with another portable game device (child device). As described above, GameName is game program identification information stored in the ROM 42 of the cartridge 16 connected to the parent game device.

In the payload field Payload, substantial transmission data from the parent device to the child device is stored. Specifically, the connection response transmitted from the parent device to the child device, the data of the provided character information 1 and the data of the provided character information 2 that are required for the game data exchange process, or the communication game are necessary. This is a field for transmitting game data to be exchanged or game data (character information data) to be exchanged, and a field for storing data transmitted from the parent device to the child device.

FIG. 17B is a diagram showing details of a slave unit packet transmitted from the slave unit to the master unit. The child device packet includes a head field CID that stores an identification number of the game device (child device), a user name field UserName that follows it, and a payload field Payload. The user name field is information on the user name (player name) of the slave unit as described above. The payload field Payload stores substantial transmission data from the child device to the parent device. Specifically, it is a field for storing a connection request transmitted from the child device to the parent device, data of provided character information 1 and provided character information 2 transmitted from the child device to the parent device, or game data. By exchanging the parent device packet and the child device packet, the parent device and the child device can know each other's user name.

  When each portable game device 10 operates as a parent device, the transmission of the parent device packet and the reception of the child device packet are alternately repeated, and when operating as a child device, the reception of the parent device packet and the transmission of the child device packet are alternately performed. Repeat. In the communication partner search and connection process (1) or (2), the portable game device 10 broadcasts the parent device packet during the Tsp period, and then transmits the child device packet ( Repeat the process of attempting to receive (connection request). In addition, during the period of Tsc, the portable game device 10 attempts to receive a parent device packet transmitted from another game device, and transmits a child device packet (connection request) if reception is successful. repeat.

  In addition, since the portable game device 10 is driven by a battery, in order to prevent the battery from being wasted, the broadcast data is transmitted every predetermined period (in this embodiment, 64 ms) during the period of working as the master unit. It is. That is, broadcast transmission is executed intermittently.

Although omitted in the character exchange process (FIGS. 12 to 15) described above, provided character information 1, provided character information 2, and game data (character information data) are the payload field Payload of the parent device packet or the child device packet. Is stored between the parent device and the child device.

  The communication partner search and connection process (1) and the communication partner search and connection process (2) will be specifically described below with reference to flowcharts.

  FIG. 18 is a flowchart showing communication partner search and connection processing (1). Referring to FIG. 18, when communication partner search and connection processing (1) is started, Tsc is randomly determined within a range of 0 to Tcycle in step S151. Although illustration is omitted, since Tcycle is a fixed value, when Tsc is determined, Tsp is also determined.

  Subsequent steps S153 to S163 are processes executed in the above-described Tsc, and a process of operating as a slave unit and searching for a master unit is performed. Steps S165 to S177 are processes executed in the above-described Tsp, and a process of operating as a master unit and searching for a slave unit is performed.

  In step S153, a search for the master unit is started. Although not shown, the timer circuit is started at this time. Next, in step S155, it is determined whether or not broadcast data indicating that the parent device can be connected (data in which Eflag is ON) has been received.

  If “YES” in the step S155, that is, if broadcast data (parent device packet) indicating that the parent device can be connected is received, a connection request (child device packet) is transmitted to the parent device in a step S157, and then In step S159, it is determined whether a connection response is received from the parent device. If “NO” in the step S159, that is, if a connection response is not received from the parent device, the process returns to the step S157 as it is. On the other hand, if “YES” in the step S159, that is, if a connection response is received from the parent device, it is determined that a connection is established with another portable game device as a child device, and in step S161, the child device is determined. The flag is turned on, and the communication partner search and connection process (1) is returned.

  Although omitted in FIG. 18, when the communication partner search and connection process (1) is started, the child device flag (the same as the parent device flag described later) is turned off (reset).

  On the other hand, if “NO” in the step S155, that is, broadcast data from the parent device is not received at all, or broadcast data from the parent device is received but the broadcast data does not indicate that connection is possible ( In step S163, it is determined whether or not Tsc seconds have passed in the parent device search time, that is, the period for attempting to connect to another portable game device as a child device.

  However, in step S155, it is determined whether or not the GameName of the broadcast data of the parent device matches the GameName stored in the ROM 42 of the cartridge 16 attached to the master device. If not, the process proceeds to step S163. The same applies to steps S185 and S211 (see FIGS. 19 and 20) in the communication partner search and connection process (2) described later.

  If “NO” in the step S163, that is, if the parent device search time has not passed Tsc seconds, the process returns to the step S155 as it is. On the other hand, if “YES” in the step S163, that is, if the parent device search time has elapsed for Tsc seconds, the child device search is started in a step S165, that is, the timer circuit is reset and started, and the connection is made in the step S167. Data indicating the possibility (master packet with Eflag set to ON) is broadcasted.

  In subsequent step S169, it is determined whether or not a connection request (child device packet) has been received from the child device. If “YES” in the step S169, that is, if a connection request is received from the slave unit, a connection response is transmitted to the slave unit in a step S171, and the master unit flag is turned on in a step S173 to search for a communication partner. And the connection process (1) is returned. That is, a connection is established between the other portable game devices as the parent device.

  On the other hand, if “NO” in the step S169, that is, if a connection request from the slave unit is not received, in a step S175, 64 ms is waited, and in the subsequent step S177, another communication game is performed as the slave unit search time, that is, the master unit. It is determined whether or not Tsp seconds have passed during the period of trying to connect to the device. If “NO” in the step S177, that is, if the handset search time has not elapsed Tsp seconds, the process returns to the step S167 as it is. On the other hand, if “YES” in the step S177, that is, if the handset search time has elapsed for Tsp seconds, it is determined that the Tcycle period has elapsed, and the communication partner search and connection process (1) is returned. By waiting for 64 ms in step S175, the broadcast transmission processing in S167 is intermittently performed, and power consumption can be suppressed.

  FIG. 19 and FIG. 20 are flowcharts showing communication partner search and connection processing (2). Referring to FIG. 19, when the communication partner search and connection process (2) is started, Tsc1 is randomly determined within a range of 0 to (Tcycle-Tsp) in step S181. As described above, in the communication partner search and connection process (2), since Tcycle and Tsp are fixed values, when Tsc1 is determined, Tsc2 is also determined.

  Subsequent steps S183 to S193 are processes executed in the above-described Tsc1, and a process of operating as a slave unit and searching for the master unit is performed. Steps S195 to S207 are processes executed in the above-described Tsp, and a process of operating as a master unit and searching for slave units is performed. Further, steps S209 to S219 are processes executed in the above-described Tsc2, and a process of operating as a slave unit and searching for the master unit is performed.

  In step S183, a search for the master unit is started. Although not shown, the timer circuit is started at this time. In step S185, it is determined whether or not broadcast data indicating that the parent device can be connected has been received.

  If “YES” in the step S185, that is, if broadcast data indicating that the parent device can be connected is received, a connection request is transmitted to the parent device in a step S187, and then a connection response is sent from the parent device in a step S189. Determine whether it has been received. If “NO” in the step S189, that is, if a connection response is not received from the parent device, the process returns to the step S187 as it is. On the other hand, if “YES” in the step S189, that is, if a connection response is received from the parent device, it is determined that a connection is established with another portable game device as a child device, and in step S191, the child device is determined. The flag is turned on, and the communication partner search and connection process (2) is returned as shown in FIG.

  Although omitted in FIG. 19, when the communication partner search and connection processing (2) is started, the slave device flag and the parent device flag are turned off because the communication partner search and connection processing (1) is performed. Is the same as

  On the other hand, if “NO” in the step S185, that is, broadcast data from the parent device is not received at all, or broadcast data from the parent device is received but the broadcast data does not indicate that connection is possible ( In step S193, it is determined whether or not Tsc1 seconds have passed in the parent device search time, that is, the period for attempting to connect to another portable game device as a child device. If “NO” in the step S193, that is, if the parent device search time does not elapse for Tsc1 seconds, the process returns to the step S185 as it is. On the other hand, if “YES” in the step S193, that is, if the parent device search time Tsc1 seconds elapses, the child device search is started in a step S195, that is, the timer circuit is reset and started, and the connection is made in the step S197. Broadcast data indicating the possibility.

  In a succeeding step S199, it is determined whether or not a connection request is received from the slave unit. If “YES” in the step S199, that is, if a connection request is received from the slave unit, a connection response is transmitted to the slave unit in a step S201, the master unit flag is turned on in a step S203, and a communication partner search is performed. And the connection process (2) is returned. That is, a connection is established between the other portable game devices as the parent device.

  On the other hand, if “NO” in the step S199, that is, if a connection request from the slave unit is not received, in a step S205, 64 ms is waited, and in a subsequent step S207, another communication game is performed as a slave unit search time, that is, a master unit. It is determined whether or not Tsp seconds have passed during the period of trying to connect to the device. If “NO” in the step S207, that is, if the handset search time has not passed Tsp seconds, the process returns to the step S197 as it is. On the other hand, if “YES” in the step S207, that is, if the handset search time elapses Tsp seconds, a search for the parent device is started in a step 209 shown in FIG. At this time, the timer circuit is reset and started.

In the next step S211, it is determined whether or not broadcast data indicating that the parent device can be connected has been received. If “YES” in the step S211, that is, if broadcast data indicating that the parent device can be connected is received, a connection request is transmitted to the parent device in a step S213, and then a connection response is transmitted from the parent device in a step S215. Determine whether it has been received. If “NO” in the step S215, that is, if a connection response is not received from the parent device, the process returns to the step S213 as it is. On the other hand, if “YES” in the step S215, that is, if a connection response is received from the parent device, it is determined that a connection is established with another portable game device as a child device, and in step S217, the child device is determined. The flag is turned on, and the communication partner search and connection process (2) is returned.

  On the other hand, if “NO” in step S211, that is, if broadcast data from the parent device is not received at all, or if broadcast data from the parent device is received but the broadcast data does not indicate that connection is possible ( In step S219, it is determined whether Tsc2 seconds have elapsed. If “NO” in the step S219, that is, if the parent device search time has not passed Tsc2 seconds, the process returns to the step S211 as it is. On the other hand, if “YES” in the step S219, that is, if the parent device search time has elapsed for Tsc2 seconds, it is determined that the Tcycle period has elapsed, and the communication partner search and connection process (2) is returned.

  According to this embodiment, since characters that meet the exchange conditions can be automatically exchanged by wireless communication, there is no trouble of negotiating character exchange with an acquaintance. That is, game data can be exchanged easily.

  Moreover, since the partner to exchange is not limited to an acquaintance, if it goes to the place where people gather, the possibility that characters can be exchanged can be increased, and the enjoyment of exchange can be increased. That is, the interest of the game can be improved.

  In this embodiment, only a game system using a portable game device has been described. However, a portable terminal such as a mobile phone or a PDA having a game function can be used instead of the portable game device.

  In this embodiment, one exchange character and one exchange condition are set as exchange conditions set at a time. However, a plurality of provided character information may be set at one time and an exchange condition may be set for each. That is, a plurality of pieces of game data owned by the player are set as game data to be provided, and an exchange condition is set for each. In this way, a plurality of exchange conditions are set at one time, and the probability of matching with the exchange conditions of other players is increased, and the possibility of exchanging game data is further increased.

  In this case, for example, it is assumed that a plurality of provided characters are set in game device A and game device B, and an exchange condition is set for each provided character. When the characters are exchanged between the game device A and the game device B, the exchange conditions of the game device A and the set of characters provided by the game device B that satisfy the conditions are picked up. Then, for the set of the exchange condition (exchange condition a) of the picked-up game apparatus A and the provided character (provided character b) of the game apparatus B, the provided character (provided character a) for which the exchange condition a is set ) Satisfies the exchange condition (exchange condition b) of the game apparatus B set for the provided character b, and if satisfied, the provided character a and the provided character b are exchanged.

  Furthermore, in this embodiment, the character type and level are specified as the provided character information and the exchange condition. However, the present invention is not limited to this, and only the character type may be specified. Only the level may be specified without specifying. Further, the information to be specified may be information other than the character type and level.

Furthermore, in this embodiment, the master unit broadcasts predetermined information, establishes a connection with the slave unit that has received the information, and then transmits / receives information for determining the exchange condition. The broadcast data transmitted from the parent device may include information for determining the exchange condition (provided character information (type, level) and requested character information (type, level) in the above-described embodiment). . Then, the slave unit that has received the broadcast data refers to the information on the provided character and the information on the request character included in the broadcast data, and only if the specified information satisfies its own provided character or exchange condition, A connection request may be made to the terminal.

  Furthermore, in this embodiment, based on the exchange table, provided game data and exchange conditions are set when the progress of the game satisfies a predetermined condition, but the player can always provide provided game data and exchange conditions. It may be settable.

  Furthermore, in this embodiment, while the game process (step S5 in FIG. 7) is being executed, the character exchange process (step S9 in FIG. 7) is simultaneously executed in parallel, but the game process is being executed. If not, only the character exchange process may be executed. In this case, since the display of the LCD 18 is not necessary except during the process of confirming the intention of exchange or the process of displaying information about the game data exchanged when there is an exchange, the power to the LCD 18 is saved for power saving. The supply is cut off (the value of the LCD power supply register is set to 0 and the display of the LCD 18 is turned off), and the CPU 20 performs the character exchange process. Then, processing for confirming whether or not to exchange (steps S128 and 129 in FIG. 14) or processing for displaying information about the exchanged characters (step S116 in FIG. 13 and step S146 in FIG. 15). When executing the above, by setting the value of the LCD power supply register to 1, the power is supplied to the LCD so that the screen for confirming the exchange and information about the exchanged character are displayed on the LCD 18. May be. By doing so, for example, the game device can be carried in a bag or pocket, and the character exchange process can be executed to continue searching for an opponent whose exchange conditions match, and the display on the LCD is off. Convenient for saving power. Assuming such a situation, when turning on the LCD display, a sound (music) is output from the game device, or a vibration function is provided to vibrate the game device to inform the player to that effect. You may make it alert | report.

  Furthermore, even when the character is set as the provided character, when the character is selected as a character to be used for the game process (FIGS. 8 and 9), the provided character is not subject to exchange. You may make it not. That is, for a character selected by the player before the game is started as a character used for the game process, even if the character is set as a provided character, the character exchange process (FIGS. 12 to 15). ), It may be excluded from the processing as not being set as the provided character.

DESCRIPTION OF SYMBOLS 10 ... Portable game device 12 ... Portable game machine 14 ... Wireless communication unit 16 ... Cartridge 18 ... LCD
20 ... Processor 22 ... CPU core 24 ... Boot ROM
28 ... WRAM
38 ... Operation switch 42 ... ROM
44 ... Backup RAM

Claims (6)

A game system including a plurality of portable game devices and transmitting / receiving game data between the game devices,
Each of the game devices
Game data storage means for storing game data;
Communication means for communicating with other game devices;
When it is determined that the game data can be transmitted and received, the communication means is used to search for an unspecified other game device, and to communicate with another game device searched by the search means. Thus, the game data stored in the game data storage means is transmitted to the other game device, the game data transmitted from the other game device is received, and the received game data is stored in the game data storage. A game system comprising game data transmission / reception means stored in the means. The search means, wherein when it is determined the game data to be transmitted and received ready, by using the communication unit to search for another game apparatus unspecified existing in a predetermined range, according to claim 1 Symbol placement game system. The game apparatus further includes game program storage means for storing a game program, and game program execution means for executing the game program,
The game data transmission / reception means searches for another unspecified game device existing in a predetermined range by the search means during execution of the game program by the game program execution means, and communicates with the other game devices searched for. The game data stored in the game data storage means is transmitted to the other game device, the game data transmitted from the other game device is received, and the received game data is transmitted to the game data. stored in the storage unit, according to claim 2 Symbol placement game system. The game program, the game device to generate game data to the processing means provided in the game data the generated to perform the process of storing the game data storage unit, according to claim 3, wherein the game system. Before Symbol game data reception means, during the execution of the game program by the game program executing means, wherein one of the stored game data in the game data storage unit, is selected as the game data used to run the game program exclude game data are from the transmission of the target, according to claim 3 or 4 SL placement game system. The game apparatus further comprises progress of the virtual game according the game program executed by the pre-Symbol game program executing means a determination means for determining that a predetermined condition is satisfied,
6. The game system according to claim 3 , wherein the game data transmitting / receiving unit is activated or disabled in response to the determination unit determining that the predetermined condition is satisfied.

Images