JP2024051014A - Game control method, computer and control program - Google Patents

Abstract

[Problem] The present invention aims to provide a game control method etc. that enables a player to maintain a desire to continue playing a game. [Solution] The game control method according to the present invention is a game control method in a computer that executes a game in which processing of a plurality of stages is executed sequentially, and includes executing processing of one of the plurality of stages in accordance with a first instruction by the player, and executing processing of a predetermined number of stages (two or more) of the plurality of stages in succession in accordance with a second instruction by the player. [Selected Figure] Figure 3

Description

Application for application of Article 30, Paragraph 2 of the Patent Law has been filed. Website address: http://tdig. gree-apps. net/ Posted on: July 16, 2013

Application for application of Article 30, Paragraph 2 of the Patent Law has been filed. Website address: http://tdig. gree-apps. net/? mode=card&act=dungeon_top Posted on: July 16, 2013

The present invention relates to a game control method, a computer, and a control program.

In recent years, servers that provide games to mobile terminals via communication networks have become widespread. Games provided by such servers include those in which multiple players can participate (so-called "social games"). One known example of such a social game is one in which players battle enemy characters using cards (so-called "card battle games") (see, for example, Patent Document 1).

Also known as such social games are those in which the player progresses through a game scenario and completes so-called quests (so-called "quest games"). Generally, quest games have multiple stages, and each time a progress command is given by the player, the process of each stage is executed in sequence.

JP 2008-113768 A

However, in conventional quest games, the player must give instructions each time a process for each stage is executed, and executing processes for multiple stages requires a great deal of time and effort. As a result, there is a risk that the player's motivation to continue playing the game may be lost midway through the quest game.

The present invention was made to solve these problems, and aims to provide a game control method, computer, and control program that enable players to maintain their desire to continue playing the game.

The control method of the present invention is a game control method in a computer that executes a game in which processing of a plurality of stages is executed sequentially, and includes executing processing of one of the plurality of stages in accordance with a first instruction by a player, and successively executing processing of a predetermined number of stages (two or more) among the plurality of stages in accordance with a second instruction by the player.
The computer may be any type of computer capable of executing the above procedures, such as a mobile terminal, a fixed terminal, or a server.

Furthermore, in the control method according to the present invention, when a predetermined number of stages of processing are executed in accordance with the second instruction, it is preferable that the execution results of each of the predetermined number of stages of processing are displayed after all of the predetermined number of stages of processing have been executed.

Furthermore, in the control method according to the present invention, when processing of a predetermined number of stages is executed in accordance with the second instruction, it is preferable that the item to be granted in the predetermined number of stages is granted to the player after all processing of the predetermined number of stages is executed.

Furthermore, in the control method according to the present invention, when processing of a predetermined number of stages is executed in accordance with the second instruction, it is preferable to consume points for the predetermined number of stages from the points owned by the player for executing the processing of the stages.

Furthermore, in the control method according to the present invention, when a specific event occurs in any of the predetermined number of stages executed in accordance with the second instruction, it is preferable not to execute the processing of the stages subsequent to the stage in which the specific event occurred consecutively.

In addition, in the control method according to the present invention, it is preferable to change the benefit given to the player when the stage processing is performed according to the first instruction and when the stage processing is performed according to the second instruction.

In addition, in the control method according to the present invention, if the conditions for clearing a specific stage out of a predetermined number of stages executed in accordance with the second instruction are not met, it is preferable not to execute the processing of stages subsequent to the specific stage consecutively.

In addition, in the control method according to the present invention, if the conditions for clearing a specific stage among a predetermined number of stages to be executed in accordance with the second instruction are not met, it is preferable not to execute the processing of the specific stage and stages after the specific stage consecutively.

In addition, in the control method according to the present invention, it is preferable to store other players related to each player, and to grant a bonus to the other players related to the player when a predetermined number of stages have been processed in accordance with the second instruction.

In addition, in the control method according to the present invention, it is preferable that the game field is progressed a fixed distance at a time during the processing of each of the multiple stages.

The computer according to the present invention is a computer that executes a game in which processing of multiple stages is executed sequentially, and includes a first execution unit that executes processing of one of the multiple stages in accordance with a first instruction from a player, and a second execution unit that executes processing of a predetermined number of stages (two or more) in succession in accordance with a second instruction from the player.

The program according to the present invention is a control program for a computer that executes a game in which processing of multiple stages is executed sequentially, and causes the computer to execute processing of one of the multiple stages in accordance with a first instruction from a player, and to execute processing of a predetermined number of stages (two or more) in succession in accordance with a second instruction from the player.

The control method, computer, and control program of the present invention execute the processing of one stage when a first instruction is given by the player, and execute the processing of multiple stages in succession when a second instruction is given, thereby making it possible to execute multiple stages in succession according to instructions from the player, and maintaining the player's desire to continue playing the game.

FIG. 1 is a diagram illustrating an example of a schematic configuration of a game system. FIG. 2 is a diagram illustrating an example of a schematic configuration of a mobile terminal. FIG. 2 illustrates an example of a schematic configuration of a server. 1A is a diagram showing an example of the data structure of a player management table, FIG. 1B is a diagram showing an example of the data structure of a card management table, and FIG. 1C is a diagram showing an example of the data structure of a dungeon management table. 11A to 11D are diagrams showing examples of display screens of a mobile terminal. 13A to 13D are diagrams showing other examples of the display screen of the mobile terminal. 13A to 13D are diagrams showing still another example of the display screen of the mobile terminal. 13A to 13C are diagrams showing yet another example of a display screen of a mobile terminal. FIG. 11 is a diagram showing an example of an operation sequence of the game system. FIG. 13 is a diagram illustrating an example of an operational flow of a game progress process by a server. FIG. 11 is a diagram illustrating an example of an operation flow of a normal execution process by a server. FIG. 11 is a diagram illustrating an example of an operation flow of a continuous execution process by a server.

Various embodiments of the present invention will be described below with reference to the drawings. However, please note that the technical scope of the present invention is not limited to these embodiments, but extends to the inventions described in the claims and their equivalents.

1. Overview of the Present Embodiment In the game system of the present embodiment, a player plays a game provided by a server using a mobile terminal. The server executes quests that progress according to a game scenario as events in the game provided. A quest is generally also called a search, a mission, or the like, and has multiple stages, with processing of each stage being executed sequentially. Each stage includes a battle (competition) with an enemy character using game media owned by the player, the granting of a special privilege such as a specific game media to the player, a so-called RAID battle in which multiple players participate, an encounter with another player and/or a battle (competition) with another player, and the like. By executing a quest, a player can grow a character and obtain items.

The game medium is electronic data used in the game, and includes, for example, cards, items, characters, and avatars. The game medium is electronic data that can be acquired, held, used, managed, exchanged, synthesized, strengthened, sold, discarded, and/or given away by the player in the game as the game progresses, but the manner in which the game medium is used is not limited to that described in this specification. In this embodiment, cards registered in the game system in advance are used as an example of the game medium. Cards used in battles with enemy characters have parameters such as attack power, defense power, vitality (or HP (hit points)), attributes (for example, fire, water, lightning, etc.), rarity (for example, normal, rare, S (super) rare, SS (double super) rare, SSS (triple super) rare, legend, etc.), skill (special effect) activation rate, number of attacks in one turn, number of defenses in one battle, etc., and/or jobs (for example, occupation, type of soldier, etc.).

In the present embodiment, the quest is to explore the dungeon from the entrance to the location of the floor boss, and each area into which the dungeon is divided at a fixed distance is treated as one stage. For example, if a 200m dungeon has 20 stages, the distance per stage is 10m. Instead of dividing the dungeon at fixed distances, the distance of each stage may be set to any distance (e.g., 1m, 15m, etc.). The distance of each stage may be changed according to the ability of the character card used by the player, so that the higher the ability of the character card used by the player, the longer the distance of each stage, and the lower the ability, the shorter the distance. The dungeon may be divided into multiple units (e.g., floors), and each unit may be divided into multiple stages. The player progresses through the game field at a fixed distance in each stage. In the game system of this embodiment, the player progresses through the quest by issuing a normal execution instruction to execute the processing of one stage, or a continuous execution instruction to execute the processing of multiple stages in succession. This allows the player to execute the processes of multiple stages consecutively with a single command, reducing the time and effort required to clear a dungeon and helping to maintain the player's desire to continue playing the game.

2. Configuration of Game System 1 FIG. 1 is a diagram showing an example of a schematic configuration of the game system 1.

The game system 1 includes at least one mobile terminal 2 and a server 3. The mobile terminal 2 and the server 3 are connected to each other via a communication network, for example, via a base station 4, a mobile communication network 5, a gateway 6, and the Internet 7. A program executed on the mobile terminal 2 (e.g., a browsing program) and a program executed on the server 3 (e.g., a game program) communicate with each other using a communication protocol such as Hypertext Transfer Protocol (HTTP).

2.1 Configuration of the Portable Terminal 2 FIG. 2 is a diagram showing an example of a schematic configuration of the portable terminal 2.

The portable terminal 2 connects to the server 3 via a base station 4, a mobile communication network 5, a gateway 6, and the Internet 7, and communicates with the server 3. The portable terminal 2 requests the server 3 to progress in the game in response to the player's operation of an operation unit 23 (buttons, etc.). The portable terminal 2 also receives and displays display data related to the progress of the game from the server 3. To this end, the portable terminal 2 includes a device communication unit 21, a device memory unit 22, an operation unit 23, a display unit 24, and a device processing unit 25.

In this embodiment, the mobile terminal 2 is assumed to be a multi-function mobile phone (a so-called "smartphone"), but the present invention is not limited to this. The mobile terminal 2 may be any device to which the present invention is applicable, such as a mobile phone (a so-called "feature phone"), a personal digital assistant (PDA), a portable game console, a portable music player, a tablet terminal, a tablet PC, or a notebook PC.

The terminal communication unit 21 has a communication interface circuit including an antenna sensitive to a specific frequency band, and connects the mobile terminal 2 to a wireless communication network. The terminal communication unit 21 establishes a wireless signal line with the base station 4 by a CDMA (Code Division Multiple Access) method or the like via a channel assigned by the base station 4, and communicates with the base station 4. The terminal communication unit 21 then transmits data supplied from the terminal processing unit 25 to the server 3 or the like. The terminal communication unit 21 also supplies data received from the server 3 or the like to the terminal processing unit 25. The terminal communication unit 21 may also perform wireless communication with a Wi-Fi (Wireless Fidelity) access point (not shown) by a wireless communication method conforming to the IEEE 802.11 standard.

The terminal storage unit 22 includes, for example, a semiconductor memory device. The terminal storage unit 22 stores an operating system program, a driver program, an application program, data, and the like used in the processing in the terminal processing unit 25. For example, the terminal storage unit 22 stores, as driver programs, an input device driver program that controls the operation unit 23, an output device driver program that controls the display unit 24, and the like. The terminal storage unit 22 also stores, as application programs, programs that acquire and display display data related to the progress of the game. The computer program may be installed in the terminal storage unit 22 from a computer-readable portable recording medium such as a CD-ROM (compact disk read only memory) or a DVD-ROM (digital versatile disk read only memory) using a known setup program, and the like. The terminal storage unit 22 also stores, as data, display data, video data, image data, and the like related to the progress of the game. Furthermore, the terminal storage unit 22 may temporarily store temporary data related to a predetermined process.

The operation unit 23 may be any device capable of operating the mobile terminal 2, such as a touch panel or key buttons. The player can use the operation unit 23 to input letters, numbers, symbols, etc. When operated by the player, the operation unit 23 generates a signal corresponding to the operation. The generated signal is then supplied to the device processing unit 25 as an instruction from the player.

The display unit 24 may be any device capable of displaying video, images, etc., such as a liquid crystal display or an organic EL (Electro-Luminescence) display. The display unit 24 displays video corresponding to video data supplied from the device processing unit 25, images corresponding to image data, etc.

The device processing unit 25 includes one or more processors and their peripheral circuits. The device processing unit 25 centrally controls the overall operation of the mobile device 2, and is, for example, a CPU (Central Processing Unit). The device processing unit 25 controls the operation of the device communication unit 21, the display unit 24, etc. so that various processes of the mobile device 2 are executed in an appropriate order based on the programs stored in the device storage unit 22, the operation of the operation unit 23, etc. The device processing unit 25 executes processes based on the programs (operating system programs, driver programs, application programs, etc.) stored in the device storage unit 22. The device processing unit 25 can also execute multiple programs (application programs, etc.) in parallel.

2.1.1 Configuration of the device processing unit 25 The device processing unit 25 includes at least a browsing execution unit 251. The browsing execution unit 251 is a functional module realized by a program executed by a processor included in the device processing unit 25. Alternatively, the browsing execution unit 251 may be implemented in the mobile device 2 as firmware.

The browsing execution unit 251 acquires and displays display data related to the progress of the game. That is, in response to an instruction from the player, the browsing execution unit 251 transmits a request to acquire display data related to the progress of the game to the server 3 via the device communication unit 21. The browsing execution unit 251 also receives corresponding display data from the server 3 via the device communication unit 21. The browsing execution unit 251 creates drawing data based on the received display data. That is, the browsing execution unit 251 analyzes the received display data to identify control data and content data, lays out the identified content data based on the identified control data, and creates drawing data. The browsing execution unit 251 then outputs the created drawing data to the display unit 24.

2.2 Configuration of Server 3 FIG. 3 is a diagram showing an example of a schematic configuration of the server 3.

The server 3 progresses the game in response to requests from the mobile device 2. The server 3 also creates display data related to the progress of the game and transmits it to the mobile device 2. To this end, the server 3 includes a server communication unit 31, a server storage unit 32, and a server processing unit 33.

The server communication unit 31 includes a communication interface circuit for connecting the server 3 to the Internet 7, and communicates with the Internet 7. The server communication unit 31 then supplies data received from the mobile terminal 2 or the like to the server processing unit 33. The server communication unit 31 also transmits data supplied from the server processing unit 33 to the mobile terminal 2 or the like.

The server storage unit 32 includes at least one of a magnetic tape device, a magnetic disk device, and an optical disk device. The server storage unit 32 stores an operating system program, a driver program, an application program, data, and the like used in the processing in the server processing unit 33. For example, the server storage unit 32 stores a game program, etc., as an application program, for progressing a game and creating display data related to the results. The computer program may be installed in the terminal storage unit 22 from a computer-readable portable recording medium, such as a CD-ROM or a DVD-ROM, using a known setup program, etc. In addition, the server storage unit 32 stores, as data, a player management table (FIG. 4(a)) for managing players, a card management table (FIG. 4(b)) for managing cards, a dungeon management table (FIG. 4(c)) for managing dungeons, image data related to players, cards, and enemy characters, and the like. In addition, the server storage unit 32 may temporarily store temporary data related to a predetermined process.

Figures 4(a), (b), and (c) show examples of data structures of various management tables.

Figure 4 (a) shows the player management table. The player management table stores, for each player, the player's identification number (player ID), password, name, file name of image data, identification number (card ID) of the character card (possessed card) owned by the player, parameter information on each parameter of the player, quest card information on the character card (quest card) used in quests, stage information on the stage currently being played, RAID boss battle information on the RAID boss battle, and player IDs of other players related to the player.

The parameter information includes the player's level, experience points, HP, stamina, etc. The level is a parameter for determining the upper limit of HP, the number of other players related to the player, etc. The experience points are a parameter to which a specific value is added when a battle is won. When the experience points exceed a predetermined value, the level is incremented (increased by 1). The HP is a parameter to which a value according to the amount of damage received when attacked by an enemy character in a battle is subtracted. When the HP becomes 0, the player is defeated in that battle. Note that HP can be recovered by using a specific item, etc., but it does not recover over time. Stamina is points for executing stage processing, and is consumed each time a stage processing is executed. This stamina is an example of points owned by the player. Note that stamina is recovered after a certain amount of time has passed or by using a specific item, etc.

Quest cards consist of a preset number (e.g., three) of player cards from the owned cards, and a preset number (e.g., one) of guest cards arbitrarily designated by the server 3 from cards other than the owned cards. Guest cards have a level, experience points, and HP. These guest cards are granted to players when they complete a quest. Quest card information includes the card ID of each player card, and the card ID, level, experience points, and HP of the guest cards.

The stage information includes the identification number of the dungeon (dungeon ID) in which the player is currently performing a quest, the identification number of the stage (stage ID), etc.

The RAID boss battle information includes the card IDs of the character cards (deck cards) that make up the deck used in the RAID boss battle. The deck cards are made up of a preset number (e.g., seven) of cards from among the cards owned.

Other players related to a player include other players who belong to the same group as the player, other players who are friends with the player, other players who have rescued the player in a past battle with an enemy character or in a quest, other players who have played against the player in the past, and/or other players who belong to a group that the player has played against in the past.

Figure 4 (b) shows the card management table. For each card, the card management table stores the card ID, name, image data file name, and parameters such as rarity, attack power, and defense power of the card.

The dungeon management table is shown in FIG. 4(c). For each dungeon, the dungeon management table stores the dungeon's dungeon ID, name, image data file name, distance, number of stages, and stage IDs for each stage included in the dungeon.

The server processing unit 33 includes one or more processors and their peripheral circuits. The server processing unit 33 centrally controls the overall operation of the server 3, and is, for example, a CPU. The server processing unit 33 controls the operation of the server communication unit 31, etc., so that various processes of the server 3 are executed in an appropriate order based on the programs, etc. stored in the server storage unit 32. The server processing unit 33 executes processes based on the programs (operating system programs, driver programs, application programs, etc.) stored in the server storage unit 32. The server processing unit 33 can also execute multiple programs (application programs, etc.) in parallel.

2.2.1 Functions of the Server Processing Unit 33 FIGS. 5 to 8 are diagrams showing examples of the display screen of the mobile terminal 2 based on the display data created by the server 3. FIG.

Figure 5 (a) shows a home screen 500 that is displayed when the game is started. The home screen 500 is displayed based on home screen display data received from the server 3. A list of multiple buttons is displayed on the home screen 500. Tapping the "Go explore" button 501 causes a request to start a quest game to be sent to the server 3 via the device communication unit 21.

5(b) shows a quest start screen 510 that is displayed when the start of a quest game is requested on the home screen 500 shown in FIG. 5(a). The quest start screen 510 is displayed based on the quest start screen display data received from the server 3. The quest start screen 510 displays an image 511 of the dungeon currently in progress, the name of the dungeon, the current position in the dungeon, text 512 indicating the distance from the current position to the position of the floor boss, and a gauge 513 indicating the current position in the entire dungeon in the form of a bar graph. The quest start screen 510 further displays a "sprint" button 514, an "explore" button 515, and an end button 516. Tapping the "sprint" button 514 requests the server 3 to execute the processing of multiple stages continuously via the terminal communication unit 21. On the other hand, tapping the "explore" button 515 requests the server 3 to execute the processing of one stage normally via the terminal communication unit 21. Additionally, tapping the end button 516 requests the server 3 to end the quest game via the device communication unit 21.

Figure 5 (c) shows a normal battle screen 520 that is displayed when normal execution is requested on the quest start screen 510 shown in Figure 5 (b) and a normal battle is executed on that stage. The normal battle screen 520 is displayed based on normal battle screen display data received from the server 3. The normal battle is executed between the player cards and guest cards used in the quest game and an enemy character. The normal battle screen 520 displays text 521 indicating that a normal battle will be executed with an enemy character, an image 522 of the enemy character, and a "fight" button 523. Tapping the "fight" button 523 requests the execution of a normal battle to the server 3 via the device communication unit 21.

5(d) shows a battle result screen 530 that is displayed when a normal battle is requested on the normal battle screen 520 shown in FIG. 5(c). The battle result screen 530 is displayed based on the battle result screen display data received from the server 3. The battle result screen 530 displays text 531 similar to the text 512 in FIG. 5(b), a gauge 532 similar to the gauge 513 in FIG. 5(b), and text and an image 533 that show the results of the battle. The battle result screen 530 further displays a "sprint" button 514, an "explore" button 515, and an end button 516. Note that in addition to the information represented by the text 512 in FIG. 5(b), the text 531 indicates from which position to which position the player has moved by executing the stage process.

6(a) shows an item granting screen 600 that is displayed when normal execution is requested on the quest progress screen 510 shown in FIG. 5(b) and an item is granted on that stage. The item granting screen 600 is displayed based on the item granting screen display data received from the server 3. The item granting screen 600 displays text 601 similar to the text 512 in FIG. 5(b), a gauge 602 similar to the gauge 513 in FIG. 5(b), and text and an image 603 indicating that an item has been granted and the granted item. The item granting screen 600 further displays a "Sprint" button 514, an "Explore" button 515, and an end button 516. In addition to the information represented by the text 512 in FIG. 5(b), the text 601 also indicates from which position to which position the player has moved by executing the stage process. Items granted on each stage include strengthening items for strengthening the attack power or defense power of the character card, and recovery items for recovering the player's stamina or HP. Additionally, the items given at each stage may include a map item for progressing to other dungeons, so that players can progress to other dungeons not only when they clear the current dungeon, but also when they obtain that map item.

6(b) shows a character card granting screen 610 that is displayed when normal execution is requested on the quest progress screen 510 shown in FIG. 5(b) and a character card is granted on that stage. The character card granting screen 610 is displayed based on the character card granting screen display data received from the server 3. The character card granting screen 610 displays text 611 similar to the text 512 in FIG. 5(b), a gauge 612 similar to the gauge 513 in FIG. 5(b), and text and an image 613 indicating that a character card has been granted and representing the granted character card. The character card granting screen 610 further displays a "sprint" button 514, an "exploration" button 515, and an end button 516. In addition to the information represented by the text 512 in FIG. 5(b), the text 611 indicates from which position to which position the character has moved by executing the stage process. The character card may be one type of item, and the character card may be granted on the item granting screen in FIG. 6(a).

6(c) shows a RAID boss battle screen 620 that is displayed when normal execution is requested on the quest progress screen 510 shown in FIG. 5(b) and a RAID boss battle is executed on that stage. The RAID boss battle screen 620 is displayed based on the RAID boss battle screen display data received from the server 3. The RAID boss battle is a battle in which multiple players related to the player cooperate to fight a RAID boss that is stronger than the enemy character in the normal battle. The RAID boss battle is performed using a deck made up of deck cards. The RAID boss battle screen 620 displays text 621 indicating that a battle with a RAID boss will be executed, an image 622 of the RAID boss, and a "Fight" button 623. Tapping the "Fight" button 623 requests the server 3 to execute the RAID boss battle via the terminal communication unit 21. In this case, the server 3 executes the RAID boss battle, and a battle result screen similar to the battle result screen 530 shown in FIG. 5(d) is displayed. The RAID boss battle may be started according to the player's selection as described above, or it may be started automatically as soon as the player reaches the location where the RAID boss is located.

6(d) shows a floor boss battle screen 630 that is displayed when normal execution is requested on the quest progress screen 510 shown in FIG. 5(b) and the location of the floor boss is reached. The floor boss battle is conducted between the player card and guest card used in the quest game and the floor boss. The floor boss battle screen 630 is displayed based on the floor boss battle screen display data received from the server 3. The floor boss battle screen 630 displays text 631 similar to the text 512 in FIG. 5(b), a gauge 632 similar to the gauge 513 in FIG. 5(b), and a "Challenge the boss" button 633. Note that the text 631 indicates that the location of the floor boss has been reached. Tapping the "Challenge the boss" button 633 requests the server 3 to execute the floor boss battle via the terminal communication unit 21. In this case, the battle result screen 530 shown in FIG. 5(d) is displayed. The floor boss battle may be started according to the player's selection as described above, or may be started automatically as soon as the player reaches the location of the floor boss.

7(a), (b) and (c) respectively show continuous execution screens 700, 710 and 720 which are displayed in sequence when continuous execution is requested on the quest progress screen 510 shown in FIG. 5(b). The continuous execution screens 700, 710 and 720 are displayed based on continuous execution screen display data received from the server 3. The continuous execution screen 700 shows the player cards 701-703 and the guest card 704 moving rightward and encountering the enemy character 705 that will be fought in the first stage. The continuous execution screen 710 shows the player cards 701-703 and the guest card 704 moving rightward and encountering the character card 706 that will be given in the next stage. The continuous execution screen 720 shows text 721 indicating the result of continuous execution (success/failure), the player cards 701-703 and the guest card 704, the enemy character 705 that was fought in each stage, and the given character cards 706 and 707. In this way, the continuous execution screen sequentially displays enemy characters that will be fought in each stage that is executed consecutively, character cards or items that will be granted, etc., and finally displays the results of the continuous execution.

7(d) shows a continuous execution result screen 730 displayed following the continuous execution screens 700, 710, and 720. The continuous execution result screen 730 is displayed based on the continuous execution result screen display data received from the server 3. The continuous execution result screen 730 displays text 731 similar to the text 512 in FIG. 5(b), a gauge 732 similar to the gauge 513 in FIG. 5(b), text 733 showing the execution result of the process of each stage executed continuously, and an image 735 showing the character card and/or item acquired in each stage. As shown in the text 531 in FIG. 5(d), the text 601 in FIG. 6(a), the text 611 in FIG. 6(b), and the text 631 in FIG. 6(d), in the case of normal execution, it is displayed that the distance of one stage (10 m) has progressed, but the text 731 displays that the distance of multiple stages executed continuously (70 m) has progressed. The text 733 displays the result of the battle in each stage and the character card and/or item acquired in each stage. Furthermore, if the continuous execution results in reaching the location of the floor boss, a "Challenge Boss" button 734 will also be displayed on the continuous execution result screen 730.

8(a) and (b) show continuous execution screens 800 and 810 that are displayed when continuous execution is requested on the quest progress screen 510 shown in FIG. 5(b) and a RAID boss battle is executed on a specific stage. If a battle with an enemy character, the granting of a character card, and/or the granting of an item occurs before the execution of the RAID boss battle, the continuous execution screens 800 and 810 are displayed following the continuous execution screens 700 and/or 710 shown in FIG. 7(a) and (b). The continuous execution screen 800 shows the player cards 701 to 703 and the guest card 704 moving to the right and encountering the RAID boss 801. If a RAID boss battle is executed during continuous execution, the continuous execution is interrupted and the continuous execution screen 810 is displayed. The continuous execution screen 810 displays text 811 indicating that a RAID boss has been encountered, the RAID boss 812, the player cards 701 to 703, and the guest card 704.

8(c) shows a continuous execution result screen 820 displayed following the continuous execution screens 800 and 810. The continuous execution result screen 820 displays text 821 similar to the text 512 in FIG. 5(b), a gauge 822 similar to the gauge 513 in FIG. 5(b), text 826 showing the results of the processing of each stage performed continuously until the RAID boss is encountered, and an image 827 showing the character card and/or item acquired in each stage. The continuous execution result screen 820 also displays an image 823 of the RAID boss, a "Select deck" button 824, and a "Fight" button 825. As shown in FIGS. 8(a) to (c), by displaying the image of the RAID boss and the fact that the RAID boss has appeared on the screen, the player can know that the continuous execution has been interrupted by the appearance of the RAID boss, and can smoothly transition to the RAID boss battle.

2.2.2. Configuration of the server processing unit 33 In order to realize the above functions, the server processing unit 33 includes a control unit 331, a game progression unit 332, a normal execution unit 333, and a continuous execution unit 334. Each of these units is a functional module realized by a program executed by a processor included in the server processing unit 33. Alternatively, each of these units may be implemented in the server 3 as firmware.

The processing performed by the control unit 331 is described below.

The control unit 331 controls the start and progress of the game, and instructs the game progression unit 332 and other units to execute processing as appropriate.

When the control unit 331 receives a game start request from the portable device 2 via the server communication unit 31, it passes the received game start request to a player authentication unit (not shown) and instructs it to execute authentication processing. The game start request includes a player ID and a password. When the player authentication unit has successfully authenticated the player, the control unit 331 creates home screen display data. The control unit 331 creates home screen display data for displaying buttons and the like for receiving instructions for game progress, etc., in a predetermined layout. The control unit 331 also transmits the created home screen display data to the portable device 2 via the server communication unit 31.

When the control unit 331 receives a game progress request from the mobile device 2 via the server communication unit 31, it passes the received game progress request to the game progress unit 332 and instructs it to execute game progress processing. The game progress request includes a player ID and a request type. The request type is specified as any one of a quest start request, a normal execution request, a normal battle execution request, a RAID boss battle execution request, a floor boss battle execution request, a continuous execution request, an end request, etc. In addition, the control unit 331 transmits the display data for each screen received from the game progress unit 332 to the mobile device 2 via the server communication unit 31.

The processing performed by the game progression unit 332 is explained below.

The game progression unit 332 controls the progress of the game and instructs the normal execution unit 333 or the continuous execution unit 334 to execute normal execution processing or continuous execution processing, respectively, as appropriate. In addition, the game progression unit 332 passes display data for each screen created by the game progression unit 332, normal execution unit 333, or continuous execution unit 334 to the control unit 331.

The game progression unit 332 identifies the request from the mobile device 2 from the request type included in the game progression request received from the control unit 331.

If the identified request is a quest start request, the game progression unit 332 reads the player management table and identifies the dungeon ID and stage ID of the dungeon and stage being played by the player with the player ID included in the game progress request. The game progression unit 332 then creates quest start screen display data for displaying a quest start screen that executes processing of the stage of the dungeon corresponding to the identified dungeon ID and stage ID. The game progression unit 332 reads the image, name, distance, information related to the stage, etc. corresponding to the dungeon ID from the dungeon management table, identifies the position corresponding to the stage ID, and creates quest start screen display data for displaying each piece of information, button, etc. in a predetermined layout.

If the identified request is a normal execution request, the game progression unit 332 passes the player ID included in the game progression request to the normal execution unit 333 and instructs it to execute normal execution processing.

If the identified request is a normal battle execution request, the game progression unit 332 reads the player management table and identifies the HP of the player whose player ID is included in the game progression request, the player card, the guest card, and the HP of the guest card. Furthermore, the game progression unit 332 reads the card management table and identifies the attack power and defense power of the identified player card and guest card.

The game progression unit 332 determines the amount of damage to be inflicted on the enemy character based on the attack power of the player card, the attack power of the guest card, and the defense power of the enemy character, and subtracts the determined amount of damage from the HP of the enemy character. On the other hand, the game progression unit 332 determines the amount of damage to be inflicted on the player based on the attack power of the enemy character and the defense power of the player card, and subtracts the determined amount of damage from the HP of the player. Also, the game progression unit 332 determines the amount of damage to be inflicted on the guest card based on the attack power of the enemy character and the defense power of the guest card, and subtracts the determined amount of damage from the HP of the guest card. Then, if the HP of the enemy character reaches 0 first, the game progression unit 332 determines that the player has won, and if the HP of the player card or the HP of the guest card reaches 0 first, the game progression unit 332 determines that the player has lost.

If the player wins, the game progression unit 332 adds a specific value to the player's experience value in the player management table, and if the player's experience value exceeds a predetermined value, it increments the player's level (increases by 1). Similarly, the game progression unit 332 adds a specific value to the experience value of a guest card, and if the experience value of the guest card exceeds a predetermined value, it increments the level of the guest card (increases by 1). The game progression unit 332 then creates battle execution screen display data for displaying battle performance images and battle result screen display data for displaying the results of the battle.

If the identified request is a request to execute a RAID boss battle, the game progression unit 332 reads the player management table and identifies other players associated with the player whose player ID is included in the game progression request. The game progression unit 332 also reads the player management table and identifies the deck cards of the player whose player ID is included in the game progression request. Furthermore, the game progression unit 332 reads the card management table, identifies the attack power and defense power of each identified deck card, and calculates the sums of the attack powers and defense powers of each deck card as the attack power and defense power of the deck, respectively.

The game progression unit 332 determines the amount of damage to be inflicted on the RAID boss based on the attack power of the deck and the defense power of the RAID boss, and subtracts the determined amount of damage from the HP of the RAID boss. On the other hand, the game progression unit 332 determines the amount of damage to be inflicted on the player based on the attack power of the RAID boss and the defense power of the deck, and subtracts the determined amount of damage from the HP of the player. Then, when the HP of the enemy character becomes 0, the game progression unit 332 determines that the player has won. On the other hand, when the HP of the player becomes 0, the game progression unit 332 continues to execute a battle with the RAID boss using the character cards of other players related to the player. Then, when the HP of the enemy character becomes 0, the game progression unit 332 determines that the player has won, and when the HP of all other players related to the player become 0, the game progression unit 332 determines that the player has lost.

If the player wins, the game progression unit 332 adds a specific value to the player's experience value in the player management table, and if the player's experience value exceeds a predetermined value, it increments the player's level (increases by 1). Similarly, the game progression unit 332 also adds a specific value to the experience values of all other players related to the player, and if each player's experience value exceeds a predetermined value, it increments the player's level (increases by 1). The game progression unit 332 then creates battle execution screen display data for displaying battle performance images and battle result screen display data for displaying the results of the battle.

When the identified request is a floor boss battle execution request, the game progression unit 332 executes a battle between the player card and the guest card and the floor boss in the same manner as when the identified request is a normal battle execution request. The game progression unit 332 then creates battle execution screen display data and battle result screen display data for displaying the performance images and result details of the battle.

If the identified request is a continuous execution request, the game progression unit 332 passes the player ID included in the game progression request to the continuous execution unit 334 and instructs it to execute the continuous execution process.

If the identified request is an end request, the game progression unit 332 ends the quest game and instructs the control unit 331 to create home screen display data. In this case, the control unit 331 creates home screen display data and passes the created home screen display data to the game progression unit 332.

The processing performed by the normal execution unit 333 is described below.

The normal execution unit 333 performs normal execution processing to execute processing for one of the multiple stages in the quest game in accordance with a single instruction from the player (tapping the "Explore" button). The normal execution unit 333 also passes display data for each screen created in the normal execution processing to the game progression unit 332.

The normal execution unit 333 reads the player management table and identifies the stamina of the player whose player ID is included in the game progress request, as well as the dungeon ID and stage ID of the dungeon and stage being executed. On the condition that the identified stamina is equal to or greater than the consumption points required to execute the processing of one stage, the normal execution unit 333 consumes (subtracts) consumption points from the stamina to progress one stage. The normal execution unit 333 progresses the stage by updating the stage ID in the player management table.

If the stage to which the player has progressed is the final stage of the dungeon, the normal execution unit 333 determines that the event in that stage will be a floor boss battle. In this case, the normal execution unit 333 creates floor boss battle screen display data for displaying, in a predetermined layout, a notice that the player has reached the location of the floor boss and a "Challenge Boss" button, etc.

On the other hand, if the stage to which the player has progressed is not the final stage of the dungeon, the normal execution unit 333 determines the event in that stage to be one of the following, based on a predetermined criterion (for example, with a predetermined probability using pseudo-random numbers generated using the current time or the like as a seed).

When the normal execution unit 333 determines that the event in that stage is a normal battle, it determines an enemy character based on predetermined criteria and creates normal battle screen display data for displaying the enemy character and the "fight" button, etc., in a predetermined layout.

On the other hand, when the normal execution unit 333 determines that the event in that stage is an item granting event, it determines the item to grant based on predetermined criteria, and grants the determined item to the user. The normal execution unit 333 then creates item granting screen display data for displaying the granted items, etc. in a predetermined layout.

On the other hand, when the normal execution unit 333 determines that the event in that stage is to grant a character card, it determines the character card to be granted based on predetermined criteria, and grants the determined character card to the user. Then, the normal execution unit 333 creates character card granting screen display data for displaying the granted character card, etc. in a predetermined layout.

On the other hand, if the normal execution unit 333 determines that the event in that stage is a RAID boss battle, it creates RAID boss battle screen display data for displaying the RAID boss and the "Fight" button, etc., in a specified layout.

The processing performed by the continuous execution unit 334 is described below.

The continuous execution unit 334 performs continuous execution processing to execute a predetermined number (e.g., 10) of stages that are two or more of the multiple stages in the quest game in accordance with a single instruction from the player (tapping the "sprint" button). The continuous execution unit 334 also passes the display data for each screen created in the continuous execution processing to the game progression unit 332.

The continuous execution unit 334, like the normal execution unit 333, identifies the player's stamina, the dungeon ID and stage ID of the dungeon and stage being executed, and, on condition that the identified stamina is equal to or greater than the consumed points, consumes consumed points from the stamina to progress through the stages one by one. Note that, rather than consuming consumed points from the stamina each time a stage is progressed, the continuous execution unit 334 may consume all consumed points for the stages that have been executed continuously from the stamina when the continuous execution process ends.

If the stage to which the player has progressed is the final stage of the dungeon, the continuous execution unit 334 determines that the event in that stage will be a floor boss battle. In this case, the continuous execution unit 334 ends the continuous execution process and does not continuously execute the process for stages after that stage.

On the other hand, if the stage to which the player has progressed is not the final stage of the dungeon, the continuous execution unit 334 determines the event in that stage to be one of the following, based on a predetermined criterion: a normal battle, an item grant, a character card grant, or a RAID boss battle.

When the continuous execution unit 334 determines that the event in that stage is a normal battle, it determines an enemy character based on a predetermined criterion. Then, the continuous execution unit 334 executes the normal battle in the same manner as the normal battle executed by the game progression unit 332.

If the player's HP or the guest card's HP becomes 0 as a result of the normal battle and the player is defeated, the continuous execution unit 334 ends the continuous execution process and does not continuously execute the process of the stage after that stage. In this way, if the conditions for clearing a stage are not met, the continuous execution unit 334 does not continuously execute the process of the stage after that stage. This makes it possible to prevent the player from mistakenly progressing to a stage to which they should not progress.

In addition, if the player's level or the guest card's level increases as a result of a normal battle, the continuous execution unit 334 also ends the continuous execution process and does not execute the process of the stage after that stage in succession. This allows the player to know in real time that the level has increased, and after the level has increased, the player can change various settings and proceed to the next stage.

In addition, if the player's HP or the guest card's HP is equal to or lower than a predetermined value before the normal battle, the continuous execution unit 334 may end the continuous execution process and not execute the process of the stage after that stage in succession. The predetermined value is set, for example, to a value predicted to be necessary to win the next battle. In this way, if the conditions for clearing the stage to be executed are not met, the continuous execution unit 334 does not execute the process of that stage and the stages after that in succession. This allows the player to recover HP before engaging in a normal battle, and prevents the player from unexpectedly being defeated by an enemy character due to continuous normal battles being conducted by the continuous execution process. For example, if an item that restores HP that has reached 0 is a special item different from an item that restores HP that is not 0, the player can prevent the HP from reaching 0 and consuming the special item.

On the other hand, if the continuous execution unit 334 determines that the event in that stage will grant an item, it determines the item to grant based on predetermined criteria.

On the other hand, if the continuous execution unit 334 determines that the event in that stage will award a character card, it determines the character card to be awarded based on predetermined criteria.

On the other hand, if the continuous execution unit 334 determines that the event in that stage is a RAID boss battle, it ends the continuous execution process and does not continuously execute the processing of stages after that stage.

The continuous execution unit 334 ends the continuous execution process when the number of stages progressed reaches a predetermined number, i.e., when all the processing of the predetermined number of stages has been executed.

When the continuous execution process ends, the continuous execution unit 334 grants to the player all items and character cards that were decided to be granted to the player during the continuous execution.

Furthermore, when the continuous execution process ends, the continuous execution unit 334 creates continuous execution screen display data that shows the enemy characters, items, and/or character cards that have been fought in each of all the stages that have been continuously executed being displayed in sequence. Note that, if the event in the last stage of the continuous execution is a RAID boss battle, the continuous execution unit 334 creates continuous execution screen display data in which the RAID boss is displayed following the enemy characters, items, and/or character cards.

The continuous execution unit 334 also creates continuous execution result screen display data for displaying the execution results of all the consecutively executed stages in a predetermined layout. If the last stage of the consecutive execution is the last stage of the dungeon, the continuous execution unit 334 creates continuous execution result screen display data that further displays a "Challenge Boss" button, etc. If the last stage of the consecutive execution is a normal battle and the player's HP or the HP of the guest card becomes 0 and the player is defeated, the continuous execution unit 334 creates continuous execution result screen display data that further displays the fact that the HP has become 0, etc. If the last stage of the consecutive execution is a normal battle and the level of the player or the guest card has increased, the continuous execution unit 334 creates continuous execution result screen display data that further displays the fact that the level has increased, etc. If the last stage of the consecutive execution is a RAID boss battle, the continuous execution unit 334 creates continuous execution result screen display data that further displays the RAID boss and a "Fight" button, etc. Furthermore, if the stamina is less than the consumed points, the continuous execution unit 334 creates continuous execution result screen display data that further displays a message to the effect that the stage process cannot be executed due to insufficient stamina.

The server processing unit 33 may change the benefits given to the player in the normal execution process and in the consecutive execution process. For example, the consecutive execution unit 334 may count the number of consecutive executions, and when the number of consecutive executions reaches a predetermined number or more, may give the player a benefit such as an item or a level-up.

For example, when performing continuous execution processing, the server processing unit 33 may grant items with higher parameters, such as level, attack power, defense power, HP, rarity, skill activation rate, number of attacks in one turn, number of defenses in one battle, or a larger number of items, than the items granted in normal execution processing. Conversely, when performing continuous execution processing, the server processing unit 33 may grant items with lower parameters, or a smaller number of items, than the items granted in normal execution processing.

Similarly, the server processing unit 33 may change the points consumed in the case of normal execution processing and in the case of continuous execution processing. In this case, the server processing unit 33 may make the points consumed when performing continuous execution processing smaller than the points consumed when performing normal execution processing. Conversely, the server processing unit 33 may make the points consumed when performing continuous execution processing larger than the points consumed when performing normal execution processing.

Similarly, the server processing unit 33 may change parameters such as attack power, defense power, and/or HP in normal battles between normal execution processing and continuous execution processing. In this case, the server processing unit 33 may make the parameters higher when performing continuous execution processing than when performing normal execution processing. Conversely, the server processing unit 33 may make the parameters lower when performing continuous execution processing than when performing normal execution processing.

Similarly, the server processing unit 33 may change the experience points granted when a normal battle is won between normal execution processing and continuous execution processing. In this case, the server processing unit 33 may grant higher experience points when continuous execution processing is performed than experience points granted when normal execution processing is performed. Conversely, the server processing unit 33 may grant lower experience points when continuous execution processing is performed than experience points granted when normal execution processing is performed.

By making the bonus awarded when performing consecutive execution processing larger than the bonus awarded when performing normal execution processing, consecutive execution processing becomes more attractive to players, and the utilization rate of consecutive execution processing can be increased. This allows players to clear dungeons in a shorter time, and allows game providers to have players complete more dungeons. On the other hand, if the bonus awarded when performing consecutive execution processing is smaller than the bonus awarded when performing normal execution processing, players can obtain larger bonuses if they take a long time to clear a dungeon. This allows players to strategically choose whether to perform consecutive execution processing or normal execution processing, and can improve the appeal of the game.

In addition, the above-mentioned benefits granted to a player when consecutive execution processing is performed may also be granted to other players related to the player. For example, when a player who performed consecutive execution processing is accompanied by another player into a dungeon, the server processing unit 33 grants the above-mentioned benefits to the other players who accompanied the player. Alternatively, the server processing unit 33 may grant the above-mentioned benefits to other players who participated in a RAID boss battle.

Figure 9 is a diagram showing an example of an operation sequence of the game system 1. Note that the operation sequence described below is executed mainly by the device processing unit 25 and the server processing unit 33 in cooperation with each element of the mobile device 2 and the server 3, based on programs previously stored in the device storage unit 22 and the server storage unit 32.

The player issues an instruction to start the game using the operation unit 23 of the mobile device 2. The browsing execution unit 251 accepts a player ID and a password from the player using the operation unit 23, and transmits a game start request including the accepted player ID and password to the server 3 via the device communication unit 21 (step S101).

When the control unit 331 of the server 3 receives a game start request from the mobile device 2 via the server communication unit 31, it passes the player ID and password included in the received game start request to the player authentication unit and instructs it to execute authentication processing (step S102).

If authentication by the player authentication unit is successful, the control unit 331 creates home screen display data (step S103).

The control unit 331 transmits the created home screen display data to the mobile device 2 via the server communication unit 31 (step S104).

When the browsing execution unit 251 of the mobile device 2 receives home screen display data from the server 3 via the device communication unit 21, it creates drawing data based on the received home screen display data. In addition, the browsing execution unit 251 outputs the created drawing data to the display unit 24 to display the home screen 500 (step S105).

Next, in response to an instruction from the player using the operation unit 23, the browsing execution unit 251 transmits a game progress request including a request type corresponding to the instruction and the player's player ID to the server 3 via the device communication unit 21 (step S106).

When the "Go explore" button 501 on the home screen 500 in FIG. 5(a) is tapped, the request type becomes a quest start request. When the "Explore" button 515 on the quest start screen 510 in FIG. 5(b), the battle result screen 530 in FIG. 5(d), the item grant screen 600 in FIG. 6(a), the character card grant screen 610 in FIG. 6(b), etc. is tapped, the request type becomes a normal execution request. When the "Fight" button 523 on the normal battle screen 520 in FIG. 5(c) is tapped, the request type becomes a normal battle execution request. When the "Fight" button 623 on the RAID boss battle screen 620 in FIG. 6(c) is tapped, the request type becomes a RAID boss battle execution request. In addition, when the "Challenge the boss" button 633 on the floor boss battle screen 630 in FIG. 6(d) or the "Challenge the boss" button 734 on the continuous execution result screen 730 in FIG. 7(d) is tapped, the request type becomes a floor boss battle execution request. In addition, when the "Sprint" button 514 on the quest start screen 510 in FIG. 5(b), the battle result screen 530 in FIG. 5(d), the item grant screen 600 in FIG. 6(a), the character card grant screen 610 in FIG. 6(b), or the like is tapped, the request type becomes a continuous execution request. In addition, when the end button 516 on the quest start screen 510 in FIG. 5(b), the battle result screen 530 in FIG. 5(d), the item grant screen 600 in FIG. 6(a), the character card grant screen 610 in FIG. 6(b), or the like is tapped, the request type becomes an end request.

When the control unit 331 receives a game progress request from the mobile device 2 via the server communication unit 31, it passes the received game progress request to the game progress unit 332 and instructs it to execute game progress processing. When the game progress processing is instructed by the control unit 331 to be executed, the game progress unit 332 executes the game progress processing (step S107). In the game progress processing, each unit of the server processing unit 33 creates display data corresponding to the received game progress request, and the game progress unit 332 passes the created display data to the control unit 331. Details of the game progress processing will be described later.

Next, the control unit 331 transmits each display data received from the game progression unit 332 to the mobile device 2 via the server communication unit 31 (step S108).

When the browsing execution unit 251 receives each display data etc. from the server 3 via the device communication unit 21, it creates drawing data based on the received display data. The browsing execution unit 251 also outputs the created drawing data to the display unit 24 and displays the corresponding screen (step S109). Thereafter, the processing of steps S106 to S109 is repeated.

Figure 10 is a diagram showing an example of the operation flow of the game progression processing by the game progression unit 332. The game progression processing shown in Figure 10 is executed in step S107 of Figure 9.

First, the game progression unit 332 identifies the request from the mobile device 2 from the request type included in the game progression request received from the control unit 331 (step S201).

If the identified request is a quest start request (step S202-Yes), the game progression unit 332 creates quest start screen display data (step S203). Next, the game progression unit 332 passes the created quest start screen display data to the control unit 331 (step S215), and ends the series of steps.

On the other hand, if the identified request is a normal execution request (step S202-No, step S204-Yes), the game progression unit 332 instructs the normal execution unit 333 to execute normal execution processing, and the normal execution unit 333 executes the normal execution processing (step S205). In the normal execution processing, the normal execution unit 333 executes processing of one stage of the quest game, creates display data for each screen according to the results, and passes it to the game progression unit 332. Details of the normal execution processing will be described later. Next, the game progression unit 332 passes the display data received from the game progression unit 332 to the control unit 331 (step S215), and ends the series of steps.

On the other hand, if the identified request is a normal battle execution request (step S204-No, step S206-Yes), the game progression unit 332 executes the normal battle and creates battle execution screen display data and battle result screen display data (step S207). Next, the game progression unit 332 passes the created battle execution screen display data and battle result screen display data to the control unit 331 (step S215), and ends the series of steps.

On the other hand, if the identified request is a RAID boss battle execution request (step S206-No, step S208-Yes), the game progression unit 332 executes the RAID boss battle and creates battle execution screen display data and battle result screen display data (step S209). Next, the game progression unit 332 passes the created battle execution screen display data and battle result screen display data to the control unit 331 (step S215), and ends the series of steps.

On the other hand, if the identified request is a floor boss battle execution request (step S208-No, step S210-Yes), the game progression unit 332 executes the floor boss battle and creates battle execution screen display data and battle result screen display data (step S211). Next, the game progression unit 332 passes the created battle execution screen display data and battle result screen display data to the control unit 331 (step S215), and ends the series of steps.

On the other hand, if the identified request is a continuous execution request (step S210-No, step S212-Yes), the game progression unit 332 instructs the continuous execution unit 334 to execute a continuous execution process, and the continuous execution unit 334 executes the continuous execution process (step S213). In the continuous execution process, the continuous execution unit 334 executes the processes of multiple stages of the quest game continuously, creates continuous execution screen display data and continuous execution result screen display data according to the results, and passes them to the game progression unit 332. Details of the continuous execution process will be described later. Next, the game progression unit 332 passes the continuous execution screen display data and continuous execution result screen display data received from the game progression unit 332 to the control unit 331 (step S215), and ends the series of steps.

On the other hand, if the identified request is none of the above, i.e., it is an end request (step S212-No), the game progression unit 332 ends the quest game and instructs the control unit 331 to create home screen display data. The control unit 331 creates the home screen display data and passes it to the game progression unit 332 (step S214). Next, the game progression unit 332 passes the successive execution screen display data and successive execution result screen display data received from the game progression unit 332 to the control unit 331 (step S215), and ends the series of steps.

Figure 11 shows an example of the operation flow of normal execution processing by the normal execution unit 333. The normal execution processing shown in Figure 11 is executed in step S205 of Figure 10.

First, the normal execution unit 333 determines whether the stamina in the player management table is equal to or greater than the consumed points (step S301).

If the stamina is less than the consumed points (step S301-No), the normal execution unit 333 creates display data to display that the stage process cannot be executed due to insufficient stamina (step S302). Next, the normal execution unit 333 passes the created display data to the game progression unit 332 (step S315), and ends the series of steps.

On the other hand, if the stamina is equal to or greater than the consumed points (step S301-No), the normal execution unit 333 subtracts the consumed points from the stamina (step S303) and advances one stage (step S304).

Next, the normal execution unit 333 determines whether the stage to which the player has progressed is the final stage of the dungeon (step S305).

If the stage to which the player has progressed is the final stage of the dungeon (step S305-Yes), the normal execution unit 333 determines that the event in that stage will be a floor boss battle, and creates floor boss battle screen display data (step S306). Next, the normal execution unit 333 passes the created floor boss battle screen display data to the game progression unit 332 (step S315), and ends the series of steps.

On the other hand, if the stage to which the player has progressed is not the final stage of the dungeon (step S305-No), the normal execution unit 333 determines the event for that stage to be one of the following, a normal battle, an item grant, a character card grant, or a RAID boss battle, based on predetermined criteria (step S307).

If the normal execution unit 333 determines that the event in that stage is a normal battle (step S308-Yes), it determines an enemy character based on predetermined criteria and creates normal battle screen display data (step S309). Next, the normal execution unit 333 passes the created normal battle screen display data to the game progression unit 332 (step S315), and ends the series of steps.

On the other hand, if the normal execution unit 333 determines that the event in that stage is to grant an item (step S308-No, step S310-Yes), it determines the item to grant based on predetermined criteria, grants the item to the user, and creates item granting screen display data (step S311). Next, the normal execution unit 333 passes the created item granting screen display data to the game progression unit 332 (step S315), and ends the series of steps.

On the other hand, if the normal execution unit 333 determines that the event in that stage is to grant a character card (step S310-No, step S312-Yes), it determines the character card to be granted based on predetermined criteria, grants the character card to the user, and creates character card grant screen display data (step S313). Next, the normal execution unit 333 passes the created character card grant screen display data to the game progression unit 332 (step S315), and ends the series of steps.

On the other hand, if the normal execution unit 333 determines that the event in that stage is something other than the granting of a normal battle item or a character card, i.e., if it determines that it is a RAID boss battle (step S310-No), it creates RAID boss battle screen display data (step S312). Next, the normal execution unit 333 passes the created RAID boss battle screen display data to the game progression unit 332 (step S315), and ends the series of steps.

Figure 12 shows an example of the operation flow of the continuous execution process by the continuous execution unit 334. The continuous execution process shown in Figure 12 is executed in step S213 of Figure 10.

First, the continuous execution unit 334 determines whether the stamina in the player management table is equal to or greater than the consumed points (step S401).

If the stamina is less than the consumed points (step S401-No), the continuous execution unit 334 proceeds to step S416.

On the other hand, if the stamina is equal to or greater than the consumed points (step S401-Yes), the continuous execution unit 334 subtracts the consumed points from the stamina (step S402) and advances the stage by one (step S403).

Next, the continuous execution unit 334 determines whether the stage to which the player has progressed is the final stage of the dungeon (step S404).

If the stage to which the player has progressed is the final stage of the dungeon (step S404-Yes), the continuous execution unit 334 determines that the event in that stage will be a floor boss battle, and transitions to step S416.

On the other hand, if the stage to which the player has progressed is not the final stage of the dungeon (step S404-No), the continuous execution unit 334 determines the event in that stage to be one of the following, a normal battle, an item grant, a character card grant, or a RAID boss battle, based on a predetermined criterion (step S405).

If the continuous execution unit 334 determines that the event in that stage is a normal battle (step S406-Yes), it determines an enemy character based on predetermined criteria and executes a normal battle (step S407).

Next, the continuous execution unit 334 determines whether or not the player has lost the normal battle because the player's HP or the guest card's HP has become 0 (step S408). If the player has lost (step S408-Yes), the continuous execution unit 334 transitions to step S416.

On the other hand, if the player wins (step S408: No), the continuous execution unit 334 determines whether the level of the player or the guest card has increased (step S409). If the player's level has increased (step S409: Yes), the continuous execution unit 334 proceeds to step S416, and if the player's level has not increased (step S409: No), the continuous execution unit 334 proceeds to step S415.

On the other hand, if the continuous execution unit 334 determines that the event in that stage is to award an item (step S406-No, step S410-Yes), it determines the item to be awarded to the player based on predetermined criteria (step S411) and proceeds to step S415.

On the other hand, if the continuous execution unit 334 determines that the event in that stage is to award a character card (step S410-No, step S412-Yes), it determines the character card to be awarded to the player based on predetermined criteria (step S413) and proceeds to step S415.

On the other hand, if the continuous execution unit 334 determines that the event in that stage will be something other than the normal battle item grant or character card grant, i.e., a RAID boss battle (step S412-No), the continuous execution unit 334 starts the RAID boss battle (step S414) and proceeds to step S416.

In step S415, the continuous execution unit 334 determines whether the number of stages to which the player has progressed has reached a predetermined number (step S415). If the number of stages to which the player has progressed has not reached the predetermined number (step S415-No), the continuous execution unit 334 returns the process to step S401 and repeats the processes from step S401 onward.

On the other hand, if the number of stages progressed reaches a predetermined number (step S415-Yes), the continuous execution unit 334 grants the player all of the items and character cards determined in step S411 (step S416).

Next, the continuous execution unit 334 creates continuous execution screen display data that shows the enemy characters, assigned items, assigned character cards, or RAID bosses that have been fought in each of all the continuously executed stages being displayed in sequence. The continuous execution unit 334 also creates continuous execution result screen display data for displaying the results of each continuously executed stage, etc., in a predetermined layout (step S417).

Next, the normal execution unit 333 passes the created successive execution screen display data and successive execution result screen display data to the game progression unit 332 (step S418), and ends the series of steps.

As explained above, the server 3 executes the processing of one stage in accordance with a normal execution instruction from the player, and executes the processing of multiple stages consecutively in accordance with a consecutive execution instruction from the player. This allows the player to execute the processing of multiple stages consecutively with a single instruction, reducing the time and effort required to clear a dungeon and maintaining the player's motivation to continue playing the game.

For example, if the distance of one stage is 10 m and it takes three seconds to clear one stage, in order to clear a 200 m dungeon, in normal execution, the user would need to perform 20 commands, which would take 60 seconds. On the other hand, in continuous execution, the user can clear the dungeon in six seconds with two operations.

In addition, in the continuous execution process of this embodiment, instead of progressing to the dungeon goal in one go, the player progresses through the stages a predetermined number at a time, allowing the player to get the feeling that they are controlling the progress of the quest within a certain range.

Note that the present invention is not limited to this embodiment. For example, in this embodiment, the server 3 executes the game, but the server 3 may be omitted and the mobile device 2 may execute the game. The device storage unit 22 stores information about the player of the mobile device 2 from the player management table, a card management table, a dungeon management table, etc., and the device processing unit 25 has each unit with the same function as each unit of the server processing unit 33 of the server 3 in addition to the units shown in FIG. 2. The device processing unit 25 transmits and receives each piece of information within the device processing unit 25, instead of transmitting and receiving each piece of information via the device communication unit 21 and the server communication unit 31.

It should be understood by those skilled in the art that various changes, substitutions, and modifications can be made thereto without departing from the spirit and scope of the present invention.

REFERENCE SIGNS LIST 1 Game system 2 Mobile terminal 3 Server 31 Server communication unit 32 Server storage unit 33 Server processing unit 331 Control unit 332 Game progression unit 333 Normal execution unit 334 Continuous execution unit

Claims (17)

The computer
Store information regarding the user's points owned;
In response to a first request from the user, decreasing the owned points and moving the position of the user in a virtual space;
In response to a second request from the user, decreasing the owned points and moving the position of the user in the virtual space;
an amount of reduction in the owned points in response to the first request is less than an amount of reduction in the owned points in response to the second request, and a distance traveled by the user in response to the first request is less than a distance traveled by the user in response to the second request,
When a moving distance in response to the second request reaches a predetermined distance, a first benefit is given to the user.
A control method comprising: The computer,
The control method according to claim 1 , further comprising: displaying information indicating a position of the user after the movement and displaying an image showing the inside of the virtual space. In displaying the information indicating the user's location,
When the user moves in response to the first request, a moving distance of the user in response to the first request is displayed;
The control method according to claim 2 , further comprising the step of: displaying, in a case where the user moves in response to the second request, a distance moved by the user in response to the second request. The computer,
The control method according to any one of claims 1 to 3, further comprising: increasing the owned points over time. The control method according to any one of claims 1 to 4, wherein the distance traveled by the user in response to the first request is a preset arbitrary distance. The control method according to any one of claims 1 to 5, wherein the distance traveled by the user in response to the first request is longer the higher the ability of the character used by the user. The computer,
The control method according to any one of claims 1 to 6, further comprising: moving the user in another virtual space different from the virtual space when the user has moved throughout the entire virtual space or when the user has acquired a predetermined item in the virtual space. The computer,
When the user moves in response to the first request, a second benefit is granted to the user;
The control method according to claim 1 , further comprising: when the user moves in response to the second request, granting the changed second benefit to the user. The computer,
When the user moves in response to the first request, a second benefit is granted to the user;
The control method according to claim 1 , further comprising the step of: providing the user with a third benefit greater than the second benefit when the user moves in response to the second request. The computer,
When the user moves in response to the first request, a second benefit is granted to the user;
The control method according to claim 1 , further comprising the step of: providing the user with a third benefit smaller than the second benefit when the user moves in response to the second request. The control method according to any one of claims 1 to 10, wherein a value obtained by dividing the distance traveled by the user in response to the first request by the amount of reduction in the owned points in response to the first request is greater than a value obtained by dividing the distance traveled by the user in response to the second request by the amount of reduction in the owned points in response to the second request. The control method according to any one of claims 1 to 10, wherein a value obtained by dividing the distance traveled by the user in response to the first request by the amount of reduction in the owned points in response to the first request is smaller than a value obtained by dividing the distance traveled by the user in response to the second request by the amount of reduction in the owned points in response to the second request. The computer,
moving a position of another user associated with the user in the virtual space together with a position of the user in the virtual space;
The control method according to claim 1 , further comprising: when the first privilege is granted to the user, granting the first privilege to the other user. The control method according to any one of claims 1 to 13, wherein the user's position is moved in response to the first request when the user's owned points are equal to or greater than the amount of the owned points that is decreased in response to the first request. The control method according to any one of claims 1 to 14, wherein the movement of the user's position in response to the second request is performed when the owned points of the user are equal to or greater than the amount of the decrease in the owned points in response to the second request. A storage unit that stores information regarding points owned by a user;
In response to a first request from the user, decreasing the owned points and moving the position of the user in a virtual space;
a processing unit that decreases the owned points and moves a position of the user in a virtual space in response to a second request by the user;
Equipped with
an amount of reduction in the owned points in response to the first request is less than an amount of reduction in the owned points in response to the second request, and a distance traveled by the user in response to the first request is less than a distance traveled by the user in response to the second request,
When a distance traveled in response to the second request reaches a predetermined distance, a first benefit is given to the user.
1. A computer comprising: On the computer,
Store information regarding the user's points owned;
In response to a first request from the user, decreasing the owned points and moving the position of the user in a virtual space;
In response to a second request from the user, decreasing the owned points and moving the position of the user in the virtual space;
an amount of reduction in the owned points in response to the first request is less than an amount of reduction in the owned points in response to the second request, and a distance traveled by the user in response to the first request is less than a distance traveled by the user in response to the second request,
When a moving distance in response to the second request reaches a predetermined distance, a first benefit is given to the user.
A control program comprising:

Images