JP2015091328A - Game system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a game system capable of suppressing a real money trade in terms of technology.SOLUTION: The game system includes: a transaction rate information generation unit 56 for generating transaction rate information that includes the quantity of transactions of a first game medium and the quantity of transactions of a second game medium but does not include player identification information capable of identifying each of a plurality of players, on the other hand; a transaction rate information presentation unit 57 that presents the transaction rate information in a game played by a third player; a transaction condition update request acceptance unit 58 that accepts a first transaction condition update request including the quantity of transactions of the first game medium set by the third player; and a transaction condition update unit 59 for updating first transaction condition information so as to include the quantity of transactions included in the first transaction condition update request and player identification information of the third player in the case where the first transaction condition update request is accepted before a transaction ending time and the quantity of transactions included in the transaction information update request is greater than the quantity of transactions included in the first transaction condition information.

Description

  The present invention relates to a game system.

  A so-called online game in which game data is provided from a game system installed in a server device to a plurality of terminal devices via a communication line, and the game is simultaneously progressed using the provided game data in the plurality of terminal devices is widely used. doing.

  In an online game, a function for exchanging items such as cards and weapons used in the game between players may be implemented in order to encourage exchange between players. For example, Japanese Unexamined Patent Application Publication No. 2009-187143 (Patent Document 1) discloses a method for exchanging items used in an online game between players.

JP 2009-187143 A

  As described in Patent Document 1, some players perform an action called real money trade in which cards and items are bought and sold in real currency. If the real money trade is released, only some players can play the game under extremely advantageous conditions, which may impair the game balance. Accordingly, online game providers are striving to suppress real money trade by prohibiting real money trade according to user rules and stopping the use of games by players who violate user rules.

  However, even if the usage rules are strictly used, there is a limit to the effect of suppressing real money trade. Accordingly, various embodiments of the present invention provide a game system capable of suppressing real money trade from a technical aspect.

  In the game system according to an embodiment of the present invention, the possessed quantity of each player of the first game medium and the second game medium held by each of the plurality of players of the game is associated with player identification information unique to each player. A stored quantity storage unit that stores the first game condition information including a transaction quantity of the first game medium set by a first player included in the plurality of players and player identification information of the first player; Transaction condition information storage for storing the transaction quantity of the second game medium set by the second player included in the plurality of players and the second transaction condition information including the player identification information of the second player in association with each other. And the transaction quantity of the first game medium and the transaction quantity of the second game medium stored in the transaction condition information storage unit, A transaction rate information generating unit that generates transaction rate information that does not include player specifying information that can specify each layer, and a transaction rate that presents the transaction rate information in a game played by a third player included in the plurality of players An information presentation unit; a transaction condition update request reception unit that receives a first transaction condition update request including a transaction quantity of the first game medium set by the third player from the third player; and the first transaction condition If the update request is received before the transaction end time and the transaction quantity included in the transaction information update request is greater than the transaction quantity included in the first transaction condition information, the first transaction condition update request A transaction condition update unit for updating the first transaction condition information so as to include a transaction quantity included in the first player and player identification information of the third player, and a transaction end Based on the first transaction condition information and the second transaction condition information stored in the transaction condition information storage unit at the same time, the first game medium and the second game content stored in the possessed quantity storage unit A possession quantity updating unit for updating the possession quantity of the game media.

  A game program according to an embodiment of the present invention includes a computer including a first game medium transaction quantity set by a first player included in the plurality of players and player identification information of the first player. The transaction condition information is stored in association with the second transaction condition information including the transaction quantity of the second game medium set by the second player included in the plurality of players and the player identification information of the second player. A player that can specify each of the plurality of players while including a transaction quantity of the first game medium and a transaction quantity of the second game medium stored in the transaction condition information storage means Transaction rate information generating means for generating transaction rate information not including specific information, a game played by a third player included in the plurality of players The transaction rate information presenting means for presenting the transaction rate information in the above, a transaction condition update request for receiving a first transaction condition update request including a transaction quantity of the first game medium set by the third player from the third player When accepting means, when the first transaction condition update request is received before the transaction end time, and the transaction quantity included in the transaction information update request is larger than the transaction quantity included in the first transaction condition information , Transaction condition update means for updating the first transaction condition information so as to include the transaction quantity included in the first transaction condition update request and player identification information of the third player, and the transaction condition information at a transaction end time Based on the first transaction condition information and the second transaction condition information stored in the storage means, the first game condition stored in the possessed quantity storage means. Functioning means for updating the possession quantity of the game medium and the second game medium.

  Various embodiments of the present invention can provide a game system capable of suppressing real money trade from a technical aspect.

1 is a block diagram schematically showing the architecture of a game system according to an embodiment of the present invention. The block diagram which shows notionally the architecture of the terminal device with which the game system which concerns on one Embodiment of this invention was equipped The block diagram which shows the function of the server apparatus with which the game system which concerns on one Embodiment of this invention was equipped. Example of player specific information table Example of possession quantity management table provided in the game system according to one embodiment of the present invention An example of a transaction condition information management table provided in a game system according to an embodiment of the present invention Example of transaction condition information management table after update Example of owned quantity management table after update The flowchart which shows an example of the process which replaces | exchanges game media using the game system which concerns on one Embodiment of this invention. Item display example in game system according to one embodiment of the present invention Display example of transaction condition setting screen for setting item transaction condition information in game system according to one embodiment of the present invention Display example of transaction rate screen showing transaction rate information in game system according to one embodiment of the present invention Display example of transaction rate setting screen for setting item transaction rate in game system according to one embodiment of the present invention Display example of transaction rate screen showing transaction rate information in a game system according to another embodiment of the present invention Display example of transaction rate setting screen for setting item transaction rate in game system according to another embodiment of the present invention An example of a group management table provided in a game system according to an embodiment of the present invention An example of a group classification table provided in the game system according to an embodiment of the present invention An example of a player management table provided in a game system according to an embodiment of the present invention

  Hereinafter, various embodiments of the present invention will be described with reference to the drawings as appropriate. In addition, the same referential mark is attached | subjected to the same component in drawing.

  FIG. 1 is a block diagram schematically showing the architecture of a game system in one embodiment of the present invention. As shown in FIG. 1, in one embodiment of the present invention, an online game server device 10 (hereinafter, simply referred to as “server device 10”) has a communication function via a communication network 20 such as the Internet. Are connected to be communicable with a plurality of terminal devices 30-1, 30-2,..., 30-N (hereinafter sometimes collectively referred to as “terminal device 30”). The server device 10 is an example of a device that implements part or all of the game system according to an embodiment of the present invention.

  The server device 10 includes a CPU 11, a main memory 12, a user I / F 13, a communication I / F 14, an external memory 15, and a disk drive 16, as shown in the figure. Are electrically connected to each other. The CPU 11 loads various programs for controlling the progress of the operating system and the online game from the external memory 15 to the main memory 12, and executes instructions included in the loaded programs. The main memory 12 is used for storing a program executed by the CPU 11, and is constituted by a DRAM, for example.

The user I / F 13 includes, for example, an information input device such as a keyboard and a mouse that accepts operator input, and an information output device such as a liquid crystal display that outputs the calculation results of the CPU 11.
The communication I / F 14 is implemented as hardware, firmware, communication software such as a TCP / IP driver or PPP driver, or a combination thereof, and is configured to be able to communicate with the terminal device 30 via the communication network 20.

  The external memory 15 is composed of, for example, a magnetic disk drive, and stores various programs such as a game program for executing an online game in the terminal device 30 and a control program for controlling the progress of the online game. The game program is created using, for example, Adobe Flash (registered trademark), which is a format for handling moving images and games developed by Adobe Systems. A game program created by Adobe Flash is stored in the external memory 15 as a SWF format file. The game program will be described later. The disk drive 16 reads data stored in various storage media such as CD-ROM, DVD-ROM, and DVD-R, or writes data to these storage media. For example, data such as game programs stored in the storage medium is read by the disk drive 16 and installed in the external memory 15.

  The terminal device 30 is an arbitrary information processing device that is stored in the server device 10 and executes a game displayed on a web browser and can be operated. For example, a mobile phone, a smartphone, a game console, a personal computer, a touch Includes but is not limited to pads and e-book readers. The terminal device 30 can also receive a game program from the server device 10 via a communication I / F 34 described later and execute the game.

  The architecture of such various terminal devices 30 will be described with reference to FIG. FIG. 2 is a block diagram conceptually showing the architecture of the terminal device 30 according to an embodiment of the present invention. The terminal device 30 includes a CPU 31, a main memory 32, a user I / F 33, a communication I / F 34, and an external memory 35, as shown in the figure, and these components are electrically connected to each other via a bus 36. Connected.

  The CPU 31 loads various programs such as an operating system from the external memory 35 into the main memory 32, and executes instructions included in the loaded program. The main memory 32 is used for storing a program executed by the CPU 31, and is constituted by a DRAM, for example.

  The user I / F 33 includes, for example, an information input device such as a touch panel that accepts an input from a player (user), a keyboard, a button, and a mouse, and an information output device such as a liquid crystal display that outputs a calculation result of the CPU 31. The communication I / F 34 is implemented as hardware, firmware, communication software such as a TCP / IP driver or PPP driver, or a combination thereof, and is configured to be able to communicate with the server device 10 via the communication network 20.

  The external memory 35 is composed of, for example, a magnetic disk drive or a flash memory, and stores various programs such as an operating system. Further, when a game program is received from the server device 10 via the communication I / F 34, the external memory 35 stores the received game program.

  The terminal device 30 having such an architecture is provided by, for example, browser software for interpreting an HTML file and displaying the screen, and plug-in software (for example, provided by Adobe Systems Inc.) incorporated in the browser software. Flash Player) is acquired, the SWF format file embedded in the HTML file is acquired from the server device 10, and the SWF format file is executed using browser software and plug-in software. A game function can be provided to a user, that is, a game player.

  Next, the game program will be described with reference to FIG. 1 and FIG. The game program is stored in the external memory 15 of the server device 10 in various formats. For example, the game program can be provided as application software executed on various application execution platforms. The player can execute or operate the game application through the terminal device 30.

  The external memory 15 of the server device 10 stores game programs for executing or operating various games that can be executed or operated on the terminal device 30. This game program can be created in a script language such as ActionScript or JavaScript (registered trademark) or an object-oriented programming language such as Objective-C or Java (registered trademark). These game programs are executed and / or operated on a platform mounted on the terminal device 30. Further, the game program stored in the external memory 15 may be a web page created in a markup language such as HTML5 modified with a style sheet such as CSS3. A web page created in such a markup language is executed or operated by browser software installed in the terminal device 30. Further, the server device 10 can store an arbitrary number of game programs in the external memory 15, and a game program for executing and / or operating a game selected by the terminal device 30 is controlled according to the control of the CPU 11. , It can be provided to any number of terminal devices 30 via the communication I / F 14. In the terminal device 30, the game program transmitted by the server device 10 is transmitted and stored in the external memory 35 via the communication I / F 34 according to the control of the CPU 31.

  The terminal device 30 can play various games such as an action game, a role playing game, a baseball game, and a card game by executing or operating this game. The game realized by the game program is not limited to the one specified in this specification. When the game is executed, for example, an animation instructed by the program and an operation icon are displayed on the screen of the terminal device 30. The player can input an instruction to advance the game using an input interface (for example, a touch screen or a button) of the terminal device 30. The instruction input from the player is transmitted to the server device 10 through a browser function of the terminal device 30 or a platform function such as NgCore (trademark). The terminal device 30 appropriately stores information indicating various parameters used in the game (such as information regarding the number of acquired game points and items acquired) and information indicating the status (such as information for identifying the mission completed) to the server device 10 as appropriate. Send. The server device 10 manages the progress of the game for each player based on instructions received from the plurality of terminal devices 30, information indicating parameters, information indicating status, and the like. As a result, the player can resume the interrupted game from the state immediately before the interruption based on the information on the progress of the game held by the server device 10.

  Next, functions of the server device 10 realized by the components shown in FIG. 1 will be described with reference to FIG. FIG. 3 is a block diagram illustrating functions of the server device 10 according to an embodiment of the present invention. As shown in FIG. 3, the server device 10 according to the present embodiment includes a game program storage unit 51, a player specifying information storage unit 52, a possessed quantity storage unit 53, a transaction condition information receiving unit 54, and transaction condition information. Storage unit 55, transaction rate information generation unit 56, transaction rate information presentation unit 57, transaction condition update request reception unit 58, transaction condition update unit 59, owned quantity update unit 60, and transaction end time update unit 61 A group management unit 62, a group update unit 63, and a player management unit 64.

  The game program storage unit 51 stores game programs for executing or operating various games that can be executed or operated on the terminal device 30 as described above. A user of the terminal device 30 can play a game using the terminal device 30 by acquiring the game program stored in the game program 51 and causing the terminal device 30 to execute the acquired game program. As described above, in the terminal device 30, various games are executed. In the game executed on the terminal device 30, various game media such as an electronic card, an item, and a virtual currency usable in the game are used.

  The game medium is a general term for electronic data used by the player for the progress of the game, and includes, for example, a card, an item, an avatar, and a virtual currency. In one aspect of the present invention, the game medium can be acquired, held, used, managed, exchanged, combined, enhanced, sold, discarded, and / or gifted, etc., by the player in the game as the game progresses. The usage mode of the game media is not limited to those specified in this specification. When selling a card in a game, not a real currency but a virtual currency used in the game is paid to the player as a consideration for selling the card. For example, parameters (for example, “attribute”, “level”, “attack power”, “defense power”, etc.) necessary for the progress of the game are set in the card as the game medium. These parameters can be updated as the game progresses. The player can advance the game using a card having the updated parameters.

  A player of a game stored in the game program storage unit 51 can acquire and hold various game media such as items as the game progresses. Items used in the game include, for example, weapon items that increase the attack power of characters operated by the player, armor items that increase defense power, vehicle items that increase mobility, and “life” and “hit points” Recovery items that recover parameters called are included, but the items of the present invention are not limited to those explicitly disclosed herein.

  The player specifying information storage unit 52 stores, for example, player specifying information that can specify each player of the game. “Player specifying information” is arbitrary information representing the individuality and characteristics of the player, and is information that allows the player to be specified by presentation to other players. In a game, a display image representing each player is generated based on the player specifying information, and the display image is displayed on the game screen of another player, so that the individuality and characteristics of the player are different from those of other players. Communicated. Since the individuality of each player appears in the display image representing the player, the exchange between the players throughout the game is promoted.

  This player specifying information may include, for example, player attribute information such as a player name and avatar set by the player to characterize the player. Since the player name is freely determined by each player, a plurality of players may use the same player name. Therefore, the player name does not uniquely identify the player, but since the number of players interacting in the game is limited by time constraints and the like, the player name actually identifies other players. Serves as a sign of Therefore, in this specification, the player name is included in the player specifying information that can specify the player. The avatar is also included in the player specifying information for the same reason. In other words, in order to express individuality, game players often play games using avatars with a unique appearance, and in order to support the needs of such players, As a platform function, various items for decorating avatar are provided. Therefore, the avatar cannot necessarily uniquely identify the player, but can actually function to identify the player.

  The player specifying information storage unit 52 can generate and manage a player specifying information table illustrated in FIG. The player identification information table in FIG. 4 manages various player identification information such as player names and avatars in association with player identification information of each player. For example, the avatar is stored as an image in the JPEG format in the server device 10, and the storage position of the image can be managed as a URL in the player specifying information table. In addition to player attribute information arbitrarily set by the player, such as a user name and an avatar, various information generated according to the progress of the game can be included in the player specifying information. For example, since the player can be identified by knowing player identification information described later, the player identification information itself can be included in the player identification information.

  The possessed quantity storage unit 53 stores, for each type of game medium, the possessed quantity of the game medium held by each player in association with the player identification information of the player who owns the game medium. FIG. 5 shows an example of the possessed quantity management table provided in the game system according to the embodiment of the present invention. In FIG. 5, the possessed quantities of item A, item B, item C,... Held by each player are stored in association with the player identification information of each player. FIG. 5 is merely an example, and the possessed quantity management table can store the possessed quantities of various game media such as cards and virtual currencies in addition to the items. When the player acquires or consumes a new item as the game progresses, the possessed quantity of the item in the owned quantity management table is updated to reflect the action in the game.

  “Player identification information” is an identification code for identifying a player of the game, and is composed of, for example, a 6-digit decimal number. The code system of the player identification information is not limited to that specified in this specification, and an arbitrary code system can be used as the player identification information. For example, the player identification information can include alphabets. For example, the player identification information is usually assigned to a player when the player logs in to the game for the first time, and the same player identification information is normally used at the time of re-login. Thus, the player identification information is identification information unique to each player for identifying each player in the game.

  In the example of FIG. 5, the player identified by the player identification number “000001” (hereinafter sometimes referred to as “player 1”) owns 74 items A and 18 items C. Yes. Since the player 1 does not own the item B, “0” is set in the item indicating the quantity of the item B held. The player identified by the player identification number “000002” (hereinafter sometimes referred to as “player 2”) owns 12 items A, 2 items B, and 14 items C. ing. The player identified by the player identification number “000003” (hereinafter sometimes referred to as “player 3”) has 89 items A and 13 items C, respectively. The configuration of the owned quantity management table shown in FIG. 5 is only an example, and various modifications are possible. Further, the game medium identification information storage unit 52 does not necessarily need to store the possession quantity management table, and the player can identify the possession quantity of the game medium possessed by each player by any method apparent to those skilled in the art. It can be stored in association with information. Similarly, the players other than the player 1 to the player 3 also have various game media, and the game media possessed by each player is stored in association with the player identification information of the player. In this specification, the player identified by the player identification number “000004” in FIG. 5 may be referred to as player 4, and the player identified by the player identification number “000005” may be referred to as player 5.

  Since game media such as items are acquired by the player as the game progresses, the owned quantity management table is also updated as the game progresses to reflect changes in the player's owned quantity. For example, when the player acquires three items A, “3” is added to the quantity of items A held by the player, and when one item B is consumed, the quantity of items B held by the player "1" is subtracted from

  When the game player performs a transaction for exchanging game media with another player, the transaction condition information receiving unit 54 receives transaction condition information for determining the transaction condition from the player. The transaction condition information transmitted from one player includes, for example, the type and quantity of game media to be given to another player by exchange, player identification information of the one player, and receiving from another player by exchange. The type and quantity of game media desired can be included. When exchanging items as game media, the types of items to be exchanged include, for example, rifles, shotguns, knives, bulletproof vests, coats, helmets, bikes, jeep, airplanes, helicopters, recovery drinks, traps, etc. However, the types of items that can be exchanged in the present invention are not limited to these.

  The transaction condition information storage unit 55 can store one or more transaction condition information received by the transaction condition information reception unit 54 in the transaction condition information management table. FIG. 6 is an example of a transaction condition information management table provided in the game system according to one embodiment of the present invention. For example, when the transaction condition information receiving unit 54 receives transaction condition information from one player, the transaction condition information storage unit 55 generates a record for storing the transaction condition information in the transaction condition information management table. Each record is given a “transaction ID” for identifying a transaction based on each transaction condition information, and this “transaction ID” is associated with various information included in the transaction condition information to manage the transaction condition information. Stored in a table. In this specification, in the transaction condition information management table, data stored in association with a specific transaction ID may be referred to as “transaction data” associated with the transaction ID.

  As illustrated, the transaction condition information management table may include items of “type of game medium 1”, “transaction quantity of game medium 1”, and “player identification information 1”. In this specification, for convenience of explanation, a part or all of “type of game medium 1”, “transaction quantity of game medium 1”, and “player identification information 1” are collectively referred to as “first transaction condition information”. There are things to do. The “type of game medium 1” indicates the type of game medium that one player gives to another player. “Transaction quantity of game medium 1” indicates the quantity of game medium specified by “type of game medium 1” given by one player to other players. “Player identification information 1” indicates player identification information of the one player. “Type of game medium 1”, “transaction quantity of game medium 1”, and “player identification information 1” are included in the transaction condition information received from one player. Alternatively, in another embodiment, “type of game medium 1”, “transaction quantity of game medium 1”, and “player identification information 1” are generated in the server device 10 based on the transaction condition information. As described above, the “first transaction condition information” is information for setting a game medium transaction condition given by one player to another player.

  The transaction condition information management table may include items of “type of game medium 2”, “transaction quantity of game medium 2”, and “player identification information 2”. In this specification, for convenience of explanation, part or all of “type of game medium 2”, “transaction quantity of game medium 2”, and “player identification information 2” are collectively referred to as “second transaction condition information”. There are things to do. “Type of game medium 2” indicates the type of game medium exchanged with the game medium specified in “Type of game medium 1”. “Transaction quantity of game media 1” is the quantity of game media specified by “game media type 2” given to the above one player in exchange for the game media specified by “game media type 1” Indicates. “Player identification information 2” indicates player identification information of the other player that gives a game medium specified by “game medium type 2” to one player. As described above, the “second transaction condition information” sets game medium transaction conditions given to one player from another player in order to exchange with the game medium specified by the “first transaction condition information”. Information. The “transaction data” of a specific transaction ID includes “first transaction condition information” indicating the transaction condition of one game medium, and “second transaction condition information” indicating the transaction condition of the game medium exchanged with the game medium. ”Is included, the transaction rate of these game media is determined by“ transaction data ”.

  As will be described later, “type of game medium 1”, “transaction quantity of game medium 1”, “player identification information 1”, “type of game medium 2”, “transaction quantity of game medium 2”, and “player identification” Each item of “information 2” can be updated at any time based on transaction condition information or a transaction condition update request received by the server device 10 from the game player.

  In the transaction condition information management table, “transaction end time” is set for each transaction ID. “Transaction end time” indicates a time at which the exchange between items specified by each transaction ID ends. For example, the time when the transaction ID is generated can be used as a reference, and the time one hour later can be set as the “transaction end time”. As an example, when a transaction ID is generated at 7:51 am on April 9th, 8:51 am on April 9th, one hour later, can be set as the “transaction end time”. As will be described later, the transaction rate between items is determined based on the transaction record stored in the transaction condition information management table at the transaction end time. As will be described later, the transaction end time can be updated when other data stored in the transaction condition information management table is updated.

  The transaction end time can be included in transaction rate information described later and provided to a game played by the player. When the transaction end time is included in the transaction rate information, the transaction end time is displayed on the display screen of the terminal device 30. When the transaction ID is generated immediately after the transaction condition information is transmitted by the player, the player can substantially freely set the transaction end time by adjusting the transmission timing of the transaction condition information. Therefore, by transmitting this transaction end time to other players by means of mail outside the game, it is possible to specify the player for which the other player has set the transaction condition information (that is, the player who specified the transaction end time). there is a possibility. Therefore, by changing the transaction end time read from the transaction condition information management table by rounding and including the changed transaction end time in the transaction rate information, it is possible to prevent the player from being identified based on the display of the transaction end time. . For example, the transaction ID “A000001” in FIG. 6 has “April 9 8:51” as the transaction end time, so if “April 9 8:51” is displayed as it is, “April 9 By transmitting “9: 8: 51” to other players, it becomes possible to identify the player involved in the transaction corresponding to this transaction ID. The transaction end time is, for example, “April 9, 9:00” By changing to a time with good separation, it is possible to prevent the identification of the exhibitor player based on the exhibition period (see FIG. 12). In another embodiment, it is possible not to notify the player of the transaction end time by making the transaction rate information not include the transaction end time.

  In the example shown in FIG. 6, in association with the transaction ID “A000004”, the item type code “bbbb” indicating item B as “type of game medium 1”, “2” as “transaction quantity of game medium 1”, In addition, “002987” is stored as “player identification information 1”. The transaction record with the transaction ID “A000004” includes, for example, an item type code “bbbb” for specifying item B, information for specifying “2” as the quantity, and player identification from the player with player identification information “002987”. Generated when transaction condition information including information “002987” is received. The first transaction condition information is obtained when the player with the player identification information “002987” provides two items B to another player and desires to receive another item from the other player. It is generated in the device 30 and transmitted to the server device 10. If this transaction condition information does not include information specifying the game media that the player wants to receive from other players, as shown in the record of transaction ID “A000004” in FIG. No information is stored in the items of “type of medium 2”, “transaction quantity of game medium 2”, and “player identification information 2”.

In the example shown in FIG. 6, the item type code “aaaa” is set as “type of game medium 1” and “40” is set as “transaction quantity of game medium 1” in association with the record of transaction ID “A000005”. “038349” is stored as “player identification information 1”, item type code “ffff” is stored as “type of game medium 2”, and “10” is stored as “transaction quantity of game medium 2”. The transaction record with the transaction ID “A000005” indicates that the player with the player identification information “038349” wants to obtain 10 items F in exchange for 40 items A, according to the transaction conditions from the player. Generated when condition information is accepted. In the record of transaction ID “A000005”, no information is stored in “player identification information 2”, but the item F of item F identified by item type code “ffff” is associated with transaction ID “A000005” from another player. When the transaction condition information specifying the quantity is received, the player identification information of the other player is stored in “player identification information 2”.

  Further, the record with the transaction ID “A000001” shown in FIG. 6 shows an example in the case where transaction condition information or a transaction condition update request is received from another player. As shown in the figure, the transaction record with the transaction ID “A000001” includes an item type code “aaaa” as “type of game medium 1”, “50” as “transaction quantity of game medium 1”, and “player identification information 1”. “000001”, “Game media 1 type” as item type code “bbbb”, “Game media 2 transaction quantity” as “1”, and “Player identification information 2” as “000002”. In this record, for example, the player 1 having the player identification information “000001” wishes to exchange 50 items A owned by the player with the item B owned by another player, and the player identification information “000002” It is generated when the identified player presents transaction conditions for providing one item B in response to the exchange request.

  As will be described later, a part of the data stored in the transaction condition information management table is presented to other players through a game play screen or the like. For example, since a part of the information included in the record with the transaction ID “A000001” is provided to the player of the game via the game, the player selects 50 items A and 1 item B. It can be understood that exchange conditions to be exchanged are presented. For example, the player can transmit a transaction condition update request specifying a condition more advantageous than the already presented condition to the server device 10, and the server device 10 performs a transaction based on the transaction condition update request. The condition information management table can be updated. The update of the transaction condition information management table will be described later.

  For example, in response to a search request from a player, the transaction rate information generation unit 56 for each transaction ID stored in the transaction condition information management table, the transaction quantity of the game medium 1 associated with the transaction ID and the game Transaction rate information including the transaction quantity of medium 2 is generated. As will be described later, the generated transaction rate information is displayed on the display screen of the terminal device 30 as a part of the game screen when the terminal device 30 plays a game. The player can know at what transaction rate the game media are exchanged by looking at the transaction rate information displayed on the terminal device.

  In one embodiment, the transaction rate information is generated so as not to include player specific information. The transaction condition information management table in FIG. 6 stores player identification information of a player who wants to trade. In one embodiment, the transaction rate information generation unit 56 uses the player identification information and the player identification information. Transaction rate information is generated so as not to include player identification information (for example, player name and avatar) other than the player identification information identified by referring to the player identification information table or the like from the identification information. As described above, the transaction rate information includes information for specifying the exchange rate of the item to be exchanged, but does not include information for identifying the player who has set the exchange rate. For example, when transaction rate information is generated based on the transaction record with transaction ID “A000001”, the exchange rate for exchanging 50 items A and 1 item B is specified based on the transaction rate information. The player identification information for specifying the player identification information “000001” for which the exchange condition for the item A is set, and the player identification for specifying the player for the player identification information “000002” for the item B. Information is not included in the transaction rate information.

  In one embodiment, the transaction rate information generation unit 56 can change the content of the data read from the transaction condition information management table and include the changed data in the transaction rate information. For example, since the transaction quantity of the game media can be freely input by each player, unnatural information is set as the transaction quantity, and the set information is transmitted to other players by means such as mail outside the game. Thus, there is a possibility that the player who has input the information is specified by other players. For example, by inputting an unnatural transaction quantity such as “131” for a predetermined item and transmitting the number “131” to another player, the other player can obtain the transaction quantity “131”. As an identification mark, there is a possibility that a player who has input the information can be identified from other players. Therefore, in one embodiment of the present invention, the transaction rate information generating unit 56 changes input information freely input by the player by rounding processing, and generates transaction rate information using the information after the change. This prevents information that can be freely input by the player from functioning as a sign. For example, if the transaction quantity is set to “131”, it can be rounded with a rounding width of 50 and changed to “150”, and rounded with a rounding width of 100 and changed to “100”. You can also When rounding processing is performed with a rounding width of “50”, when the transaction rate information is displayed on the terminal device 30, the transaction quantity is displayed as “150” instead of “131”. It can be prevented from functioning as a sign.

  The transaction rate information presentation unit 56 provides the player with the transaction rate information generated by the transaction rate information generation unit 56 based on a request from the player. Each player can transmit a transaction rate information display request to the server device 10 through operation of the terminal device 30 executing the game during the game. The transaction rate information presentation unit 56 can transmit the transaction rate information to the game being executed on the terminal device 30 that has transmitted the display request. The terminal device 30 can display a transaction rate display screen generated based on the transaction rate information, for example, as a part of a game display screen.

  The player can present a transaction condition more advantageous than the transaction rate shown on the transaction rate display screen by transmitting a transaction condition update request from the terminal device 30 to the server device 10. This transaction condition update request is received by the transaction condition update request reception unit 58 of the server device 10. When the transaction condition update request is received by the transaction condition update request reception unit 58 before the transaction end time, the transaction condition update unit 59 is a game medium associated with the transaction ID specified in the transaction condition update request. Is compared with the transaction quantity of the game content included in the transaction condition update request. As a result of the comparison, the transaction condition update unit 59 determines that the transaction quantity included in the transaction information update request is larger than the transaction quantity stored in the transaction condition information management table at the time of receiving the transaction information update request. “Transaction quantity of game medium 1” and “Player identification information 1” in the transaction condition information management table so as to include the transaction quantity included in the transaction condition update request and the player identification information of the player who transmitted the transaction information update request. Update the item.

  For example, in the transaction ID “A000001” in FIG. 6, an exchange rate for exchanging 50 items A and 1 item B is set. The player identified by the player identification information “000003” generates, for example, a transaction condition update request including the transaction ID “A000001”, the item type information “aaaa” identifying the item A, and the transaction quantity “60” of the item A. Then, the transaction condition update request can be transmitted to the server device 10. This transaction condition update request is received by the transaction condition update request receiving unit 58. When the transaction condition update request is received before the transaction end time, the transaction condition update unit 59 stores the transaction quantity of the item A associated with the transaction ID “A000001” included in the transaction condition update request ( In the example of FIG. 6, “50”) is compared with “60” that is the transaction quantity of item A included in the transaction condition update request. In this case, since the transaction quantity of the item A included in the transaction condition update request is larger, the transaction quantity “60” included in the transaction information update request and the player identification information of the player who transmitted the transaction information update request “000003” is stored in the items “transaction quantity of game medium 1” and “player identification information 1” corresponding to the transaction ID “A000001” of the transaction condition information management table.

  As described above, the transaction conditions registered in the transaction condition information management table can be updated based on the transaction condition update request. FIG. 7 shows an example of the updated transaction condition information management table. In the example of FIG. 7, “60” is stored in “Transaction quantity of game medium 1” of transaction ID “A000001” instead of “50” that was originally registered, and “player identification information 1 "000003" is registered in place of "000001" that was originally registered. In this way, the first transaction condition information and / or the second transaction condition information registered in the transaction condition information management table can be updated when a better transaction rate is presented by the transaction condition update request.

The transaction end time update unit 61 can update the transaction end time set for each transaction ID based on the transaction condition update request. For example, the transaction end time update unit 61 is set in the transaction condition information management table for the transaction ID based on the time when the transaction condition update request for the specific transaction ID is received by the transaction condition update request reception unit 58. The transaction end time can be updated. For example, in the example shown in FIG. 6, “April 9 8:51” is set as the transaction end time in association with the transaction ID “A000001”. If a transaction condition update request related to the transaction ID “A000001” is received before this transaction end time, the originally set transaction end time is extended by, for example, one hour, and “April 9 9:51” Is set as the new transaction end time.
In the updated transaction condition information management table shown in FIG. 7, the updated “April 9 9:51” is stored in the “transaction end time” corresponding to the transaction ID “A000001”.

  The transaction rate set for each transaction ID in the transaction condition information management table is determined at the transaction end time associated with the transaction ID. When the transaction end time is updated, the transaction rate is fixed at the updated transaction end time. Specifically, the player specified by the player identification information stored in “player identification information 1” (hereinafter referred to as “player 1” for convenience of description) and the player stored in “player identification information 2”. A game medium stored in the “type of game medium 1” by the player 1 (hereinafter referred to as “player 2” for convenience of explanation) (hereinafter referred to as “second” for convenience of explanation). 1 game medium ”) is given to the player 2 by the quantity stored in the“ transaction quantity of the game medium 1 ”, and instead, the game in which the player 2 is stored in the“ type of game medium 2 ”. A transaction condition is determined in which a medium (hereinafter referred to as “second game medium” for convenience of explanation) is given to the player 1 by the quantity stored in “the transaction quantity of the game medium 2”. That is, a transaction in which the first game medium and the second game medium are exchanged between the player 1 and the player 2 at a transaction rate specified by the transaction quantity of the game medium 1 and the transaction quantity of the game medium 2 is a game. It is established within.

  For example, in the example of FIG. 7, when 9:51 on April 9 which is the transaction end time corresponding to the transaction ID “A000001” arrives, the player 2 of the player identification information “000003” An exchange is established in which 60 items A are given to player 3 and one item B is received in exchange.

  When the transaction end time arrives for the record specified by the specific transaction ID, the owned quantity update unit 60 receives the first transaction condition information and the second transaction condition stored in the transaction condition information management table at the transaction end time. Based on the information, the possession quantities of the first game medium and the second game medium stored in the possession quantity management table are updated. For example, for the transaction record specified by the transaction ID “A000001” shown in FIG. 7, the owned quantity update unit 60 uses the item A (first game) associated with the player identification information of the third player in the owned quantity management table. Subtracting “60”, which is the transaction quantity included in the first transaction condition information, from the “89” which is the possession quantity of the medium), and the player identification of the third player in the possession quantity management table “1” that is the transaction quantity included in the second transaction condition information is added to the possession quantity of the item B (second game medium) associated with the information at the transaction end time. Also, “1” that is the transaction quantity included in the second transaction condition information is subtracted from the possession quantity of the item B associated with the player identification information of the second player in the possession quantity management table at the transaction end time. In addition, “60”, which is the transaction quantity included in the first transaction condition information, is added to the possession quantity of the item A associated with the player identification information of the second player in the possession quantity management table at the transaction end time. .

  FIG. 8 shows the owned quantity management table updated in this way. As shown in FIG. 8, the quantity of item A held by player 2 increases by 60 from “12” before exchange to “72”, while the quantity of item B held by player 2 is increased before exchange. Decrease by 1 from “2” to “1”. On the other hand, the quantity of item A held by player 3 is reduced by 60 from “89” before exchange to “29”, while the quantity of item B held by player 3 is changed from “0” to “1” before exchange. Increased by one. Thus, when the exchange is established between the player 2 and the player 3 in which the player 2 gives one item B and the player 3 gives 60 items A to the player 2 instead, the possessed quantity management is performed. The number of holdings reflecting the exchange is stored in the table.

  Next, with reference to FIG. 9, a process for exchanging game media in the game system configured as described above will be further described. FIG. 9 is a flowchart showing an example of processing for exchanging an item called “recovery drink” and an item called “ground vehicle” in the game using the game system according to one embodiment of the present invention. It is. The “recovery drink” and “ground vehicle” illustrated in the process of FIG. 9 are merely examples of game media. In the present invention, any other game media can be traded according to the processing method shown in FIG. Can be done. FIG. 9 shows an example in which game media are exchanged among player 1, player 2, player 3, and player 4. However, any number of players can play game media according to the processing method shown in FIG. Trading can be done.

  First, in step 902, card medium exchange processing is started. In step 902, the player 1 operates his / her terminal device 30 to acquire a desired game program from the server device 10, and causes the terminal device 30 to execute the game program. Next, in step 904, the player 1 displays the items held in the game on the screen of the terminal device 30 in accordance with the instructions of the game program. For example, on the main screen of the game displayed on the terminal device 30 by executing the game program, links and operation buttons displayed as “item”, “treasure”, “possession” etc. are displayed. By operating such links and operation buttons, some or all of the items held by the player can be displayed.

  FIG. 10 shows a display example of items in the game system according to one embodiment of the present invention. For example, when the player 1 operates an icon including a display “possession” on the game screen, the display screen 100 shown in FIG. 10 is displayed on the display screen of the portable terminal 30 of the player 1. As shown in the possessed quantity management table of FIG. 5, since the player 1 has 74 items A, a display image 101 representing an item “recovered drink” corresponding to the item A is displayed on the player 1. Displayed on the mobile terminal 30 of the mobile phone. The display image 101 includes an item name “recovery drink”, an image indicating the item, a parameter set for the item (recovery power 30 Pt), the number of items held (74), and the transaction conditions of the item A link 102 to the setting screen is included. The display image 101 can include various information other than the information illustrated in FIG.

  When the player 1 selects the link 102, the process proceeds to step 906, and a transaction condition setting screen 110 for setting the item transaction conditions illustrated in FIG. 11 is displayed on the terminal device 30 of the player 1. As shown in the figure, the transaction condition setting screen 110 includes a setting image 111 for setting transaction conditions of “recovery drink” that the player 1 provides to other players. This setting image 111 includes a pull-down box 112 for setting the number (transaction quantity) of “recovered drinks” that player 1 gives to other players, A pull-down box 113 for designating the type of item desired to be received from another player, an input box 114 for setting the quantity of the item, and a decision button 115 for determining the entered transaction conditions Including. Since the pull-down box 112 provides a finite number of options (for example, “10”, “20”, “200” in 10 increments from 10 to 200) representing the quantity of items to be provided to other players, The player 1 selects a value equal to or less than the quantity of the item A owned by the player 1 from the options, for example, “50”. The pull-down box 113 provides a plurality of options representing the item type. For example, the pull-down box 113 provides options such as “shotgun”, “ballistic vest”, “ground vehicle”, “helicopter”, etc., so that the player 1 selects “ground vehicle” from the options. select. The player 1 inputs, for example, “1” in the input box 114 as the number of “ground vehicles”. After completing the input of the transaction conditions in this way, the player 1 selects the decision button 115 and determines the transaction condition information to be notified to the server device 10.

  As described above, the transaction rate input from the input box 114 may be changed by the transaction rate information generation unit 56 in order to prevent its use as a sign. In this case, although not displayed in FIG. 11, a screen for confirming that the transaction quantity is changed is displayed, and only when the operation button included in the display screen is selected by the player, the determination button 115 is displayed. , The player's prior consent can be obtained that the transaction quantity is changed (rounded).

  In one embodiment, the input box 114 presents a finite number of choices (e.g., 10 to 200 choices from “10”, “20”, “200”), similar to the pull-down box 112. May be configured. As described above, the transaction quantity is used as a sign as in the case of rounding the transaction quantity by selecting the transaction quantity from a limited number of preset options without allowing free input to the player. It can be prevented from being used.

  When the OK button 115 is selected, the item type code “aaaa” for specifying the “recovered drink” provided by the player 1, the quantity “50” of the “recovered drink”, and the “ground use” that the player 1 desires to receive Transaction condition information including a game media type code “bbbb” for identifying “vehicle”, a quantity “1” of “ground vehicle”, and player identification information “000001” of player 1 is transmitted to server device 10. . The server device 10 receives the received transaction condition information via the transaction condition information receiving unit 54. Subsequently, in the transaction condition information storage unit 55, “A000001” is generated as a transaction ID for specifying a transaction based on the transaction condition information, and the transaction ID “A000001” and various kinds of information included in the transaction condition information are generated. The information is associated and stored in the transaction condition information management table. Specifically, the item type code “aaaa” for specifying “recovery drink”, the quantity “50” of “recovery drink”, and the player identification information “000001” of player 1 are set as transaction ID “A000001” as the first transaction condition information. Is stored in association with "." In addition, the game media type code “bbbb” specifying the “ground vehicle” that the player 1 wishes to receive and the quantity “1” are associated with the transaction ID “A000001” as part of the second transaction condition information. Remembered. Immediately after the transaction ID “A000001” is generated, no exchange application has been made by another player, so no information is stored in the player identification information 2.

Subsequently, the process proceeds to step 908, where transaction condition information is set by the player 2. When the player 2 is playing the same or the same kind of game as the player 1 on the terminal device 30, the “recovered drink” is selected as the exchange target from the transaction condition information management table using the search function provided by the game. You can get the information of the transaction record. For example, in the transaction rate information generation unit 56, based on a search request from the player, a transaction ID “A000001” for which “recovery drink” is to be exchanged is identified and associated with this transaction ID “A000001”. The transaction rate information including the transaction volume of the “recovered drink” and the transaction volume of the “ground vehicle” is generated. The generated transaction rate information is provided to the game being executed on the terminal device 30 that has transmitted the search request. The transaction rate information may include a transaction ID “A000001”. The terminal device 30 generates a transaction rate information display screen (transaction rate screen) based on the transaction rate information, and displays the generated transaction rate screen on the display screen as a part of the game screen.

  FIG. 12 is a display example of a transaction rate screen 120 showing transaction rate information in the game system according to one embodiment of the present invention. As shown in the figure, on the transaction rate screen 120, an image representing “recovery drink” associated with the transaction ID “A000001”, “50” characters indicating the transaction quantity, and “ground vehicle” are displayed. An exchange target item display image 121 including an image to be displayed and “1” character indicating the transaction quantity is included. The player 2 in contact with the transaction rate screen 120 can understand that a transaction rate for exchanging 50 “recovery drinks” and 1 “ground vehicle” is set. On the other hand, as described above, since the transaction rate information does not include player specifying information that can specify the player, even if the transaction rate screen 120 is viewed, the player who sets the transaction condition information regarding the transaction rate is specified. Can not do it. In the transaction condition information management table shown in FIG. 6, transaction condition information for exchange of “recovered drink” is also stored for transaction ID “A000002” and transaction ID “A000005”. Accordingly, the transaction rate information generated based on the transaction ID “A000002” and the transaction ID “A000005” is also provided to the game executed on the terminal device 30 of the player 2. Player 2 selects transaction button information generated based on transaction ID “A000002” and / or transaction ID “A000005” by selecting operation button 123 displayed as “Next” at the bottom of display screen 120. A transaction rate screen can be displayed on the terminal device 30.

  On the display screen 120, an operation button 122 represented as “replacement application” is displayed below the image representing “recovery drink”. When the operation button 122 is selected by the player 2, the display screen of the terminal device 30 of the player 2 transitions to a transaction rate setting screen 130 for setting the transaction rate shown in FIG. The transaction rate setting screen 130 in FIG. 13 includes an input box 131. The player 2 can input the transaction quantity of the “ground vehicle” provided to the exchange partner in the input box 131 in order to obtain 50 “recovery drinks”. When, for example, “1” is input to the input box 131 by the player 2 and then the enter button 132 is selected, the transaction ID “A000001” and the game media type code “bbbb” for specifying “ground vehicle” are entered. , Transaction condition information including the quantity “1” of the “ground vehicle” and the player identification information “000002” of the player 2 is transmitted to the server device 10.

  The transaction condition information from the player 2 is received by the transaction condition information receiving unit 54. Subsequently, the transaction condition information storage unit 55 associates the transaction ID “A000001” included in the received transaction condition information with the quantity “1” of the “ground vehicle” included in the transaction condition information and the player 2. Player identification information “000002” is stored as the second transaction condition information.

  Subsequently, in step 910, the transaction condition information is set by the player 3 who wishes to obtain the “ground vehicle”. The player 3 searches for a record in which the “ground vehicle” is an exchange target in the transaction condition information management table by a method similar to the method already described for the player 2. Based on this search result, transaction rate information is generated in the same manner as described above, and the generated transaction rate information is presented to a game played by the player 3. The terminal device 30 of the player 3 generates a transaction rate information display screen (transaction rate screen) based on the transaction rate information, generates the transaction rate screen, and displays the transaction rate screen as a part of the game screen on the display screen. The transaction rate screen displayed on the terminal device 30 of the player 3 is the same as the screen shown in FIG. 12, but the “exchange request” button is not under the “recovery drink” image, but “ground vehicle”. Is displayed below the image.

  Subsequently, when “exchange application” is selected by the player 3, a transaction rate setting screen is displayed on the terminal device 30. This transaction rate setting screen is almost the same as the transaction rate setting screen 130 shown in FIG. 13, except that the input box for inputting the transaction quantity of the item provided to the exchange partner player is an image of “ground vehicle”. It is different in that it is displayed under the "Recovery Drink" image instead of under. Player 3 enters “60” as the quantity of “recovery drink” in the input box displayed under “recovery drink” on the transaction rate setting screen. Thereafter, when the determination button similar to the determination button 132 is selected by the player 3, the transaction ID “A000001”, the game medium type code “aaaa” for specifying “recovery drink”, and the “3” set by the player 3 are set. A transaction condition update request including the quantity “60” of “recovered drink” and the player identification information “000003” of the player 3 is transmitted to the server device 10.

  The transaction condition update request from the player 3 is received by the transaction condition update request receiving unit 58. If the time when the transaction condition update request is received is before the transaction end time (April 9, 9:00) set for the transaction ID “A000001”, the transaction condition update unit 59 , “50” for “recovery drink” stored in association with transaction ID “A000001” in the transaction condition information management table, and “60” for “recovery drink” included in the transaction condition update request. Are compared. In this case, since the quantity of “recovery drink” included in the transaction condition update request is larger than the quantity held in the transaction condition information management table, the first transaction associated with the transaction ID “A000001”. The transaction condition information management table is updated so that the condition information includes the quantity “60” of “recovered drink” and the player identification information “000003” of the player 3 included in the transaction condition update request. Specifically, as shown in FIG. 7, “60” instead of “50” is stored in “Transaction quantity of game medium 1” associated with the transaction ID “A000001”, and “Player identification information 1” In this case, “000003” is stored instead of “000001”. If the player 3 sets “40” as the transaction quantity of the “recovery drink”, the transaction quantity of the “recovery drink” set by the player 3 is stored in the transaction condition information management table. Since it is smaller than the transaction volume of “recovered drink”, the transaction condition information management table is not updated.

  Next, in step 912, based on the fact that the first transaction condition information corresponding to the transaction ID “A000001” has been updated, the transaction end time update unit 61 performs a transaction associated with the transaction ID “A000001”. The end time is extended, for example, by 1 hour.

Next, when the transaction end time set for the transaction ID “A000001” comes, it is stored in the transaction condition information management table in association with the transaction ID “A000001” by the owned quantity update unit 60 in step 914. Based on the first transaction condition information and the second transaction condition information, the possession quantity of the game content stored in the possession quantity management table is updated. If the transaction end time has arrived after the transaction condition update request from the player 3 is received and the transaction record with the transaction ID “A000001” is updated as shown in FIG. 7, the transaction ID “A000001” shown in FIG. First transaction condition information (that is, information stored in “type of game medium 1”, “transaction quantity of game medium 1”, and “player identification information 1”) of the transaction record corresponding to The exchange rate specified by the condition information (that is, the information stored in “type of game medium 2”, “transaction quantity of game medium 2”, and “player identification information 2”) is determined. Based on the transaction condition information and the second transaction condition information, the possession quantity of the game media stored in the possession quantity management table is updated. In FIG. 7, “000003” indicating the player 3 is stored in the “player identification information 1”, and “000002” indicating the player 2 is stored in the “player identification information 2”. In the quantity management table, “Item A possession quantity” and “Item B possession quantity” respectively associated with “000003” and “000002” are “Transaction quantity of game media 1” and “Game It is updated based on “Transaction volume of medium 2”. In other words, “60” stored in “Transaction quantity of game media 1” from “89” of the possession quantity of item A (here “recovery drink”) associated with “000003” in the possession quantity management table. In addition to the subtraction, “1” stored in “Transaction quantity of game media 2” is added to the possession quantity “0” of item B (here “ground vehicle”). In parallel with this, the stored quantity “12” of item A (here “recovered drink”) associated with “000002” in the owned quantity management table is stored in “Transaction quantity of game media 1”. While “60” is added, “1” stored in “Transaction quantity of game media 2” is subtracted from the quantity “2” of item B (here “ground vehicle”).

  As a result of updating the possessed quantities of item A and item B in this way, the retained quantity management table is updated as shown in FIG. After this update, Player 2 can play the game using 72 “Recovery Drinks” and 1 “Ground Vehicle”, and Player 3 can play 29 “Recovery Drinks” and 1 “Recovery Drink” A game can be played using a “ground vehicle”. Regarding Player 1, since the transaction for obtaining the “ground vehicle” has not been completed, the number of “ground vehicles” held is still “0”. As described above, the game media are exchanged between the players based on the transaction conditions set by each player.

  Although not shown in FIG. 9, if it is before the transaction end time, the transaction condition information management table can be further updated based on the transaction condition update request transmitted to the server device 10 from other than the player 3. . For example, when the player 4 wishes to obtain a “recovered drink”, a record in which the “recovered drink” stored in the transaction condition information management table is to be exchanged using a search function provided by the game Search for. Based on this search result, transaction rate information including the transaction quantity of “recovery drink” and the transaction quantity of “ground vehicle” is generated in the same manner as described above with respect to player 3, and the generated transaction Rate information is presented to the game of player 4.

  FIG. 14 is a display example of a transaction rate screen showing the transaction rate information presented to the game in this way, and FIG. 15 is a transaction rate setting screen for setting a transaction rate that can be transitioned from the transaction rate screen of FIG. Is a display example. As an example, FIG. 14 shows a transaction rate screen 140 when the transaction condition information management table is updated to the state shown in FIG. 7 in response to a transaction condition update request from the player 3. In the transaction condition information management table of FIG. 7, “Transaction quantity of game medium 1” indicating the transaction quantity of “Recovery drink” has been updated to “60”. Is displayed as 60 pieces. When the player 4 selects the operation button 142 on the transaction rate screen 140 illustrated in FIG. 14, the display screen of the terminal device 30 transitions to the transaction rate setting screen 150 illustrated in FIG. The player 4 inputs the transaction quantity of “ground vehicle” in the input box 151 on the transaction rate setting screen 150.

  Thereafter, when the determination button 152 is operated, a transaction condition update request including the transaction quantity of the “ground vehicle” set by the player 4 and the player identification information of the player 4 is transmitted to the server device 10. Similarly to the transaction condition update request received from the player 3, the server device 10 can process the transaction condition update request from the player 4, and can update the transaction end time and update the owned quantity management table. 14 and 15 show the transaction rate screen when the player 4 searches for transaction data for “recovered drink” in order to receive “recovered drink” in exchange for “ground vehicle”. Also, the display example of the transaction rate setting screen is shown, but the player 4 can also search for transaction data for “ground vehicle” as an exchange target in order to receive the “ground vehicle” in the same manner as the player 3. In this case, a display screen for accepting provision of the “ground vehicle” is provided to the player 4, as with the player 3.

  As described above, in one embodiment of the present invention, when a transaction rate for exchanging game media between players is presented to other players, a player who sets a transaction condition based on the transaction rate is set. The transaction rate information is generated so as not to include the player specifying information that can specify. Thus, in a series of processes for exchanging game media in the game, each player cannot specify the player for which the transaction conditions are set. Therefore, even if the players promise to exchange the actual currency as a price for exchanging game media outside the game, it is not possible to identify the other party who traded outside the game within the game. As described above, by implementing a function that prevents the identification of the game media exchange partner in the game system, it is possible to prevent the performance of transactions in the real world. Therefore, real money trade can be suppressed from a technical aspect by the game system according to the embodiment of the present invention.

  In another embodiment of the present invention, the server device 10 may further include a group management unit 62. The group management unit 62 randomly assigns game players to a plurality of groups. The group management unit 62 manages the group to which the player belongs, for example, using the group management table shown in FIG. FIG. 16 is an example of a group management table for managing groups to which game players belong. In FIG. 16 (a), player 1, player 2, and player 3 belong to the first group represented by group identification information “01”, and player 4 and player 5 have group identification information “02”. Belong to the second group represented.

  The group update unit 63 changes the grouping of players regularly or irregularly based on a predetermined algorithm. FIG. 16B is an example of the group management table after the grouping change. In FIG. 16B, player 1 and player 2 belong to the first group represented by the group identification information “01”, and player 3, player 4, and player 5 have the group identification information “02”. Belong to the second group represented.

  In the present embodiment, when the transaction rate information presenting unit 56 presents the transaction rate information generated for the transaction data associated with the predetermined transaction ID, the player identification associated with the transaction ID is performed. The transaction rate information is presented only to the games of players belonging to the same group as the players specified by information 1 and player identification information 2. For example, when the grouping shown in FIG. 16 (a) is performed, the transaction rate information representing the transaction data of the transaction ID “A000001” storing the transaction conditions between the player 1 and the player 2 shown in FIG. Is presented to the game of the player 3 belonging to the same group as the player 1 and the player 2, but is not presented to the game of the player 4 and the player 5 belonging to another group.

  Further, the group management unit 62 stores each of a plurality of groups to which the game player belongs in association with each other. For example, the game management unit 62 associates a plurality of groups with the group classification table illustrated in FIG. This association between groups is made, for example, in order to limit players who can obtain, refer to, or browse transaction data. For example, in the example shown in FIG. 17A, group 1 is associated with each of group 1, group 5, and group 21. In this case, transaction data relating to transactions between players belonging to group 1 can be obtained and referenced by players belonging to the associated group 1, group 5, and group 21, but players belonging to other groups. Is not obtained or referenced from. In this specification, a group in which acquisition and reference of exhibition data exhibited by players belonging to a specific group is permitted may be referred to as a referable group. When the transaction rate information presenting unit 56 presents the transaction rate information generated for the transaction data associated with a predetermined transaction ID, the player identification information 1 and the player identification information associated with the transaction ID Transaction rate information indicating transaction data of the transaction ID is presented only to players belonging to a group associated with the group to which the player specified in 2 belongs as a referenceable group. For example, the transaction rate information indicating the transaction data of transaction ID “A000001” storing the transaction conditions between player 1 and player 2 is as follows. When player 1 and player 2 belong to group 1, Presented only for games of players belonging to any one of group 1, group 5, and group 21.

  The group updating unit 63 can change the group association regularly or irregularly based on a predetermined algorithm. FIG. 17B is an example of the group classification table after the association is changed. In the example shown in FIG. 17B, referenceable group 1 is not changed, but referenceable group 2 and reference group 3 are changed. In this way, the referenceable group may be partially changed. As is clear from FIG. 17, in one aspect of the present invention, the same group as a specific group can be fixed as a referenceable group. That is, group 1 can be fixedly set as a group that can be referred to as group 1. In this way, by fixing the same group as a specific group as a referable group, transaction rate information can always be presented to players belonging to the same group. The example shown in FIG. 16 can be considered as an example in which the same group as a specific group is set as a referenceable group in the embodiment shown in FIG.

  In this way, even in the real world, even if it is promised to exchange the real currency accompanying the exchange of game media, it is necessary to exchange game media in the game unless the parties to the transaction belong to the same group in the game. I can't. Since this grouping is performed randomly according to a predetermined algorithm, it is impossible for the player to determine whether or not trading partners in the real world belong to the same group in the game. In this way, players can be grouped randomly, and exchange of game media is performed only between players belonging to the same group, so that execution of transactions in the real world can be inhibited and real money trade can be suppressed. .

  Further, by changing the grouping of the players, even if the player's belonging group is specified by the player, the belonging group can be made unknown again after the grouping change. Also, by changing the group that can be referred to, the group that can be referred to can be made unknown after the change. Thereby, real money trade can be controlled more effectively.

  In another embodiment of the present invention, the server device 10 may further include a player management unit 64. The player management unit 64 can store the player identification information of the players of the game in a dynamic association with the player identification information of other players, for example, using the player management table shown in FIG. For example, each player can register another player as a “friend”. For example, players registered as “friends” can cooperate in the progress of the game. The “friend” is set by applying from one player to the other player and approving the application. In addition, the setting of “companies” can be canceled when any player performs processing for canceling the “comrades” setting.

  In the present embodiment, when the transaction rate information presenting unit 56 presents the transaction rate information generated for the transaction data associated with a predetermined transaction ID, the player identification information associated with the transaction ID. The transaction rate information is presented only to the game of the player registered as a “friend” for the player specified by 1 and the player identification information 2. For example, the transaction rate information representing the transaction data of transaction ID “A000001” storing the transaction conditions between player 1 and player 2 shown in FIG. 6 is set as “companies” for player 1 and player 2 It is presented for the game of the player 3 being played, but is not presented for the games of the player 4 and the player 5 that are not set as “companies”.

  As a result, even in the real world, even if it is promised to exchange the real currency accompanying the exchange of game media, the game media will be exchanged in the game unless the trading party is registered as a “companion” in the game. It is not possible. In many cases, there is an upper limit on the number of “companies” that can be set, and it is unlikely that setting “companies” only for the purpose of trading game media will occur. In this way, by exchanging game media only between players registered as “comrades”, it is possible to inhibit the execution of transactions in the real world and suppress real money trade.

  The processes and procedures described in the present specification are realized by software, hardware, or any combination thereof other than those explicitly described in the embodiments. More specifically, the processes and procedures described in this specification are performed by mounting logic corresponding to the processes on a medium such as an integrated circuit, a volatile memory, a nonvolatile memory, a magnetic disk, or an optical storage. Realized. Further, the processes and procedures described in the present specification can be implemented as various computer programs by implementing the processes and procedures as computer programs.

  Even if it is described that the processes and procedures described herein are performed by a single device, software, component, or module, such processes or procedures may involve multiple devices, multiple software, multiple Component and / or multiple modules. Also, even though the data, tables, or databases described herein are described as being stored in a single memory, such data, tables, or databases are provided on a single device. Alternatively, the data can be distributed and stored in a plurality of memories or a plurality of memories arranged in a plurality of devices. Furthermore, the software and hardware elements described herein can be implemented by integrating them into fewer components or by disassembling them into more components.

10 Server device
30 Terminal equipment
51 Game program storage
52 Player specific information storage
53 Holding quantity storage
54 Transaction conditions information reception
55 Transaction condition information storage
56 Transaction rate information generator
57 Transaction rate information presentation section
58 Transaction condition update request reception department
59 Transaction Terms Update Department
60 Holding quantity update department
61 Trading end time update section
62 Group Management Department
63 Group Update Department
64 Player management

Claims (11)

A game program storage unit for storing a game program for executing the game;
A possessed quantity storage unit for storing a possessed quantity of each player of the first game medium and the second game medium possessed by each of the plurality of players of the game in association with player identification information unique to each player;
First transaction condition information including the transaction quantity of the first game medium set by the first player included in the plurality of players and player identification information of the first player, and a second player included in the plurality of players A transaction condition information storage unit that stores the transaction quantity of the second game medium set by the second transaction condition information including the player identification information of the second player in association with each other;
A transaction rate that includes the transaction quantity of the first game medium and the transaction quantity of the second game medium stored in the transaction condition information storage unit, but does not include player specifying information that can specify each of the plurality of players A transaction rate information generator for generating information,
A transaction rate information presentation unit for presenting the transaction rate information in the game played by a third player included in the plurality of players;
A transaction condition update request accepting unit for accepting a first transaction condition update request including a transaction quantity of the first game medium set by the third player from the third player;
When the first transaction condition update request is received before the transaction end time and the transaction quantity included in the transaction information update request is larger than the transaction quantity included in the first transaction condition information, the first A transaction condition update unit for updating the first transaction condition information so as to include a transaction quantity included in one transaction condition update request and player identification information of the third player;
Based on the first transaction condition information and the second transaction condition information stored in the transaction condition information storage unit at the transaction end time, the first game medium stored in the possessed quantity storage unit and A holding quantity update unit for updating the holding quantity of the second game medium;
A game system comprising: The possessed quantity update unit receives the first transaction condition update request before the transaction end time, and the transaction quantity included in the first transaction condition update request is included in the first transaction condition information. When the transaction quantity is larger than the transaction quantity, the first transaction condition information is included in the transaction end time from the possession quantity of the first game medium associated with the player identification information of the third player in the possession quantity storage unit. And the second transaction condition information at the transaction end time to the possession quantity of the second game medium associated with the player identification information of the third player in the possession quantity storage unit. And the possession of the second game medium associated with the player identification information of the second player in the possession quantity storage unit. The first game medium that subtracts the transaction quantity included in the second transaction condition information from the amount at the transaction end time and is associated with the player identification information of the second player in the possessed quantity storage unit Adding the transaction quantity included in the first transaction condition information to the transaction end time,
The game system according to claim 1. The transaction rate information presenting unit presents the transaction rate information in a game played by a fourth player included in the plurality of players,
The transaction condition update request accepting unit accepts a second transaction condition update request including a transaction quantity of the first game content set by the fourth player from the fourth player,
The transaction condition update unit receives the second transaction condition update request before the transaction end time, and the transaction quantity included in the transaction information update request is greater than the transaction quantity included in the first transaction condition information. The first transaction condition information is updated to include the transaction quantity included in the second transaction condition update request and the player identification information of the fourth player,
The game system according to claim 1. The transaction rate information presenting unit presents the transaction rate information in a game played by a fourth player included in the plurality of players,
The transaction condition update request receiving unit receives a second transaction condition update request including a transaction quantity of the second game medium set by the fourth player from the fourth player,
The transaction condition update unit receives the second transaction condition update request before the transaction end time, and the transaction quantity included in the transaction information update request is greater than the transaction quantity included in the second transaction condition information. The second transaction condition information is updated to include the transaction quantity included in the second transaction condition update request and the player identification information of the fourth player.
The game system according to claim 1. The game system according to claim 1, further comprising a transaction end time update unit that updates the transaction end time based on a time at which the first transaction condition update request is received. 5. The game system according to claim 3, further comprising a transaction end time update unit that updates the transaction end time based on a time at which the second transaction condition update request is received. A group management unit that randomly assigns each of the plurality of players of the game to any of a plurality of groups, and associates each of the plurality of groups with each other;
The transaction rate information presenting unit is configured to add the transaction rate to a game played by the third player only when the group to which the third player belongs is associated with the group to which the first player and the second player belong. Presenting information,
The game system according to claim 1. A player management unit for storing player identification information unique to each of the plurality of players of the game in association with player identification information of other players dynamically;
The transaction rate information presenting unit is only provided when the player management unit stores the player identification information of the third player in association with both the player identification information of the first player and the second player. Present the transaction rate information to the game played by 3 players,
The game system according to claim 1. The transaction rate information generation unit changes a transaction quantity of the first game medium included in the first transaction condition information and a transaction quantity of the second game medium included in the second transaction condition information, and Generating the transaction rate information so as to include the transaction volume after the change of the game medium and the second game medium;
The game system according to claim 1. The transaction quantity of the first game medium included in the first transaction condition information and the transaction quantity of the second game medium included in the second transaction condition information are selected from a predetermined limited number of options. Is,
The game system according to claim 1. Computer
Game program storage means for storing a game program for executing a game;
Possessed quantity storage means for storing the possessed quantity of each player of the first game medium and the second game medium possessed by each of the plurality of players of the game in association with player identification information unique to each player;
First transaction condition information including the transaction quantity of the first game medium set by the first player included in the plurality of players and player identification information of the first player, and a second player included in the plurality of players Transaction condition information storage means for storing the transaction quantity of the second game medium set by the second transaction condition information including the player identification information of the second player in association with each other,
A transaction rate that includes the transaction quantity of the first game medium and the transaction quantity of the second game medium stored in the transaction condition information storage means, but does not include player specifying information that can specify each of the plurality of players Transaction rate information generating means for generating information,
Transaction rate information presenting means for presenting the transaction rate information in a game played by a third player included in the plurality of players;
Transaction condition update request accepting means for accepting a first transaction condition update request including the transaction quantity of the first game content set by the third player from the third player,
When the first transaction condition update request is received before the transaction end time and the transaction quantity included in the transaction information update request is larger than the transaction quantity included in the first transaction condition information, the first A transaction condition updating means for updating the first transaction condition information so as to include a transaction quantity included in the one transaction condition update request and player identification information of the third player;
Based on the first transaction condition information and the second transaction condition information stored in the transaction condition information storage means at a transaction end time, the first game medium stored in the possessed quantity storage means and the Holding quantity update means for updating the holding quantity of the second game media,
Game program to function as.

Images