JP2014161532A - Game apparatus, program, and game method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To substantially secure opportunities that each player can acquire items in a match event.SOLUTION: A game apparatus 14 provides a game in which each player collects a plurality of items. A control device S identifies a player PB to be an opponent of a player PA in the match event for causing the player PA to acquire a first item. When the player PA defeats the player PB in the match event, the game apparatus offers the first item to the player PA and removes a second item different from the first item from possessed items of the player PB.

Description

  The present invention relates to a game for collecting items.

  A game in which a privilege is given by collecting a plurality of items has been conventionally proposed. For example, in an SNS (Social Networking Service) game disclosed in Non-Patent Document 1, items owned by each player are exchanged between the players. For example, in a battle event in which a player PA designates a specific player PB as an opponent and battles, a desired item can be acquired from the player PB when the player PA wins. The player PA designates the player PB that owns the desired item as an opponent.

“Social Game General Information Magazine Application STYLE Vol.2”, East Press, Inc., April 1, 2011, p.26-p.29

  However, since the progress of collection of each item differs for each player, there is a possibility that there are not enough players who own the desired item of the player PA. Therefore, there is a problem that the opportunity for the player PA to acquire a desired item is limited, and as a result, the interest of the game is lowered. In view of the above circumstances, an object of the present invention is to ensure a sufficient opportunity for each player to acquire a desired item at an event with another player as an opponent.

  Means employed by the present invention to solve the above problems will be described below. In order to facilitate understanding of the present invention, reference numerals in the drawings will be appended in parentheses for convenience in the following, but the present invention is not intended to be limited to the illustrated forms.

  A game device (14) according to a preferred aspect of the present invention is a game device (14) that provides a game in which each player collects a plurality of items divided into a plurality of types (G), and the plurality of types are provided. A specifying unit for specifying the second player (PB) as the opponent of the first player (PA) in the first event for the first player (PA) to acquire the item of the first type (GX) in (G). (32, SB3-SB5) and in the first event, the first type (GX) item is given to the first player (PA), and the second type (GY, GX) is different from the first type (GX). And a management unit (32, SB8) for removing items of GZ) from items owned by the second player (PB). In the above configuration, in the first event for the first player (PA) to acquire the item of the first type (GX), the item of the first type (GX) is given to the first player (PA), and The items of the second type (GY, GZ) that are different from the first type (GX) are removed from the items owned by the second player (PB). That is, the second player (PB) who is the opponent of the first player (PA) in the first event for the first player (PA) to acquire the item of the first type (GX) is the first type (GX). It is not limited to the player who owns the item. Therefore, it is possible to secure a sufficient opportunity for each player to acquire a desired item at an event with another player as an opponent.

  By the way, in a game in which the player collects items of type (G) corresponding to the attribute (S) associated with each player among a plurality of attributes (S), the player who owns the item of each type (G) is classified. There is a possibility that the total number is different for each attribute (S). Assuming the above tendency, the management unit (32, SB8) determines that the first player (PA) associated with the first attribute (SX) among the plurality of attributes (S) in the first event is the first player (PA). An item of the first type (GX) corresponding to one attribute (SX) is given, and the second player (PB) associated with a second attribute (SY, SZ) different from the first attribute (SX) A configuration in which an item of the second type (GY, GZ) corresponding to the second attribute (SY, SZ) is removed from the owned item is particularly suitable. Specifically, each of the plurality of types (G) includes a plurality of items corresponding to each other among the attributes (S), and the management unit (32, SB8) is associated with the first attribute (SX). The first player (PA) is given one item selected by the first player (PA) among the plurality of items of the first type (GX), and the plurality of items of the second type (GY, GZ) The item corresponding to one item is removed from the items owned by the second player (PB) associated with the second attribute (SY, SZ).

  In a preferred aspect of the present invention, the specifying unit (32, SB3-SB5) includes a plurality of candidate players including a player who does not own an item of the first type (GX), and the first player (PA) has the first type ( GX) is presented to the first player (PA) as a candidate for the partner to acquire the item, and the player selected by the first player (PA) from the plurality of candidate players is specified as the second player (PB). In the above configuration, a plurality of candidate players including a player who does not own an item of the first type (GX) is a first player as a candidate of an opponent from whom the first player (PA) acquires an item of the first type (GX). (PA). Therefore, there is an advantage that the first player (PA) cannot grasp that the candidate player who does not actually own the item of the first type (GX) is presented.

  In a preferred aspect of the present invention, when there are a predetermined number of players who own items of the first type (GX), the specifying unit (32, SB3-SB5) sets the player as a candidate player as the first player ( PA) and when there is no predetermined number of players who own the first type (GX) item, the first player (PA) is a player who does not own the first type (GX) item as a candidate player. When the second player (PB) owns an item of the first type (GX) in the first event, the management unit (32, SB8) owns the item of the second player (PB). When the second player (PB) does not own the item of the first type (GX), the item of the second type (GY, GZ) is removed from the owned item of the second player (PB). In the above aspect, when there is a predetermined number of players who own items of the first type (GX), the players are presented to the first player (PA) as candidate players, and there is no predetermined number of players. In addition, a player who does not own the first type (GX) item is presented as a candidate player to the first player (PA). Therefore, there is an advantage that a player who actually owns an item of the first type (GX) is preferentially extracted as a candidate player as compared with a non-owned player. In addition, a configuration in which the specifying unit (32, SB3-SB5) specifies a player who satisfies a predetermined candidate extraction condition other than whether or not the item of the first type (GX) is owned as a candidate player is also preferable.

  In a preferred aspect of the present invention, the management unit (32, SB8) sends the second player (PB) the first player (PB) as an opponent who has acquired the second type (GY, GZ) item from the second player (PB). PA). In the above aspect, the first player (PA) is presented to the second player (PB) as the partner who acquired the item of the second type (GY, GZ) removed from the items owned by the second player (PB). . Therefore, the item of the first type (GX) given to the first player (PA) is actually different from the item of the second type (GY, GZ) removed from the items owned by the second player (PB). There is an advantage that the second player (PB) cannot grasp what to do.

  In a preferred aspect of the present invention, in the second event in which the second player (PB) recaptures the item from the first player (PA), the management unit (32, SF) receives the second player (PB ) Items of the second type (GY, GZ) removed from the possessed items are given to the second player (PB) and the first type (GX) given to the first player (PA) at the first event ) Is removed from the items owned by the first player (PA). In the above configuration, since the second event is executed to recapture the items removed from the items owned by the second player (PB) in the first event, it is possible to improve the fun of the game.

  The game apparatus (14) according to a preferred embodiment of the present invention is a game apparatus (14) that provides a game in which each player collects a plurality of items, and the first player (PA) acquires the first item. In the first event, the specifying unit (32, SB3-SB5) for specifying the second player (PB) as the opponent of the first player (PA) in the first event, and the first item in the first event as the first player (PA) And a management unit (32, SB8) for removing the second item different from the first item from the owned item of the second player (PB). In the above configuration, in the first event for the first player (PA) to acquire the first item, the first item is given to the first player (PA) and the second item is different from the first item. The item is removed from the items owned by the second player (PB). That is, the second player (PB) who is the opponent of the first player (PA) in the first event for the first player (PA) to acquire the first item is not limited to the player who owns the first item. Therefore, it is possible to secure a sufficient opportunity for each player to acquire a desired item at an event with another player as an opponent.

  The present invention is also specified as a program for causing a computer to function as the game apparatus (14) according to each of the above aspects. In order to provide a game in which each player collects a plurality of items divided into a plurality of types (G), the program according to the present invention allows a computer to be a first type (GX) of the plurality of types (G). A specifying unit (32, SB3-SB5) for specifying a second player (PB) as an opponent of the first player (PA) in a first event for the first player (PA) to acquire an item, and a first In the event, an item of the first type (GX) is given to the first player (PA), and an item of the second type (GY, GZ) different from the first type (GX) is given to the second player (PB). It is made to function as a management part (32, SB8) removed from the possessed items. The program of the present invention is provided, for example, in a form stored in a computer-readable recording medium and installed in the computer. The recording medium is, for example, a non-transitory recording medium, and an optical recording medium (optical disk) such as a CD-ROM is a good example, but a known arbitrary one such as a semiconductor recording medium or a magnetic recording medium This type of recording medium can be included. For example, the program of the present invention can be provided in the form of distribution via a communication network and installed in a computer. Recording media that can be accessed by the distribution server that distributes the program of the present invention (for example, storage devices inside or outside the distribution server) are also included in the concept of the recording medium.

  The present invention is also specified as a method for providing a game in which each player collects a plurality of items classified into a plurality of types (G) by a computer. In the game method of the present invention, the first player (PA) becomes the opponent of the first player (PA) in the first event for the first player (PA) to acquire items of the first type (GX) among the plurality of types (G). Two players (PB) are specified, and in the first event, an item of the first type (GX) is given to the first player (PA), and a second type (GY, GX, which is different from the first type (GX)) GZ) is removed from the items owned by the second player (PB).

1 is a block diagram of a game system according to a first embodiment of the present invention. It is explanatory drawing of a game. It is explanatory drawing of an item group and an item. It is a schematic diagram of player information. It is explanatory drawing of the transition of a game image. It is a flowchart of a search process. It is a flowchart of a battle process. It is a flowchart of a candidate extraction process. It is explanatory drawing of a candidate extraction process. It is a flowchart of an item management process. It is explanatory drawing of an item management process. It is a schematic diagram of the game image at the time of defeat. It is a schematic diagram of the player information in 2nd Embodiment. It is a flowchart of the recapture process in 2nd Embodiment.

<First Embodiment>
FIG. 1 is a block diagram of a game system 100 according to the first embodiment of the present invention. As shown in FIG. 1, the game system 100 according to the first embodiment includes a plurality of terminal devices 12 and a game device 14. Each terminal device 12 is an information processing device such as a mobile phone or a smartphone, and communicates with the game device 14 via a communication network 16 (for example, a mobile communication network or the Internet). The game device 14 is a server device (for example, a web server) that provides a computer game to a player who uses each terminal device 12.

  As shown in FIG. 1, each terminal device 12 is realized by a computer system including a control device 20, a storage device 22, a communication device 24, a display device 26, and an input device 28. The control device 20 is an arithmetic processing device that comprehensively controls each element of the terminal device 12. The communication device 24 communicates with the game device 14 via the communication network 16. The communication between the terminal device 12 and the communication network 16 is typically wireless communication. However, for example, when a stationary information processing device is used as the terminal device 12, the terminal device 12 and the communication network 16 Can also be wired. The storage device 22 (for example, a semiconductor recording medium) stores programs executed by the control device 20 and various data used by the control device 20.

  The display device 26 (for example, a liquid crystal display panel) displays various images under the control of the control device 20. The input device 28 is a device for the player to input an instruction to the terminal device 12, and includes, for example, a plurality of operators that the player operates. Note that a touch panel integrated with the display device 26 and a microphone for inputting an instruction to the terminal device 12 by voice may be employed as the input device 28.

  The game device 14 according to the first embodiment provides an SNS game (for example, a browser game) that is associated with each other by a plurality of players using the terminal devices 12 to provide the players of the terminal devices 12. In the first embodiment, a game is provided in which each of a plurality of players collects items. Each item is a virtual object (object) collected by the player in the game, and is represented as a treasure or a jewel, for example.

  2 and 3 are explanatory diagrams of the game of the first embodiment. As shown in FIG. 2, in the game of the first embodiment, a plurality of scenarios S (SX, SY, etc.) in which the characters appearing in the virtual world and the virtual world view (atmosphere and story) in which each character is active are different. SZ) is prepared. Each player selects a desired scenario (hereinafter referred to as “selected scenario”) S from among a plurality of scenarios S, and then advances the game under the selected scenario S. As understood from the above description, the scenario S is a good example of the attribute associated with each player.

  As illustrated in FIGS. 2 and 3, a plurality of types (hereinafter referred to as “item groups”) G corresponding to different scenarios S (SX, SY, SZ) are prepared. Each item group G (GX, GY, GZ) is a set of a plurality of items (six types in the following example). Each player sequentially collects each item of the item group G corresponding to the selected scenario S by executing an event (hereinafter referred to as “search event”) for searching the virtual world of the selected scenario S, for example. For example, the player who has selected the scenario SX collects a plurality of items X (X-1 to X-6) constituting the item group GX corresponding to the scenario SX. Similarly, the player who has selected the scenario SY collects the items Y (Y-1 to Y-6) of the item group GY corresponding to the scenario SY, and the player who has selected the scenario SZ is the item corresponding to the scenario SZ. Collect each item Z (Z-1 to Z-6) of group GZ.

  As understood from FIG. 3, each item includes type information q1 (q1 = X, Y, Z) and 1 for identifying an item group G (or a scenario S in which the item can be acquired) that includes the item. Each item group G is uniquely specified in combination with an element number q2 (q2 = 1 to 6) for identifying each item. Each of the plurality of item groups G corresponding to different scenarios S includes items corresponding to each other among the scenarios S (specifically, items having the same element number q2). For example, item X-2 of item group GX, item Y-2 of item group GY, and item Z-2 of item group GZ correspond to each other. In the first embodiment, the case where each item group G includes the same number of items is illustrated for convenience, but the total number (number of types) of items may be different for each item group G.

  As illustrated in FIG. 2, each scenario S is divided into a plurality of stages. Each stage of one scenario S is associated with any of a plurality of items in the item group G corresponding to the scenario S. Each player can acquire an item corresponding to the stage in the item group G corresponding to the selected scenario S with a predetermined probability by executing a search event in each stage of the selected scenario S. Further, when a predetermined condition (for example, a condition that the achievement rate accumulated for each execution of the event reaches the target value) is satisfied, the player proceeds to the next stage. Each stage can be divided into a plurality of sub-stages.

  In the search event of each stage, only some items among a plurality of items of the item group G corresponding to the selected scenario S can be acquired. Items that can be acquired at the search event of each stage of the selection scenario S may differ among players. Items that cannot be acquired by each player through a search event can be acquired (taken) from the opponent's player by executing an event (hereinafter referred to as a “match event”) for playing against other players. For example, as illustrated in FIG. 2, a player who can acquire item X-1, item X-3, and item X-5 at the search event of the selected scenario SX cannot acquire the item (X-2 , X-4, X-6) can be acquired by winning at a battle event with another player who acquired the item at the search event of the selected scenario SX.

  A privilege is given to a player who collects all items of the item group G corresponding to one scenario S. The privilege is, for example, various rights and treatments for the player to develop the game advantageously. Specifically, a character that can participate in a battle event and a tool (for example, a recovery item) for favorably progressing a search event are given to the player as a privilege. It is also possible to give a predetermined amount of virtual currency that can be used in the SNS or the game as a privilege to the player.

  As shown in FIG. 1, the game apparatus 14 includes a control device 32, a storage device 34, and a communication device 36. It is also possible to realize the game apparatus 14 with a plurality of devices configured separately from each other (for example, a plurality of server devices that communicate with each other via the communication network 16). The control device 32 is an arithmetic processing device that comprehensively controls each element of the game device 14. Each function of the control device 32 can be distributed to a plurality of devices. The communication device 36 communicates with each terminal device 12 via the communication network 16.

  The storage device 34 stores a program (game program) executed by the control device 32 and various data used by the control device 32. For example, a recording medium such as a semiconductor recording medium or a magnetic recording medium, or a combination of a plurality of types of recording media can be employed as the storage device 34. A configuration in which the storage device 34 is installed in an external device (for example, a server device) separate from the game device 14 and the game device 14 obtains information in the storage device 34 from the external device via the communication network 16 is also adopted. Can be done. That is, the storage device 34 is not an essential requirement for the game device 14. In addition, for example, the storage device 34 (virtual one recording medium) can be configured by a plurality of storage circuits independent from each other (for example, a plurality of server devices installed at geographically different positions). .

  The storage device 34 stores player information D for each player. FIG. 4 is a schematic diagram of the player information D. As shown in FIG. 4, the player information D of each player includes identification information D1, possessed item information D2, selection scenario information D3, ability information D4, and battle history information D5. The identification information D1 is a code for uniquely identifying the player.

  The owned item information D2 in FIG. 4 specifies an item owned by the player (hereinafter referred to as “owned item”). Specifically, the owned item information D2 designates the identification information Q and the number of players owned (total number of items owned by the player) K for each item of each item group G. The identification information Q includes type information q1 (q1 = X, Y, Z) and an element number q2 (q2 = 1 to 6). Note that the number K of possession of each item is the total number of the items that the player has acquired in the past and still owns, and the items that the player has acquired in the past but currently do not own (for example, the opponent's Items taken by the player) are not counted in the possession number K. The selected scenario information D3 in FIG. 4 specifies a scenario (selected scenario) S selected by the player.

  The ability information D4 is information relating to the player's ability to compete at the competition event. Specifically, the capability information D4 of the first embodiment includes a level that is an index of the player's growth level, an attack power that is an index of the player's attack capability, and a defense force that is an index of the player's defense capability. specify. The battle event according to the first embodiment is an event in which the overall ability values of a plurality of characters (for example, monsters) owned by a player as an opponent are compared to determine victory or defeat between them. Therefore, the ability information D4 designates the attack power and defense power of each character owned by the player. The battle history information D5 is information indicating the history of the battle event, and is an item taken away by the opponent's identification information D1 in the battle event in which the player participated in the past (the battle event in which the player lost) and the defeat in the battle event. And the identification information Q.

  The control device 32 of FIG. 1 implements various functions for providing a game to each terminal device 12 by executing a program stored in the storage device 34. Specifically, the control device 32 executes a process according to a request transmitted from the terminal device 12 in response to an instruction from the player with respect to the input device 28 of each terminal device 12, and displays a game image ( For example, display data for displaying a web page) is transmitted from the communication device 36 to the requesting terminal device 12 to display a game image as a processing result on the display device 26.

  FIG. 5 is an explanatory diagram of the game image 51 that the control device 32 displays on the display device 26 of the terminal device 12 of an arbitrary player PA. In the game image 51 of FIG. 5, an operation unit 61 and an operation unit 62 that can be operated by the player PA using the input device 28 of the terminal device 12 are arranged. Each of the operation unit 61 and the operation unit 62 is a link object (for example, link text or command button) in which a link to display data of another game image is set.

  A player PA who wishes to execute a search event operates the operation unit 61 (search). When the operation unit 61 is operated, the control device 32 executes the search process SA of FIG. 6 for advancing the search event. When the search process SA is started, the control device 32 displays the game image 52 of FIG. 5 that causes the player PA to select the scenario S on the display device 26 of the terminal device 12 of the player PA (SA1). The game image 52 includes a plurality of operation units (for example, link objects) 63 corresponding to different scenarios S. The player PA can select the scenario S by operating the operation unit 63 corresponding to the desired scenario S. The control device 32 specifies the scenario S selected by the player PA as the selected scenario S (SA2). Specifically, the control device 32 updates the selected scenario S designated by the selected scenario information D3 of the player PA to the scenario S corresponding to the operation unit 63 operated by the player PA.

  The control device 32 executes a search event lottery process corresponding to the selection scenario S of the player PA (SA3). The lottery process SA3 is a process of giving an item associated with the current stage among the item group G corresponding to the current selected scenario S to the player PA with a predetermined probability. Specifically, the control device 32 increases the owned number K corresponding to the identification information Q of the item selected in the lottery process SA3 among the owned item information D2 of the player PA. For example, as illustrated in FIG. 2, in the search event of stage 1 of the selection scenario SX, the item X-1 is given to the player PA with a predetermined probability, and in the search event of stage 2 of the selection scenario SY, the item Y- 3 is given to the player PA with a predetermined probability. The control device 32 repeats the lottery process SA3 according to an instruction from the player PA to advance the stage at any time. When the player PA instructs the end of the search event, the control device 32 displays on the display device 26 of the terminal device 12 of the player PA. The game image 51 of FIG. 5 is displayed. As understood from the above description, the player PA can execute a search event for each scenario S while changing the selected scenario S as needed.

  In the search event lottery process SA3, in addition to the item corresponding to the selected scenario S, a character that can participate in the battle event can be given to the player PA with a predetermined probability. An item corresponding to one selected scenario S can be given to the player only by a search event of the selected scenario S, but for characters, characters corresponding to all scenarios S are given to the player by a search event of the selected scenario S. obtain.

  On the other hand, the player PA who desires to execute the battle event operates the operation unit 62 (match) of the game image 51 of FIG. When the operation unit 62 is operated, the control device 32 executes the battle process SB of FIG. 7 in which the battle event is advanced. When the battle process SB is started, the control device 32 presents a candidate for an item (hereinafter referred to as “target item”) that the player PA intends to acquire in the battle event and causes the player PA to select the game image 53 of FIG. Is displayed on the display device 26 of the terminal device 12 (SB1). In the game image 53, each item of each item group G is presented as a selection candidate, and the player PA can select a desired item from the game image 53 by operating the input device 28. The control device 32 specifies the item selected by the player PA as the target item (SB2). And the control apparatus 32 performs the process (SB3-SB5) for specifying the player PB used as the opponent of the player PA by the battle event for the player PA to acquire a target item.

  First, the control device 32 executes a candidate extraction process for extracting a predetermined number (N) players (hereinafter referred to as “candidate players”) as candidates for the opponent (SB3). Then, the control device 32 causes the display device 26 of the terminal device 12 of the player PA to display the game image 54 of FIG. 5 presenting the N candidate players extracted in the candidate extraction process SB3 to the player PA (SB4). The game image 54 illustrated in FIG. 5 is a list (candidate list) in which the names of candidate players and the fighting ability (level) specified by the ability information D4 are arranged for each of N candidate players. The target item selected by the player PA is also presented in the game image 54.

  The player PA can select a desired candidate player among the N candidate players presented in the game image 54 as an opponent for the current battle event by appropriately operating the input device 28 of the terminal device 12. Is possible. The control device 32 specifies the candidate player selected by the player PA as the opponent player PB (SB5). As understood from the above description, the control device 32 executes the processing from step SB3 to step SB5, thereby realizing an element (specifying unit) for specifying the player PB that is the opponent of the player PA in the battle event.

  FIG. 8 is a flowchart of specific contents of the candidate extraction process SB3 of FIG. When the candidate extraction process SB3 is started, the control device 32 stores a player who owns the target item selected by the player PA (that is, a player whose possession number K of the target item specified by the owned item information D2 is 1 or more). The player information D is extracted from all the players stored in 34 (SC1). Specifically, the control device 32 extracts a player who owns the target item and satisfies a predetermined condition (hereinafter referred to as “candidate extraction condition”). Candidate extraction conditions are conditions other than whether or not the target item is owned. Specifically, the player is extracted with the candidate extraction condition that the fighting ability (level, attack power, and defense power) indicated by the ability information D4 approximates the player PA.

  The control device 32 determines whether or not the number M of players extracted in step SC1 (that is, a player who owns the target item and satisfies the candidate extraction conditions) is less than a predetermined number N of candidate players. (SC2). When N or more players who own the target item are extracted in step SC1 (M ≧ N), the control device 32 determines N of the M players extracted in step SC1 as candidate players. (SC3). Therefore, a game image 54 in which all N candidate players who own the target item are selection candidates is presented to the player PA in step SB4.

  On the other hand, if the number of players M extracted in step SC1 is less than the predetermined number N (SC2: YES), the control device 32 extracts (NM) players who do not own the target item (SC4). . Specifically, the control device 32 owns an item corresponding to the target item (hereinafter referred to as “corresponding item”) in the item group G of the scenario S that is separate from the target item, and is similar to step SC1 described above. Are extracted (N−M) players who satisfy the candidate extraction condition (for example, the ability of the battle is close to that of the player PA). The corresponding item is, for example, an item having the element number q2 in common with the target item.

  For example, as illustrated in FIG. 9, a situation is assumed in which the player PA selects the item X-6 of the item group GX as the target item. The player P1 illustrated in FIG. 9 does not own the target item X-6, but the corresponding item Y has the same element number q2 (q2 = 6) as the target item X-6 in the item group GY of the scenario SY. Since -6 is owned, it can be extracted as a candidate player in step SC4. Similarly, the player P3 in FIG. 9 does not own the target item X-6, but owns the corresponding item Z-6 corresponding to the target item X-6 in the item group GZ. It can be extracted as a player. On the other hand, since the player P2 does not own the target item X-6 or the corresponding item (Y-6, Z-6), it is not extracted as a candidate player in step SC4.

  A total of N players composed of the M players extracted in step SC1 and the (NM) players extracted in step SC4 are determined as candidate players. In other words, the shortage of candidate players ((N−M) people) extracted in step SC1 is supplemented by players who do not own the target item. If no player matching the condition is extracted in step SC1 (M = 0), N candidate players who do not own the target item are extracted in step SC4. As understood from the above description, the player who owns the target item is extracted as a candidate player preferentially compared with the player who does not own the target item.

  As a result of the candidate extraction process SB3 being executed in the above procedure, the N candidate players presented to the player PA in step SB4 of the battle process SB of FIG. 7 may include players who do not own the target item. However, in the game image 54 (candidate list) shown in FIG. 5 presented to the player PA in step SB4, N candidate players are presented to the player PA as candidates of opponents with which the player PA acquires the target item. That is, a player who does not actually own the target item is also presented to the player PA as a candidate player (player who owns the target item) as a candidate for the acquisition target of the target item. Therefore, the player PA cannot recognize that the player who does not actually own the target item is included in the N candidate players.

  When the opponent player PB is specified in the process from step SB3 to step SB5 in FIG. 7, the control device 32 executes a win / loss determination process for determining win / loss between the player PA and the player PB (SB6). Specifically, the control device 32 determines the victory or defeat between the two by comparing the ability information D4 of the player PA and the ability information D4 of the player PB. When the player PA wins the player PB in the win / loss determination process SB6 (SB7: YES), the control device 32 executes an item management process for giving the target item to the player PA (SB8). On the other hand, when the player PA loses to the player PB in the win / loss determination process SB6, the item management process SB8 is not executed. That is, the player PA cannot acquire the target item.

  When the above processing is completed, the control device 32 notifies the player PA of the battle result with the player PB (SB9). Specifically, when the player PA wins the player PB in the win / loss determination process SB6, the control device 32 displays the game image 55 of FIG. 5 for notifying the victory in the battle event on the display device 26 of the terminal device 12 of the player PA. To display. The game image 55 includes, for example, an image 71 for notifying the victory at the battle event, an image 72 for notifying the opponent player PB, and an image 73 for notifying the item acquired by the player PA due to the victory. The On the other hand, when the player PA loses to the player PB in the win / loss determination process SB6, the control device 32 causes the display device 26 of the terminal device 12 of the player PA to display a game image (not shown) notifying the defeat at the battle event. .

  As understood from the above description, the battle process SB of the first embodiment is executed when the player PA instructs the start of the battle event, and the player PB starts the battle event with the player PA. There is no need to recognize in real time or immediately during execution. That is, the game (competition event) of the first embodiment is an asynchronous game in which each player who competes in the competition event does not need to execute the game at the same time. Therefore, there is an advantage that a large number of players can easily participate in a battle event as compared with a synchronous game in which a plurality of players are required to participate in the game at the same time. However, the present invention can also be applied to a synchronous game.

  FIG. 10 is a flowchart of the item management process SB8 of FIG. 7 executed when the player PA wins in the battle event. When the item management process SB8 is started, the control device 32 gives the target item to the player PA (SD1). Specifically, the control device 32 increases the owned number K that the owned item information D2 of the player PA designates for the target item.

  The control device 32 refers to the owned item information D2 of the player PB to determine whether or not the opponent player PB in the current battle event owns the target item (SD2). When the player PB owns the target item (SD2: YES), the control device 32 removes the target item from the owned item of the player PB (SD3). Specifically, the control device 32 decreases the possession number K specified for the target item by the possessed item information D2 of the player PB. That is, the target item of the player PB shifts to the player PA. In addition, the control device 32 sets the battle history information D5 including the identification information D1 of the player PA (the opponent who took the target item) and the identification information Q of the target item removed from the possessed item as the player information D of the player PB. to add.

  As described above for the candidate extraction process SB3, a player who does not actually own the target item can also be selected as the player PB (SC4). When the player PB does not own the target item (SD2: NO), the control device 32 determines that the corresponding item owned by the player PB (element number q2 is the target item in the item group G of the scenario S separate from the target item). Are removed from the items owned by the player PB (SD4). Specifically, the control device 32 decreases the possession number K specified for the corresponding item by the owned item information D2 of the player PB. That is, the target item is given to the player PA in exchange for the loss of the corresponding item of the player PB. Further, the control device 32 uses the battle history information D5 including the identification information D1 of the player PA (the opponent who took the corresponding item) and the identification information Q of the corresponding item removed from the possessed item as the player information D of the player PB. to add.

  For example, as illustrated in FIG. 11, in a battle event in which the player PA selects the item X-6 of the item group GX as the target item, the target item X-6 is not owned but the corresponding item Y-6 is owned. Assume that the player PB is selected as an opponent. When the player PA wins the player PB, as shown by the arrow in FIG. 11, the target item X-6 is given to the player PA (SD1), and the corresponding item Y-6 of the player PB is removed (SD4). . That is, it can be said that the corresponding item Y-6 of the player PB is converted to the target item X-6 and then transferred to the player PA. As understood from the above description, the control device 32 executes the item management process SB8 of FIG. 10 to give the player PA a target item and assign a corresponding item (that is, an item different from the target item) to the player PB. An element (management unit) to be removed from the owned item is realized.

  In the image 73 of the game image 55 of FIG. 5 presented to the player PA in step SB9 after the execution of the item management process SB8, whether the item removed from the owned item of the player PB is a target item or a corresponding item. Regardless, the target item given to the player PA is presented to the player PA. Therefore, the player PA recognizes that the target item has been acquired from the player PB. That is, the player PA cannot grasp that the item removed from the item owned by the player PB is actually a corresponding item that is different from the target item.

  The player PB can confirm the result of the battle event executed in the past with the player PA at the stage where the game is started by appropriately operating the terminal device 12. Specifically, when display of the result of the battle with the player PA is instructed to the terminal device 12 of the player PB, the control device 32 refers to the battle history information D5 of the player information D of the player PB. The game image 56 in FIG. 12 for notifying the defeat at the battle event with the player PA is displayed on the display device 26 of the terminal device 12 of the player PB. The game image 56 includes, for example, an image 74 for notifying the defeat at the battle event, an image 75 for notifying the opponent player PA, and an image 76 for notifying the item taken by the player PA. . The image 75 includes the name of the player PA of the identification information D1 designated by the battle history information D5. Further, the item notified by the image 76 is an item (target item or corresponding item) removed from the possessed item of the player PB in step SD3 or step SD4 in FIG. Therefore, the player PB recognizes that his own item (target item or corresponding item) has been taken by the player PA. That is, the player PB cannot grasp that the target item given to the player PA is an item that is actually different from the owned item of the player PB. In the above description, the game image 56 at the time of defeat of the player PB is illustrated for convenience. However, the game image when the player PB wins the player PA in the battle event is also the same as that of the terminal device 12 of the player PB. It is displayed on the display device 26.

  As understood from the above description, when the player PB that owns the target item is specified as the opponent, the item shown by the image 73 of the game image 55 presented to the player PA and the game presented to the player PB The item indicated by the image 76 of the image 56 is a common target item. On the other hand, when the player PB who does not own the target item is specified as the opponent, the image 73 of the game image 55 presented to the player PA shows the target item, and the image 76 of the game image 56 presented to the player PB. Indicates a corresponding item that is different from the target item.

  As described above, in the first embodiment, when the player PA wins a battle event with the player PB that does not own the target item, the target item is given to the player PA and the player PB owns the item. Corresponding items are removed. That is, the player PB who becomes the opponent of the player PA in the battle event for the player PA to acquire the target item is not limited to the player who owns the target item. Therefore, it is possible to secure a sufficient opportunity for each player to acquire a desired target item at the battle event.

  In the configuration in which each player collects items corresponding to a specific scenario S as in the first embodiment, the total number of players who own items in each item group G may be different for each scenario S (for each item group G). . In the configuration of the first embodiment in which each player can select a desired scenario S, the above tendency becomes obvious. When the players concentrate on a specific scenario S, the total number of players who own items of other scenarios S cannot be secured sufficiently. Therefore, in the conventional technique disclosed in Non-Patent Document 1, etc. May limit the chance that an item can be acquired. Since the total number of players is small at the stage immediately after the provision of the game is started, the above problem becomes obvious. In the first embodiment, the player can be selected as an opponent of the battle event regardless of whether or not the target item is owned. Therefore, even when the total number of players for each scenario is significantly different, each player can select a desired target item in the battle event. Enough opportunities to acquire are secured. That is, the configuration of the first embodiment that can be selected as the opponent of the battle event regardless of whether or not the target item is owned is exceptionally effective in a configuration in which each player can select a desired scenario S.

  In the first embodiment, N candidate players including a player who does not own the target item are presented to the player PA as candidates for the opponent of the player PA (that is, the target item acquisition destination). Therefore, there is an advantage that the player PA is not aware of the inconsistency that a candidate player who does not actually own the target item is presented as an opponent candidate. Further, since the player PA is presented to the player PB as the opponent who has acquired the corresponding item from the player PB, the target item given to the player PA in exchange for the corresponding item of the player PB is actually different from the corresponding item. There is an advantage that the player PB is not aware of the inconsistency. As described above, according to the first embodiment, an effect is realized that an inconsistency between items exchanged between the player PA and the player PB is not perceived by the player PA and the player PB.

  In the first embodiment, when candidate players who own the target item are sufficiently extracted, the opponent player PB is identified from the candidate players who own the target item, and the candidate players who own the target item are sufficiently selected. If it cannot be extracted, the opponent player PB is identified from the candidate players who do not own the target item. In other words, the player who actually owns the target item is extracted as a candidate player preferentially compared with the non-owned player. Therefore, there is an advantage that the frequency of the difference between the item acquired by the player PA and the item removed from the player PB is reduced. Further, since candidate players are extracted based on candidate extraction conditions other than the presence or absence of possession of the target item, players who are inappropriate as opponents of the player PA (for example, players who are too strong or players who are too weak compared to the player PA) are candidates. It is possible to reduce the possibility of being extracted as a player.

Second Embodiment
A second embodiment of the present invention will be described below. In the second embodiment, an event (hereinafter referred to as “recapture event”) for the player PB who has lost the battle with the player PA in the battle event illustrated in the first embodiment to recapture the item captured by the player PA. It is possible to execute. In addition, about the element in which an effect | action and a function are equivalent to 1st Embodiment in each form illustrated below, the code | symbol referred by description of 1st Embodiment is diverted, and each detailed description is abbreviate | omitted suitably.

  FIG. 13 is a schematic diagram of the player information D of the player PB in the second embodiment. As shown in FIG. 13, the battle history information D5 of the second embodiment is configured to include the identification information D1 of the player PA who is the opponent in the past battle event, the identification information QA, and the identification information QB. The identification information QA is the identification information Q of the target item given to the player PA in the past battle event. On the other hand, the identification information QB is identification information Q of an item (hereinafter referred to as “recapture item”) removed from the possessed item of the player PB due to the defeat at the battle event. In the following description, it is assumed for the sake of convenience that a player PB who does not own the target item selected by the player PA is identified as an opponent in the past battle event. Therefore, the recapture item specified by the identification information QB is a corresponding item that is different from the target item given to the player PA.

  For example, the player PB who desires to execute the recapture event instructs the occurrence of the recapture event by operating an image 75 (for example, a link object) that notifies the name of the player PA among the game images 56 of FIG. When the occurrence of the withdrawal event is instructed to the terminal device 12 of the player PB, the control device 32 executes the withdrawal process SE shown in FIG. 14 in which the withdrawal event is advanced. When the player PB has instructed the execution of the recapture event, the player PA does not already have the target item captured from the player PB in the past battle event (for example, the player PB was captured in the battle event with another player). ), The recapture event of the player PB is not executed. If the player PA does not already own the target item that has been captured in the past from the player PB, a normal battle event in which the player PB battles the player PA instead of the recapture event is the same procedure as in the first embodiment. It is also possible to execute with.

  When the recapture processing SE is started, the control device 32 specifies the player PA of the identification information D1 specified by the battle history information D5 of the player PB that has instructed the recapture event as an opponent in the recapture event (SE1). Then, the control device 32 executes a win / loss determination process for determining win / loss between the player PA and the player PB (SE2). Specifically, like the winning / losing determination process SB6 of FIG. 7, the control device 32 determines the winning / losing between the players PA by comparing the ability information D4 of the player PA and the ability information D4 of the player PB.

  When the player PB has won the player PA in the win / loss determination process SE2 (SE3: YES), the control device 32 executes an item management process for giving a recapture item to the player PB (SF). Specifically, the item management process SF includes a process SF1 for giving a recapture item specified by the identification information QB of the battle history information D5 to the player PB, and a target item specified by the identification information QA of the battle history information D5. And the process SF2 to be removed from the owned items. Specifically, the control device 32 increases the owned number K corresponding to the recapture item identification information Q in the owned item information D2 of the player PB (SF1), and the target item of the owned item information D2 of the player PA. The owned number K corresponding to the identification information Q is decreased (SF2).

  For example, a situation is assumed in which the target item X-6 is given to the player PA and the corresponding item Y-6 is removed from the owned item of the player PB in the past battle event as illustrated in FIG. When the player PB wins in the recapture event, the corresponding item Y-6 removed in the past battle event is given to the player PB as a recapture item (SF1), and the target item X-6 is acquired from the owned item of the player PA. Removed (SF2). That is, the recapture item Y-6 is given to the player PB in exchange for the target item X-6 of the player PA. In other words, the target item X-6 of the player PA is converted to the recapture item Y-6 and then the player PB is transferred. As understood from the above description, the control device 32 executes the item management process SF to give the player PB the recaptured item removed from the owned item of the player PB in the past battle event, and at the battle event, the player An element (management unit) for removing the target item assigned to PA from the owned item of player PA is realized.

  When the item management process SF is completed, the control device 32 notifies the player PB of the result of the battle with the player PA (SE4). For example, when the player PB wins in the win / loss determination process SE2, the control device 32 indicates that the recapture item has been acquired from the player PA by winning the recapture event, similarly to the game image 55 illustrated in FIG. The image is displayed on the display device 26 of the terminal device 12 of the player PB. The above is a specific example of the recovery process SE.

  In the second embodiment, the same effect as in the first embodiment is realized. Moreover, in 2nd Embodiment, since it is possible to recapture by the recapture event the item captured by the opponent player in the past battle event, there exists an advantage that the interest property of a game improves.

<Modification>
Each of the above-described embodiments can be variously modified. Specific modifications are exemplified below. Two or more modes arbitrarily selected from the following examples can be appropriately combined within a range that does not contradict each other.

(1) In each of the above embodiments, the configuration in which each player arbitrarily selects the scenario S has been exemplified. However, the selection scenario S of each player is automatically determined (that is, without taking into account the intention of each player). Is also possible. Further, in each of the above-described embodiments, the configuration in which the selection scenario S of each player is changed at any time is illustrated, but a configuration in which the selection scenario S of each player is fixed (a configuration in which the change of the scenario S is not permitted) may be employed. .

  In each of the above-described forms, the attribute associated with each player is not limited to the scenario S exemplified in each of the above-described forms. For example, it is also possible to give an item corresponding to the attribute to each player by a search event, for example, with the attribute (race or occupation) of the character representing the player as an attribute. As understood from the above description, the item management process SB8 in FIG. 7 is directed to the player PA associated with the first attribute (for example, the scenario SX) and the target of the type (for example, the item group GX) corresponding to the first attribute. While giving an item, the item of the type (for example, item group GY) corresponding to the said 2nd attribute is removed from the possessed item of the player PB with which the 2nd attribute (for example, scenario SY) different from a 1st attribute was linked | related. It is included as processing to do.

  Note that the correspondence between each item group G (item) and the attribute of the player is not an essential requirement of the present invention, and the configuration in which the attribute is associated with each player may be omitted. As understood from the above description, the item management process SB8 in FIG. 7 gives the first item (the target item in the above example) to the player PA and the second item different from the first item (the above example). Then, the corresponding item) is included as a process of removing the item from the possessed item of the player PB. It does not matter whether the first item and the second item are elements of a common item group G or different items.

(2) In each of the above embodiments, the player PA instructing the execution of the battle event selects the desired player PB from the N candidate players as the opponent, but the selection of the opponent by the player PA may be omitted. For example, it is also possible for the control device 32 to automatically identify an opponent player PB that satisfies a predetermined condition (that is, without taking into account the intention of the player PA). That is, the process of extracting N candidate players can be omitted.

(3) In each of the above-described embodiments, the specific item is removed from the player's owned item by reducing the number of possessions K of each item in the owned item information D2, but the specific item is removed from the owned item of each player. The method for this is changed as appropriate. For example, in a configuration in which the identification information Q is registered in the owned item information D2 for each owned item of the player, the item can be removed from the owned item by deleting the item identification information Q from the owned item information D2. . It is also possible to remove the item from the owned item by changing the flag added to the identification information Q of each item in the owned item information D2 from the valid state to the invalid state.

(4) In each of the above-described embodiments, the case where N candidate players including both the player who owns the target item and the player who does not own the target item is extracted. However, the player who owns the target item and the target It is also possible to present a player who does not own an item as a candidate player to the player PA. For example, when the number M of players who own the target item is less than a predetermined number N (SC2: YES), a configuration in which N players who do not own the target item are extracted as candidate players is also employed.

DESCRIPTION OF SYMBOLS 100 ... Game system, 12 ... Terminal device, 14 ... Game device, 16 ... Communication network, 20 ... Control device, 22 ... Storage device, 24 ... Communication device, 26 ... Display device, 28 ... ... Input device, 32 ... Control device, 34 ... Storage device, 36 ... Communication device.

Claims (11)

A game device that provides a game in which each player collects a plurality of items divided into a plurality of types,
A specifying unit for specifying a second player who is an opponent of the first player in a first event for the first player to acquire an item of the first type among the plurality of types;
A management unit for giving the first type of item to the first player in the first event and removing a second type of item different from the first type from the possessed item of the second player; Game device provided. A game device that provides a game in which an item of a type corresponding to an attribute associated with each player among a plurality of attributes is collected by the player,
The management unit assigns the first type item corresponding to the first attribute to the first player associated with the first attribute among the plurality of attributes in the first event, and The game device according to claim 1, wherein the second type item corresponding to the second attribute is removed from items owned by the second player associated with a second attribute different from the one attribute. Each of the plurality of types includes a plurality of items corresponding to each other between attributes,
The management unit provides the first player associated with the first attribute with one item selected by the first player among the plurality of items of the first type, and the plurality of the second type. The game apparatus according to claim 2, wherein an item corresponding to the one item is removed from items owned by the second player associated with the second attribute. The specifying unit presents, to the first player, a plurality of candidate players including a player who does not own the first type item as candidates for a partner from which the first player acquires the first type item, The game device according to any one of claims 1 to 3, wherein a player selected by the first player from a plurality of candidate players is specified as the second player. When there is a predetermined number of players who own the first type of item, the specifying unit presents the players as the candidate players to the first player, and the predetermined unit owns the first type of item. If the player does not exist, the player who does not own the item of the first type is presented to the first player as the candidate player,
In the first event, when the second player owns the first type of item, the management unit removes the item from the owned item of the second player, and the second player The game device according to claim 4, wherein when the item of the type is not owned, the item of the second type is removed from the item owned by the second player. The game device according to claim 5, wherein the specifying unit extracts, as the candidate player, a player that satisfies a predetermined candidate extraction condition other than whether or not the first type item is owned. The game device according to claim 2, wherein the management unit presents the first player to the second player as an opponent who has acquired the second type of item from the second player. In a second event in which the second player recaptures an item from the first player,
The management unit provides the second player with the second type item removed from the items owned by the second player at the first event, and grants the first player to the first player at the first event. The game device according to any one of claims 1 to 7, wherein the item of the first type is removed from the possessed item of the first player. A game device for providing a game in which each player collects a plurality of items,
A specifying unit for specifying a second player who is an opponent of the first player in a first event for the first player to acquire the first item;
A game device comprising: a management unit that gives the first item to the first player in the first event and removes a second item different from the first item from the possessed items of the second player. . In order to provide a game in which each player collects a plurality of items divided into a plurality of types, a computer is provided.
A specifying unit for specifying a second player who is an opponent of the first player in a first event for the first player to acquire an item of the first type among the plurality of types; and
In the first event, the first type item is given to the first player, and the second type item different from the first type is removed from the possessed item of the second player. Program to make. A method for providing a game in which each player collects a plurality of items divided into a plurality of types by a computer,
Identifying a second player who is the opponent of the first player in a first event for the first player to acquire an item of the first type among the plurality of types,
A game method in which, in the first event, the item of the first type is given to the first player, and the item of the second type different from the first type is removed from the owned item of the second player.

Images