JP5607403B2 - GAME SYSTEM AND GAME DEVICE - Google Patents

Description

  The present invention relates to a game system or the like in which a server system and a plurality of game apparatuses capable of executing a multiplayer game are connected to be able to communicate with each other.

  A game system that stores game data of each player in a server using a game card as a network game system in which a server that manages a network game and a business game device installed in a store or the like are connected via a communication line It has been known. In this game system, the game data of the player is stored in the server in association with the card ID of the game card owned by the player, and in the game device, the game data corresponding to the card ID of the game card is acquired from the server. Then, a game using this game data is executed. Thereby, the player can continuously enjoy the game play using his / her game data on any game device in any store by using the game card (see, for example, Patent Document 1).

JP 2009-213737 A

  There are various game systems that use game cards, such as raising the level and raising it to a stronger character through continuous game play by using the game card, and obtaining benefits such as items based on the accumulated virtual money, the number of times played, etc. There are many ways to enjoy it.

  However, using a game card has a high threshold for players who rarely play arcade game devices. In other words, since it is usually necessary to purchase a game card separately, it is necessary to decide whether or not to continue playing the game before purchasing the game card. However, the fun of games using game cards has not been understood by players who do not purchase game cards.

  The present invention has been made in view of the above circumstances, and an object of the present invention is to make it possible to experience the fun of a game unique to possession of a game card even if the game card is not possessed.

The first form for solving the above problem is
The game data of the owner player who is the owner of the authentication medium (for example, the game card 50 in FIG. 1) storing the authentication ID is stored in the storage unit (for example, the storage unit 200 in FIG. 17) in association with the authentication ID. A server system (for example, the server system 10 in FIG. 1) and a reading device (for example, the card reading unit 320 in FIG. 9) that reads the authentication ID from the authentication medium when performing login processing as an owner player. Alternatively, a game system in which a plurality of game devices (for example, the game device 30 in FIG. 1) capable of executing a multiplayer game by a plurality of devices are connected to be communicable,
The game device includes:
A residence registration accepting means (for example, step C25 in FIG. 21) that accepts a selection operation for selecting an owner player as a residence destination and accepts a residence registration process for registering the player as a residence player of the owner player of the residence destination. ,
Resident player data transmission means for transmitting the game data of the multiplayer game of the own player to the server system as data as a residence player of the owner player of the residence destination accepted by the residence registration acceptance means (for example, step of FIG. 21) C33)
With
The server system is
In accordance with the contents received by the residence registration acceptance means, the game data transmitted by the residence player data transmission means is stored as a game data of the residence player in the storage unit in association with the authentication ID of the owner player of the residence destination. Means (for example, step E43 in FIG. 24),
With
It is a game system.

As another form,
A server system (for example, the server in FIG. 1) that stores the game data of the owner player who is the owner of the authentication medium (for example, the game card 50 in FIG. 1) storing the authentication ID in the storage unit in association with the authentication ID. A game apparatus (for example, FIG. 1) that includes a reader that reads the authentication ID from the authentication medium when performing login processing as an owner player, and that executes a multiplayer game by a single unit or a plurality of units. 1 game device 30),
A residence registration accepting means for accepting a selection operation for selecting an owner player as a residence destination, and accepting a residence registration process for registering the player as a residence player of the owner player of the residence destination;
Resident player data transmission means for transmitting game data of the multiplayer game of the player to the server system as data as a residence player of the owner player of the residence destination accepted by the residence registration acceptance means;
With
The server system stores the game data transmitted by the residence player data transmission means in association with the authentication ID of the owner player of the residence destination as game data of the residence player in accordance with the contents accepted by the residence registration acceptance means Will be remembered,
A game device may be configured.

  According to the first embodiment, the own player is registered as the residence player of the owner player who owns the authentication medium, so that the owner player player owns the game data of the own player. It can be stored in the server system in association with the authentication medium. Accordingly, even if the user does not own the authentication medium, a game using his / her own game data stored in association with the authentication medium owned by the owner player of the residence destination is possible.

A second form is a game system according to the first form,
The residence registration receiving means permits execution of the residence registration process when a predetermined approval process is performed by the owner player of the residence destination.
A game system may be configured.

  According to the second embodiment, when a predetermined approval process is performed by the owner player of the residence destination, execution of the residence registration process is permitted. In other words, it is impossible to register a staying player who uses the owner player as a destination without permission from the owner player.

A third form is a game system according to the first or second form,
The game device includes:
Simultaneous login detection means (for example, step A11 in FIG. 19) for detecting that the owner player of the destination is simultaneously performing login processing;
Residence registration inquiry means (for example, step A25 in FIG. 19) for making an inquiry to the server system as to whether or not the player is registered as a residence player of the owner player of the residence destination detected by the simultaneous login detection means;
When an answer indicating that the registration is made in response to the inquiry of the residence registration inquiry means is obtained, the game data of the corresponding residence player is obtained from the server system, and the player is determined to be the residence player based on the game data. As a residence data play execution control means (for example, step A17 in FIG. 19) for participating in the multi-play game,
You may comprise the game system provided further.

  According to the third aspect, in the game device, when the own player who is registered as the residence player logs in at the same time, the game data of the corresponding residence player is acquired from the server system. Then, the player can participate in the multiplayer game as a staying player based on the game data.

A fourth form is a game system according to the third form,
The server system is
Residing player data deleting means for deleting game data of the staying player from the storage unit according to the number of plays as the staying player executed by the staying data play execution control means and / or the elapsed time since the last play. The
A game system may be configured.

  According to the fourth aspect, in the server system, the game data of the staying player is deleted from the storage unit according to the number of plays as the staying player and / or the elapsed date and time since the last play. In other words, if the player has not played for a predetermined period of time, or if the player has played more than a predetermined number of times, the game data for the player will be invalid.

Further, as a fifth form, the game system according to any one of the first to fourth forms,
The server system is
A data movement request receiving means (for example, step E45 of FIG. 24) for receiving a movement request signal of game data having the residence player and the owner player of the residence destination as the movement source and another owner player as the movement destination;
In accordance with the content received by the data movement request receiving means, the game data of the movement source player player stored in the storage unit in association with the authentication ID of the movement source owner player is used as game data of the movement destination owner player. Data moving means for storing and updating in the storage unit (for example, step E51 in FIG. 24);
With
A game system may be configured.

  According to the fifth embodiment, in the server system, the owner of the movement source is received by receiving the movement request signal of the game data with the residence player and the owner player of the residence destination as the movement source and another owner player as the movement destination. The game data of the source player player stored in association with the player authentication ID is stored and updated as the game data of the destination owner player. Thus, for example, when a new authentication medium is purchased and becomes an owner player, the game data registered as a staying player of another owner player is moved to the new own authentication medium (correctly) Change the association).

Moreover, as a sixth mode, the game system according to any one of the first to fifth modes,
The server system is
For each owner player, a plurality of characters owned by the owner player having a growth element such as a level or a rank are included in the game data and stored in the storage unit,
The game device includes:
During the login process, a borrowing processing means (for example, step A41 in FIG. 19) that accepts a selection operation for selecting another owner player who is not the player and a borrowed character to be borrowed from among a plurality of characters owned by the other owner player. )When,
When another owner player selected by the borrowing processing means is simultaneously logging in, the borrowed character data selected by the borrowing processing means is acquired from the server system and owned by the other owner player. Character borrowing play execution control means (for example, step A43 in FIG. 19) for allowing the borrowed character having the growth element to participate in the multiplayer game as the operation character of the player,
With
A game system may be configured.

As a seventh form,
For each owner player who is the owner of the authentication medium storing the authentication ID, game data including data of a plurality of characters owned by the owner player having a growth factor such as a level or rank is associated with the authentication ID. A server system stored in the storage unit communicates with a plurality of game devices including a reading device that reads the authentication ID from the authentication medium when performing login processing as an owner player, and capable of executing a multiplayer game by a single device or a plurality of devices. A connected game system,
The game device includes:
A borrowing processing means for accepting a selection operation for selecting another owner player who is not his / her player and a borrowed character to be borrowed from a plurality of characters owned by the other owner player at the time of login processing;
When another owner player selected by the borrowing processing means is simultaneously logging in, the borrowed character data selected by the borrowing processing means is acquired from the server system and owned by the other owner player. A character borrowing play execution control means for participating in the multiplayer game as a borrowed character having a growth element as an operation character of the player,
With
A game system may be configured.

As another form,
For each owner player who is the owner of the authentication medium storing the authentication ID, game data including data of a plurality of characters owned by the owner player having a growth factor such as a level or rank is associated with the authentication ID. A game device that is connected to a server system stored in a storage unit so as to be communicable, and that includes a reading device that reads the authentication ID from the authentication medium when performing login processing as an owner player, and executes a single player or a plurality of multiplayer games Because
A borrowing processing means for accepting a selection operation for selecting another owner player who is not his / her player and a borrowed character to be borrowed from a plurality of characters owned by the other owner player at the time of login processing;
When another owner player selected by the borrowing processing means is simultaneously logging in, the borrowed character data selected by the borrowing processing means is acquired from the server system and owned by the other owner player. A character borrowing play execution control means for participating in the multiplayer game as a borrowed character having a growth element as an operation character of the player,
You may comprise the game device provided with.

  According to the sixth embodiment, the game device borrows a character from a plurality of characters owned by the owner player from other owner players who are simultaneously logged in, and uses the borrowed character as an operation of the player. You can participate in a multiplayer game as a character.

Further, as an eighth form, the game system of the sixth or seventh form,
The server system is
For each owner player, the virtual money acquired during the game is stored in the storage unit,
Virtual money acquisition destination control in which the virtual money acquired by the borrowed character participating in the multiplayer game by the character borrowing play execution control means is updated and stored in the storage unit as virtual money acquired by the owner player of the borrower of the borrowed character With means,
A game system may be configured.

  According to the eighth embodiment, the server system stores the virtual money acquired during the game for each owner player, and the virtual money acquired by the borrowed character participating in the multiplayer game is the lender of the borrowed character. It is stored and updated as virtual money acquired by the owner player. That is, when participating in a multiplayer game using a borrowed character as an operation character, the acquired virtual money is treated as virtual money acquired by the owner player of the borrower character lender. This can be a motivation for lending an owned character to another player.

The block diagram of a game system. Explanatory drawing of registration of the character to a game card. Explanatory drawing (1) of a character's residence. Explanatory drawing (2) of a character's residence. Explanatory drawing of character borrowing. Specific examples of characters that can be used by the player. Specific examples of characters that can be used by the player. Explanatory drawing of the movement of the character between game cards. The functional block diagram of a game device. Data structure example of matching data. An example of a character type selection screen. An example of your character selection screen. An example of a borrowing player selection screen. An example of a borrowed character selection screen. An example of a screen for selecting whether or not to borrow own character. An example of a destination selection screen. The function block diagram of a server system. An example of the data structure of card data. The flowchart (1) of a game process. The flowchart (2) of a game process. The flowchart (3) of a game process. The flowchart of the single play process performed during a game process. The flowchart (1) of a data management process. The flowchart (2) of a data management process.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. In the following, a business network game system for playing a car racing game will be described as an example, but an embodiment to which the present invention can be applied is not limited to this.

[System configuration]
FIG. 1 is a configuration diagram of a game system 1 of the present embodiment. As shown in FIG. 1, the game system 1 is a network game system in which a server system 10 and a plurality of game devices 30 are connected to be communicable via a communication line N. Here, the communication line N is meant to include a communication network such as a telephone communication network, a cable network, and the Internet in addition to a dedicated line (dedicated cable) for direct connection, a LAN using Ethernet (registered trademark), and the like. The communication method may be wired / wireless.

  The server system 10 is installed and managed on the game system operating company (game maker) side, and is configured using a known server computer. The server system 10 functions as a game server that manages the execution of games in the game system 1 and also functions as a data management server that manages game data of players in the game. The server system 10 may be configured by a plurality of server computers connected to each other or may be configured by a single server computer.

  The game device 30 is a business game device that is installed in a store such as a game center and is used for a player to play a game. The game devices 30 in the same store are connected by a communication line realized by a local network or the like. In the game apparatus 30, a car racing game is executed in which a racing car that is a player character is operated to run on a race course and compete with other racing cars for time and ranking. In this car racing game, as a game mode, “single play” which is executed by a single device and plays against a computer-controlled character, and communicates with other game devices 30 in the same store to play against other players. "Multiplayer (communicative battle)" is possible.

[Game card]
In the game system 1 of the present embodiment, the player stores the game data including the player character data in the server system 10 by possessing the game card 50 as an authentication medium and registering it in the game system 1. In any game device 30 in any store, it is possible to enjoy a car racing game using its own player character (own character). Here, the game card 50 is provided to the player by sales or the like, and is realized, for example, by an IC card incorporating an IC chip in which a unique card ID is stored.

  As a feature of the present embodiment, in multiplayer, a game card 50 owned by a certain player can be “used” by another player. Specifically, (1) “move (deposit)” a character of a player who does not own the game card 50 to another player who owns the game card 50, and (2) another player who owns the game card 50. It is possible to "borrow" a character from

  FIG. 2 is a diagram for explaining the outline of registration of characters in the game card 50. As shown in FIG. 2, the game card 50 includes (1) a player character 60 that is a player character of the player who owns the game card 50 (owner player), and (2) other players (residence) other than the owned player. Two types of registered characters 70 are registered. A player who owns the game card 50 can register a plurality of own characters 60 in the game card 50. Moreover, as for the staying characters 70, one staying character 70 can be registered for each of the staying players up to a predetermined number of people (three people in FIG. 2). Here, “registered” in the game card 50 means that the character data is stored in the server system 10 in association with the game card 50.

  FIG. 3 is a diagram for explaining the “residence” of a character in multiplayer. FIG. 3 shows a case where multiplayer is performed by a plurality of players including players A and B in the same store. Player A logs in using game card 50A, and player B does not own game card 50. The player A's own character 60-a is registered in the game card 50A owned by the player A.

  In multiplayer, the player A performs a game play using the player character 60-a registered in the game card 50A owned by the player A, and the player B performs a game play using the new character.

  Then, after the multiplayer is completed, the data of the player character 60-a registered in the game card 50A is updated based on the play result of the player A. Further, based on the play result of the player B, the new character used is additionally registered in the game card 50A as the staying character 70-b of the player B. In other words, the character 70-b of the player B “stops” to the player A. In this case, the player A is a “departure destination” player, and the player B is a “departure origin” player.

  Thereafter, when both of the players A and B play multiplayer, as shown in FIG. 4, the player A performs game play using the player character 60-a registered in the game card 50 owned by the player A, B can play a game using the staying character 70-b registered in the game card 50 of the player A. Then, after the end of the multiplayer, the data of the player character 60-a of the game card 50A is updated based on the play result of the player A, and the staying character 70-b of the game card 50A is updated based on the play result of the player B. The data of is updated.

  As described above, when the player B performs multiplayer with the player A, the player B “uses” the game card 50A owned by the player A, as if he / she owns the game card 50. You can enjoy the game using characters.

  FIG. 5 is a diagram for explaining “borrowing” of a character in multiplayer. FIG. 5 shows a case where multiplayer is performed by a plurality of players including players A and B in the same store. The player A logs in using the game card 50A, and the player B does not own the game card 50. Two player A's own characters 60-a1 and 60-a2 are registered in the game card 50A of the player A.

  In multiplayer, the player A performs a game play using the player character 60-a1 registered in the game card 50A. Further, the player B can “borrow” the player A's own character 60-a2 registered in the game card 50, and can play a game using the player character 60-a2.

  Then, after the multiplayer is completed, the data of the player character 60-a1 of the game card 50A is updated based on the play result of the player A. However, the data of the player character 60-a2 borrowed by the player B is not updated.

  Here, the characters that can be borrowed by other players are the own characters that are not used by the player who owns the game card 50. That is, in FIG. 5, since player A uses his / her own character 60-a1, player B can borrow another player's own character 60-a2. In this case, player A is a “borrowing source” player and player B is a “borrowing destination” player.

  In this way, in multi-play, the player (1) own character 60 registered in the game card 50 owned by himself, (2) a staying character (other player owns) that is “stopped” by another player. (3) A borrowed character (borrowed) from another player (own character 60 registered in the game card 50 of another player), (4) prepared in advance 4 types of new characters can be used.

  6 and 7 are diagrams showing specific examples of characters that can be used by the player in multiplayer. In FIG. 6, the player A logs in using the game card 50 </ b> A, and the players B and C do not own the game card 50. Registered in the game card 50A of the player A are the own characters 60-a1 to 60-a3 of the player A who is the owning player and the staying characters 70-b and 70-e of the players B and E which are the staying players. Has been.

  In this case, in multiplayer, the player A can use any of the own characters 60-a1 to 60-a3 registered in the game card 50A owned by the player A and a new character.

  Then, if the player A uses the player character 60-a1, the player B is the player A's own character registered in the game card 50A and is not used by the player A. -A3, any of the staying character 70-b staying on the game card 50A of the player A and the new character can be used. In addition, the player C may use one of the player A's own characters registered in the game card 50A and the player A's own characters 60-a2, 60-a3 and new characters that the player A does not use. it can.

  In FIG. 7, the players A and D are logged in using the game cards 50 </ b> A and 50 </ b> D, respectively, and the player C does not own the game card 50. In the game card 50A of the player A, the player A's own character 60-a1 to 60-a3 as the owned player and the residence characters 70-b and 70-e of the players B and E as the residence players are registered. ing. Further, the player D's own character 60-d1 to 60-d3 is registered in the game card 50D of the player D.

  In this case, the player A can use any of the player character 60-a1 to 60-a3 registered in the game card 50A owned by the player A and a new character. Player B can use a new character. Further, the player D can use his / her own characters 60-d1 to 60-d3 and new characters registered in the game card 50D he / she owns.

  When the player A uses the player character 60-a1, the players B and D can also use their own characters 60-a2 and 60-a3 that are not used by the player A of the game card 50A. When player D borrows and uses player character 60-a2 from player A, players A and B further have player characters 60-d1 to 60-d3 not used by player D of game card 50D. Can also be used.

  In addition, a character (residence character) staying with another player can be “moved” from the game card 50 of the staying destination to the game card 50 of the staying source. The character can be moved between the game cards 50 in a state where the residence destination and the player of the residence source are logged in using the game card 50 owned by both.

  FIG. 8 is a diagram for explaining the “movement” of the character between the game cards 50. FIG. 8 shows a case where player B is staying at player A. That is, in the game card 50A owned by the player A, the own character 60-a of the player A who is the owning player and the staying character 70-b of the player B who is the staying player are registered. In addition, both players A and B are logged in using their own game cards 50A and 50B.

  When the staying character 70-b staying at the player A is “moved” to the game card 50B of the player B, the player B who is staying at the game apparatus 30 logged in using the game card 50B. The destination player A is designated and a movement instruction is input. Then, the staying character 70-b registered in the game card 50A of the designated destination player is “moved” to the game card 50B of the player B as the player B's own character 60-b. That is, the staying character 70-b of the game card 50A is deleted, and the own character 60-b is additionally registered in the game card 50B.

[Function configuration]
FIG. 9 is a diagram illustrating a functional configuration of the game apparatus 30. According to FIG. 8, the game device 30 functionally includes an operation input unit 310, a card reading unit 320, a processing unit 330, an image display unit 340, an audio output unit 350, a communication unit 360, The storage unit 400 is provided.

  The operation input unit 310 receives an operation instruction from the player and outputs an operation signal corresponding to the operation to the processing unit 330. This function is realized by, for example, a button switch, a lever, a mouse, a keyboard, a touch panel, and various sensors.

  The card reading unit 320 reads data (mainly a card ID) recorded on the inserted game card 50 and outputs the read data to the processing unit 330.

  The processing unit 330 performs various arithmetic processes such as overall control of the game apparatus 30, game progress, and image generation based on programs and data read from the storage unit 400, operation signals input from the operation input unit 310, and the like. This function is realized by, for example, an arithmetic device such as a CPU (CISC type or RISC type), an ASIC (gate array or the like), or a control program thereof. The processing unit 330 mainly includes a game calculation unit 331 that performs calculation processing related to the execution of the game, an image generation unit 332 that generates a game image based on various types of data obtained by the processing of the game calculation unit 331, And a sound generation unit 333 that generates game sounds such as sound effects and BGM.

  The game calculation unit 331 performs game processing for executing game play in the game device 30 in accordance with the game program 410. In this game process, first, the presence or absence of the game card 50 is determined. If there is a game card 50, the server system 10 is requested to authenticate the game card 50. At this time, an input screen for inputting the player name and password is displayed on the image display unit 340, and the server system 10 is requested to perform card authentication together with the input player name and password and the card ID read from the game card 50. . When the card authentication is performed, the game mode (multiplayer / single play) is subsequently determined according to the operation input of the player.

  When performing multi-play, communication processing is performed with other game devices 30 in the same store, and matching processing is performed to determine the game device 30 to play against. Here, data on the matching performed is stored as matching data 430.

  FIG. 10 is a diagram illustrating an example of the data configuration of the matching data 430. According to FIG. 10, the matching data 430 stores the player name 432, the presence / absence 433 of the game card 50, and the character 434 to be used for each of the matched game devices 431.

  Next, the game calculation unit 331 determines a character used by the player. That is, first, a character type selection screen for selecting the type of character to be used (own character / resident character / borrowed character / new character) is displayed on the image display unit 340 in accordance with the presence or absence of the game card 50.

  FIG. 11A shows an example of a character type selection screen when there is a game card 50, and FIG. 11B shows an example of a character type selection screen when there is no game card 50. FIG. As shown in FIGS. 11A and 11B, the character type selection screen displays a list of character type names that can be selected by the player.

  That is, as shown in FIG. 11A, on the character type selection screen in the case where there is a game card 50, four types of own character, resident character, borrowed character, and new character are displayed as options P1 as a list. Has been. Further, as shown in FIG. 11B, on the character type selection screen when there is no game card 50, three types of a staying character, a borrowed character, and a new character are listed as options P1. .

  In the character type selection screen, the game calculation unit 331 determines the character to be used according to the determined type when the type of the character to be used is selected and determined according to the operation input of the player. That is, if the player character is used, the server system 10 is requested to request a list of registered player characters along with the card ID of the game card 50. In response to this, a self-character selection screen for selecting a self-character to be used is displayed on the image display unit 340 based on the self-character list transmitted from the server system 10.

  FIG. 12 is a diagram illustrating an example of the own character selection screen. As shown in FIG. 12, on the player character list screen, the names and images of the player characters registered in the game card 50 are listed as options P2.

  In the player character list screen, the game calculation unit 331 selects and determines the player character to be used in accordance with the player's operation input. Next, the server system 10 is requested for character data corresponding to the determined own character, and in response to this, the character data transmitted from the server system 10 is received.

  If a residence character is used, the game calculation unit 331 requests the residence authentication from the server system 10. At this time, an input screen for inputting the player name and the destination player name is displayed on the image display unit 340, and the residence authentication is requested together with the input player name and the player name of the destination. Here, the destination is the other player who is playing multiplayer together, and the player with the game card 50 is determined from the matching data 430. When the residence authentication is performed, the character data of the residence character transmitted from the server system 10 is received.

  If a borrowed character is used, first, a borrowed player selection screen for selecting a player who borrows the character is displayed on the image display unit 340.

  FIG. 13 is a diagram illustrating an example of a borrowed player selection screen. As shown in FIG. 13, on the borrowing player selection screen, player names that can borrow characters are listed as options P3. Here, a player who can borrow a character is another player who is playing multiplayer together and has a game card 50, and is determined by referring to the matching data 430.

  On this borrowing player selection screen, the game calculation unit 331 selects and determines a player (borrowing destination player) that borrows the character in accordance with the player's operation input. Next, a character borrowing inquiry is transmitted to the game device 30 of the determined borrowed player. In response to this, a borrowed character selection screen for selecting a borrowed character is displayed on the image display unit 340 based on whether or not the borrowed character is transmitted from the game apparatus 30.

  FIG. 14 is a diagram illustrating an example of a borrowed character selection screen. According to FIG. 14, on the borrowed character selection screen, the names and images of characters permitted to be borrowed from the borrowed player are listed as options P4. Here, the borrowable character is the player character registered in the game card 50 of the borrowed player.

  In the borrowed character selection screen, the game calculation unit 331 selects and determines one character (borrowed character) to be borrowed according to the operation input of the player. Subsequently, the server system 10 is requested for the character data of the determined borrowed character, and in response to this, the character data transmitted from the server system 10 is received.

  If a new character is to be used, a list of a plurality of new characters prepared in advance is displayed, and one character is selected from these characters according to the operation input of the player and determined as a character to be used. Here, the character data of the new character is stored as new character data 420.

  Further, when there is a game card 50, if a character borrowing inquiry is made from another game device 30, the game calculation unit 331 may lend the player character registered in the game card 50 to another player. The image display unit 340 displays a screen for determining whether or not to borrow the own character for determining whether or not (borrowability). At this time, the server system 10 is requested to request a list of own characters together with the card ID, and in response to this, based on the list of own characters transmitted from the server system 10, the own character displayed as a list is displayed. Display the character borrowing decision screen.

  FIG. 15 is a diagram illustrating an example of the own character borrowing availability determination screen. As shown in FIG. 15, on the own character borrowing permission / inhibition decision screen, the player who is requested to borrow is permitted to borrow for each of the own characters registered in the game card 50 excluding the player's own character. Whether or not to do so is displayed as option P5.

  In this own character borrowability determination screen, the game calculation unit 331 determines whether or not to borrow each own character excluding the character to be used by itself among the own characters registered in the own game card 50 in accordance with the operation input of the player. To do. Then, the determined availability of each character is transmitted to the game device 30 that has been inquired.

  After that, when the characters to be used in all the matched game devices 30 are determined, communication is performed with the matched game devices 30, and a game play (multi-play) for battle between the game devices 30 is started.

  When the game play (multiplayer) is completed, the game calculation unit 331 transmits play data of the game play performed to the server system 10. Specifically, (1) when there is a game card 50, the play data of the performed game play is transmitted to the server system 10 together with a request according to the type of character used.

  That is, if the used character is the own character, the play data is transmitted to the server system 10 together with the card ID of the game card 50 and the character ID of the used own character, and the update of the data of the own character is requested. .

  If the used character is a staying character, the play data is transmitted to the server system 10 together with the character ID of the used staying character, the player name, and the name of the destination player to request updating of the staying character data. .

  If the used character is a borrowed character, the play data is transmitted to the server system 10 together with the player name, the borrowed player name, and the character ID of the borrowed character used to end the borrowing of the character. Notice.

  If the used character is a new character, the play data is transmitted to the server system 10 together with the card ID of the game card 50, and the additional registration to the game card 50 is requested with the used new character as the new own character. .

  On the other hand, (2) if there is no game card 50, it is first determined whether or not to newly purchase the game card 50 according to the operation input of the player.

  If a game card 50 is to be purchased, a new game card 50 is sold to the player, and a card purchase / registration process for newly registering the game card 50 in the server system 10 is performed. That is, when a predetermined number of coins are inserted as card consideration, an input screen for inputting a player name and password is displayed, and the player name and password input by the player are used as the card ID of the game card 50 to be sold. At the same time, it is transmitted to the server system 10 to request a new registration of the game card 50.

  If the game card 50 is sold and newly registered, the game calculation unit 331 subsequently transmits the play data of the game play performed to the server system 10 together with a request according to the type of character used. That is, if the used character is a staying character, the play data is transmitted to the server system 10 together with the player name, the player name of the staying destination, and the character ID of the used staying character, and the data of the corresponding staying character. Request an update.

  Next, a “character moving process” is performed in which the resident character is moved from the resident to the newly purchased game card 50. That is, the server system 10 is requested to move the residence character to the own game card 50 together with the own player name, the player name of the residence destination, and the card ID of the own game card 50.

  If the used character is a borrowed character, the play data is transmitted to the server system 10 together with the player name, the borrowed player name, and the character ID of the borrowed character used to end the borrowing of the character. Notice.

  If the used character is a new character, the game data is transmitted to the server system 10 together with the card ID of the sold game card 50, and a new registration to the game card 50 is requested with the new character used as its own character. To do.

  On the other hand, if the game card 50 is not purchased, the play data of the performed game play is transmitted to the server system 10 together with a request according to the type of character used.

  That is, if the used character is a staying character, the play data is transmitted to the server system 10 together with the player name, the player name of the staying destination, and the character ID of the used staying character, and the data of the corresponding staying character. Request an update.

  If the used character is a borrowed character, the play data is transmitted to the server system 10 together with the player name, the borrowed player name, and the character ID of the borrowed character used to end the borrowing of the character. Notice.

  If the used character is a new character, it is determined whether or not another player is allowed to stay according to the operation input of the player. At this time, a destination selection screen for selecting a destination player is displayed on the image display unit 340.

  FIG. 16 is a diagram illustrating an example of a destination selection screen. As shown in FIG. 16, on the destination selection screen, players capable of staying characters are listed as options P6. Here, a player who can stay is another player who is playing multiplayer and has a game card 50, and is determined by referring to the matching data 430. On this destination selection screen, the game calculation unit 331 selects and determines a player (a destination player) as a destination in accordance with the player's operation input.

  Next, an inquiry about whether or not to allow a residence is transmitted to the game device 30 of the decided destination player. In response to this, if a residence permission is received from the game apparatus 30, the play data is transmitted to the server system 10 together with the player name and the player name of the destination, and the new character used. Requests a residence to a player of the destination.

  Returning to FIG. 9, the image display unit 340 displays the game screen while redrawing an image of one frame every 1/60 seconds, for example, based on the image signal from the image generation unit 332. This function is realized by a display device such as a CRT, LCD, ELD, or PDP. The sound output unit 350 outputs game sound such as BGM and sound effects based on the sound signal from the sound generation unit 333. This function is realized by a speaker, for example.

  The communication unit 360 is connected to the communication line N in accordance with a control signal from the processing unit 330, and performs data communication with an external device (mainly the server system 10). This function is realized by a wireless communication module, TA, router, wired communication cable jack, control circuit, and the like.

  The storage unit 400 stores a system program for realizing various functions for causing the processing unit 330 to control the game apparatus 30 in an integrated manner, a program and data for realizing various functions in the present embodiment, and the like. , Which is used as a work area of the processing unit 330, temporarily stores calculation results executed by the processing unit 330 according to various programs, input data from the operation input unit 310, and the like. This function is realized by, for example, various IC memories, hard disks, MO, ROM, RAM, and the like. In the present embodiment, the storage unit 400 stores a game program 410 as a program, and stores new character data 420 and matching data 430 as data.

  FIG. 17 is a diagram illustrating a functional configuration of the server system 10. According to FIG. 17, the server system 10 is functionally configured to include an input unit 110, a processing unit 120, a display unit 130, a communication unit 140, and a storage unit 200.

  The input unit 110 receives an operation instruction from an administrator of the server system 10 and outputs an operation signal corresponding to the operation instruction to the processing unit 120. This function is realized by, for example, a button switch, lever, keyboard, mouse, touch panel, various sensors, and the like.

  The processing unit 120 is based on programs and data stored in the storage unit 200, operation signals input from the input unit 110, data received from an external device (mainly, the game device 30) via the communication unit 140, and the like. Thus, overall control of the server system 10 is performed. This function is realized, for example, by an arithmetic device such as a CPU (CISC type or RISC type), ASIC (gate array, etc.) or a control program thereof.

  In addition, the processing unit 120 performs a data management process for managing the registered game card 50 in accordance with the data management program 210. Here, data on the game card 50 to be managed by the server system 10 is stored as card data 220.

  FIG. 18 is a diagram illustrating an example of a data configuration of the card data 220. As illustrated in FIG. As shown in FIG. 18, the card data 220 is generated for each registered game card 50, and includes a card ID 221 for identifying the game card 50, owned player data 230 relating to the player who owns the game card 50, Stored is the player player data 240 related to the staying player who owns the owned player.

  The owned player data 230 includes an owned player ID 231, owned player name 232, authentication password 233, own character data 234, play history 235, owned virtual money 236, and own character lending history 237.

  The own character data 234 is data for each own character of the owned player, and includes the character ID and level of the corresponding own character, and data of possessed items. The play history 235 is a history of game play performed by the owned player using the player character, and stores data such as a play date, a play store, and a player character ID used.

  The held virtual money 236 is the currently held virtual money, and the virtual money acquired in the game play using the player character and the game play in which the other player who borrowed the player character uses the player character. And the virtual money acquired in the game play using the staying characters registered in the game card 50 by the other player (residing player) whose owner is the owning player.

  The own character lending history 237 is a history of lending the own character to other players in multi-play, and stores data such as a lending date, a lending own character ID, and a lending destination player name.

  The residence player data 240 stores data for a predetermined number of people (maximum of 3 in FIG. 18). Each residence player data 240 includes a residence player ID 241, a residence player name 242, an authentication password 243, and residence character data. 244 and play history 245 are included. The play history 245 is a history of game play performed by the staying player using the staying character, and stores data such as a play date and a play store.

  In the data management process, the processing unit 120 authenticates the game card 50 in response to the game card 50 authentication request from the game apparatus 30 and transmits the authentication result to the game apparatus 30. That is, whether or not the game card 50 is properly registered is determined depending on whether or not the card ID, player name, and password transmitted together with the card authentication request match the data stored as the card data 220. Certify.

  Further, the processing unit 120 transmits the requested character data to the game device 30 in response to a request from the game device 30. That is, if the data of the player character is requested, the game device 30 refers to the card data 220, and obtains the card ID received together with the request and the character data corresponding to the character ID (player character data 234). Send to.

  If borrowed character data is requested, the card data 220 is referred to, and the borrowed player name, borrowed player name, and character data corresponding to the character ID received along with the request (own character data 234). ) Is transmitted to the game apparatus 30.

  Further, when the residence authentication is requested from the game apparatus 30, the processing unit 120 receives the residence source player name, the residence destination player name, and the residence source player password transmitted together with the request. Based on whether or not the data matches the data stored in the card data 220, it is verified whether or not the character of the player who has stayed is registered as a staying character in the game card 50 of the player who has stayed. Then, if the residence is authenticated, the data of the corresponding residence character (the residence character data 244) is transmitted to the game apparatus 30.

  Further, when a list of the player character is requested from the game device 30, the list data such as the name and image of the player character registered in the game card 50 corresponding to the card ID transmitted together with the request is obtained. This is transmitted to the game apparatus 30.

  Further, after the game play in the game apparatus 30 is completed, the corresponding character data in the card data 220 is updated based on the play data transmitted from the game apparatus 30.

  That is, if an update of the data of the player character is requested together with the play data, the card data 220 is referred to, and it corresponds to the card ID based on the card ID transmitted with the request and the player character ID. The game card 50 is specified, and based on the received play data, the corresponding own character data 234, the play history, and the retained virtual money data of the corresponding card data 220 are updated.

  If update of the data of the residence character is requested together with the play data, the card data 220 is referred to, and the player name of the destination, the player name of the residence source, and the character ID transmitted together with the request are indicated. Based on the received play data, the corresponding resident character data 244 and the possessed virtual money 236 are updated based on the received play data.

  Also, if the end of character borrowing is notified together with the play data, the card data 220 is referred to, and the borrower-destination player name, borrower player name, and borrowed character ID transmitted together with the notification are stored. In addition, the lending player, the lending player, and the rented character are identified, and the character lending history and the virtual money data of the corresponding card data 220 are updated.

  If a new character registration is requested together with the play data, the game card 50 for newly registering the character is specified based on the card ID transmitted together with the request, and the corresponding game card 50 is The own character data 234 based on the received play data is added.

  Further, if the game device 30 requests the character to move, a character moving process for moving the character between the game cards 50 is performed. That is, along with the request, based on the transmitted player name, destination player name, and card ID transmitted, the character's source and destination game cards 50 and the character to be moved (source game) The resident character registered in the card 50 is specified. Next, data of the character to be moved (stopped character data 244) is added as own character data 234 to the card data 220 corresponding to the destination game card 50. Then, the data of the character to be moved (stopping character data 244) is deleted from the game card 50 as the movement source.

  Returning to FIG. 17, the display unit 130 displays a display screen based on the display signal from the processing unit 120. This function is realized by a display device such as a CRT, LCD, ELD, or PDP.

  The communication unit 140 is connected to the communication line N in accordance with a control signal from the processing unit 120, and performs data communication with an external device (mainly, the game device 30). This function is realized by a wireless communication module, TA, router, wired communication cable jack, control circuit, and the like.

  The storage unit 200 stores a system program for causing the processing unit 120 to control the server system 10 in an integrated manner, a program and data for realizing various functions in the present embodiment, and the work area of the processing unit 120. And temporarily stores the calculation results executed by the processing unit 120 according to various programs, input data from the input unit 110, and the like. This function is realized by, for example, an IC memory, hard disk, MO, RAM, VRAM, CD-ROM, or the like. In the present embodiment, the storage unit 200 stores a data management program 210 as a program and card data 220 as data.

[Process flow]
19 to 21 are flowcharts for explaining processing in the game apparatus 30. This game process is executed when a predetermined number of coins are inserted as game consideration in the game apparatus 30.

  As shown in FIG. 19, the game calculation unit 331 first determines whether or not there is a game card 50, and if there is a game card 50 (step A <b> 1: YES), the game ID is read from the own game card 50. Is sent to the server system 10 together with the player name and password input in step S3 to request authentication of the game card 50 (step A3).

  Next, the game mode is selected according to the player's operation input (step A5). If the selected game mode is single play (step A7: NO), single play processing (see FIG. 22) is performed (step A9).

  If the selected game mode is multi-play (step A7: YES), the game calculation unit 331 performs matching processing and determines a game device 30 to play together (step A11). Subsequently, a character type selection screen corresponding to the presence or absence of the game card 50 is displayed, and the type of character to be used is determined.

  If there is a game card 50 (step A13: YES) and the player character is to be used (step A15: YES), the server system 10 is requested to request a list of player characters together with the card ID of the player game card 50. In response to this, a list of own characters transmitted from the server system 10 is received (step A17). Then, a self-character selection screen based on the received self-character list is displayed, and one self-character to be used is selected according to the operation input of the player (step A19). Next, the server system 10 is requested for the character data of the selected own character, and the character data of the own character transmitted from the server system 10 in response thereto is received (step A21).

  If a residence character is used (step A15: NO to A23: YES), a residence authentication request is transmitted to the server system 10 together with the player name inputted by the player and the destination player name (step A25). ). When the residence authentication is performed, the character data of the residence character transmitted from the server system 10 is received (step A27).

  If a borrowed character is used (steps A23: NO to A29: YES), the game calculation unit 331 is a player of another game device 30 that is playing multiplayer, and a player with a game card 50. Is displayed as a list of borrowed player selection screens (step A31). Next, one player is selected from the displayed players in accordance with the player's operation input (step A33), and an inquiry about whether or not the character can be borrowed is transmitted to the game device 30 of the selected borrowing player (step A35). .

  If borrowing of at least one or more characters is permitted based on whether or not borrowing for each character transmitted from the game apparatus 30 is permitted (step A37: YES), a list of borrowable characters is displayed. The borrowed character selection screen is displayed, and one character to be borrowed is determined according to the operation input of the player (step A41). Thereafter, the server system 10 is requested for the character data of the determined borrowed character, and the character data of the borrowed character transmitted from the server system 10 in response thereto is received (step A43).

  On the other hand, if the borrowing of the character is not permitted (step A37: NO), the game calculation unit 331 determines whether there is another player who can borrow the character, and if there is (step 39: YES), the process goes to step A33. Returning, another player who borrows the character is selected (step A33). If there is no other player that can borrow the character (step A39: NO), the process returns to step A13 to reselect the type of character to be used.

  If a new character is to be used (step A29: NO), the game calculation unit 331 selects and determines one character to be used from among the new characters prepared in advance according to the operation input of the player ( Step A45).

  Further, when there is a game card 50 (step A47: YES), if an inquiry about whether or not a character can be borrowed is made from another game device 30 (step A49: YES), each character is borrowed according to the operation input of the player. The availability is determined, and the determined availability of each of the own characters is transmitted to the other game device 30 (step A51).

  And if the character used in all the other game devices 30 matched is determined, communication with these game devices 30 will be performed, and a game play (multiplayer) will be started (step A53).

  As shown in FIG. 20, when the game play (multiplayer) is completed, if there is a game card 50 (step B1: YES), the game calculation unit 331 performs a game performed together with a request according to the type of character used. Play data of play is transmitted to the server system 10.

  That is, if the used character is the own character (step B3: YES), the play data is transmitted to the server system 10 together with the card ID of the game card 50 and the character ID of the used own character. Is requested to be updated (step B5).

  If the used character is a staying character (steps B3: NO to B7: YES), the play data is sent to the server system 10 together with the player name, the player name of the destination, and the character ID of the used staying character. It transmits and requests the update of the data of the resident character (step B9).

  Next, it is determined whether or not to move the staying character to the own game card 50 according to the operation input by the player. If the character is to be moved (step B11: YES), the character moving process is performed, and the used staying character is moved to the own game card 50 as the own character (step B13).

  If the used character is a borrowed character (steps B7 to B15: YES), the game calculation unit 331 sends the play data to the server system 10 together with the card ID of the game card 50 and the borrowed player name. The character is borrowed and transmitted (step B17).

  If the used character is a new character (step B15: NO), the play data is transmitted to the server system 10 together with the player name and the card ID of the player game card 50, and the new character is used as the player character. An additional registration to the game card 50 is requested (step B19).

  If an inquiry is made from another game device 30 as to whether or not the character is allowed to stay (step B21: YES), it is determined whether or not to allow the player to stay in accordance with the operation input of the player, and the determined residence is determined. The approval / disapproval is transmitted to the other game device 30 (step B23).

  On the other hand, if there is no game card 50 (step B1: NO), first, as shown in FIG. 21, it is determined whether or not to newly purchase the game card 50 according to the operation input of the player. If the game card 50 is newly purchased (step C1: YES), card purchase / registration processing is performed (step C3). That is, the game card 50 is sold in exchange for the insertion of a predetermined number of coins as card consideration, and the card ID of the sold game card 50 is transmitted to the server system 10 together with the player name and password input by the player, A new registration of the game card 50 is requested.

  Next, if the used character is a staying character (step C5: YES), the play data is transmitted to the server system together with the player name, the player name of the staying destination, and the character ID of the used staying character. Is requested to be updated (step C7). Thereafter, a character movement process for moving the used staying character to the own game card 50 is performed (step C9). That is, the server system 10 is requested to move the staying character to the own game card 50 together with the player name, the card ID of the player game card 50, and the player name of the destination.

  If the used character is a borrowed character (steps C5: NO to C11: YES), the play data is sent to the server system 10 together with the player name, the borrowed player name, and the character ID of the borrowed character used. It transmits and notifies the end of the borrowing of the character (step C13).

  If the used character is a new character (step C11: NO), the play data is transmitted to the server system 10 together with the card ID of the own game card 50, and the new character is newly registered in the own game card 50. Is requested (step C15).

  On the other hand, if the game card 50 is not purchased (step C1: NO), the game calculation unit 331 transmits to the server system 10 the play data of the performed game play together with a request according to the type of character used.

  That is, if the used character is a residence character (step C17: YES), the play data is transmitted to the server system 10 together with the player name, the player name of the residence destination, and the character ID of the residence character used. A request is made to update the character data of the character (step 19).

  If the used character is a borrowed character (steps C17: NO to C21: YES), the play data is sent to the server system 10 together with the player name, the borrowed player name, and the character ID of the borrowed character used. This is transmitted to notify the end of character borrowing (step C23).

  Further, if the used character is a new character (step C21: NO), it is determined according to the player's operation input whether this new character is to be sent to another player. If other players are allowed to stay (step C25: YES), other players who are both playing multiplayer and have the game card 50 are displayed as a list of destination candidates, and according to the player's operation input, A destination player is selected (step C27).

  Next, an inquiry about whether or not to allow residence is transmitted to the game device 30 of the selected player (step C29). If residence is permitted from the game device 30 (step C31: YES), the game data is sent to the server system 10. This is transmitted together with the player name and the player name of the destination, and requests the new character to stay at the destination player (step C33).

  On the other hand, if the residence is not permitted (step C31: NO), the presence / absence of another player capable of residence is determined. If there is another player capable of residence (step C35: YES), the process returns to step C27 and the residence is made. The previous player is reselected (step C27). If the above process is performed, the game calculating part 331 will complete | finish a game process.

  FIG. 22 is a flowchart for explaining the flow of the single play process. According to FIG. 22, the game calculation unit 331 first determines the presence or absence of the game card 50, and if there is a game card 50 (step D <b> 1: YES), the game calculation unit 331 sends the server system 10 with the card ID of the own game card 50. A list of own characters is requested, and a list of own characters transmitted from the server system 10 in response to this is received (step D3).

  Next, a self-character selection screen based on the received self-character list is displayed, and one self-character to be used is selected according to the operation input of the player (step D5). Subsequently, the server system 10 is requested for the character data of the selected own character, and the character data of the own character transmitted from the server system 10 in response thereto is received (step D7).

  If there is no game card 50 (step D1: NO), the game calculation unit 331 uses a new character, and selects one character to be used from among new characters prepared in advance according to the operation input of the player. Selection / determination (step D9).

  Thus, when the character to be used is determined, the game calculation unit 331 starts game play (single play) using the determined character (step D11).

  When the game play (single play) ends, the game calculation unit 331 determines whether or not the game card 50 is present, and if there is a game card 50 (step D13: YES), the server system 10 plays the game play performed. The data is transmitted together with the card ID of the game card 50 and the character ID of the used own character, and an update of the data of the own character is requested (step D15).

  On the other hand, if there is no game card 50 (step D13: NO), it is determined whether or not to newly purchase the game card 50 according to the operation input of the player. If the game card 50 is newly purchased (step D17: YES), card purchase / registration processing is performed (step D19). Next, the play data is transmitted to the server system 10 together with the card ID of the own game card 50, and a new registration of the new character in the own game card 50 is requested (step D21). If the above process is performed, the game calculating part 331 will complete | finish a single play process.

  23 and 24 are flowcharts for explaining data management processing in the server system 10. As shown in FIG. 23, the processing unit 120 performs processing in response to a request from the game apparatus 30.

  That is, if a card authentication request is made from the game apparatus 30 (step E: YES), card authentication processing is performed in response to the request, and the authentication result is transmitted to the game apparatus 30 (step E3). That is, referring to the card data 220, the game card 50 requested to be authenticated is identified based on the card ID, player name, and password transmitted together with the request, and registered in the corresponding game card 50. Whether or not the game card 50 is registered is authenticated based on whether or not the player name and password match.

  If the game device 30 requests the player character list (step E5: YES), the card data 220 is referred to and registered in the game card 50 corresponding to the card ID transmitted together with the request. A list of own characters is created and transmitted to the game apparatus 30 (step E7).

  Thereafter, if data of the player character is requested from the game device 30 (step E9: YES), the card data 220 is referred to, and based on the card ID and the player character ID transmitted together with the request, The data of the corresponding own character registered in the corresponding game card 50 is transmitted to the game apparatus 30 (step E11).

  Also, if a residence authentication request is made from the game device 30 (step E13: YES), a residence authentication process for authenticating whether the player of the game device 30 is the residence player of the player who has requested as the residence destination is performed. (Step E15). That is, referring to the card data 220, whether or not the transmitted player name and password are identical to the residence player name and password registered in the game card 50 owned by the residence destination player. Then, it is determined whether or not the player is a regular resident player. Next, a staying character is specified (step E17), and character data corresponding to the specified staying character is transmitted to the game apparatus 30 (step E23).

  If borrowed character data is requested from the game device 30 (step E21: YES), the card data 220 is referred to, and the borrowed player name and borrowed character ID transmitted together with the request are referred to. Originally, the player character to be borrowed from the borrower player is specified, and the data of the player character is transmitted to the game apparatus 30 (step E23).

  Also, as shown in FIG. 24, if the game device 30 requests the update of the player character along with the play data (step E25: YES), the card data 220 is referred to and transmitted along with the request. Based on the card ID and the character ID, the used game card 50 and the own character are specified, and the data of the specified own character (own character data 234) is updated in the card data 220 of the specified game card 50. At the same time, the data such as the play history of the owned player and the owned virtual money are updated (step E27).

  If the game device 30 requests to update the staying character together with the play data (step E29: YES), the card data 220 is referred to, and the name of the destination player sent along with the request, and the staying character are sent. Based on the character ID, the game card 50 of the player at the residence destination and the used residence character are identified, and in the card data 220 of the identified game card 50, data of the identified residence character (residence character data 244) And the data such as the virtual money held by the owned player are updated (step E31).

  If the game device 30 notifies the end of borrowing of the character together with the play data (step E33: YES), the card device 220 is referred to, and the borrowed player name transmitted along with the request, and Based on the borrowed character ID, the borrowed player's game card 50 and the borrowed character used are identified, and in the card data 220 of the identified game card 50, the rental history and owned virtual money of the owned player character are identified. And the data of the specified borrowed character (own character data 234) are updated (step E35).

  If a new character registration is requested from the game device 30 together with the play data (step E37: YES), the card data 220 is referred to and the character ID is transmitted based on the card ID transmitted with the request. The game card 50 to be newly registered is specified, and the own character data (own character data 234) based on the received play data is added to the card data 220 of the specified game card 50 (step E39).

  Further, if the game device 30 requests a stop to another player together with the play data (step E41: YES), the card data 220 is referred to, and the name of the stop destination player transmitted along with the request is displayed. Originally, the game card 50 of the player as the residence destination is specified, and in the card data 220 of the specified game card 50, data of the residence character (residence character data 244) based on the received play data is added (step E43).

  If a new registration of the game card 50 is requested from the game device 30 (step E45), the processing unit 120 is requested based on the card ID, player name, and password transmitted together with the request. By generating card data 220 corresponding to the game card 50, the game card 50 is newly registered (step E47).

  If the game device 30 requests the character to move (step E49: YES), the processing unit 120 performs a character moving process for moving the character between the game cards 50 (step E51). That is, based on the own player name, the name of the player who has stayed, and the card ID transmitted with the request, the game card 50 that is the character's movement source and destination, and the character to be moved (the game card that is the movement source) 50 is registered). Next, in the card data 220 of the destination game card 50, the data of the moving character of the source game card 50 (the resident character data 244) is added as the own character data 234, and the card data of the source game card 50 is added. In 220, the data of the moving character (the resident character data 244) is deleted. If the above process is performed, the process part 120 will return to step E1, and will repeat the same process.

[Action / Effect]
As described above, in the game system 1 of the present embodiment, the game card 50 includes the game data of the owned player of the game card 50 (owned player data 230) and the game data of the staying player who uses the owned player as the stoppage destination. (Residence player data 240) is stored in association with each other. That is, the player can leave the game data by multiplayer to another player and use it in the next game play or use the character of another player. Thus, when performing multiplayer, the game card 50 owned by another player is “used” and the game is played using his / her character as if he / she owns the game card 50. Can enjoy.

[Modification]
It should be noted that embodiments to which the present invention can be applied are not limited to the above-described embodiments, and can be appropriately changed without departing from the spirit of the present invention.

(A) Restriction of the staying player data 240 For example, some restriction may be provided for the use of the staying character. Specifically, for example, an expiration date may be provided for the residence player data 240. That is, when a game play using the resident character data 244 has not been made for a predetermined period (for example, 30 days) from the last day (last play date) on which the multiplayer was performed using the resident character data 244 The server system 10 sets the corresponding residence player data 240 as “invalid” and deletes the registration from the game card 50 of the residence destination. The last play date using the staying character data 244 can be determined by referring to the play history 245 of the corresponding staying player data 240.

  Moreover, you may decide to provide a frequency | count limitation in the game play using a residence character. That is, the server system 10 stores the number of multiplayers using the staying character data 244 in association with each staying character data 244, and the number of times of multiplay using the staying character data 244 is a predetermined number (for example, , 20 times), the corresponding residence player data 240 is made “invalid” and the registration is deleted from the game card 50 of the residence destination.

  Moreover, you may decide to provide a restriction | limiting in the level of a resident character, or a possession item. That is, while the staying character data 244 is updated by multi-play using the staying character data 244, at this time, an upper limit is set on the level that the staying character can reach, and some items acquired in the game play include In the case of a character, it can be stored as a possessed item, but in the case of a resident character, there is an item possession restriction such that there are items that cannot be retained.

(B) Movement of the staying character between the game cards 50 Further, the movement of the staying character between the game cards 50 is performed in this store terminal by separately installing a store terminal connected to the server system 10 via the communication line N in the store. Alternatively, it may be performed by accessing the server system 10 using a mobile terminal such as a mobile phone owned by the player.

(C) Type of game In the above-described embodiment, the case where a car racing game is executed has been described as an example. However, in a network game system, a game that performs multiplayer in which a game is played against or in cooperation with other players Any of them can be applied.

DESCRIPTION OF SYMBOLS 1 Game system 10 Server system 110 Input part, 120 processing part, 130 Display part, 140 Communication part 200 Storage part 210 Data management program, 220 Card data 30 Game device 310 Operation input part, 320 Card reading part 330 Processing part 331 Game calculation Unit, 332 image generation unit, 333 audio generation unit 340 image display unit, 350 audio output unit, 360 communication unit 400 storage unit 410 game program 420 new character data, 430 matching data 50 game card N communication line

Claims (8)

Read a server system to be stored in the storage unit to the game data of the owner player is the owner of the authentication medium storing the authentication ID in association with the authentication ID, and the authentication ID from the authentication medium at the time of login process A game system including a reading device and connected to a plurality of game devices capable of executing a multiplayer game by a single unit or a plurality of units, in a communicable manner,
The game device includes:
Residence registration accepting means for accepting a setting registration operation by the non-owner player with the first owner player as the residence destination, and accepting a residence registration process for registering the character of the non-owner player as the residence character of the first owner player When,
Sending character data transmitting means for sending game data of the multiplayer game of the character of the non-owner player to the server system as data of the staying character of the first owner player;
With
The server system is
According Accepts by the alien registration receiving means, as the game data stranger character game data transmitted by the alien character data sending means, stranger character to be stored in the storage unit the authentication ID and the association with the first owner player Registration means,
With
Game system. The residence registration accepting unit permits execution of the residence registration process when a predetermined approval process is performed by the first owner player.
The game system according to claim 1. The game device includes:
Simultaneous login detection means for detecting that the first owner player is logged in simultaneously with the non-owner player in the multiplayer game ;
A residence registration inquiry means for inquiring of the server system whether or not the character of the non-owner player is registered as the residence character of the first owner player detected by the simultaneous login detection means,
When an answer indicating that the registration is made in response to the inquiry of the residence registration inquiry means is obtained, game data of the corresponding residence character is obtained from the server system, and the character of the non-owner player is assigned to the game data. A residence data play execution control means for participating in the multiplayer game as a residence character based on
The game system according to claim 1, further comprising: The server system is
According to the elapsed time from the number of plays and / or final play as alien character executed by the alien data play execution control means, comprising a stranger character data deletion means for deleting the game data of the stranger character from the storage unit The
The game system according to claim 3. The server system is
Data movement request receiving means for receiving a movement request signal of the game data of the staying character with the first owner player as the movement source and the second owner player as the movement destination;
Wherein according to the received content by the data movement request receiving means, the game data of the alien character which has been stored in the storage unit in association with the authentication ID of the first player, the memory as the game data of the second owner player Data moving means for storing and updating in the unit;
With
The game system as described in any one of Claims 1-4. The server system is
For each owner player, a plurality of characters owned by the owner player having a growth element such as a level or a rank are included in the game data and stored in the storage unit,
The game device includes:
During the login process, a selection operation for selecting another owner player who is not the logged-in person (hereinafter referred to as “ own player ” in this claim) and a borrowed character to be borrowed from among a plurality of characters owned by the other owner player Borrowing processing means for accepting,
When another owner player selected by the borrowing processing unit is logged in at the same time, the data of the borrowed character selected by the borrowing processing unit is acquired from the server system, and the growth owned by the other owner player is acquired. Character borrowing play execution control means for participating in the multiplayer game as a borrowed character having an element as an operation character of the player,
With
The game system as described in any one of Claims 1-5. The server system is
For each owner player, the virtual money acquired during the game is stored in the storage unit,
Virtual money acquisition destination control in which the virtual money acquired by the borrowed character participating in the multiplayer game by the character borrowing play execution control means is updated and stored in the storage unit as virtual money acquired by the owner player of the borrower of the borrowed character With means,
The game system according to claim 6 . Is communicably connected to the server system to be stored in the storage unit to the game data of the owner player is the owner of the authentication medium storing the authentication ID in association with the authentication ID, from the authentication medium at the time of login process A game device comprising a reading device for reading the authentication ID and executing a multiplayer game by a single unit or a plurality of units,
Residence registration accepting means for accepting a setting registration operation by the non-owner player with the first owner player as the residence destination, and accepting a residence registration process for registering the character of the non-owner player as the residence character of the first owner player When,
Sending character data transmitting means for sending game data of the multiplayer game of the character of the non-owner player to the server system as data of the staying character of the first owner player;
With
The server system stores the game data transmitted by the residence character data transmission means in association with the authentication ID of the first owner player as game data of the residence character according to the contents received by the residence registration acceptance means. Will be stored in the department,
Game device.

Images