JP7540720B2 - GAME PROGRAM, GAME PROCESSING METHOD, AND GAME SYSTEM - Google Patents

Description

The present invention relates to a game program, a game processing method, and a game system.

There are competitive games in which teams play offense and defense against each other (see, for example, Patent Document 1). For example, competitive games include so-called tower defense games in which a defending user plays against an attacking user using a game stage created by the defending user.

JP 2015-131036 A

In a competitive game in which players compete using game stages created by users, the difficulty level of the created game stage may not be appropriate, or may be intentionally set too high. As a result, other users who play using such a game stage may become dissatisfied with that game stage.

One of the objectives of some aspects of the present invention is to provide a game program, a game processing method, and a game system that reduces user dissatisfaction with game stages in a competitive game in which players compete using game stages created by users.

Another aspect of the present invention is to provide a game program, a game processing method, and a game system that can achieve the effects described in the embodiments described below.

In order to solve the above-mentioned problems, one aspect of the present invention is a game program that executes a process of matching opponents in a competitive game in which an attacking user and a defending user play against each other using game stages created by the defending user, the defending user being able to create a plurality of game stages, and the game program causes a computer to execute the steps of: determining, by a matching method selected from a plurality of matching methods that have different ranges of users to be matched, which of the plurality of game stages is usable for the competitive play; and matching the defending user who plays the competitive play using one of the determined usable game stages with the attacking user.

Another aspect of the present invention is a game processing method executed by a computer that executes a process of matching opponents in a competitive game in which an attacking user and a defending user play against each other using game stages created by the defending user, the game processing method including a step of determining, by a matching method selected from a plurality of matching methods that are different in the range of users to be matched, a game stage that is usable for the competitive play among the plurality of game stages, and a step of matching the defending user who plays the competitive play using one of the determined usable game stages with the attacking user.

Another aspect of the present invention is a game system including a game device that executes a process for a competitive game in which an attacking user and a defending user play against each other using a game stage created by the defending user, and a game server that executes a process for matching opponents in the competitive game, in which the defending user is capable of creating a plurality of game stages, and the game server includes a stage determination unit that determines which of the plurality of game stages is usable for the competitive play by a matching method selected from a plurality of matching methods that have different ranges of users to be matched, and a matching unit that matches the defending user who plays the competitive play using one of the determined usable game stages with the attacking user.

1 is a schematic block diagram showing an example of the configuration of a game system according to a first embodiment. FIG. 4 is a diagram showing an example of a game screen according to the first embodiment. 6A and 6B are diagrams showing an example of notification of a remaining state of a treasure chest according to the first embodiment; FIG. 4 is a diagram showing an example of a game stage creation screen according to the first embodiment. FIG. 13 is a diagram showing an example of a selection screen for an initial setting game stage according to the first embodiment. FIG. 1 is a block diagram showing an example of a hardware configuration of a game device according to a first embodiment. FIG. 2 is a block diagram showing an example of a hardware configuration of a game server according to the first embodiment. FIG. 2 is a block diagram showing an example of the functional configuration of a game device and a game server according to the first embodiment. 13 is a flowchart showing an example of a key acquisition process by an attacking user according to the first embodiment. 13 is a flowchart showing an example of a treasure chest acquisition process by an attacking user according to the first embodiment. 13 is a flowchart showing an example of a battle play start and end process for an attacking user according to the first embodiment. 13 is a flowchart showing an example of a battle play start and end process for a defending user according to the first embodiment. FIG. 13 is a diagram showing an example of a selection screen for a matching method according to the second embodiment. FIG. 11 is a diagram showing an example of a matching method according to the second embodiment. FIG. 13 is a diagram showing an example of a room selection screen according to the second embodiment. 13A to 13C are diagrams showing examples of constraint conditions for a game stage according to each matching method according to the second embodiment; FIG. 11 is a diagram showing an example of the functional configuration of a matching processing unit according to a second embodiment. 13 is a flowchart showing an example of a match request transmission process according to the second embodiment. 13 is a flowchart showing an example of a matching process according to the second embodiment.

Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
[First embodiment]
First, a first embodiment of the present invention will be described.
FIG. 1 is a schematic block diagram showing an example of the configuration of a game system 1 according to this embodiment. The game system 1 includes a plurality of game devices 10 (10-1, 10-2, 10-3, ...) and a game server 30. The plurality of game devices 10 and the game server 30 are communicatively connected via a network NW. Since the game devices 10-1, 10-2, and 10-3 have the same configuration, when there is no particular need to distinguish between them, the descriptions will be omitted, such as "-1" and "-2," and will be described as "game device 10." Here, three game devices 10 are illustrated, but any number of game devices 10 may be communicatively connected to the game server 30 via the network NW.

The game device 10 is a computer device that allows a user to play a game by operating it, and may be, for example, a home game machine (a stationary or portable game machine), a PC (Personal Computer), a tablet PC, a mobile phone such as a smartphone or feature phone, a personal digital assistant (PDA), or a commercial game machine installed in a game center, etc.

The game server 30 stores and manages user information for each user who plays a game using each of the multiple game devices 10. In addition, the game server 30 executes a process of matching opponents when multiple users play a competitive game through communication using their respective game devices 10 (hereinafter referred to as a "matching process"). For example, a user who plays using game device 10-1 and a user who plays using game device 10-2 are matched as opponents, allowing the competitive game to be played via the network NW. Note that the matching of opponents is not limited to one-to-one matching, and may be one-to-many or many-to-many matching.

The network NW is a communication network such as the Internet, a mobile phone network, a VPN (Virtual Private Network), a dedicated communication line network, a WAN (Wide Area Network), a LAN (Local Area Network), a PSTN (Public Switched Telephone Network), or a combination of these.

In addition, the game device 10 can also play a competitive game by directly communicating with other game devices 10 via a P2P (Peer to Peer) connection or the like.

[Game Overview]
Next, an example of a game played by a user using the game device 10 according to the present embodiment will be described. The game according to the present embodiment is, for example, a battle game between one defending user and multiple (e.g., 10) attacking users. In the battle play of this battle game, the defending user and the attacking user move their respective characters within a game stage based on their respective operations, destroy obstacles within the game stage, and attack the opponent using bombs to progress through the game.

The game stage includes a game field (game space) in which characters move and attack based on the play operations of the defending user and the attacking user. The game field is, for example, a virtual space having three-dimensional information, but may also be a two-dimensional virtual space. Within the game field, there are arranged limiting objects (e.g., blocks) that limit the movement of the characters, as well as game objects and items that users can obtain using their characters. The game stage also includes game rules such as the time limit for play in a competitive game. In other words, the game stage includes the elements necessary for executing a competitive game.

The game stage used in the battle game may be one created by the defending user. Note that the game stage used in the battle game may be one that is prepared in advance for the battle game, or a part of a prepared game stage that has been modified by the defending user.

Characters are people, animals, objects (e.g., vehicles) that appear in the game, and in this fighting game, for example, a warrior that is the target of operation by the user. Based on the user's operation, it is possible to move the target character within the game field, attack using the character, and obtain various game objects and items placed in the game field using the character. The defending user controls the defending user's character, and the attacking user controls the attacking user's character. Note that the characters that appear in the game may include NPCs (Non Player Characters) controlled by the game device 10 (computer).

Figure 2 is a diagram showing an example of a game screen displayed by the game device 10 according to this embodiment. The illustrated game screen G10 displays a game field GF of a game stage where users play against each other in a competitive game. For example, the game screen G10 displays a partial area of the game field GF during competitive play, and a map MA corresponding to the entire area of the game field GF. Which area of the game field GF is displayed on the game screen G10 is controlled for each game device 10 so that the position within the game field GF of the character played by the user is included. Also, which area of the game field GF is displayed on the game screen G10 is indicated by a rectangular area CA on the map MA.

In the example shown in this figure, the game screen G10 displays one defending user's character DC and three attacking user's characters AC1, AC2, and AC3 among the characters present in the game field GF. For example, the game screen G10 shown in this figure is an example of a game screen displayed on a game device 10 played by an attacking user who controls character AC1.

Blocks BL that restrict the movement of the character are placed within the game field GF. The blocks BL are placed as obstacles that restrict the movement of the character, and are, for example, objects in the shape of a right cube, but may be objects of any shape. For example, the blocks BL include soft blocks and hard blocks. Soft blocks are destroyed and disappear when a bomb BM explodes. When a soft block is destroyed and disappears, the character becomes able to move to the location where the soft block was placed. On the other hand, hard blocks are not destroyed by the blast of a bomb BM.

In addition, multiple treasure chests are placed within the game field GF. The treasure chest is an example of a game object that is placed within the game field GF, and is a specific game object that affects the outcome of a battle play. A treasure chest icon TR indicating the location where the treasure chest is placed is displayed on the map MA of the game screen G10. The attacking user moves their character in a direction approaching the treasure chest while referring to the position of the treasure chest icon TR on the map MA, and when the location where the treasure chest is placed enters the area of the game field GF displayed on the game screen G10, the treasure chest will also be displayed within the game field GF.

In this example, five treasure chests are placed in one location within the game field GF. Note that the number of treasure chests is not limited to five, and may be one or any multiple number. The location in which they are placed is also not limited to one, and for example, multiple treasure chests may be placed in different locations.

In addition, although the competitive game according to this embodiment is played by multiple players, it is essentially an individual match. For example, multiple attacking users each operate a character in the same game field GF to compete against a defending user, but at the same time, the attacking users are opponents rather than allies. Therefore, the blast of a bomb BM set off by an attacking user affects (damages) not only the characters of the defending users, but also the characters of other attacking users. Because it is an individual match, even if there are multiple players, there is no need for cooperation or consultation with other users as allies, and players can easily participate in the competitive game.

A maximum number of players is set for each of the attacking and defending sides (e.g., 10 attackers, 1 defender, etc.). Defensive users include users who have created game stages to be used in match-up play. A predetermined time limit (e.g., 10 minutes) is set for each game stage, and match-up play takes place within this time limit. Time limit information TL indicating the time remaining until the time limit is displayed on the game screen G10, and a countdown continues from the start of match-up play until the time limit is reached.

(Victory and defeat conditions for the attacking and defending sides)
The victory condition for the attacking user is to obtain one of the multiple (e.g., five) treasure chests placed within the game field GF. The attacking user can obtain a treasure chest by moving the character that is the object of his/her control to the location where the treasure chest is located. Note that the attacking user may obtain the treasure chest by moving his/her character to the location where the treasure chest is located, and then performing an operation to open the treasure chest and obtain its contents. In other words, obtaining a treasure chest includes obtaining the contents of the treasure chest.

When the attacking user obtains the treasure chest, they have fulfilled the victory conditions at that point, and are declared victorious (or their victory is confirmed), and the battle ends. Meanwhile, the other attacking users continue the battle until the victory conditions are fulfilled or the time limit is reached. For example, if there are five treasure chests, there can be a maximum of five winners among the attacking users. If an attacking user fails to obtain the treasure chest within the time limit, they have fulfilled the defeat conditions, and are declared losers, and the battle ends. In other words, an attacking user who is able to obtain the treasure chest within the time limit is declared victorious (winner), and an attacking user who fails to obtain the treasure chest within the time limit is declared defeated (loser).

In addition, an attacking user who meets the processing conditions may be awarded a reward corresponding to a victory. The reward awarded may be, for example, the contents of a treasure chest obtained by the attacking user who met the processing conditions.

The attacking user who obtains the treasure chest becomes the winner at that point (or their victory is confirmed) and ends the match-up. The attacking user who has ended the match-up cannot subsequently participate in the match-up, but may be able to watch the match-up.

The winning condition for the defending user is to protect the treasure chests from the attacking user until the time limit is reached. If all of the multiple treasure chests are acquired (stolen) by the attacking user, the defeat condition is met and the defending user loses (becomes the loser); however, this is not limited to this and defeat may also occur when a predetermined number or a predetermined percentage of the multiple treasure chests are stolen. If the defending user maintains a state where the above defeat condition is not met until the time limit is reached, the defending user will have satisfied the victory condition and will be victorious (become the winner).

In this way, the outcome of the battle between the attacking user and the defending user is determined based on the acquisition status of the treasure chests placed within the game field GF by the attacking user, in other words, based on the remaining status of the treasure chests that have not been acquired by the attacking user.

The defending user is basically the single user who created the game stage used in play, but there may be multiple defending users. Even if there are multiple defending users, the user who created the game stage used in play will always be included.

In addition, if there are multiple defending users, the defending side may play as a team, or the outcome of the defending side may be determined on a team basis. Even in this case, the attacking side must play as an individual.

In addition, if the character operated by the attacking user has parameters such as HP (Hit Points) set, and the rules of the game are such that the attacking user who operates that character loses when the HP reaches zero, the defending user may be declared the winner (have fulfilled the victory conditions) when the HP of all attacking users' characters reaches zero.

(Game End Conditions)
The end condition of the competitive game is that all treasure chests are acquired by the attacking user before the time limit, or the time limit has elapsed. When the end condition of the competitive game is met, the competitive play of all users ends, and the competitive game ends.

If parameters such as HP are set for characters, the end condition for the battle game may be that the number of surviving characters (characters whose HP is not zero) of the defending or attacking user reaches zero.

(Items required to obtain treasure chests)
In order for the attacking user to obtain the treasure chest, he or she needs a "key," which is an item necessary for obtaining the treasure chest. The key is placed somewhere in the game field GF so that the attacking user can obtain it. The attacking user cannot obtain the treasure chest unless he or she has the key, so the attacking user must first obtain the key.

The location of the key is shown, for example, approximately on a map MA displayed on the game screen G10, and the attacking user uses this information to find the key. A key mark is displayed on the character who has the key, and the key is also displayed on the map MA. Alternatively, the location of the key may be made unknown to the attacking user in the initial state at the start of battle play. The key may be made to appear when the attacking user destroys an obstacle such as a block (e.g., a soft block) at the location of the key with the blast of a bomb BM or the like. In this way, it is possible to add a game element of searching for the key.

Note that the location of the key within the game field GF may be indicated by an icon on the map MA, just like the treasure chest.

The attacking user can obtain the key by moving the character that he or she controls to the location where the key is located. The attacking user may also obtain the key by moving his or her character to the location where the key is located, and then performing an operation to pick up and obtain the key. This increases the number of elements to conquer the game stage, as the attacking user no longer simply has to head to the location of the treasure chest.

Once an attacking user has acquired a key, they may maintain possession of the key, or attacking users may be allowed to compete for the key with each other. For example, when a character of another attacking user who is in possession of a key is damaged by the blast of a bomb BM, ownership of the key may be transferred to the character of the attacking user who caused the damage. Also, when a character of another attacking user who is in possession of a key is damaged by the blast of a bomb BM, the character in possession of the key may be dropped onto the game field GF. The dropped key may be available to attacking users on a first-come, first-served basis.

Note that the defending user may also be able to use a bomb BM to take back the key from the attacking user. When the defending user takes the key back, the key will be placed somewhere within the game field GF. The location where the key is placed may be one of the pre-set locations, or it may be any location within the game field GF.

Note that if parameters such as HP are set for the character controlled by the attacking user, and the game has rules that allow a character whose HP reaches zero to respawn (die and restart from a specified position), the character may lose the key when its HP reaches zero, and the key may be dropped at the position where its HP reached zero.

When an attacking user who has a key obtains a treasure chest, the key disappears. The number of keys placed within the game field GF can basically be the same as the number of treasure chests, but there can also be more keys than treasure chests. Having more keys than treasure chests makes it easier to obtain the keys.

In addition, even if an attacking user who has a key obtains a treasure chest, the key does not disappear and may be dropped onto the game field GF. In this case, the relationship between the number of keys and treasure chests may be the opposite of the relationship described above, and there may be fewer keys than there are treasure chests. Reducing the number of keys increases the difficulty of obtaining them, as they will lead to scrambling for them.

The number of keys placed within the game field GF is determined to be an initial number (e.g., three) at the start of the match-up, and new keys may be placed and added based on additional conditions based on the passage of time (e.g., five minutes after the start of the match-up) or additional conditions based on the progress of the match-up (e.g., all three initial keys have been used and disappeared). The number of keys that can exist simultaneously within the game field GF may also be limited (e.g., limited to two). Limiting the number of keys that exist simultaneously can encourage attacking users to compete for keys.

(Notification of remaining treasure chest status)
When the attacking user acquires a treasure chest and there is a change in the remaining status of the treasure chests within the game field GF, the user playing the match may be notified of this, as shown in FIG.
Fig. 3 is a diagram showing an example of a notification of the remaining status of treasure chests according to this embodiment. The game screen G11 shown in this figure notifies that the number of treasure chests remaining in the game field GF has decreased from five to four as a result of one of the attacking users acquiring a treasure chest during the battle play on the game screen G10 shown in Fig. 2. The game screen G11 displays text information and pictures of four treasure chests as information indicating that there are only four treasure chests remaining.

(Creating a game stage)
A user can create a game stage to be used in a match-up. A user can use a game stage that he or she has created when participating in a match-up as a defending user. In other words, a user creates a game stage that assumes that the user will play against an attacking user as a defending user. Creating a game stage includes creating a game field GF in which the match-up will take place and setting the game rules.

Figure 4 is a diagram showing an example of a game stage creation screen according to this embodiment. The initial setting game field GF is displayed in the center of the illustrated game stage creation screen G20. Here, a schematic rectangular game field GF is displayed, but it may be of any shape, or only a partial area of the game field GF may be displayed.

The icons lined up on the left side of the game field GF are operation buttons for selecting objects that can be placed in the game field GF. The user selects one of these icons to place the object at any position in the game field GF. Icons B11 and B12 are operation buttons for selecting blocks that the character cannot enter, with icon B11 being a soft block and icon B12 being a hard block. Icon B13 is an operation button for selecting a weapon such as a cannon for attacking the attacking character. Icon B14 is an operation button for selecting an NPC for attacking the attacking character. Like objects, NPCs can be placed in the game field GF. Icon B15 is an operation button for selecting a trap to set against the attacking character. Icon B16 is an operation button for selecting a block where an item that improves the character's abilities will appear.

When any of the icons is selected, a description of the object that will be placed with the selected icon is displayed below the game field GF. In the example shown, icon B11 has been selected and a description of the soft block is displayed. The objects that can be placed on the game field GF are not limited to the above examples and can include any object.

For example, the user selects an object to be placed in the game field GF from among icons B11 to B16, and then moves the cursor CS to the desired position in the game field GF to confirm the placement. Operations such as icon selection, cursor CS movement, and placement confirmation can be performed using operation buttons provided on the game device 10 or operation buttons on a controller connected to the game device 10.

In addition, icon B17 is an operation button for switching menus. When icon B17 is selected, the menu for selecting currently displayed icons B11 to B16 and placing them on the game field GF is switched to another menu (for example, a menu for setting game rules).

In addition, icon B18 is an operation button for selecting a test play. After creating a game stage, the user can perform a test play by selecting this icon B18.

Note that multiple initial settings are set in advance as a base for creating a game stage, and the user may create a game stage based on a game stage selected from the multiple initial settings.

FIG. 5 is a diagram showing an example of a selection screen for a default game stage according to this embodiment. The illustrated game stage selection screen G21 displays a plurality of base game stages that can be selected. Each of the icons B21, B22, B23, B24, ... is associated with a base default game stage. The default game stage (e.g., "Stage A") associated with a selected icon among the icons B21, B22, B23, B24, ... is displayed above these icons. When the user performs an operation to confirm the selection in this state, the base default game stage is determined, and the screen transitions to a game stage creation screen G20 (FIG. 3) in which the game field GF of the determined game stage is displayed. Operations such as icon selection and game stage determination can be performed using operation buttons provided on the game device 10 or operation buttons on a controller connected to the game device 10.

When creating a game stage, game rules such as the time limit, the number of opponents (e.g., the number of attacking users), the number of treasure chests, and the number of keys can be set. When creating a game stage as a defending user, the difficulty level of that game stage for the attacking user can be changed by changing the game rule settings. For example, extending the time limit lowers the difficulty level for the attacking user, and shortening the time limit raises the difficulty level for the attacking user. The number of opponents is a setting for the upper limit of the number of attacking users. Also, the number of treasure chests and the number of keys can be set arbitrarily. For example, when selecting an initial setting game stage, the locations of the treasure chests and the keys are preset in the selected game stage. The locations are fixed, but the numbers can be set freely. The locations of the treasure chests and the keys may also be set arbitrarily.

(Uploading game stages)
When a competitive game is played using a game stage created by a user, the created game stage may be uploaded to the game server 30 in advance, or data of the game stage may be transmitted from the game device 10 of the defending user to the game device 10 of the attacking user when the competitive game is played. Also, only game stages that have cleared a test play (game stages that have been won in a test play by the attacking user) may be made uploadable. In this case, the uploaded game stage may be made available to a user other than the user who created the game stage when playing a competitive game as a defending user.

[Hardware configuration of the game device]
6 is a block diagram showing an example of a hardware configuration of the game device 10 according to this embodiment. The game device 10 includes, for example, a CPU (Central Processing Unit) 11, a communication unit 12, an input unit 13, a display unit 14, and a storage unit 15, and communicates with a game server 30 and other devices connected via a network NW via the communication unit 12. These components are connected to each other via a bus so that they can communicate with each other. The CPU 11 executes various programs such as a game program stored in the storage unit 15, and controls each unit of the game device 10.

The communication unit 12 communicates game data and the like with the game server 30 and other devices via the network NW based on the control of the CPU 11. The communication unit 12 may also communicate game data and the like with other game devices 10 using short-range wireless communication, etc.

The input unit 13 includes a plurality of operation buttons through which user operations are input, and outputs the input operation information to the CPU 11. Note that the input unit 13 may be other input devices, such as a touch panel integrated with a display, a controller provided with a plurality of operation buttons, a keyboard, a mouse, a touchpad, or a microphone through which various instructions are input by voice. The input unit 13 may also be a controller connected to the game device 10.

The display unit 14 is configured to include, for example, a liquid crystal display panel, an organic EL (ElectroLuminescence) display panel, etc. For example, the display unit 14 displays various game screens in the above-mentioned competitive game. The display unit 14 may be an external display device such as a television or monitor.

The storage unit 15 includes, for example, a hard disk drive (HDD), a solid state drive (SSD), an electrically erasable programmable read-only memory (EEPROM), a read-only memory (ROM), a random access memory (RAM), etc., and stores game programs, game data, etc. Note that the storage unit 15 is not limited to being built into the game device 10, but may also include an external storage device connected via a digital input/output port such as a USB.

The game device 10 may be configured to include hardware components such as a speaker, an audio output terminal, a camera, a gyro sensor, and a GPS (Global Positioning System) receiving module (not shown).

[Game server hardware configuration]
7 is a block diagram showing an example of a hardware configuration of the game server 30 according to this embodiment. The game server 30 includes, for example, a CPU 31, a communication unit 32, an input unit 33, and a storage unit 35, and communicates with a plurality of game devices 10 and other devices connected via a network NW via the communication unit 32. These components are connected to each other via a bus so that they can communicate with each other. The CPU 31 executes various programs stored in the storage unit 35 and controls each unit of the game server 30.

The communication unit 32 communicates with a plurality of game devices 10 and other devices via the network NW under the control of the CPU 31 .
The input unit 33 is, for example, a keyboard, a mouse, a touch pad, a microphone for inputting various instructions by voice, or other input devices.

The storage unit 35 includes, for example, a HDD, an EEPROM, a RAM, and the like, and stores the game control program, the application program, various setting information and history information necessary for the game, and the like. Note that the storage unit 35 is not limited to being built into the game server 30, and may include an external storage device connected via a digital input/output port such as a USB. The storage unit 35 may also be an external storage device physically separated from the game server 30, or may be connected to the game server 30 via a network NW. The game server 30 may also be configured to include hardware components such as a display unit, a speaker, and an audio output terminal (not shown).

[Functional configuration]
Next, the functional configurations of the game device 10 and the game server 30 included in the game system 1 will be described with reference to FIG.
FIG. 8 is a block diagram showing an example of the functional configuration of the game device 10 and the game server 30 according to the present embodiment.

[Functional configuration of the game device]
First, the functional configuration of the game device 10 will be described.
The game device 10 includes a game processing unit 110 as a functional configuration realized by the CPU 11 executing a game program stored in the storage unit 15. The game processing unit 110 controls game processing of a fighting game based on a user's operation on the input unit 13. For example, the game processing unit 110 includes a game stage management unit 111, a match request unit 112, a play progress management unit 113, a game data transfer unit 114, a character control unit 115, an acquisition management unit 116, a play management unit 117, and a display control unit 118. The storage unit 15 includes a user data storage unit 151, a game stage storage unit 152, and a possessed data storage unit 153.

The game stage management unit 111 performs processes such as the creation of game stages by users and the saving and uploading of the created game stages. For example, as described with reference to Figures 4 and 5, the game stage management unit 111 performs a process of creating a game field GF based on user operations on the game stage creation screen G20, the initial setting game stage selection screen G21, etc., and sets game rules for the game stage battle, such as the time limit, number of battles, number of treasure chests, number of keys, etc., set by the user.

The game stage management unit 111 stores data of the created game stage (game stage data) in the game stage storage unit 152. The game stage data includes a game stage ID as identification information for identifying the game stage, information on the base game stage (e.g., stage A), placement information of objects and items in the game field GF, setting information of the game rules, and the like. In addition, the game stage management unit 111 permits uploading of game stages that have been cleared in a test play, and when an upload request is made by a user, the game stage management unit 111 associates the user ID as identification information of the user (creator) who created the game stage with the game data, and uploads the data to the game server 30 via the communication unit 12. Note that user information (user ID, user name, etc.) of the user playing on the game device 10 is stored in the user data storage unit 351.

When a user participates in a competitive game, the match request unit 112 transmits a match request to the game server 30 via the communication unit 12 based on the user's operation. At this time, the user selects whether to participate in the competitive game as the defending side or the attacking side. When the user participates as the defending side, the match request unit 112 selects a game stage to be used in the match from among the game stages that the user created. When transmitting a match request to participate as the defending side, the match request unit 112 associates the game stage data of the selected game stage with the match request as the defending side and transmits them to the game server 30. When transmitting a match request to participate as the attacking side, the match request unit 112 transmits the match request as the attacking side to the game server 30.

In response to the match request sent by the match request unit 112 to the game server 30, the game server 30 performs matching processing between the defending user and the attacking user. When the matching result is obtained from the game server 30, the play progress management unit 113 executes processing to start match play. In addition, when match play starts, the play progress management unit 113 counts the elapsed time from the start of match play and manages the time limit for match play.

The game data transfer unit 114 transfers game data of users participating in the match-up play. The game data transfer unit 114 transmits play data of the user playing on this game device 10 (information on the character's position, the position of the bomb BM, the acquisition of treasure chests and keys, etc.) to the other game devices 10 via the game server 30. The game data transfer unit 114 also acquires play data of users playing on the other game devices 10 from the other game devices 10 via the game server 30. This allows the play status of the users participating in the match-up play to be shared between each game device 10, and the status of the match-up play can be synchronized.

In a battle play of a battle game, the character control unit 115 moves each character of multiple attacking users based on their respective operations within the game field GF created by the defending user. For example, the character control unit 115 moves the character of the attacking user playing on its own game device 10 based on the operation of the attacking user. On the other hand, the character control unit 115 moves the character of the attacking user playing on another game device 10 based on the operation of the attacking user, based on play data acquired by the game data transfer unit 114 from the other game device 10 via the game server 30.

In addition, in a battle play in a battle game, when the user playing on one's own game device 10 is a defending user, the character control unit 115 moves the character of the defending user based on the operation of the defending user. On the other hand, when the user playing on another game device 10 is a defending user, the character control unit 115 moves the character of the defending user based on the operation of the defending user, based on the play data acquired by the game data transfer unit 114 from the other game device 10 via the game server 30.

When one of the characters of the attacking user reaches a key placed within the game field GF, the acquisition management unit 116 causes the attacking user operating that character to acquire the key that the character has reached. For example, the acquisition management unit 116 causes the attacking user to acquire the key by having the character of the attacking user move to the position of the key placed within the game field GF, or by having the character move and then perform an operation to pick up and acquire the key.

The acquisition management unit 116 may allow an attacking user to acquire a key that has already been acquired by another attacking user. For example, the attacking user can acquire a key by causing damage to the character of another attacking user who has already acquired a key, such as by using the blast of a bomb BM to cause the character to drop the key. The acquisition management unit 116 allows the attacking user to acquire the key by having the attacking user's character move to the position of the key dropped by the other attacking user, or by having the character move and then perform an operation to pick up and acquire the key.

In addition, when one of the attacking user's characters reaches a treasure chest located within the game field GF, the acquisition management unit 116 causes the attacking user operating that character to acquire the treasure chest that the character has reached. For example, the acquisition management unit 116 causes the attacking user to acquire the treasure chest by one of the attacking user's characters moving to the position of the treasure chest located within the game field GF, or by performing an operation to acquire the contents of the treasure chest after the character has moved.

Here, the acquisition management unit 116 sets the condition for acquiring a treasure chest as having already acquired a key. Specifically, when one of the characters of an attacking user who has acquired a key reaches one of the multiple treasure chests placed within the game field GF, the acquisition management unit 116 allows the attacking user operating that character to acquire the treasure chest that the character reaches. On the other hand, even if the character of the attacking user who has not acquired a key reaches the treasure chest, the acquisition management unit 116 does not allow the attacking user to acquire the treasure chest.

The acquisition management unit 116 also stores the treasure chest and key data acquired by the attacking user in the possessed data storage unit 153 in association with the user ID as possessed data of the user.

The play management unit 117 ends the match play of an attacking user among the multiple attacking users who has acquired a treasure chest, as the victory condition has been met. On the other hand, the play management unit 117 allows the match play of other attacking users other than the attacking user who has acquired the treasure chest to continue. Furthermore, each time another attacking user acquires a treasure chest, the play management unit 117 ends only the match play of the attacking user who has acquired the treasure chest, as the victory condition has been met. Then, when all of the multiple attacking users have acquired a treasure chest before the time limit has elapsed, the play management unit 117 ends all match play of the attacking users as the victory condition has been met. On the other hand, the play management unit 117 ends the match play of an attacking user who has not acquired a treasure chest before the time limit has elapsed as the defeat condition has been met.

If the remaining status of treasure chests that have not been acquired by the attacking user is maintained so as not to reach a predetermined remaining status (e.g., zero remaining treasure chests) from the start of the match-up until the time limit has elapsed, the play management unit 117 determines that the victory condition for the defending user has been met, and ends all match-ups between the defending user and the attacking user (the attacking user who is continuing the match-up at that point). If all of the multiple attacking users have acquired treasure chests before the time limit has elapsed, the play management unit 117 determines that the defeat condition for the defending user has been met, and ends the match-up.

The play management unit 117 may award a reward corresponding to the victory to an attacking user who acquires a treasure chest and fulfills the victory conditions. For example, the play management unit 117 stores reward acquisition information in the user data storage unit 151, which associates information indicating the contents of the treasure chest acquired by the attacking user with the user ID of the attacking user. Furthermore, when the play management unit 117 stores the reward acquisition information in the user data storage unit 151, the game data transfer unit 114 transmits this reward acquisition information to the game server 30 and stores it in the user data storage unit 351 as well.

The display control unit 118 generates drawing data for the images to be displayed on the game screen in the competitive game and displays it on the display unit 14. For example, the game screen includes various game screens such as the game screen G10 in FIG. 2, the game screen G11 in FIG. 3, the game stage creation screen G20 in FIG. 4, and the game stage selection screen G21 in FIG. 5.

The game processing unit 110 also executes various other game processes. For example, the game processing unit 110 controls the placement of a bomb BM based on an operation by an attacking user or a defending user to set off a bomb BM, and controls the explosion of the bomb BM to cause damage to characters within a specified range due to the blast (for example, reducing HP).

The game processing unit 110 may also place a new key within the game field GF based on a specified additional condition. For example, the game processing unit 110 may place and add a new key within the game field GF based on a condition based on the passage of time from the start of the match-up play (e.g., five minutes after the start of the match-up play) or an additional condition based on the progress of the match-up play (e.g., all three initial keys have been used and disappeared).

[Functional configuration of game server 30]
Next, the functional configuration of the game server 30 will be described.
The game server 30 includes a server processing unit 310 as a functional configuration realized by the CPU 31 executing the game program stored in the storage unit 35. For example, the server processing unit 310 includes a server-side game processing unit 311 that executes server-side processing of the game processing of the competitive game, and a matching processing unit 314 that performs matching processing of opponents for the competitive game. The storage unit 35 includes a user data storage unit 351, a game stage storage unit 352, and a possessed data storage unit 353.

The user data storage unit 351 stores user information (user ID, user name, etc.) of multiple users (registered users) who can participate in the competitive game. The user data storage unit 351 also stores information indicating the relationships between multiple users (e.g., friend information) as user information.

The game stage storage unit 352 stores game stage data of game stages created and uploaded by users in association with the creator's user ID.

The possession data storage unit 353 stores possession data of multiple attacking users during a match. For example, the possession data storage unit 353 stores data on treasure chests and keys acquired by each attacking user during a match in association with the user ID of each attacking user.

The server-side game processing unit 311 includes a game stage management unit 312 and a game data transfer unit 313 .
The game stage management unit 312 associates the game stage data uploaded from the game device 10 with the user ID of the creator and stores them in the game stage storage unit 352. The game stage management unit 312 also provides game stages based on the stored game stage data so that they can be used in a fighting game. For example, the game stage management unit 312 may provide the uploaded game stage so that it can be used by users other than the creator.

The game data transfer unit 313 acquires game data of users participating in the match-up play from the game device 10 of each user participating in the match-up play. In addition, the game data transfer unit 313 transmits the game data of each user acquired from each game device 10 to each game device 10 participating in the match-up play. The play status of the users participating in the match-up play can be shared between each game device 10, and the status of the match-up play can be synchronized.

The matching processing unit 314 executes a matching process that matches a defending user and an attacking user who will play against each other in a competitive game. For example, when the matching processing unit 314 receives a match request sent from each game device 10 to participate in a competitive game as the defending or attacking user, the matching processing unit 314 selects a defending user and an attacking user from among the users who sent the match request, and when matching is established, transmits a matching result to the game device 10 of the matched user and starts competitive play. Details of this matching process will be described in the second embodiment.

[Game Processing Operation]
Next, the operation of the game processing executed by the CPU 11 of the game device 10 will be described.
FIG. 9 is a flowchart showing an example of a key acquisition process by an attacking user according to this embodiment.

The CPU 11 determines whether or not the attacking user has performed an operation to move the character (step S101). If the CPU 11 determines that no operation to move the character has been performed (step S101: NO), it performs the process of step S101 again. On the other hand, if the CPU 11 determines that an operation to move the character has been performed (step S101: YES), it moves the character in accordance with that operation (step S103).

Next, the CPU 11 compares the position of the character after the movement with the position of the lock (step S105). Then, based on the result of the comparison between the position of the character after the movement and the position of the lock, the CPU 11 determines whether the attacking user's character has reached the position of the lock (step S107).

If the CPU 11 determines that the attacking user's character has not reached the location of the key (step S107: NO), the process returns to step S101. On the other hand, if the CPU 11 determines that the attacking user's character has reached the location of the key (step S107: YES), the CPU 11 causes the attacking user to obtain the key and stores it as possessed data in the possessed data storage unit 153 (step S109).

Figure 10 is a flowchart showing an example of the treasure chest acquisition process by an attacking user according to this embodiment.

The CPU 11 determines whether or not an operation to move the character has been performed by the attacking user (step S201). If the CPU 11 determines that an operation to move the character has not been performed (step S201: NO), it performs the process of step S101 again. On the other hand, if the CPU 11 determines that an operation to move the character has been performed (step S201: YES), it moves the character in accordance with that operation (step S203).

Next, the CPU 11 compares the position of the character after the movement with the position of the treasure chest (step S205). Then, based on the result of the comparison between the position of the character after the movement and the position of the treasure chest, the CPU 11 determines whether or not the attacking user's character has reached the position of the treasure chest (step S207).

If the CPU 11 determines that the attacking user's character has not reached the location of the treasure chest (step S207: NO), the process returns to step S201. On the other hand, if the CPU 11 determines that the attacking user's character has reached the location of the treasure chest (step S207: YES), the CPU 11 refers to the possession data stored in the possession data storage unit 153 to determine whether the attacking user has acquired the key (step S209).

If the CPU 11 determines that the attacking user who has reached the location of the treasure chest has not acquired the key (step S209: NO), the process returns to step S201. On the other hand, if the CPU 11 determines that the attacking user who has reached the location of the treasure chest has already acquired the key (step S209: YES), the CPU 11 causes the attacking user to acquire the treasure chest and stores the treasure chest as possessed data in the possessed data storage unit 153 (step S211).

Figure 11 is a flowchart showing an example of the process for starting and ending a match-play by an attacking user in this embodiment.

Based on the user's operation, the CPU 11 sends a match request as the attacking side to the game server 30 (step S301). After sending the match request, if matching is established, the CPU 11 obtains the matching result (step S303). Then, when the CPU 11 obtains the matching result, the CPU 11 starts match play (step S305).

The CPU 11 determines whether the attacking user has acquired a treasure chest during the match play (step S307). If the CPU 11 determines that the attacking user has acquired a treasure chest (step S307: YES), it determines that the victory condition has been met and ends the match play of the attacking user who has acquired the treasure chest (step S309).

On the other hand, if the CPU 11 determines that the attacking user has not acquired the treasure chest (step S307: NO), the CPU 11 allows the attacking user to continue the match play (step S311). Then, the CPU 11 determines whether the time limit has elapsed since the start of the match play (step S313).

If the CPU 11 determines that the time limit has not elapsed (step S313: NO), the process returns to step S307. On the other hand, if the CPU 11 determines that the time limit has elapsed (step S313: YES), the CPU 11 determines that the defeat condition has been met, and ends the battle play for the attacking user who has not acquired the treasure chest (step S315).

Figure 12 is a flowchart showing an example of the process for starting and ending a match play by a defending user in this embodiment.

Based on the user's operation, the CPU 11 transmits a match request as the defending side to the game server 30 (step S401). After transmitting the match request, if matching is established, the CPU 11 obtains the matching result (step S403). Then, upon obtaining the matching result, the CPU 11 starts the match play (step S405).

The CPU 11 determines whether the remaining status of the treasure chests that have not been acquired by the attacking user in the battle play has reached a predetermined remaining status (e.g., there are no remaining treasure chests) (step S407). If the CPU 11 determines that the remaining status of the treasure chests has reached the predetermined remaining status (step S407: YES), it determines that the defeat condition has been met and ends the battle play for the defending user (step S411).

On the other hand, if the CPU 11 determines that the remaining status of the treasure chest has not reached a predetermined remaining status (step S407: NO), it determines whether or not the time limit has elapsed since the start of the battle play (step S409). If the CPU 11 determines that the time limit has not elapsed (step S409: NO), it returns to the processing of step S407.

On the other hand, if the CPU 11 determines that the time limit has elapsed (step S409: YES), it determines that the victory condition has been met and ends the battle play of the defending user (step S413).

Summary of the First Embodiment
As described above, the game system 1 according to the present embodiment includes a game device 10 and a game server 30 that communicates with the game device 10, and executes processing of a battle game between a plurality of attacking users and at least one defending user. For example, the game device 10 includes a character control unit 115, an acquisition management unit 116, and a play management unit 117. In a battle play of a battle game, the character control unit 115 moves each character in a game field GF (an example of a game space) created by a defending user based on the operation of each of the plurality of attacking users. The acquisition management unit 116 causes the attacking user who operates the character to acquire the treasure chest that the character has reached, due to the arrival of one of the characters of the attacking user to a treasure chest (an example of a specific object) located in the game field GF. The play management unit 117 ends the battle play of the attacking user who has acquired the treasure chest among the plurality of attacking users as the victory condition is satisfied, and allows the other attacking users to continue the battle play. Furthermore, if the remaining status of the treasure chests remaining without being acquired by the attacking user is maintained so as not to reach a predetermined remaining status (for example, no remaining treasure chests) from the start of the match-up until a time limit (an example of a predetermined time) has elapsed, the play management unit 117 determines that the victory condition for the defending user has been met and ends all match-ups between the defending user and the attacking user. Note that the treasure chest is just an example, and any specific object may be used instead of the treasure chest.

As a result, the game system 1 can provide a game in which the elements of cooperation between users are reduced in a competitive game between multiple users, even if the competitive game is between multiple attacking users and defending users, since the game is essentially an individual match. Therefore, users can easily participate in a competitive game without needing to cooperate or consult with other users as friends.

In addition, if all of the attacking users acquire the treasure chest before the time limit elapses, the play management unit 117 determines that the victory conditions for all attacking users have been met and ends all match-ups between the attacking users and the defending users. In this case, the play management unit 117 determines that the defeat conditions for the defending user have been met and ends the match-up.

As a result, the game system 1 determines whether the attacking user wins or loses against the defending user depending on whether all of the attacking users obtain the treasure chest within the time limit. Therefore, although it is an individual match, the final defeat of the defending user is determined by the play results of each of the attacking users, so it can also provide an element of a team battle.

In addition, a key (an example of an item) required for the attacking user to obtain the treasure chest is placed within the game field GF so that the attacking user can obtain it. When one of the characters of the attacking user who has obtained a key reaches one of the multiple treasure chests placed within the game field GF, the acquisition management unit 116 allows the attacking user operating that character to obtain the treasure chest that the character reaches. On the other hand, even if the character of the attacking user who has not obtained the key reaches the treasure chest, the acquisition management unit 116 does not allow the attacking user to obtain the treasure chest. Note that the key is just an example, and any item may be used instead of the key.

As a result, the game system 1 does not require the attacking user to simply head towards the location of the treasure chest, increasing the number of elements to conquer the game stage and improving game play.

For example, an attacking user can acquire keys that are placed within the game field GF, as well as keys that have already been acquired by other attacking users. For example, an attacking user can acquire a key by causing damage to a character of another attacking user who has already acquired a key, such as by using the blast of a bomb (BM), causing the character to drop the key.

This allows the game system 1 to allow attacking users to compete with each other for the key, making it more difficult for them to reach the treasure chest once they have obtained the key.

Keys placed within the game field GF are newly placed within the game field GF based on certain additional conditions.

In this way, the game system 1 can encourage attacking users to scramble for keys by setting the number of keys to be less than the number of treasure chests at the start of a match.

The specified additional condition under which a new key is placed within the game field GF is a condition based on the passage of time from the start of match-up play (for example, 5 minutes after the start of match-up play).

In this way, the game system 1 can encourage attacking users to compete for the keys by setting the number of keys to be less than the number of treasure chests at the start of the match-up play. Note that the specified additional condition under which a new key is placed in the game field GF may be an additional condition based on the progress of the match-up play (for example, all three initial keys have been used and disappeared).

When creating a game field GF, the defending user can customize at least the blocks (one example of a limiting object) that limit the movement of characters within the game field GF. For example, when creating a game field GF, the defending user may be able to place soft or hard blocks within the game field GF, and to move or destroy blocks that have already been placed.

This allows the game system 1 to create game stages by adjusting the difficulty of movement of the attacking user's character. For example, the defending user can create multiple game stages with different difficulty levels and use game stages with different difficulty levels for each match.

Second Embodiment
Next, a second embodiment of the present invention will be described.
In this embodiment, details of the matching process for matching a defending user and an attacking user who will play a battle will be described.

As described in the first embodiment, in the game system 1, a game stage created by a defending user can be used to play a competitive game with various users. The game stages that can be used are limited by the matching method that determines the opponent when playing a competitive game.

When a user plays a competitive game, they first choose whether to participate in the competitive game as the attacking or defending side, and then select a matching method. Basically, the defending user becomes the honor during matching. The honor refers to the user who created the room. A room is used to invite attacking users to a match to be played on a game stage created by the defending user, and accepts participation in the competitive game from users other than the honor. There are four types of matching methods: quick match, conditional match, friend match, and designated match. Users can choose from any of the four matching methods.

FIG. 13 is a diagram showing an example of a matching method selection screen according to this embodiment. The illustrated matching method selection screen G30 is displayed on the display unit 14 of the game device 10 in order for the user to select a matching method before starting a match play of this match game. Icon B31 is an operation button for selecting a quick match. Icon B32 is an operation button for selecting a conditional match. Icon B33 is an operation button for selecting a friend match. Icon B34 is an operation button for selecting a designated match. The user selects a matching method by operating the matching method selection screen G30 shown in FIG. 13 whether participating as an attacking side or a defending side. After selecting either the attacking side or the defending side, the user selects a matching method on the matching method selection screen G30 shown in FIG. 13 and participates in the match game.

When a user on the game device 10 performs an operation to select one of the icons B31 to B34, a match request is sent from the game device 10 to the game server 30, and matching processing is executed on the game server 30 according to the selected matching method. When matching is established on the game server 30, the matching result is sent to the game device 10, and match play begins. Each matching method will be described with reference to FIG. 14.

Figure 14 is a diagram showing an example of a matching method according to this embodiment. This diagram shows the matching range and whether or not a room is selected in each matching method. The matching range is the range of users to be matched, and it is specified whether unspecified users (unspecified users) or specific users (specific users) are the targets of matching. A specific user is a user who has a specified relationship with the honor (for example, a friend relationship), or a user specified by the honor's operation. An unspecified user is a user that is not a specific user (including both specific users and users other than specific users). In addition, whether or not a room is selected is specified by whether or not the attacking user can select the room he or she wants to participate in (the user and game stage he or she wants to play).

[Quick Match]
When the defending user selects the quick match, the game device 10 transmits a match request to the game server 30 to participate as the defending side in a match game using a game stage created by the user. If a plurality of game stages created by the user are saved, the user may select which game stage to use. When the attacking user selects the quick match, the game device 10 transmits a match request to the game server 30 to participate as the attacking side in a match game. The game server 30 automatically performs matching with one of the defending users currently making a match request. There are no particular conditions for users to be matched, and matching with unspecified users is performed. Basically, opponents are unknown users, so the matching requires fairness. In the quick match, there is no room selection.

[Conditional Match]
Conditional matches match unspecified users like quick matches, but unlike attacking users' quick matches, they can select a room. By creating a room, the defending user can invite attacking users to participate in the game stage they created. By selecting the room they want to join, the attacking user can participate in a competitive game that uses the game stage of that room.

15 is a diagram showing an example of a room selection screen according to the present embodiment. The room selection screen G40 shown in this figure displays room labels R41, R42, ... which describe the information of each room created by a user who will participate in the battle game as a defender, and icons B41, B42, ... as operation buttons for selecting participation in each room. The room labels display the creator of the game stage (i.e., the room honor), the cleared status of the test play, the game rules (time limit, number of treasure chests, etc.), comments by the creator (comments to the attacking user), etc. By checking the contents of the room label, the attacking user can participate in the battle game after understanding to some extent what kind of game stage it is. For example, in the case of a game stage where "test play" is "not cleared," the attacking user can participate with the understanding in advance that it may be a game stage with a high level of difficulty (maybe it is impossible to clear), so that the user's feeling of absurdity after actually participating in the battle game can be reduced.

[Friend Match]
In the friend match, there is a room selection like in the condition match, but the matching is limited to specific users who are friends with the attacking user and the defending user. If the users are friends, a certain degree of freedom is allowed for the game stages that can be used in the battle game.

[Designated Match]
In the designated match, a specific user who is relatively close to the defending user, such as an acquaintance, is matched as an attacking user. For example, the defending user directly specifies the user ID of the attacking user to perform the match. The attacking user may enter a password previously determined with the defending user and participate in the battle game using a game stage created by the defending user. Alternatively, matching may be performed between users who can battle each other by communicating between the game devices 10 using short-range communication such as Bluetooth (registered trademark) or infrared. If the users are in a close relationship, there are basically no constraints (restrictions) on the game stages that can be used in the battle game. In the designated match, there is no room selection.

Figure 16 is a diagram showing an example of constraint conditions for game stages according to each matching method according to this embodiment. Each matching method has constraint conditions for usable game stages. Depending on how these constraint conditions are set, the difficulty of the game stage for the attacking user will differ.

The constraints for a game stage are set out in terms of whether the test play has been cleared and the game rules. A game stage that has not been cleared in a test play may not have been cleared by the user who created it, or may not have been test played at all. Therefore, a game stage that has not been cleared in a test play may be more difficult than a game stage that has been cleared in a test play. If the constraints do not include whether the test play has been cleared, game stages with high difficulty will be included. Therefore, by including the fact that the test play has been cleared in the constraints for a game stage, it is possible to eliminate game stages that are at least too difficult for the attacking side to win.

Game rules include constraints such as the time limit for the battle play, the number of attacking users, the number of treasure chests, and the number of keys. The longer the time limit, the lower the difficulty of the game stage for the attacking users, and the shorter the time limit, the higher the difficulty of the game stage for the attacking users. Also, the fewer the number of attacking users, the lower the difficulty of the game stage for each attacking user, and the greater the number of attacking users, the higher the difficulty of the game stage for each attacking user. Also, the more treasure chests there are, the lower the difficulty of the game stage for the attacking users, and the fewer the treasure chests, the higher the difficulty of the game stage for the attacking users. Also, the more keys there are, the lower the difficulty of the game stage for the attacking users, and the fewer the keys, the higher the difficulty of the game stage for the attacking users. By setting these constraints on the game rules, the difficulty of the available game stages can be adjusted compared to the case where there are no constraints.

In the illustrated example, the game stages available in "Quick Match" have been cleared in the test play, have a time limit of 10 minutes or more, have 10 or fewer attacking users, have 5 or more treasure chests, and have 7 or more keys. The game stages available in "Condition Match" do not have a constraint on the clearing status of the test play, but have a time limit of 5 minutes or more, have 15 or fewer attacking users, have 3 or more treasure chests, and have 5 or more keys. The game stages available in "Friend Match" do not have a constraint on the clearing status of the test play, but have a time limit of 5 minutes or more, have 15 or fewer attacking users, have 2 or more treasure chests, and have 3 or more keys. The game stages available in "Designated Match" do not have a constraint on the clearing status of the test play, but have a time limit of 5 minutes or more, have 15 or fewer attacking users, have 2 or more treasure chests, and have 3 or more keys. Note that there are no constraints on the game stages available in "Designated Match".

In other words, the constraints are set so that the game stage difficulty is the lowest for the quick match, and the next lowest for the condition match. By setting constraints in this way, when matching with unspecified users, it is possible to prevent a match against an unknown, unspecified opponent from being played on an absurdly difficult game stage.

On the other hand, friend matches are not matched with strangers but with users who are friends, so compared to quick matches and condition matches, constraints are set so that matches can take place on game stages with higher difficulty. In designated matches, the defending user directly specifies the opposing attacking user for matching, so no constraints are set and matches can be played on game stages of any difficulty.

In this way, the matching method sets constraints on the game stages that can be used in battle play among multiple game stages. The constraints on the game stages that can be used in battle play differ based on whether the user to be matched is an unspecified user or not, and are set so that the difficulty of the game stages for the attacking user is lower when matching with an unspecified user than when matching with a specified user.

In the example shown in FIG. 16, the constraints for the test play are set only for the quick match. In such a case, some or all of the constraints of the game rules set for the quick match may be included in the play content of the test play. For example, the play content of the test play may be set to a time limit of 10 minutes and five treasure chests, etc., to satisfy the conditions of the quick match. For example, by including all of the constraints of the game rules for the quick match in the test play, the only constraint for the game stage in the quick match may be that the test play has been cleared.

[Configuration of Matching Processing Unit]
Next, the matching processing unit 314 included in the game server 30 will be described in detail with reference to FIG.

Figure 17 is a diagram showing an example of the functional configuration of the matching processing unit 314 according to this embodiment. The functional configuration of the matching processing unit 314 shown in this figure is a specific example of the matching processing unit 314 shown in Figure 8. The matching processing unit 314 includes a target stage determination unit 3141 (an example of a stage determination unit) and a matching unit 3142.

The target stage determination unit 3141 determines which of the multiple game stages can be used for battle play, using a matching method selected from multiple matching methods with different matching ranges. For example, the target stage determination unit 3141 determines the constraints (see FIG. 16) for the game stages that can be used for battle play, using the selected matching method.

For example, there are cases where the matching range is unspecified users or specific users. The target stage determination unit 3141 determines the above constraint conditions so that the difficulty of the game stages available for battle play differs depending on whether the matching method is one in which the matching range is unspecified users (e.g., quick match and condition match) or one in which the matching range is specific users (e.g., friend match and designated match).

That is, the target stage determination unit 3141 determines the difficulty levels of the game stages available for battle play to be different based on whether the matching range is unspecified users. More specifically, for example, as described with reference to FIG. 16, the target stage determination unit 3141 determines the constraints on the available game stages (the clear status of the test play and the constraints on the game rules) so that the difficulty levels of the game stages available for battle play are different for each of the four matching methods, quick match, condition match, friend match, and designated match.

The matching unit 3142 matches a defending user and an attacking user who will play a match using one of the available game stages determined by the target stage determination unit 3141. For example, the matching unit 3142 matches a defending user and an attacking user based on the selected matching method and the constraints of the game stage.

In the case of a quick match, the matching unit 3142 matches any of the users (defensive users) who have selected quick match and made a match request as the defending side with any of the users (attacking users) who have selected quick match and made a match request as the attacking side. In this case, the users (matching range) who are the target of matching are unspecified users. Also, the available game stages are those that satisfy the constraints in the case of quick match shown in FIG. 16. For example, the matching unit 3142 selects any of the users who have selected quick match and made a match request as the attacking side as a matching target for the user (defensive user) who has selected quick match and made a match request as the defending side. Specifically, for example, the matching unit 3142 randomly selects from among the users who have made a match request as the attacking side (selection so that the probability of each user being selected is equal). Also, the matching unit 3142 may select from among the users who have made a match request as the attacking side in the order in which the match requests were made. The matching unit 3142 selects the number of attacking users according to the game rules from the users selected as the matching targets and matches them with the defending users.

In the case of a conditional match, the matching unit 3142 matches any of the users (defensive users) who have selected the conditional match and made a match request as the defending side with any of the users (attacking users) who have selected the conditional match and made a match request as the attacking side. In this case, the users (matching range) who are the subject of matching are unspecified users, as in the case of a quick match. Also, the available game stages are those that satisfy the constraints in the case of a conditional match shown in FIG. 16. For example, a selection screen (for example, the room selection screen G40 shown in FIG. 15) that allows the user to select a room created by the user (defensive user) who has selected the conditional match and made a match request as the defending side is displayed on the game device 10, and the matching unit 3142 matches the defending user with the attacking user based on the room selection result on the selection screen.

In the case of a friend match, the matching unit 3142 matches a user who has selected a friend match and requested a match as the defending side (defensive user) with a user who has selected a friend match and requested a match as the attacking side. At this time, the users who are the subject of matching (matching range) are users who are friends with each other. The available game stages are those that satisfy the constraints for the friend match shown in FIG. 16.

In the case of a designated match, the matching unit 3142 matches a user designated by a user (defensive user) who has selected the designated match and made a match request as the defending side, as an attacking user. The matching unit 3142 also matches a user designated by a user (attacking user) who has selected the designated match and made a match request as the attacking side, as a defending user. There are no restrictions on the available game stages.

[Matching Processing Operation]
Next, the operation of the matching process executed by the game system 1 will be described.
First, the operation of the match request transmission process executed by the CPU 11 of the game device 10 will be described. Fig. 18 is a flowchart showing an example of the match request transmission process according to the present embodiment. This match request transmission process corresponds to a specific example of the process of step S301 in Fig. 11 and step S401 in Fig. 12.

The CPU 11 controls the display unit 14 to display a matching method selection screen G30 (see FIG. 13) (step S501). The CPU 11 selects a matching method from among four types of matching methods, quick match, conditional match, friend match, and designated match, based on the user's operation on the matching method selection screen G30 (step S503).

Then, the CPU 11 transmits a match request to the game server 30 in association with information indicating the selected matching method (step S505). For example, when participating in a match game as the attacking side, the CPU 11 transmits a match request as the attacking side to the game server 30 in association with information indicating the selected matching method. On the other hand, when participating in a match game as the defending side, the CPU 11 transmits a match request as the defending side to the game server 30 in association with information indicating the selected matching method. Note that if multiple game stages created by the defending user are saved, the match request may also be transmitted to the game server 30 in association with selection information of the game stage to be used.

Next, the operation of the matching process executed by the CPU 31 of the game server 30 will be described. Figure 19 is a flowchart showing an example of the matching process according to this embodiment.

The CPU 31 acquires a match request transmitted from the game device 10 (step S601). For example, the CPU 31 acquires a match request as the attacking side and a match request as the defending side transmitted from each of the multiple game devices 10.

The CPU 31 determines which of the multiple game stages can be used in battle play, based on the matching method associated with the battle request acquired in step S601 (the matching method selected by the user participating as the defending or attacking side) (step S603). For example, the CPU 31 determines the constraints for the game stages that can be used in battle play, based on the selected matching method.

Next, the CPU 31 performs matching between a defending user and an attacking user who will play a match using one of the available game stages determined in step S603 (step S605). For example, the CPU 31 performs matching between a defending user and an attacking user who will play a match using one of the game stages that satisfy the constraint conditions of the available game stages determined in step S603 based on the selected matching method and the constraint conditions of the game stage. Specifically, for example, if the selected matching method is quick match, the CPU 31 randomly extracts a defending user and an attacking user from among the defending user and the attacking user who requested a match in the quick match and performs matching. Also, for example, if the selected matching method is conditional match, the CPU 31 matches the attacking user who requested a match with the honor (defensive user) who created the room on a first-come, first-served basis until the room is filled. Also, if the selected matching method is friend match, for example, the difference from conditional match is that the room is made available to only users (e.g., friends) who have a predetermined relationship with the honor (defensive user). For example, in the case of a friend match, the CPU 31 matches a friend (attacking user) who has requested a match with the honoree (defensive user) who created the room on a first-come, first-served basis until the room reaches capacity.

When a user creates a room, the CPU 31 may also notify users who have a predetermined relationship with the user (e.g., friends) of an invitation to the room (an invitation to a battle).

Then, the CPU 31 transmits the matching result, which includes the user information of the matched defending user, the user information of the attacking user, and information on the game stage to be used in the match play, to the game device 10 of the matched user (step S607).

Summary of the second embodiment
As described above, the game system 1 according to the present embodiment includes a game device 10 and a game server 30 that communicates with the game device 10, and executes a process of matching opponents in a battle game in which an attacking user and a defending user play a battle using a game stage created by the defending user. The defending user can create a plurality of game stages. The game server 30 includes a matching processing unit 314 that executes the matching process. For example, the matching processing unit 314 includes a target stage determination unit 3141 (an example of a stage determination unit) and a matching unit 3142. The target stage determination unit 3141 determines a game stage that can be used for a battle among a plurality of game stages by a matching method selected from a plurality of matching methods having different ranges of users to be matched (for example, a matching range). The matching unit 3142 performs matching between a defending user and an attacking user who play a battle using one of the available game stages determined by the target stage determination unit 3141.

As a result, in a competitive game in which players compete using game stages created by users, the game system 1 determines the game stages that can be used for competitive play depending on the range of users to be matched, thereby reducing user dissatisfaction with game stages.

For example, the target stage determination unit 3141 determines the game stages that can be used for battle play based on whether the user to be matched is an unspecified user.

This allows the game system 1 to make the game stages available for battle play different when matching with an unspecified user and when matching with a specific user, thereby reducing user dissatisfaction with game stages.

In this embodiment, when a user selects a matching method, the difficulty level of the game stages available for battle play is determined to be different based on whether or not the users (matching range) to be matched in the selected matching method are unspecified users. However, conversely, a configuration may be used in which the user selects a game stage and available matching methods are presented in a selectable manner according to the selected game stage.

In addition, the defending user can use the game stage he or she created to become the attacking user and conduct a test play of a battle. The difficulty level of the game stage for the attacking user varies based on whether or not the attacking user was able to win in the test play. The target stage determination unit 3141 then determines the difficulty level of the game stage available for battle play to vary depending on whether or not the user to be matched is an unspecified user.

As a result, the game system 1 can determine the difficulty level of the game stage created by the defending user based on the clear status of the test play, and can differentiate the difficulty level of the game stage available for battle play when matching with an unspecified user from when matching with a specified user, thereby reducing user dissatisfaction with the game stage.

The difficulty level of the game stage for the attacking user differs based on the game rules set by the defending user for the game stage when playing against each other. The target stage determination unit 3141 then determines the difficulty level of the game stage available for playing against each other depending on whether the user to be matched is an unspecified user or not.

As a result, the game system 1 can determine the difficulty level of the game stage created by the defending user based on the game rules, and can differentiate the difficulty level of the game stage available for battle play when matching with an unspecified user from when matching with a specific user, thereby reducing user dissatisfaction with the game stage.

The game rules also include constraints on the number of attacking users.

As a result, the game system 1 can determine the difficulty level of the game stage created by the defending user based on the constraint of the number of attacking users, and can make the difficulty level of the game stage available for battle play different when matching with an unspecified user and when matching with a specific user.

In addition, one or more treasure chests (an example of a specific object) are placed within the game stage, and in a match-up, the outcome of the match between the defending user and the attacking user is determined based on the acquisition status of treasure chests by the attacking user from the start of the match-up until a time limit (an example of a predetermined time) has elapsed. The game rules include constraints on the number of treasure chests placed within the game stage or constraints on the time limit.

As a result, the game system 1 can determine the difficulty level of a game stage created by a defending user based on the constraint of the number of treasure chests placed in the game stage or the constraint of the time limit, and can make the difficulty level of the game stage available for battle play different when matching with an unspecified user and when matching with a specified user.

In addition, keys (an example of an item) necessary for the attacking user to obtain the treasure chest are placed within the game stage so that the attacking user can obtain them, and the game rules include constraints on the number of keys that can be placed within the game stage.

As a result, the game system 1 can determine the difficulty level of a game stage created by a defending user based on the constraint of the number of keys placed in the game stage, and can differentiate the difficulty level of the game stage available for battle play when matching with an unspecified user from when matching with a specified user.

In addition, when creating a game stage, the defending user can customize blocks (an example of a limiting object) that limit the movement of characters that move within the game stage in response to at least the operations of the attacking user.

This allows the game system 1 to adjust the difficulty level of a game stage when the defending user creates the game stage based on the number and position of blocks within the game stage.

In addition, when the defending user has created multiple game stages, the game system 1 presents the attacking user with only those game stages that can be used for match play, allowing them to select using the matching method.

This allows the game system 1 to make it easier for an attacking user to select a defending user to compete against when participating in a competitive game.

[Modification]
Although the embodiment of the present invention has been described in detail with reference to the drawings, the specific configuration is not limited to the above-mentioned embodiment, and the present invention also includes designs that do not deviate from the gist of the present invention. For example, the above-mentioned configurations can be arbitrarily combined.

In the above embodiment, an example of the specification was described in which the attacking user could not obtain the treasure chest unless he had a key, but the specification may also be such that a key is not required to obtain the treasure chest. Also, in the above embodiment, the attacking user fulfilled the victory condition by obtaining the treasure chest as a result of reaching the treasure chest, but the victory condition may also be fulfilled by reaching the treasure chest.

In the above embodiment, an example was described in which the winning condition for the attacking user was to obtain one treasure chest, but this is not limited to one and may be multiple. In other words, the winning condition for the attacking user may be to obtain multiple treasure chests (e.g., two, three, etc.). The more treasure chests the attacking user must obtain in order to win, the more difficult it will be for the attacking user to win.

In the above embodiment, the defending user also operates a character in the battle play in the same way as the attacking user, but the defending user does not necessarily need to have a character to operate. For example, the defending user may simply see whether he or she can protect a treasure chest within the time limit by setting traps or the like in a game stage that he or she created. Alternatively, the only element in which the defending user intervenes in the battle play may be the operation of operating weapons such as a cannon or traps (for example, firing a cannon, making an NPC appear, activating a trap that makes blocks fall, etc.).

In addition, a program for implementing the functions of the game processing unit 110 or the server processing unit 310 may be recorded on a computer-readable recording medium, and the program recorded on the recording medium may be read into a computer system and executed to perform part or all of the processing of the game processing unit 110 or the server processing unit 310. Here, "reading a program recorded on a recording medium into a computer system and executing it" includes installing the program into a computer system. The "computer system" here includes hardware such as an OS and peripheral devices. The "computer system" may also include multiple computer devices connected via a network including the Internet, WAN, LAN, dedicated lines, and other communication lines. The "computer-readable recording medium" refers to portable media such as flexible disks, optical magnetic disks, ROMs, and CD-ROMs, and storage devices such as hard disks built into a computer system. In this way, the recording medium storing the program may be a non-transient recording medium such as a CD-ROM. The recording medium also includes a recording medium provided inside or outside and accessible from a distribution server to distribute the program. The code of the program stored in the recording medium of the distribution server may be different from the code of the program in a format executable by the terminal device. In other words, as long as it can be downloaded from the distribution server and installed in a format executable by the terminal device, the format in which it is stored in the distribution server does not matter. The program may be divided into multiple parts, downloaded at different times, and then combined on the terminal device, or each of the divided programs may be distributed by a different distribution server. Furthermore, the "computer-readable recording medium" includes a memory that holds a program for a certain period of time, such as a volatile memory (RAM) inside a computer system that becomes a server or client when a program is transmitted over a network. The program may also be a program for realizing part of the above-mentioned functions. Furthermore, the program may be a so-called difference file (difference program) that can realize the above-mentioned functions in combination with a program already recorded in the computer system.

In addition, part or all of the above-mentioned game processing unit 110 or server processing unit 310 may be realized as an integrated circuit such as an LSI (Large Scale Integration). Each of the above-mentioned functions may be individually processed, or part or all of them may be integrated into a processor. The integrated circuit method is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. Furthermore, if an integrated circuit technology that can replace LSI appears due to advances in semiconductor technology, an integrated circuit based on that technology may be used.

In addition, the server processing unit 310 may be provided with a portion of the configuration of the game processing unit 110 described above. For example, the game server 30 may be responsible for most of the game processing, and the game device 10 may be configured to display game images based on the game processing executed by the game server 30 and to input user operations.

The game server 30 may be configured as a single computer device, or may be configured as a distributed system across multiple computer devices. For example, the game server 30 may be configured as a distributed system across multiple computer devices connected via a network NW. As an example, a server that performs the matching process for the game server 30 and a server that performs the game process may be configured as distributed systems across different computer devices. After the matching process is performed by the game server 30, the matched game devices 10 may communicate with each other via P2P to play against each other.

In addition, at least a part of the configuration of the game processing unit 110 of the game device 10 may be provided in the game server 30. For example, a so-called cloud game configuration may be used in which the game device 10 only handles user operation input, drawing images on the game screen, and playing audio, while the game server 30 handles game processing including generating drawing data and audio data.

[Appendix A]
From the above description, the present invention can be understood, for example, as follows: In order to facilitate understanding of the present invention, reference numerals in the accompanying drawings are conveniently written in parentheses, but the present invention is not limited to the illustrated embodiments.

For example, in a competitive game in which a defending user and an attacking user play against each other using a game stage created by the defending user, one of the highlights of the game is for multiple attacking users to cooperate in playing to conquer the game stage created by the defending user. However, some users find such cooperative play to be cumbersome.

One of the objectives of some aspects of the present invention is to provide a game program, a game processing method, and a game system that reduce the need for cooperation between users in a competitive game played by multiple users.

(Appendix A1) A game program according to one aspect of the present invention is a game program for executing processing of a competitive game between multiple attacking users and at least one defending user, and includes a step (S103, S203) of moving each character within a game space (e.g., a game field GF) created by the defending user based on the operation of each of the multiple attacking users during a competitive play in the competitive game, and a step (S204) of causing the attacking user who is operating the character to acquire a specific object (e.g., a treasure chest) that is located within the game space, when one of the characters of the attacking users reaches the specific object. the step (S211), the step (S307, S309, S311) of terminating the battle play of the attacking user who has acquired the specific object among the multiple attacking users as the victory condition being satisfied, and allowing the other attacking users to continue the battle play, and the step (S413, S315) of terminating the battle play of all of the defending users and the attacking users as the victory condition being satisfied, if the remaining status of the specific object that has not been acquired by the attacking user is maintained so as not to become a predetermined remaining status (e.g., no remaining treasure chests) until a predetermined time (e.g., a time limit) has elapsed since the start of the battle play.

According to the configuration of Appendix A1, even in a competitive game between multiple attacking users and defending users, it is essentially an individual game, so it is possible to provide a game in which the elements of cooperation between users are reduced in a competitive game between multiple users. Therefore, users can easily participate in a competitive game without needing to cooperate or consult with other users as friends.

(Appendix A2) Another aspect of the present invention is the game program described in Appendix A1, in which the computer is caused to execute a step (S309, S411) of ending the battle play of all of the defending users and the attacking users when all of the attacking users have acquired the specific object (e.g., a treasure chest) before the predetermined time (e.g., a time limit) has elapsed, assuming that the victory condition of all of the attacking users has been satisfied.

According to the configuration of Appendix A2, the outcome between the attacking user and the defending user is determined by whether or not all of the attacking users acquire a specific object (e.g., a treasure chest) within a specified time (e.g., a time limit). Therefore, although it is an individual battle, an element of a team battle can also be provided, since the final defeat of the defending user is determined by the play results of each of the attacking users.

(Appendix A3) Another aspect of the present invention is a game program as described in Appendix A1 or Appendix A2, in which an item (e.g., a key) required for the attacking user to acquire the specific object (e.g., a treasure chest) is placed in the game space (e.g., game field GF) so that the attacking user can acquire it, and in the acquiring step, when one of the characters of the attacking user who has acquired the item reaches one of a plurality of specific objects placed in the game space, the attacking user who operates the character is caused to acquire the specific object that the character has reached.

With the configuration of Appendix A3, the attacking user no longer simply moves towards the location of a specific object (e.g., a treasure chest), which increases the number of elements to conquer in the game space (e.g., the game field GF), improving the playability of the game.

(Appendix A4) Another aspect of the present invention is the game program described in Appendix A3, in which the attacking user can acquire the items (e.g., keys) that are placed in the game space (e.g., game field GF) and items that have already been acquired by other attacking users.

According to the configuration of Appendix A4, attacking users can compete with each other for an item (e.g., a key), which increases the difficulty of reaching a specific object (e.g., a treasure chest) after acquiring the item (e.g., a key).

(Appendix A5) Another aspect of the present invention is the game program described in Appendix A3 or Appendix A4, in which the item (e.g., a key) placed in the game space (e.g., game field GF) is newly placed in the game space based on a predetermined additional condition.

According to the configuration of Appendix A5, at the start of a battle, the number of items (e.g., keys) is set to be less than the number of specific objects (e.g., treasure chests), which can encourage attacking users to compete for the items (e.g., keys).

(Appendix A6) Another aspect of the present invention is the game program described in Appendix A5, in which the predetermined additional condition is a condition based on the passage of time from the start of the match-up play.

According to the configuration of Appendix A6, at the start of a battle, the number of items (e.g., keys) is set to be less than the number of specific objects (e.g., treasure chests), which encourages attacking users to compete for the items (e.g., keys).

(Appendix A7) Another aspect of the present invention is a game program according to any one of Appendices A1 to A6, in which the defending user is able to customize at least a limiting object (e.g., a block) that limits the movement of the character within the game space (e.g., a game field GF) when creating the game space.

According to the configuration of Appendix A7, a game space (e.g., a game field GF) can be created by adjusting the difficulty of movement of the attacking user's character. For example, a defending user can create multiple game spaces (e.g., game fields GF) with different difficulty levels, allowing the defending user to use a game space (e.g., a game field GF) with a different difficulty level for each match.

(Appendix A8) A game processing method according to one aspect of the present invention is a game processing method executed by a computer that executes processing of a competitive game between multiple attacking users and at least one defending user, and includes steps (S103, S203) of moving each character within a game space (e.g., a game field GF) created by the defending user based on the operation of each of the multiple attacking users in a competitive play in the competitive game, and a step (S204) of moving each character within a game space (e.g., a game field GF) created by the defending user based on the operation of each of the multiple attacking users in a competitive play in the competitive game, and a step (S205) of moving each character within a game space (e.g., a game field GF) created by the defending user based on the operation of each of the multiple attacking users in a competitive play in the competitive game, and a step (S206) of moving each character within a game space (e.g., a game field GF) created by the defending user based on the operation of each of the multiple attacking users in a competitive play in the competitive game, and a step (S207) of moving each character within a game space (e.g., a game field GF) created by the defending user based on the operation of each of the multiple attacking users in a competitive play in the competitive game, and a step (S208) of moving each character within a game space (e.g., a game field GF) created by the defending user based on the operation of each of the multiple attacking users in a competitive play in the competitive game, and a step (S209 ... the step of allowing the attacking user to acquire the specific object (S211); the step of terminating the battle play of the attacking user among the multiple attacking users who has acquired the specific object as a victory condition being met, and allowing the other attacking users to continue the battle play (S307, S309, S311); and the step of terminating the battle play of all of the defending users and the attacking users as a victory condition being met, if the remaining status of the specific object that has not been acquired by the attacking user is maintained so as not to reach a predetermined remaining status (e.g., no remaining treasure chests) until a predetermined time (e.g., a time limit) has elapsed since the start of the battle play, as a victory condition of the defending user.

According to the configuration of Appendix A8, even in a competitive game between multiple attacking users and defending users, it is essentially an individual game, so it is possible to provide a game in which the elements of cooperation between users are reduced in a competitive game between multiple users. Therefore, users can easily participate in a competitive game without needing to cooperate or consult with other users as friends.

(Appendix A9) A game system (1) according to one embodiment of the present invention is a game system that includes a game device (10) and a game server (30) that communicates with the game device, and executes processing for a competitive game between a plurality of attacking users and at least one defending user, and includes a character control unit (S103, S203) that, in a competitive play in the competitive game, moves each character within a game space (e.g., a game field GF) created by the defending user based on the operation of each of the plurality of attacking users, and a character control unit (S103, S203) that, when one of the characters of the attacking users reaches a specific object (e.g., a treasure chest) that is located within the game space, moves the specific object that the character has reached by operating the character. and a play management unit (117) that ends the battle play of the attacking user who has acquired the specific object as a victory condition being met, among the multiple attacking users, and allows the other attacking users to continue the battle play (S307, S309, 311), and if the remaining status of the specific object that has not been acquired by the attacking user and remains is maintained so as not to become a predetermined remaining status (e.g., no treasure chests remaining) until a predetermined time (e.g., a time limit) has elapsed since the start of the battle play, the victory condition of the defending user is met, and ends the battle play of all of the defending users and the attacking users (S413, S315).

According to the configuration of Appendix A9, even in a competitive game between multiple attacking users and defending users, it is essentially an individual game, so it is possible to provide a game in which the elements of cooperation between users are reduced in a competitive game between multiple users. Therefore, users can easily participate in a competitive game without needing to cooperate or consult with other users as friends.

[Appendix B]
From the above description, the present invention can be understood, for example, as follows: In order to facilitate understanding of the present invention, reference numerals in the accompanying drawings are conveniently written in parentheses, but the present invention is not limited to the illustrated embodiments.

For example, in a competitive game in which players compete using game stages created by users, the difficulty level of the created game stage may not be appropriate, or may be intentionally set too high. As a result, other users who play using such a game stage may become dissatisfied with that game stage.

One of the objectives of some aspects of the present invention is to provide a game program, a game processing method, and a game system that reduces user dissatisfaction with game stages in a competitive game in which players compete using game stages created by users.

(Appendix B1) A game program according to one aspect of the present invention is a game program that executes a process of matching opponents in a competitive game in which an attacking user and a defending user play against each other using game stages created by the defending user, and the defending user is capable of creating a plurality of game stages. The program causes a computer to execute a step (S603) of determining, by a matching method selected from a plurality of matching methods that have different ranges of users to be matched (e.g., matching ranges), a game stage that can be used in the competitive play among the plurality of game stages that can be used, and a step (S605) of matching the defending user and the attacking user who will play the competitive play using one of the determined usable game stages.

According to the configuration of Appendix B1, in a competitive game in which players compete using game stages created by users, the game stages available for competitive play are determined according to the range of users to be matched, thereby reducing user dissatisfaction with game stages.

(Appendix B2) Another aspect of the present invention is the game program described in Appendix B1, in which in the determining step, the game stages available for the battle play are determined based on whether the user to be matched is an unspecified user.

According to the configuration of Appendix B2, the game stages available for battle play can be made different when matching with an unspecified user and when matching with a specific user, thereby reducing user dissatisfaction with game stages.

(Appendix B3) Another aspect of the present invention is a game program as described in appendix B1 or appendix B2, in which the defending user can use the game stage created by the defending user to become the attacking user and conduct a test play of the battle play, the difficulty level of the game stage for the attacking user varies based on whether the attacking user is victorious in the test play, and in the determining step, the difficulty level of the game stage available for the battle play is determined to vary depending on whether the user to be matched is an unspecified user.

According to the configuration of Appendix B3, the difficulty level of the game stage created by the defending user is determined based on whether the attacking user was able to win in a test play, and the difficulty level of the game stage available for battle play can be made different when matching with an unspecified user and when matching with a specified user, thereby reducing user dissatisfaction with the game stage.

(Appendix B4) Another aspect of the present invention is a game program as described in any one of Appendices B1 to B3, in which the difficulty level of the game stage for the attacking user differs based on the game rules set for the game stage by the defending user when the battle play is performed, and in the determining step, the difficulty level of the game stage available for the battle play is determined to differ depending on whether the user to be matched is an unspecified user or not.

According to the configuration of Appendix B4, the difficulty level of the game stage created by the defending user is determined based on the game rules, and the difficulty level of the game stage available for battle play can be made different when matching with an unspecified user and when matching with a specified user, thereby reducing user dissatisfaction with the game stage.

(Appendix B5) Another aspect of the present invention is the game program described in Appendix B4, in which the game rules include a constraint on the number of attacking users.

According to the configuration of Appendix B5, the difficulty level of the game stage created by the defending user is determined based on the constraint of the number of attacking users, and the difficulty level of the game stage available for battle play can be made different when matching with an unspecified user and when matching with a specific user.

(Appendix B6) Another aspect of the present invention is a game program as described in appendix B4 or appendix B5, in which one or more specific objects (e.g., treasure chests) are placed within the game stage, and in the match-up play, a win or loss between the defending user and the attacking user is determined based on the acquisition status of the specific objects by the attacking user from the start of the match-up play until a predetermined time (e.g., a time limit) has elapsed, and the game rules include a constraint on the number of the specific objects placed within the game stage or a constraint on the predetermined time.

According to the configuration of Appendix B6, the difficulty level of the game stage created by the defending user is determined based on the constraint of the number of specific objects (e.g., treasure chests) placed in the game stage or the constraint of the time from the start of the match-up play, and the difficulty level of the game stage available for match-up play can be made different when matching with an unspecified user and when matching with a specific user.

(Appendix B7) Another aspect of the present invention is the game program described in Appendix B6, in which an item (e.g., a key) required for the attacking user to obtain the specific object (e.g., a treasure chest) is placed in the game stage so that the attacking user can obtain it, and the game rules include a constraint on the number of items placed in the game stage.

According to the configuration of Appendix B7, the difficulty level of the game stage created by the defending user is determined based on the constraint of the number of items (e.g., keys) placed in the game stage, and the difficulty level of the game stage available for battle play can be made different when matching with an unspecified user and when matching with a specified user.

(Appendix B8) Another aspect of the present invention is a game program as described in any one of Appendices B5 to B7, in which the defending user is able to customize a limiting object (e.g., a block) that limits the movement of a character that moves in response to at least the operation of the attacking user within the game stage when creating the game stage.

According to the configuration of Appendix B8, when a defending user creates a game stage, the difficulty level of the game stage can be adjusted by the number and positions of limiting objects (e.g., blocks) in the game stage.

(Appendix B9) A game processing method according to one aspect of the present invention is a game processing method executed by a computer that executes a process of matching opponents in a competitive game in which an attacking user and a defending user play against each other using game stages created by the defending user, in which the defending user is capable of creating a plurality of game stages, and includes a step (S603) of determining which of the plurality of game stages is usable for the competitive play by a matching method selected from a plurality of matching methods having different ranges of users to be matched (e.g., matching ranges), and a step (S605) of matching the defending user who plays the competitive play using one of the determined usable game stages with the attacking user.

According to the configuration of Appendix B9, in a competitive game in which players compete using game stages created by users, the game stages available for competitive play are determined according to the range of users to be matched, thereby reducing user dissatisfaction with game stages.

(Appendix B10) A game system according to one aspect of the present invention includes a game device (10) that executes a process for a competitive game in which an attacking user and a defending user play a competitive game using a game stage created by the defending user, and a game server (30) that executes a process for matching opponents in the competitive game, in which the defending user can create a plurality of game stages, and the game server includes a game stage determination unit (3141, S603) that determines the game stage that can be used for the competitive game among the plurality of game stages by a matching method selected from a plurality of matching methods that have different ranges of users to be matched (e.g., matching ranges), and a matching unit (3142, S605) that matches the defending user who plays the competitive game using one of the determined usable game stages with the attacking user.

According to the configuration of Appendix B10, in a competitive game in which players compete using game stages created by users, the game stages available for competitive play are determined according to the range of users to be matched, thereby reducing user dissatisfaction with game stages.

1 Game system, 10 Game device, 11 CPU, 12 Communication unit, 13 Input unit, 14 Display unit, 15 Memory unit, 30 Game server, 31 CPU, 32 Communication unit, 35 Memory unit, 110 Game processing unit, 111 Game stage management unit, 112 Match request unit, 113 Play progress management unit, 114 Game data transfer unit, 115 Character control unit, 116 Acquisition management unit, 117 Play management unit, 118 Display control unit, 151 User data storage unit, 152 Game stage storage unit, 153 Possessed data storage unit, 310 Server processing unit, 311 Server side game processing unit, 312 Game stage management unit, 313 Game data transfer unit, 314 Matching processing unit, 3141 Target stage determination unit, 3142 Matching unit, 351 User data storage unit, 352 Game stage storage unit, 353 Possessed data storage unit

Claims (8)

1. A game program for executing a process of matching opponents in a competitive game in which an attacking user and a defending user play a competitive game using a game stage created by the defending user, comprising:
The defending user is capable of creating a plurality of the game stages;
On the computer,
determining, by a matching method selected from a plurality of matching methods each having a different range of users as a target of the matching, a game stage that can be used in the battle play among the plurality of game stages;
a step of matching the defending user and the attacking user who will play the match using any one of the determined available game stages;
Run the command ,
In the determining step,
determining the game stages available for the battle play based on whether the user to be matched is an unspecified user or not, such that the difficulty level of the game stages for the attacking user is lower in matching with an unspecified user than in matching with a specified user;
a difficulty level of the game stage for the attacking user is different based on a game rule set by the defending user for the game stage when playing the battle play;
One or more specific objects are placed in the game stage,
a win/loss result between the defending user and the attacking user is determined based on an acquisition status of the specific object by the attacking user from the start of the battle play until a predetermined time has elapsed,
the game rules include a constraint on the number of the specific objects placed in the game stage;
Game program. an item required for the attacking user to obtain the specific object is placed in the game stage so as to be obtainable by the attacking user;
the game rules include a constraint on the number of the items placed in the game stage;
The game program according to claim 1 . The game rules include a constraint on the predetermined time.
The game program according to claim 1 . The game rules include a constraint on the number of the attacking users.
The game program according to claim 1 . When creating the game stage, the defending user is capable of customizing a limiting object that limits the movement of a character that moves in response to at least an operation of the attacking user within the game stage.
The game program according to any one of claims 1 to 4 . the game stage created by the defending user can be used by the defending user himself/herself as the attacking user to conduct a test play of the battle play;
the difficulty level of the game stage for the attacking user is varied based on whether or not the attacking user was able to win in the test play;
In the determining step,
whether or not the game stages available for the battle play among the plurality of game stages are limited to only those game stages in which the attacking user has been victorious in the test play is varied depending on the matching method;
The game program according to claim 1 . 1. A game processing method executed by a computer that executes a process of matching opponents in a competitive game in which an attacking user and a defending user play against each other using a game stage created by the defending user, comprising:
The defending user is capable of creating a plurality of the game stages;
determining, by a matching method selected from a plurality of matching methods each having a different range of users as a target of the matching, a game stage that can be used in the battle play among the plurality of game stages;
a step of matching the defending user and the attacking user who will play the match using any one of the determined available game stages;
Including ,
In the determining step,
determining the game stages available for the battle play based on whether the user to be matched is an unspecified user or not, such that the difficulty level of the game stages for the attacking user is lower in matching with an unspecified user than in matching with a specified user;
a difficulty level of the game stage for the attacking user is different based on a game rule set by the defending user for the game stage when playing the battle play;
One or more specific objects are placed in the game stage,
a win/loss result between the defending user and the attacking user is determined based on an acquisition status of the specific object by the attacking user from the start of the battle play until a predetermined time has elapsed,
the game rules include a constraint on the number of the specific objects placed in the game stage;
Game processing method. A game system including: a game device that executes a process for a competitive game in which an attacking user and a defending user play a competitive game using a game stage created by the defending user; and a game server that executes a process for matching opponents in the competitive game,
The defending user is capable of creating a plurality of the game stages;
The game server includes:
a stage determination unit that determines, by a matching method selected from a plurality of matching methods each having a different range of users as a target of the matching, a game stage that can be used for the battle play among the plurality of game stages;
a matching unit that performs matching between the defending user and the attacking user who will play the match using any one of the determined available game stages;
Equipped with
The stage determination unit:
determining the game stages available for the battle play based on whether the user to be matched is an unspecified user or not, such that the difficulty level of the game stages for the attacking user is lower in matching with an unspecified user than in matching with a specified user;
a difficulty level of the game stage for the attacking user is different based on a game rule set by the defending user for the game stage when playing the battle play;
One or more specific objects are placed in the game stage,
a win/loss result between the defending user and the attacking user is determined based on an acquisition status of the specific object by the attacking user from the start of the battle play until a predetermined time has elapsed,
the game rules include a constraint on the number of the specific objects placed in the game stage;
Game system.

Images