Game system, game processing method, and game program
The game system manages auto mode execution time and cycles to minimize computing resource consumption, addressing excessive use in non-stamina-based games by limiting auto mode duration and processing.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- GLEE HOLDINGS CO LTD
- Filing Date
- 2024-12-26
- Publication Date
- 2026-05-29
AI Technical Summary
Existing game systems with auto modes consume excessive computing resources when user input is not required, particularly in non-stamina-based games, necessitating a mechanism to restrict auto mode usage and reduce resource consumption.
Implement a game system with a first auto mode that executes game parts without user input for a maximum execution time, determining processing cycles based on manual mode play time, and limits auto mode execution to a maximum number of cycles, reducing computational load.
Reduces computing resource consumption by managing auto mode execution time and cycles, ensuring efficient gameplay without continuous high resource usage.
Smart Images

Figure 0007867221000001 
Figure 0007867221000002 
Figure 0007867221000003
Abstract
Description
Technical Field
[0001] The disclosure in this specification relates to a game system, a game processing method, and a game program. More specifically, the disclosure in this specification relates to a game system, a game processing method, and a game program that provide a game having an auto mode for executing a game part without depending on an input from a user.
Background Art
[0002] A game having an auto mode for executing a game part without depending on an input from a user is described in Patent No. 7026311. In the auto mode, the game part progresses even without an input from a user. Therefore, by executing the game part in the auto mode, the user can obtain rewards such as experience points and game items at the end of the game part without making an input. Thus, the auto mode is a convenient function for the user to efficiently obtain rewards.
Prior Art Documents
Patent Documents
[0003]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0004] In manual mode, when progressing through the game, calculations necessary to advance the game (for example, calculations to determine the winner of a battle between characters) are not performed until user input is received. In contrast, in auto mode, user input is not required to advance the game, so calculations to advance the game are performed continuously. Therefore, if auto mode were to be available without restriction, a large amount of computing resources would be required to advance the game in auto mode. To avoid excessive consumption of computing resources, it is desirable that user use of auto mode be appropriately restricted.
[0005] In the game described in Patent Document 1, the game part is started by having the user spend game points. Games that require the user to spend game points to start or continue a game part are sometimes called "stamina-based" games. In stamina-based games, game points recover to their maximum value over time or by using game items. Therefore, in stamina-based games, the game part will not start until the user's game points have recovered to the value required to start the game part, so even if an auto mode is adopted, the consumption of computing resources for performing calculations to advance the game part is suppressed. In contrast, in games that do not require the consumption of game points to start or advance a game part (non-stamina-based games), the suppression of computing resource consumption by game points does not occur, so the introduction of a mechanism to restrict the use of auto mode is more desirable.
[0006] The purpose of this disclosure is to provide technical improvements that solve or mitigate at least some of the problems of the prior art described above. One more specific purpose of this disclosure is to provide improvements in game systems, game processing methods, and game programs for providing games with an auto mode. Another more specific purpose of this disclosure is to reduce the consumption of computing resources for providing games with an auto mode.
[0007] Any other purpose of the disclosures herein will become clear by referring to the entirety of this specification. The inventions disclosed herein may solve, in lieu of or in addition to, the problems identified from the description of the embodiments for carrying out the inventions herein. [Means for solving the problem]
[0008] One aspect of the present invention relates to a game system comprising one or more processors. In one aspect, one or more processors execute the game part of the game without user input in a first auto mode until the elapsed time since the start of the first auto mode reaches a maximum execution time. In one aspect, one or more processors determine a first processing cycle required to execute the game part for one cycle in the first auto mode based on a first play time spent to advance the game part for one cycle in manual mode, and execute the game part for a maximum number of cycles determined based on the maximum execution time and the first processing cycle in the first auto mode. [Effects of the Invention]
[0009] Embodiments of the present invention can reduce the consumption of computing resources required to provide a game with an auto mode. [Brief explanation of the drawing]
[0010] [Figure 1] Block diagram showing a game system according to one embodiment. [Figure 2] This diagram schematically illustrates the game parts included in the game provided by Game System 1. [Figure 3] This figure illustrates the user management data stored in the game system shown in Figure 1. [Figure 4] This figure illustrates the game media management data stored in the game system shown in Figure 1. [Figure 5] This figure illustrates the mode management data stored in the game system shown in Figure 1. [Figure 6] This figure illustrates the status data stored in the game system shown in Figure 1. [Figure 7] This diagram illustrates the transitions between game modes in a game provided by Game System 1. [Figure 8] This figure shows an example of a play screen displayed on the user device 10. [Figure 9] This is a schematic diagram illustrating the switching of modes using the toggle button. [Figure 10] This is a schematic diagram illustrating the settings screen used to explain individual skill settings. [Figure 11] This is a schematic diagram to explain the results screen. [Figure 12] This is a schematic diagram to explain the status screen. [Figure 13] This is a flowchart illustrating the processing flow of the game part in manual mode. [Figure 14] This is a flowchart illustrating the processing flow of the game part in the second auto mode. [Figure 15] This is a flowchart illustrating the processing flow of the game part in the first auto mode. [Modes for carrying out the invention]
[0011] Hereinafter, various embodiments of the present invention will be described with reference to the drawings as appropriate. Note that components common to multiple drawings are denoted by the same reference numerals throughout the drawings. The embodiments of the present invention described below are not intended to limit the invention as defined in the claims. The elements described in the following embodiments are not necessarily essential to the solution of the invention.
[0012] Referring to FIGS. 1 to 7, a game system 1 according to an embodiment of the present invention will be described. The game system 1 is an example of a system to which the invention disclosed in this specification is applicable. FIG. 1 is a block diagram showing the game system 1 according to an embodiment, FIG. 2 is a diagram schematically explaining game parts included in a game provided by the game system 1, FIGS. 3 to 6 are diagrams for explaining information stored in the game system 1 respectively, and FIG. 7 is a diagram for explaining the transition between game modes of a game provided by the game system 1.
[0013] As shown in FIG. 1, the game system 1 includes a user device 10 and a server 20. The game system 1 may include a storage 30. The user device 10, the server 20, and the storage 30 are communicably connected to each other via a network 5. The network 5 may be a single network or may be configured by connecting a plurality of networks. The network 5 is, for example, the Internet, a mobile communication network, and combinations thereof. As the network 5, any network that enables communication between electronic devices can be applied.
[0014] The user device 10 realizes various functions related to the game by executing a set of instructions included in the game application 15a. The server 20 provides various services related to the game to the user device 10. The user device 10 and the server 20 cooperate with each other as necessary to realize various functions of the game.
[0015] The game provided by the game system 1 includes a plurality of game parts as shown in FIG. 2. In the example shown in FIG. 2, the game G1 provided by the game system 1 includes six game parts, namely game parts GP1 to GP6. The number of game parts may be less than 6 or more than 6.
[0016] The game part is content that users can play within the game. The game part may include, for example, quests, missions, mini-games, events, other content that constitutes part of the game, or a combination thereof. The game part may have game-related challenges that the user must complete. The user may be rewarded when the challenges set in the game part are completed. Completing the challenges set in the game part is sometimes referred to as "clearing" that game part. Upon clearing a game part, the user may be rewarded with a reward corresponding to that completed game part. Clearing a game part marks the end of one cycle of that game part. As will be described later, the game part may be executed repeatedly over multiple cycles, either automatically or at the user's selection.
[0017] In one embodiment, the game part may be a versus game part. In the versus game part, the objective may be set as to fight and defeat an enemy character. In the versus game part, the user fights an enemy character using, for example, their own character. The enemy character may be a non-player character (NPC) or a character of another player. The outcome of the versus game part is determined according to predetermined game logic. In the versus game part, the user can compose a deck containing multiple game media (e.g., characters) and use the game media contained in that deck to battle an enemy character. In the versus game part, the user's character that battles an enemy character may be called a user character. Although not shown in the diagram, for each versus game part, information about the enemy characters appearing in that versus game part may be stored in the server 20. For example, the server may store an enemy character ID that identifies one or more enemy characters appearing in the game part, associated with a game part ID that identifies the game part, parameters indicating the abilities of each of those one or more enemy characters (e.g., attack power, defense power, etc.), and other information necessary for the execution of the versus game part.
[0018] The game portion may be a single-player game portion or a multiplayer game portion. A single-player game portion is played by one user. A multiplayer game portion is played by two or more users.
[0019] In one embodiment, the user can select any game part from among multiple game parts and proceed through the selected game part. For example, in the embodiment shown in Figure 2, the user may select any game part from game parts GP1 to GP6. Some game parts may be set so that they cannot be selected by the user until other game parts have been cleared. For example, game part GP3 may be set so that it does not accept selection from the user until game part GP1 has been cleared. Multiple game parts included in game G1 may have a structure that branches according to the scenario.
[0020] At least some of the multiple game parts included in the game may be playable repeatedly by the user. For example, after clearing game part GP1, the user can select game part GP1 again. The user can play the same game part repeatedly in order to repeatedly obtain the rewards that can be obtained by clearing the game part. The rewards given to the user for clearing a game part may be the same each time. If the same game part is cleared multiple times, different rewards may be given each time it is cleared.
[0021] The game may be a "stamina-based" game where game points are consumed to start a game part, or a "non-stamina-based" game where game points are not consumed to start or progress through game parts. An example of a stamina-based game is described in Patent Document 1. In a stamina-based game, game points decrease when starting or progressing through a game part, and recover to the maximum value over time or by using game items. In a stamina-based game, the user must wait until game points recover or use a game item to start a game part. In a "non-stamina-based" game, the user can start a game part at any time, provided there are no other constraints, without being restricted by the decrease in game points.
[0022] Playing the same game part repeatedly can be boring for the user. Game System 1 provides an auto mode that clears game parts without user input. By using auto mode, the user can obtain the rewards given upon clearing a game part without having to perform any input on the user device 10 to operate the game. In this specification, a game mode that does not require user input to clear a game part is called "auto mode," and a game mode that requires user input to progress through or clear a game part is called "manual mode." In other words, once a game part switches to auto mode, that game part will be cleared without any further user input. User input may be allowed in auto mode, and processing may be performed in response to that user input. Even when user input is allowed in auto mode, user input is not required to clear the game part, thus reducing the effort required for user input. Details of auto mode will be described later.
[0023] Referring again to Figure 1, the user device 10 and server 20 will be described further.
[0024] User device 10 is a smartphone, personal computer (PC), mobile phone, tablet device, personal computer, e-book reader, wearable computer, game console, head-mounted display, or any other information processing device. User device 10 is intended to be used by a user playing a game. The user can play the game by inputting data into user device 10 and receiving images and sounds output from user device 10.
[0025] The user device 10 includes a processor 11, memory 12, user interface 13, communication interface 14, and storage 15.
[0026] The processor 11 is an arithmetic unit that loads the operating system and various other programs from storage 15 or other storage into memory 12 and executes the instructions contained in the loaded programs. The processor 11 may be, for example, a CPU, MPU, DSP, GPU, various other arithmetic units, or a combination thereof. The processor 11 may also be implemented by an integrated circuit such as an ASIC, PLD, FPGA, or MCU.
[0027] Memory 12 is used to store instructions executed by the processor 11 and various other data. Memory 12 is a main memory that the processor 11 can access at high speed. Memory 12 is composed of RAM such as DRAM or SRAM.
[0028] The user interface 13 comprises an input interface for receiving user input and an output interface for outputting various information under the control of the processor 21. The input interface is a keyboard, a pointing device such as a mouse, a touch panel, or any other information input device capable of receiving user input. The output interface is, for example, a liquid crystal display, an organic EL (Electro-Luminescence) display, a display panel, or any other information output device capable of outputting the calculation results of the processor 11.
[0029] The communication interface 14 is implemented as hardware, firmware, or communication software such as a TCP / IP driver or a PPP driver, or a combination thereof. The user device 10 can send and receive data with other information devices, including the server 20, via the communication interface 14.
[0030] The storage device 15 is an external storage device accessed by the processor 11. The storage device 15 is, for example, a magnetic disk, an optical disk, a semiconductor memory, or any other storage device capable of storing data.
[0031] Server 20 includes a processor 21, memory 22, user interface 23, communication interface 24, and storage 25. The above description of processor 11, memory 12, user interface 13, communication interface 14, and storage 15 also applies to processor 21, memory 22, user interface 23, communication interface 24, and storage 25, so a detailed description of processor 21, memory 22, user interface 23, communication interface 24, and storage 25 is omitted.
[0032] Next, we will describe the information stored in storage 15 and storage 25.
[0033] The storage 15 stores a game application 15a that provides various game functions. Instructions contained in the game application 15a can be executed by the processor 11. Details of the functions realized by executing the game application 15a will be described later. The game application 15a may be downloaded to the user device 10 from, for example, an application distribution platform (not shown).
[0034] The user device 10 can, if necessary, obtain data from the server 20 to advance the game part and store the obtained data in the storage 15. Data used or referenced to advance the game part may be stored in storage 15 or in storage 25.
[0035] Storage 25 stores user management data 25a, game media management data 25b, mode management data 25c, status data 25d, and other data necessary for providing the game. At least a portion of user management data 25a, game media management data 25b, mode management data 25c, and status data 25d is referenced by the user device 10 as needed. At least a portion of user management data 25a, game media management data 25b, mode management data 25c, and status data 25d may be stored in the user device 10 as needed.
[0036] User management data 25a will be explained with reference to Figure 3. User management data 25a is a dataset in which various data about users who play games provided by game system 1 are structurally stored. User management data 25a may include user account information, various parameters set for the user, owned game media information about game media owned by the user, used game media information about game media used by the user in the game, and various other data about the user.
[0037] Account information includes, for example, a user ID that identifies a user. Account information may also include a username. In game system 1, the user ID uniquely identifies a user. The username indicates the name of the user used in the game.
[0038] A user's parameters may include the user's rank, experience points, points earned, and other user parameters associated with the user that change as the user plays the game. The user's rank is a parameter that indicates the user's proficiency in the game. The rank may increase as the user plays the game. The parameters stored in the user management data 25a are examples of user parameters used to determine the maximum execution time, which indicates the upper limit of the duration of the first auto mode M21 described later.
[0039] User-owned game media information is information about the game media owned by the user in the game. Game media is electronic data used in the game. Game media may include, for example, characters, cards, items, points, in-service currency (or in-game currency), tokens (e.g., Non-Fungible Tokens (NFTs)), tickets, characters, avatars, parameters, and other electronic data used in the game. Game media may be acquired, owned, used, managed, exchanged, synthesized, enhanced, sold, discarded, or gifted by the user within the game. Game media may also be used in ways other than those described above. Owned game media information may include a game media ID that identifies the game media owned by the user within the game. When game media is acquired by the user, the game media ID that identifies the game media is stored as owned game media information, associated with the user's user ID. Hereinafter, unless otherwise specified, game media "owned" by a user refers to game media associated with the user's user ID. Furthermore, "granting" a game medium to a user means associating that game medium with the user's user ID as a game medium "owned" by that user. Furthermore, "discarding" a game medium owned by a user means dissolving the association between the user's user ID and that game medium. Furthermore, "consuming" a game medium owned by a user means generating an in-game effect in response to dissolving the association between the user ID and the owned game medium. Furthermore, "selling" a game medium owned by a user means dissolving the association between the user's user ID and that game medium, and associating that user ID with other game mediums (e.g., virtual currency or items). Furthermore, "transferring" a game medium owned by user A to user B means dissolving the association between user A's user ID and that game medium, and associating that game medium with user B's user ID. Furthermore, "creating" a game medium means defining or determining at least a part of the information related to the game medium.
[0040] The game medium information refers to information indicating the game medium used by the user in a game part (for example, a versus game part). The game medium used by the user in the versus game part is selected from among the owned game media. The game medium used by the user in the versus game part may be selected automatically from the available game media or in response to user selections. Once a game medium is selected to run the versus game part, a deck may be constructed using that game medium. In this case, the game medium information may include a deck ID that identifies the deck containing the game medium selected as the game medium.
[0041] User management data 25a may include various other information about the user. If game system 1 provides a stamina-based game, user management data 25a may also include the user's stamina. Stamina is a parameter consumed when starting or progressing through a game part. The amount of stamina consumed may be set for each game part. Stamina recovers to its upper limit over time. Stamina may also be recovered by using items.
[0042] User management data 25a may include friend information. Friend information for a given user indicates the user IDs of users who are friends with that user. For example, if user A is friends with users B and C, user A's friend information includes the user IDs of users B and C. Users who are friends can cooperate to play games together.
[0043] Some of the data stored as user management data 25a is updated as the game progresses. For example, a user's rank increases as the user plays the game. Some of the data stored as user management data 25a is not updated as the game progresses. For example, a user ID remains unchanged even as the game progresses.
[0044] The game media management data 25b will be explained with reference to Figure 4. The game media management data 25b is a dataset in which various data related to the game media used in the game provided by the game system 1 are structurally stored. The game media management data 25b may include game media identification information for various game media, game media names, game media information representing the characteristics of the game media, and various other data related to the game media.
[0045] The game media ID is an ID that identifies the game media. The game media name indicates the name of the game media.
[0046] Game medium information includes various pieces of information that describe the characteristics of the game medium. For example, game medium information includes rarity, level, cost, life, attack power, defense power, and game function information. Rarity is information that indicates the scarcity (rarity value) of the game medium. That is, the rarity associated with a game medium represents how difficult it is to obtain that game medium. Level indicates the growth rate of the game medium. For example, the higher the level value, the greater the growth rate of the game medium. In this embodiment, the level value may increase according to the user's game play. Cost is a parameter used when determining the deck to be used in the battle game part. For example, a deck is set with an upper limit on the total cost of the game mediums that can be included in that deck. The user can select the game mediums to include in the deck so that the total cost does not exceed this upper limit.
[0047] Life is a parameter used to determine the user's victory or defeat in the versus game portion. In the versus game portion, the user's life decreases when their character is attacked by an enemy character. Life may be restored to its maximum value or below by using recovery items. If the life of all characters in the user's deck reaches zero, the user may be judged to have lost in that versus game portion.
[0048] The attack power of a game medium is a parameter that contributes to the amount of damage dealt to enemy characters by that game medium's attacks. The higher the attack power value, the greater the amount of damage dealt to enemy characters. The defense power of a game medium is a parameter that contributes to the amount of damage that the game medium receives from attacks received from enemy characters. The higher the defense power value, the greater the amount of damage received from attacks by enemy characters.
[0049] Game media information may include game function information. Game function information associated with a game medium represents the game function that the game medium uses to generate game effects in the game part. In the technical field of the present invention, game functions are sometimes called skills or abilities. In some games, "spells" used by characters also fall under the category of game functions. When a game function is used in the game part, a game effect associated with that game function occurs. Game effects generated by using a game function in a competitive game part include increased attack power, increased defense power, life recovery, and other effects that affect the outcome of a battle against an enemy character.
[0050] Game functions may include restricted game functions whose use is restricted in a predetermined sub-mode in the second auto mode (for example, the restricted mode in the second auto mode M22 described below), and unrestricted game functions whose use is not restricted in the said predetermined sub-mode in the second auto mode. Restricted game functions may also be game functions that have restrictions or conditions imposed on their use in the game. Restricted game functions may include game functions that have a limited number of uses (i.e., an upper limit on the number of uses), game functions that require the consumption of points or parameters to use, and game functions that belong to a predetermined category (for example, recovery skills, buff skills, debuff skills, special moves, and other categories). The number of uses of restricted game functions can be restored to the upper limit by the passage of time, the use of items, or by other means. Points or parameters consumed to use restricted game functions can be restored to the upper limit by the passage of time, the use of items, or by other means.
[0051] In the following, we will primarily discuss "skills" to explain game features, but the explanation of "skills" also applies to other game features (for example, abilities).
[0052] Mode management data 25c will be explained with reference to Figure 5. The game parts included in the game provided by game system 1 can be played in one of several game modes. Mode management data 25c is a dataset for managing which game part each user is playing in which of the multiple game modes. The game modes set for the game parts of the game provided by game system 1 may include manual mode M11, first auto mode M21, and second auto mode M22. Mode management data 25c may include user account information, game part information about the game part the user is playing, and mode information about the current game mode of that game part. Game part information is a game part ID that identifies the game part. Mode information is a mode ID that identifies the game mode.
[0053] The game modes of the game parts included in the game provided by Game System 1 will be described with reference to Figure 7. In one embodiment, the game modes set for the game parts of the game provided by Game System 1 include a manual mode M11 that requires user input to clear the game part, and an auto mode that does not require user input to clear the game part. The auto mode includes a first auto mode M21 and a second auto mode M22.
[0054] Assuming the user has selected to run the versus game part, the manual mode M11, first auto mode M21, and second auto mode M22 that are set for this versus game part will be described.
[0055] At the start of the versus game part, the game mode may be set to manual mode M11. When the versus game part is run in manual mode M11, the user inputs instructions for the user character via the user interface 13 of the user device 10. Instructions for the user character include performing attacks on enemy characters, using skills, using items, and other instructions. The user may also input instructions other than those for the user character. If the versus game part employs a turn-based system, user instructions are input during the user's attack turn. The user character takes actions according to the user's input. For example, the user character attacks the enemy character in accordance with the user's input instructing the user to attack the enemy character. During the enemy character's attack turn, the user character is attacked by the enemy character. The enemy character's life may decrease due to attacks from the user character, and the user character's life may decrease due to attacks from the enemy character. In the versus game part, the winner and loser are determined according to predetermined game logic. For example, if the enemy character's life is reduced to zero, the user is determined to have won, and conversely, if the user character's life is reduced to zero, the user is determined to have lost. The processing in the versus game part in manual mode is not limited to what is specified herein. Various algorithms for executing the versus game part in manual mode are publicly known. Game system 1 may employ publicly known game mechanics for processing the game part in manual mode, as long as it does not create inconsistencies.
[0056] The game part can be executed in cycles, from the start to the end of a single battle. The game part can be executed repeatedly in cycles. In the versus game part, for example, one cycle is executed from the start of the battle until the result of the win / loss determination is decided. In manual mode M11, the versus game part may be returned and executed at the user's selection. In manual mode M11, the versus game part may be executed repeatedly even without a request from the user.
[0057] Thus, in manual mode M11, even after the start of the versus game part, user input is required to progress the battle against the enemy character and clear the versus game part. If the necessary user input is not received in the versus game part set in manual mode M11, the game part will not progress until the necessary user input is received. For example, during the user character's attack turn, the game part will not progress until the user gives instructions, and will remain at that attack turn until user input is received. In manual mode M11, if a modal is displayed, the game part may not proceed until the user responds to that modal.
[0058] In the first auto mode M21, after the start of the battle game part, the battle between the user character and the enemy character is executed without user input. The first auto mode M21 continues to run for the maximum execution time. In other words, the maximum execution time is the upper limit of how long the first auto mode M21 can continue after transitioning to it. In the first auto mode M21, the game part is executed over multiple cycles, with each cycle being a unit. In the first auto mode M21, the winner or loser of the battle may be determined at the end of each cycle. In the first auto mode M21, the reward to be given to the user may be determined at the end of each cycle. In the first auto mode M21, the elapsed time after the start of the first auto mode M21 is counted, and when this elapsed time reaches the maximum execution time, the first auto mode M21 ends. In the first auto mode M21, the reward to be given to the user may be determined at its end. If the first auto mode M21 is terminated by user instruction before the maximum execution time has elapsed, the reward to be given to the user may be determined based on the number of completed cycles completed up to that point of termination.
[0059] When the game part is executed in the first auto mode M21, an auto processing cycle representing the time required to execute one cycle of the game part may be set. When an auto processing cycle is set for the first auto mode M21, the quotient obtained by dividing the maximum execution time by the auto processing cycle is the maximum number of cycles that can be executed within the maximum execution time in the first auto mode M21. In this specification, the upper limit of the number of cycles executed in the first auto mode M21 is sometimes referred to as the maximum number of cycles. In the first auto mode M21, the game part can be repeatedly executed up to the maximum number of cycles unless interrupted by the user. In the first auto mode M21, the determination of victory or defeat in each cycle may be performed collectively for multiple cycles executed during a predetermined time after the start of the first auto mode M21. For example, the determination of victory or defeat in each cycle may be performed collectively at the end of the first auto mode M21. To reduce the computational load, the first auto mode M21 may be defined as the user winning in all cycles.
[0060] The process for advancing the game part in the first auto mode M21 may be performed by the user device 10. The user device 10 may perform a first progression process for advancing the first auto mode M21 while the game application 15a is running in the foreground. The first progression process for advancing the first auto mode M21 may be a simpler process than the second progression process for advancing the second auto mode M22, which will be described later. For example, in the first auto mode M21, the user device 10 may not perform battle processing according to the battle logic (e.g., damage calculation, life calculation, and / or generation of game animation representing battle processing), but instead calculate the number of completed cycles, which represents how many cycles of the game part have been processed since the start of the first auto mode M21, and display this number of completed cycles on the display. In the first auto mode M21, the number of wins may be calculated, which represents the number of cycles in which the user is determined to have won since the start of the first auto mode M21. If it is determined that the user will win in all cycles, the number of wins will be equal to the number of completed cycles. Furthermore, the processing in the first auto mode M21 may include determining the reward to be given to the user at the end of the first auto mode M21. The number of completed cycles can be calculated using a simple calculation based on the elapsed time since the start of the first auto mode M21 and the auto processing cycle. In addition, the processing for determining the reward to be given to the user can be executed with fewer computing resources compared to the processing based on the battle logic.
[0061] While the game application 15a is running in the background on the user device 10, no processing is performed to calculate the number of completed cycles. However, when the game application 15a returns to the foreground from the background, the user device 10 can calculate the number of completed cycles based on the elapsed time since the start of the first auto mode M21 at that time, and display a status screen including the calculated number of completed cycles on the display. Therefore, a user who sees the status screen displayed when the game application 15a returns to the foreground will feel as if the first auto mode M21 had continued to progress even while the game application 15a was running in the background. Even if the game application 15a is terminated after the start of the first auto mode M21 on the user device 10 and then restarted, the number of completed cycles at the time of restarting can be calculated, and a status screen including the calculated number of completed cycles may be displayed on the display. A user who sees this status screen will feel as if the first auto mode M21 had continued to progress even while the game application 15a was not running. Thus, in the first auto mode M21, a status screen including the latest status of processing in the first auto mode M21 is displayed immediately after the game application 15a returns to the foreground from the background or immediately after the game application 15a is restarted after being terminated. Therefore, from the perspective of a user playing the game part in the first auto mode M21, the game part continues to run without interruption even while the game application 15a is running in the background or when the game application 15a is not running.
[0062] For users running the game part in the first auto mode M21, status data 25d for managing the progress of the game part in the first auto mode M21 may be stored in storage 25. The status data 25d will be explained with reference to Figure 6. The status data 25d is a dataset in which various data for managing the status of the first auto mode M21 is structurally stored for each user running the game part in the first auto mode M21. The status data 25d stores the maximum execution time of the first auto mode M21, the elapsed time since the start of the first auto mode M21, and the maximum number of cycles, which indicates the upper limit of the number of cycles that can be executed within the maximum execution time in the first auto mode M21, in association with the user's account information.
[0063] When a user runs the game part in the first auto mode M21, the maximum execution time is determined based on the user's user parameters. A user's user parameters can be identified by referring to user management data 25a. The user parameter for determining the maximum execution time for a user may be, for example, the user's rank stored in the user management data 25a. In one embodiment, the maximum execution time may be calculated such that it is longer for higher ranks. The maximum time when a user runs the game part in the first auto mode M21 may also be determined based on user parameters other than the user's rank.
[0064] The process for executing the game part in the first auto mode M21 may be executed on the server 20. Therefore, if the game part is set to the first auto mode M21, the game part can proceed on the server 20 even if the game application 15a is running in the background on the user device 10. Also, if the game part is set to the first auto mode M21, the game part can proceed even if the game application 15a is not running on the user device 10.
[0065] In the second auto mode M22, as in the first auto mode M21, the battle against the enemy character is executed after the start of the game part, regardless of user input. When the game part is set to the second auto mode M22, the game part can only proceed if the game application 15a is running in the foreground on the user device 10. In other words, when the game part is set to the second auto mode M22, the process to advance the game part is suspended while an application other than the game application 15a is running in the foreground (while the game application 15a is running in the background). The suspended game part may be resumed when the game application 15a returns to the foreground. When the processing of one cycle of the game part in the second auto mode M22 is completed, the processing of the next cycle of the game part may be started automatically. After the processing of one cycle of the game part in the second auto mode M22 is completed, the processing of the next cycle of the game part may be started in response to user input.
[0066] The second auto mode M22 is a different game mode from the first auto mode M21. As mentioned above, in the first auto mode M21, the battle processing according to the battle logic (e.g., damage calculation, life calculation, and / or generation of game animations representing the battle processing) is not performed, and a simplified process is executed. An example of the simplified process is to calculate the number of completed cycles based on the elapsed time since the start of the first auto mode M21 and to display this calculated number of completed cycles. Thus, comparing the first auto mode M21 and the second auto mode M22, the difference is that the processing load required to execute the first auto mode M21 is smaller than the processing load required to execute the second auto mode M22. In one embodiment, the second auto mode M22 can execute the game part only when the game application 15a is running in the foreground, and conversely, the execution of the game part is interrupted when the game application 15a is running in the background or when the game application 15a is terminated. This differs from the first auto mode M21, in that the execution of the game part is not interrupted even when the game application 15a is running in the background or not running on the user device 10. Further differences between the first auto mode M21 and the second auto mode M22 will be described later.
[0067] As shown in Figure 7, the game part may start in manual mode M11. If the user makes a first request R1 while the game part is running, the game part can transition from manual mode M11 to first auto mode M21. Conversely, if predetermined transition conditions are met, it may transition from first auto mode M21 to manual mode M11. If the user makes a second request R2 while the game part is running, the game part can transition from manual mode M11 to second auto mode M22. If the first request R1 is made while playing in second auto mode M22, it may transition from second auto mode M22 to first auto mode M21. Conversely, if predetermined transition conditions are met, it may transition from first auto mode M21 to second auto mode M22. It may also transition from second auto mode M22 to manual mode M11.
[0068] Next, the functions of the user device 10 and the server 20 will be explained with additional reference to Figures 8 to 12. Figures 8 to 12 show the screens or parts thereof displayed on the user device 10 as the game progresses.
[0069] The processor 11 of the user device 10 functions as a game progress unit 11a, a game part processing unit 11b, and a mode switching unit 11c by executing the instruction set included in the game application 15a and other instruction sets.
[0070] The processor 21 of the server 20 functions as a game control unit 21a, a mode setting unit 21b, and an auto processing unit 21c by executing instruction sets included in programs stored in the storage 25 and other instruction sets as needed. The game control unit 21a can control the progress of the game by processing requests and notifications from the user device 10 based on predetermined game logic and by providing various game data for running the game to the user device 10.
[0071] The game progress unit 11a works in cooperation with the server 20 to advance the game in response to user input via the user interface 13 (e.g., touch panel) of the user device 10. User inputs include, for example, inputs to specify the game part to execute, inputs to specify the movement of the user character in the virtual space, inputs to instruct the use of items, inputs to change game settings, and various other inputs related to the progress of the game. The game progress unit 11a can generate requests related to the progress of the game based on user input and instructions from the running game program, and send the generated requests to the server 20. The game progress unit 11a can also receive various game data related to the progress of the game from the server 20 and advance the game based on that game data. The game progress unit 11a can display images or videos on the user interface 13 (e.g., display) that correspond to the progress of the game.
[0072] The game progress unit 11a may retrieve data necessary for game progression from among the various data stored in the storage 25 and store the retrieved data in the storage 15. When necessary for game processing, the game progress unit 11a can read data from the storage 15 as appropriate and perform calculations using the retrieved data.
[0073] The game progression unit 11a can, for example, display a GUI (Graphical User Interface) on the user interface 13 to allow the user to select a game part, and can detect operations performed on this GUI.
[0074] The game progress unit 11a can identify the game parts that the user can execute and display the identified game parts on the user interface 13. The game progress unit 11a can identify the game parts selected by the user in response to user actions.
[0075] The game part processing unit 11b can start the game part identified by the game progress unit 11a. For example, if the user selects game part GP1, game part GP1 will be started. In the following explanation, it is assumed that game part GP1 has been selected by the user.
[0076] The game part processing unit 11b sends an execution request for the selected game part GP1 to the server 20. When the server 20 (for example, the game control unit 21a) receives the execution request from the user device 10, it can send the data used to execute the competitive game part GP1 to the user device 10. The game part processing unit 11b can store the data necessary for executing the game part GP1 obtained from the server 20 in the storage 15.
[0077] In the following explanation, it is assumed that Game Part GP1, initiated by Game Part Processing Unit 11b, is a versus game part. Furthermore, it is assumed that in this versus game part, a battle takes place between the user character included in the deck and the enemy character.
[0078] In the versus game part, for example, a turn-based battle is held between the user character and the enemy character. After the start of the game part GP1, the game part processing unit 11b alternately generates a first turn in which the user character acts and a second turn in which the enemy character acts. Each user character or deck is assigned first action points that increase over time, and the first section may begin when these first action points reach a predetermined value. Similarly, enemy characters or groups of enemy characters are assigned second action points that increase over time, and the second section may begin when these second action points reach a predetermined value.
[0079] Referring to Figure 8, an example of processing in the versus game part will be explained. Figure 8 shows an example of the play screen 50 displayed on the user device 10 during the execution of the versus game part. The play screen 50 is divided into a first area 50a and a second area 50b. The first area 50a displays a virtual space and various objects placed in this virtual space. In the illustrated example, the first area 50a includes objects representing user characters C11, C12, and C13, and an object representing the enemy character C31.
[0080] Area 2 50b displays the icon images C11a to C16a of the characters included in the user's deck. The deck contains six user characters, and three of these six user characters are displayed in Area 1 50a. The battle takes place between the three user characters in Area 1 50a and the enemy character. Upon instruction from the user, user characters included in the deck but not participating in the battle (i.e., user characters displayed in Area 2 50b but not in Area 1 50a) can be swapped with user characters included in Area 1 50a. The swapping of user characters in Area 1 50a may be performed automatically without user selection if certain conditions are met.
[0081] In each of the first region 50a and the second region 50b, the life of each character may be displayed in association with the object or icon image of each character. In the illustrated embodiment, each character is set to have two types of life: a first life P1 and a second life P2. When a character is attacked, the first life P1 decreases first. If the character is attacked after the first life P1 has decreased to zero, the character's second life P2 decreases. In other words, the second life P2 does not decrease until the first life P1 reaches zero. The illustrated first life P1 and second life P2 are examples of life that can be set for each character, and the life used in the game system 1 is not limited to those shown.
[0082] The game part processing unit 11b can start the game part in manual mode M11. When the game part is running in manual mode M11, the first section accepts input from the user regarding instructions for the user character. Instructions for the user character include performing attacks on enemy characters, using skills, using items, and other instructions. For example, when the game part processing unit 11b detects input via the GUI instructing user character C11 to attack enemy character C31, it causes user character C11 to perform the attack on enemy character C31. Specifically, the damage that enemy character C31 receives is calculated based on parameters such as attack power set for user character C11 and parameters such as defense power set for enemy character C31. The game part processing unit 11b subtracts the calculated damage from enemy character C31's life. As a result, the life of enemy character C31 decreases due to the attack from user character C11. The game part processing unit 11b can, in response to user input, cause user characters C11 to C13 to perform actions related to the battle, such as using skills, using items, and other actions other than attacking enemy character C31. In the first section, the game part processing unit 11b may cause each of user characters C11 to C13 to perform actions based on user input, or it may cause only some of user characters C11 to C13 to perform actions based on user input.
[0083] When the first section ends and the second section begins, the game part processing unit 11b causes the enemy character C31 to perform actions according to the battle logic defined for the battle game section. For example, the game part processing unit 11b causes the enemy character C31 to attack some or all of the user characters C11-C13. Specifically, the damage that user characters C11-C13 will receive is calculated based on the attack power and other parameters set for the enemy character C31 and the defense power and other parameters set for user characters C11-C13. The game part processing unit 11b then subtracts the calculated damage from the life of user characters C11-C13.
[0084] The game part processing unit 11b generates an animation corresponding to an action when user characters C11~C13 or enemy character C31 perform an action such as an attack, and displays the generated animation on the display of the user device 10.
[0085] The game part processing unit 11b determines the winner and loser in the versus game part according to predetermined game logic. For example, if the enemy character C31's second life P2 decreases to zero, the user is determined to have won. Conversely, for example, if the second life P2 of each of the user characters C11 to C13 decreases to zero, the user is determined to have lost. If the player is fighting against multiple enemy characters, the user may be determined to have won if the second life P2 of all of those enemy characters decreases to zero.
[0086] The game part processing unit 11b can terminate the processing of the first cycle of a game part if it determines that either the user or the enemy character has won in that game part. If the processing of the first cycle of a game part is completed, the game part processing unit 11b may then start the second cycle of the same game part. In this way, the user can play the same game part repeatedly.
[0087] The game part processing unit 11b may reward the user when the processing of one cycle of the game part is completed. For example, the game part processing unit 11b may reward the user if it is determined that the user has won in a competitive game part. The game part processing unit 11b may also reward the user if the user loses. The reward given when the user loses may be less than the reward given when the user wins. Rewards given to the user may include items, experience points (or other points to improve the user character's abilities), in-game currency, utility tokens, and other electronic data that can serve as an incentive for the user. The rewards given to the user may be determined for each game part. If the game part is executed over multiple cycles, the rewards given to the user may differ for each cycle. The process of giving rewards to the user may be part of the processing in the game part, or it may be an additional process separate from the processing in the game part. The rewards given to the user may be determined by the time it took to complete the game part. For example, the shorter the time it takes to complete the game part, the higher the value of the reward may be given.
[0088] The game part processing unit 11b may award different rewards depending on whether the game part is cleared in manual mode M11 or in auto mode (first auto mode M21 or second auto mode M22). According to the algorithm for determining rewards, the first and second rewards are determined such that, for example, the first reward awarded when the game part is cleared in manual mode M11 is of higher value than the second reward awarded when the game part is cleared in auto mode. In one example, the first and second rewards may be determined such that the rarity of the item awarded as the first reward tends to be higher than the rarity of the item awarded as the second reward. In another example, the experience points or points awarded as the first reward may be greater than the experience points or points awarded as the second reward.
[0089] In the play screen 50 shown in Figure 8, the first area 50a includes a toggle button 51 for switching the game mode between manual mode M11 and second auto mode M22. When the mode switching unit 11c detects operation on the toggle button 51 via the GUI, it can switch the game part currently in progress in manual mode M11 to second auto mode M22. In manual mode M11, the text "AUTO OFF" is displayed on the toggle button 51 to indicate that the game part being played is set to manual mode (in other words, auto mode is off).
[0090] The mode switching unit 11c switches the game part from manual mode M11 to second auto mode M22 when the user selects the switch button 51 while the game part is in progress in manual mode M11. The mode switching unit 11c may also send a mode switching notification to the server 20 to notify the user of the mode switch. The mode switching notification sent from the user device 10 to the server 20 may include the user ID of the user playing the game part, the game part ID that identifies the game part currently running, and the mode ID that identifies the mode after the switch. When the mode setting unit 21b of the server 20 receives the mode switching notification, it updates the mode management data 25c based on the data contained in the mode switching notification. This allows the server 20 to manage which game mode the game part is progressing in for each user.
[0091] After switching to the second auto mode M22, the game part processing unit 11b proceeds with the battle against the enemy character without user input. Specifically, in the second auto mode M22, the game part processing unit 11b can determine the actions of user characters C11-C13 and enemy character C31 (for example, attacking the opponent, using skills, using items) according to a predetermined battle logic, without user input. Based on these actions of user characters C11-C13 and enemy character C31, which are performed without user input, the game part processing unit 11b calculates the damage dealt to each of the user characters C11-C13 and enemy character C31, and can determine the winner using the same criteria as in manual mode M11. In other words, in the second auto mode M22, damage is calculated to user characters C11-C13 and enemy character C31 based on the actions of user characters C11-C13 and enemy character C31, which are determined without user input. If enemy character C31's second life P2 is reduced to zero, the user is determined to have won. Conversely, if each of the user characters C11-C13's second life P2 is reduced to zero, the user is determined to have lost.
[0092] The game part processing unit 11b may, in the second auto mode M22 as in manual mode M11, generate an animation corresponding to an action when user characters C11~C13 or enemy character C31 perform an action such as an attack, and display the generated animation on the display of the user device 10.
[0093] In the second auto mode M22, the game part can progress without user input, so the user can obtain the rewards given upon clearing the game part without having to input anything after the game part starts. Thus, in the second auto mode M22, the game part can be cleared without user input, but user input may be accepted. If user input is accepted in the second auto mode M22, the actions of user characters C11~C13 may be determined according to that input.
[0094] To reflect the user's strategy and tactics in the actions of the user character in the second auto mode M22, a sub-mode may be set for the second auto mode M22. For example, the second auto mode M22 may be set to either a restricted mode that prohibits the use of restricted game functions that meet certain conditions from among multiple game functions, or an unrestricted mode that allows the use of restricted game functions as well. As previously described, restricted game functions may include game functions that have a limited number of uses (i.e., an upper limit is set on the number of uses), game functions that require the consumption of points or parameters to be used, and game functions belonging to a predetermined category (e.g., recovery skills, buff skills, debuff skills, special moves, and other categories). The user may choose either restricted mode or unrestricted mode when switching to the second auto mode M22. Restricted mode and unrestricted mode may be switched after the start of the second auto mode M22. By selecting restricted mode, the user can, for example, conserve skills with limited uses and proceed through the game part in the second auto mode M22. This allows the user to use skills that were saved in the second auto mode (M22) when returning to manual mode (M11) after completing the game part in the second auto mode (M22). On the other hand, since skills generate effects that give the user an advantage in the game, progressing through the game part in unrestricted mode increases the chances of winning against the enemy character C31. Therefore, by selecting unrestricted mode, rewards can be obtained more efficiently.
[0095] Referring further to Figure 9, the switching from manual mode M11 to the second auto mode M22 will be explained in more detail. As shown in Figure 9, when the user selects the toggle button 51 labeled "AUTO OFF" in manual mode M11, the transition mode selection button 52 is unfolded from the toggle button 51. The transition mode selection button 52 is divided into a first area 52a associated with the restricted mode and a second area 52b associated with the unrestricted mode. After selecting the toggle button 51 and unfolding the transition mode selection button 52, the user can instruct the system to switch to the second auto mode M22 in restricted mode by touching the first area 52a of the transition mode selection button 52. Alternatively, the user can instruct the system to switch to the second auto mode M22 in unrestricted mode by touching the second area 52b of the transition mode selection button 52.
[0096] When instructed to transition to the second auto mode M22 in restricted mode, the game part processing unit 11b determines the actions of user characters C11 to C13 under the constraint that skills with limited uses are not used. On the other hand, when instructed to transition to the second auto mode M22 in unrestricted mode, the game part processing unit 11b determines the actions of user characters C11 to C13 without excluding the use of skills with limited uses.
[0097] When the game switches to the second auto mode M22, the text displayed inside the toggle button 51 on the play screen 50 changes to "AUTO ON" as shown in Figure 9. Therefore, while the game part is progressing in the second auto mode M22, the "AUTO ON" displayed on the toggle button 51 indicates that the game part is running in auto mode.
[0098] The mode switching unit 11c switches the game part from the second auto mode M22 to manual mode M11 when the user selects the switch button 51 while the game part is in progress in the second auto mode M22.
[0099] In the second auto mode M22, the availability of skills with limited usage counts may be determined individually for each user character and / or for each skill. The first area 50a of the play screen 50 shown in Figure 8 includes a setting button 53. When the game part processing unit 11b detects an operation on the setting button 53 via the GUI, it displays a setting screen on the user device 10's display for setting whether each user character can use a skill. Figure 10 is an example of a setting screen 60 for setting whether each of the multiple skills (skill 1 to skill 3) that user character C11 can use can be used.
[0100] The settings screen 60 contains display elements 61 to 63. Display element 61 is a display element for setting whether Skill 1 can be used. Display element 61 includes the display "Skill 1" and "3 / 5". The denominator of "3 / 5" means that the maximum number of times Skill 1 can be used is 5, and the numerator means that Skill 1 can be used 3 times at the time the settings screen is displayed (there are 3 skills remaining). In this specification, the number of usable skills may be called the number of remaining skills. The number of remaining skills can take an integer value between the maximum number of skill uses and zero. Display element 62 is a display element for setting whether Skill 2 can be used. Since Skill 2 has no limit on the number of uses, display element 62 does not include a display regarding the number of uses. Display element 63 is a display element for setting whether Skill 3 can be used. Display elements 61 to 63 may include a description of the effects that occur in the game when the corresponding Skills 1 to 3 are used.
[0101] Display elements 61-63 contain corresponding checkboxes 61a-63a. When a checkbox is selected by the user, the skill corresponding to that selected checkbox is made available in the second auto mode M22. For example, when checkbox 61a is selected by the user, skill 1 is made available in the second auto mode M22.
[0102] Figure 10 shows the settings screen for user character C11 to determine whether or not skills can be used in the second auto mode M22. However, for other user characters, a similar settings screen can be used to determine whether or not each skill can be used in the second auto mode M22.
[0103] In one embodiment, even when the second auto mode M22 is set to unrestricted mode, skills that have been disabled by individual settings will not be used in the second auto mode M22. For example, in the embodiment shown in Figure 10, since checkbox 63a is not checked, skill 3 of user character C11 is disabled. In this case, even if the second auto mode M22 is set to unrestricted mode, the game part processing unit 11b determines the user character C11's actions so that user character C11 does not use skill 3.
[0104] In one embodiment, even when the second auto mode M22 is set to restricted mode, skills that have been set to be usable through individual settings may be used in the second auto mode M22. For example, in the embodiment shown in Figure 10, since checkbox 61a is checked, skill 1 of user character C11 is set to be usable. In this case, even if the second auto mode M22 is set to restricted mode, the game part processing unit 11b can make user character C11 use skill 1.
[0105] Thus, individual skill settings for each user character using the settings screen 60 may take precedence over the sub-mode settings (restricted or unrestricted mode) in the second auto mode M22. Prioritizing individual settings makes it easier to reflect the user's strategy and tactics in the user character's actions in the second auto mode M22.
[0106] In another embodiment, the sub-mode settings in the second auto mode M22 take precedence over the individual skill settings for each user character using the settings screen 60. In this case, the sub-mode can be set to restricted mode or unrestricted mode, and then the usability of skills can be individually set within the limits permitted by the set sub-mode. Therefore, by setting the sub-mode, it is possible to easily set the outline of the strategy or tactics in the second auto mode M22, and then by setting the usability of skills individually using the settings screen 60, the strategy or tactics in the second auto mode M22 can be reflected in more detail. For example, a user who wants to execute the second auto mode M22 with simpler operations can execute the second auto mode M22 according to the sub-mode settings. On the other hand, a user who wants to set the usability of skills in more detail can specify the strategy or tactics during combat in more detail by setting the sub-mode and then setting the individual skills using the settings screen 60.
[0107] If the number of remaining skills is less than the maximum number of skill uses, the number of remaining skills may recover to the maximum number of uses over time. In addition to the passage of time, the number of remaining skills may also recover to the maximum number of skill uses through the use of items, clearing game parts, and the occurrence of other in-game events.
[0108] Next, referring to Figure 11, the switching to the first auto mode M21 will be described. In one embodiment, the switching to the first auto mode M21 is performed when one cycle of processing of the game part is completed in manual mode M11 or second auto mode M22.
[0109] Figure 11 shows the result screen 70 displayed on the user device 10's display when one cycle of game processing is completed in manual mode M11 or second auto mode M22. The result screen 70 includes a clear time display area 71, an end instruction button 72, a transition selection button 73 for selecting to transition to first auto mode M21, and a replay button 74. The display of the result screen 70 and processing based on instructions via the result screen 70 are performed, for example, by the mode switching unit 11c.
[0110] The clear time display area 71 shows the play time spent to complete the game part that was cleared immediately before the display of the results screen 70 in manual mode M11 or second auto mode M22. In the illustrated example, "02:27" is displayed in the clear time display area 71. This display indicates that 2 minutes and 27 seconds were spent from the start to the end (clearance) of the game part that was cleared immediately before.
[0111] The exit command button 72 is used to end the game part that was just cleared. When the exit command button 72 is selected, the game part that was just cleared will end without proceeding to the next cycle.
[0112] The transition selection button 73 is a button for selecting the transition to the first auto mode M21. The transition selection button 73 is, for example, a radio button. When the user selects the transition selection button 73 via the GUI, the transition selection button 73 becomes selected, and this selection state is maintained until the transition selection button 73 is selected again.
[0113] The replay button 74 is a button used to select the player to play the most recently cleared game part again. When the mode switching unit 11c selects the replay button 74 while the transition selection button 73 is not selected (in a non-selected state), it restarts the most recently cleared game part in the same mode as when it was cleared. For example, if the result screen 70 is displayed because the game part is cleared in manual mode M11, selecting the replay button 74 while the transition selection button 73 is non-selected will restart the game part in manual mode M11 (the next cycle of the game part will start in manual mode M11). If the result screen 70 is displayed because the game part is cleared in second auto mode M22, selecting the replay button 74 while the transition selection button 73 is non-selected will restart the game part in second auto mode M22 (the next cycle of the game part will start in second auto mode M22).
[0114] If the replay button 74 is selected while the transition selection button 73 is selected, the mode switching unit 11c can switch the game part to the first auto mode M21. The mode switching unit 11c may also send a mode switching notification to the server 20 to notify it that the game part has been switched to the first auto mode M21. The mode switching notification may include the user ID of the user playing the game part, the game part ID that identifies the game part, and the mode ID that identifies the mode after the switch. When the mode setting unit 21b of the server 20 receives the mode switching notification, it updates the mode management data 25c based on the data contained in the mode switching notification. This allows the server 20 to manage which mode the game part is progressing in for each user.
[0115] The replay button 74 includes an indicator 74a that shows the elapsed time since the results screen 70 was displayed. The elapsed time since the results screen 70 was displayed, as shown in this indicator 74a, reaches its upper limit (rightmost in the illustrated example) after a predetermined time (for example, 10 seconds). In this specification, the time from when the results screen 70 is displayed until the indicator 74a reaches its upper limit (i.e., the time from when the results screen 70 is displayed until the replay button 74 is automatically selected) is sometimes referred to as the "replay waiting time". When the elapsed time since the results screen 70 was displayed reaches the upper limit of the indicator 74a (i.e., when the replay waiting time has elapsed since the results screen 70 was displayed), it is determined that the replay button 74 has been selected even without any user input.
[0116] When the server 20 receives a mode switching notification indicating that the game part has been switched to the first auto mode M21, the auto processing unit 21c executes the game part in the first auto mode M21. The execution of the game part in the first auto mode M21 is performed without user input. In the auto processing in the first auto mode M21, the game part identified by the game part ID included in the mode switching notification is executed repeatedly over multiple cycles. In the first auto mode M21, the unit of repetition when repeatedly executing the game part is called a "cycle". For example, if the game part is to be executed for 10 cycles, the game part will be executed 10 times.
[0117] In the first auto mode M21, the auto processing unit 21c calculates a maximum execution time, which represents the upper limit of the time the game part will be continuously executed, in order to execute the game part. The maximum execution time is determined based on user parameters associated with the user ID included in the mode switching notification. For example, the maximum execution time is calculated based on at least one of the user parameters stored in the user management data 25a. The maximum execution time is determined, for example, based on the "rank" among the user parameters. The maximum execution time may be set to be longer the higher the user's rank. A list defining the correspondence between rank and maximum execution time may be created in advance, and the auto processing unit 21c may determine the maximum execution time by referring to this list. The maximum execution time may also be determined based on user parameters other than rank (e.g., experience points, acquired points). The user parameters used to determine the maximum execution time are not limited to those specified herein. The maximum execution time is determined based on parameters related to the user's proficiency in the game and the amount of time spent playing the game. This allows for setting longer maximum execution times for users with high game proficiency or long play times. In other words, users with high game skill levels or long play times can use the first auto mode M21 for extended periods. The maximum execution time is set to 8 hours for the lowest-ranked users, for example. The maximum execution time increases as the user's rank increases. The maximum increase in maximum execution time due to the user's rank is, for example, 100 hours.
[0118] The auto processing unit 21c calculates the auto processing cycle required to execute one cycle of the game part in the first auto mode M21, based on the play time (hereinafter sometimes referred to as "clear time") spent clearing one cycle of the game part immediately before transitioning to the first auto mode M21. The auto processing cycle may be calculated by adding a predetermined time to the clear time spent clearing one cycle of the game part immediately before transitioning to the first auto mode M21. This added time may be, for example, 10 seconds, 15 seconds, 20 seconds, 25 seconds, or 30 seconds, but is not limited to these. Assuming the added time is 20 seconds, as shown in Figure 11, if the clear time of the previous game part is 2 minutes and 27 seconds, the auto processing cycle is calculated as 2 minutes and 47 seconds by adding 20 seconds to 2 minutes and 27 seconds. The added time added to the clear time to calculate the auto processing cycle may be considered as the waiting time from the current cycle to the next cycle in the first auto mode M21. Therefore, in this specification, the additional time added to the clear time to calculate the automatic processing cycle is sometimes referred to as the "cycle interval."
[0119] In one embodiment, the interval between cycles is longer than the replay waiting time. For example, if the replay waiting time is 10 seconds, the interval between cycles is set to be longer than 10 seconds. By making the interval between cycles longer than the replay waiting time, the interval between cycles can be shortened in the second auto mode M22 than in the first auto mode M21, so that the game part can be executed more times within a predetermined time in the second auto mode M22 than in the first auto mode M21. This makes it possible to guide users who aim to acquire more rewards in auto mode to the second auto mode M22. Since the second auto mode M22 can be executed when the game application 15a is running in the foreground of the user device 10, increasing the play time in the second auto mode M22 can increase the user's engagement with the game.
[0120] Different cycle intervals may be used depending on whether the game part was cleared in manual mode M11 or in second auto mode M22 immediately before transitioning to first auto mode M21. For example, the cycle interval used when the game part was cleared in manual mode M11 immediately before transitioning to first auto mode M21 can be made smaller than the cycle interval used when the game part was cleared in second auto mode M22 immediately before transitioning to first auto mode M21. This can encourage users to play in manual mode M11 rather than second auto mode M22. Increasing the playtime in manual mode M11 can increase user engagement with the game.
[0121] The auto processing unit 21c can calculate the maximum number of cycles for which the game part will be repeatedly executed in the first auto mode M21, based on the maximum execution time and the auto processing cycle. The maximum number of cycles is calculated such that the smaller the auto processing cycle, the larger the maximum number of cycles. The auto processing unit 21c can use the quotient obtained by dividing the maximum execution time by the auto processing cycle as the maximum number of cycles. For example, if the maximum execution time set in the first auto mode M21 is 8 hours and the auto processing cycle is 2 minutes and 47 seconds, then 172 cycles will be the maximum number of cycles. If the maximum execution time is not divisible by the auto processing cycle, the remainder may be truncated. The method for calculating the maximum number of cycles used in the first auto mode M21 is not limited to the method described above.
[0122] Thus, if the game part is cleared in manual mode M11 immediately before transitioning to the first auto mode M21, the auto processing cycle (first processing cycle) is determined based on the clear time in manual mode M11, and the maximum number of cycles is determined based on this first processing cycle and maximum execution time. Also, if the game part is cleared in second auto mode M22 immediately before transitioning to the first auto mode M21, the auto processing cycle (second processing cycle) is determined based on the clear time in second auto mode M22, and the maximum number of cycles is determined based on this second processing cycle and maximum execution time.
[0123] In the first auto mode M21, unlike the second auto mode M22, the actions (attacks, etc.) of user characters and enemy characters do not need to be predetermined. In the first auto mode M21, one cycle of the game part may be advanced using a simpler method than the win / loss determination in the second auto mode M22. As mentioned above, in the second auto mode M22, based on the predetermined actions of user characters C11-C13 and enemy character C31, regardless of user input, the damage dealt to each of the user characters C11-C13 and enemy character C31 can be calculated, and the win / loss determination can be made based on this damage using the same criteria as the win / loss determination in manual mode M11. On the other hand, in the first auto mode M21, without calculating the actions of each character or the damage each character receives, the win / loss can be determined probabilistically based on parameters indicating each character's abilities (e.g., attack power and defense power) set for each character. Thus, in the first auto mode M21, the outcome of the battle game part can be advanced by one cycle by probabilistically determining the winner based on the parameters indicating the abilities of each character, without calculating the actions of each character or the changes in parameters (e.g., life) resulting from those actions. For this reason, in the first auto mode M21, the outcome of the game part can be determined with less computational load than in the second auto mode M22. In the first auto mode M21, unlike the second auto mode M22, it is not necessary to generate an animation representing the battle between the user character and the enemy character. In the first auto mode M21, other than the process for determining the winner or loser, which is performed in the auto processing cycle, it is not necessary to perform any processing to advance the game part. In other words, between the win / loss determination process in one cycle and the determination process in the next cycle, it is not necessary to perform any processing to advance the game part. In the first auto mode M21, processing for each auto processing cycle may be performed only when the game application 15a is running in the foreground.For example, in the first auto mode M21, if the game application 15a is running in the foreground, the number of completed cycles may be calculated based on the elapsed time since the start of the first auto mode M21 and the auto processing cycle, and it may be determined whether or not this number of completed cycles has reached the maximum number of cycles. In the first auto mode M21, it is not necessary to determine the winner or loser for each cycle. Since the first auto mode M21 is a mode for the user to efficiently acquire rewards, it may be set that the user always wins in each cycle. By setting that the user always wins in each cycle, processing for determining the winner or loser becomes unnecessary, thus reducing the processing load in the first auto mode M21. In the first auto mode M21, the determination of the winner or loser for each cycle may be performed collectively for multiple cycles executed during a predetermined time after the start of the first auto mode M21. For example, the determination of the winner or loser for each cycle may be performed collectively at the end of the first auto mode M21 (after the maximum execution time has elapsed).
[0124] As described above, in one embodiment, the auto processing unit 21c can perform win / loss determination processing each time an auto processing cycle arrives from the start of the first auto mode M21. The auto processing unit 21c performs win / loss determination a number of times equal to or less than the maximum number of cycles between the start and end of the first auto mode M21. In another embodiment, the auto processing unit 21c can perform win / loss determination for a number of times equal to or less than the maximum number of cycles at once. In yet another embodiment, the win / loss determination processing in the auto processing unit 21c can be omitted by defining that the user always wins in each cycle.
[0125] The auto-processing unit 21c can determine the reward to be given to the user after the first auto-mode M21 has finished (i.e., after the maximum execution time has elapsed). For example, the auto-processing unit 21c can determine the reward to be given to the user based on the number of times the user is determined to have won from the start to the end of the first auto-mode M21. In this case, the more times the user is determined to have won, the more reward the user may be given. In addition to the number of times the user is determined to have won from the start to the end of the first auto-mode M21, or instead, the auto-processing unit 21c may determine the reward to be given to the user based on the maximum number of cycles. If a reward is also given when the user loses, the reward given to the user may be determined based on the number of times the user is determined to have won from the start to the end of the first auto-mode M21 and the maximum number of cycles.
[0126] The auto-processing unit 21c may determine the reward to be given to the user after each cycle of the game part has finished. The auto-processing unit 21c may also determine the reward to be given to the user in the same way as in manual mode M11. For example, when the competitive game part is running in first auto mode M21, the auto-processing unit 21c may give the user a reward if it is determined that the user has won. The auto-processing unit 21c may also give the user a reward if the user has lost. Therefore, the larger the maximum number of cycles in first auto mode M21, the more opportunities the user will have to receive a reward.
[0127] As described above, in the first auto mode M21, the rewards given to the user are set to increase with the maximum number of cycles. If the rewards increase according to the number of wins the user has, the rewards will increase as the maximum number of cycles increases, as the probability of the user winning increases. Also, if the rewards are given regardless of whether the user wins or loses, or if it is set that the user will win in every cycle, the rewards will increase according to the maximum number of cycles.
[0128] In the first auto mode M21, the rewards given to the user may be determined based on the score, experience points, various points that can be obtained by clearing other game parts, or a combination thereof (hereinafter simply referred to as "earned points") obtained in the game part cleared immediately before transitioning to the first auto mode M21, in addition to or instead of the maximum number of cycles. A game part may be designed so that in order to obtain more earned points by clearing that game part, it is necessary to spend a longer time clearing that game part. For example, consider a game part in which multiple enemy characters appear, and the game part is cleared by defeating the target character among the multiple enemy characters. Furthermore, it is assumed that in that game part, points can be obtained each time an enemy character is defeated, and in the first auto mode M21, the rewards given to the user are calculated so that the shorter the time it takes to clear that game part, and the more points obtained in that game part, the greater the reward. In this case, in order to earn more rewards in the first auto mode M21, the user can adopt a strategy of defeating the target character first in order to clear the game part in a short amount of time before transitioning to the first auto mode M21, or they can adopt a strategy of defeating other enemy characters before the target character in order to increase the points earned in the game part. In this way, by determining the rewards given to the user in the first auto mode M21 based on the points earned in the game part cleared immediately before transitioning to the first auto mode M21, the strategies that the user can take to maximize the rewards obtained in the first auto mode M21 become more diverse, thereby improving the strategic aspect of the game.
[0129] In the first auto mode M21, the process for executing the game part is performed by the server 20 (for example, by the auto processing unit 21c). Therefore, the execution of the game part in the first auto mode M21 is not interrupted even if the game application 15a is not running in the foreground on the user device 10. In other words, even if the game application 15a is running in the background on the user device 10, the execution of the game part in the first auto mode M21 is not interrupted. Therefore, the user can run applications other than the game application 15a in the foreground on the user device 10 while the game part is running in the first auto mode M21.
[0130] Furthermore, even if the game application 15a is not running on the user device 10, or if the user device 10 is powered off, the game part will run without interruption in the first auto mode M21.
[0131] The user can check the status of the first auto mode M21 even before it finishes (i.e., before the maximum execution time elapses from the start of the first auto mode M21). For example, if the game application 15a is running in the foreground on the user device 10, the game part processing unit 11b can display a status screen showing the processing status in the first auto mode M21 on the display of the user device 10. Figure 12 shows an example of a status screen 80 displayed on the display of the user device 10.
[0132] The status screen 80 includes the text "First Auto Mode Running" indicating that the first auto mode M21 is running, display elements 81-83, and an exit button 84. Display element 81 shows the elapsed time since the first auto mode M21 started. Display element 82 shows the remaining time for the first auto mode M21. The remaining time for the first auto mode M21 is calculated by subtracting the elapsed time since the first auto mode M21 started from the maximum execution time. Display element 83 shows the number of times the user has been determined to have won between the start of the battle game part in the first auto mode M21 and the display of the status screen 80. In the embodiment shown in Figure 12, if the auto processing cycle in the first auto mode M21 is 2 minutes and 47 seconds as described above, then one cycle of the game part is completed every 2 minutes and 47 seconds from the start of the first auto mode M21. Therefore, 21 cycles of the game part are completed within 1 hour and 7 seconds from the start of the first auto mode M21. Display element 83 indicates that the user won 15 times out of the 21 cycles of the competitive game part that were completed from the start of the first auto mode M21. If the user is determined to win in each cycle, the number of wins will be 21, the same as the number of completed cycles. In this case, the number of wins displayed in display element 83 will be 21. If the user is determined to win in each cycle, display element 83 may also display the number of completed cycles (21 in the example above), which represents the number of cycles that were completed from the start of the first auto mode M21.
[0133] The status screen 80 may be displayed on the user device 10 when the game application 15a, which was running in the background, returns to the foreground. In one embodiment, the number of wins or completed cycles displayed on the status screen 80 may be calculated in real time during the execution of the first auto mode M21. For example, the number of wins or completed cycles may be incremented each time a time corresponding to the auto processing cycle has elapsed. In another embodiment, the number of wins or completed cycles displayed on the status screen 80 may be calculated when the processing of the game application 15a transitions from the background to the foreground. For example, while the processing of the game application 15a is being performed in the background, the number of wins or completed cycles may not be calculated, and when the processing of the game application 15a returns to the foreground, the number of completed cycles and / or wins may be calculated based on the elapsed time from the start of the first auto mode M21 and the auto processing cycle at the time of returning to the foreground. By not calculating the number of wins or completed cycles while the processing of the game application 15a is being performed in the background, computing resources can be saved. If the number of wins or the number of completed cycles is not calculated while the game application 15a is processing in the background, other processing related to the game mode (for example, processing related to battles such as calculating the amount of damage, processing to determine the win or loss in each cycle, and processing to generate animations corresponding to character actions) does not need to be performed. In this way, when the game application 15a is processing in the background, processing to advance the game part is not performed, and when the game application 15a returns to the foreground, processing related to the execution of the game part (for example, calculating the number of completed cycles, calculating the number of wins, and / or calculating the remaining time) is performed, so that even if the processing of the game application 15a moves to the background after the processing of the game part in the first auto mode M21 has started, the execution of the game part in the first auto mode M21 can continue until the maximum execution time has elapsed.While the processing of the game application 15a is in the background, no processing related to the execution of the game part is performed. However, even if processing related to the execution of the game part is not performed while the game application 15a is in the background, processing such as calculating the number of completed cycles is performed when the game application 15a returns to the foreground, so this does not hinder the user from playing the game part. More specifically, processing related to the execution of the game part (for example, calculation of the number of completed cycles) is performed in response to the processing of the game application 15a returning to the foreground, and the result of this calculation is displayed on the status screen 80. Therefore, when the game application 15a returns to the foreground, the user can check the status of the game part in the first auto mode M21. In this way, even if processing related to the execution of the game part is not performed while the processing of the game application 15a is in the background, by displaying the status screen 80 when it returns to the foreground, the user can be given the impression that the game part is continuing to progress even in the background.
[0134] The status screen 80 may be displayed on the user device 10 in response to the launch of the game application 15a. In this case, the number of wins or completed cycles displayed on the status screen 80 may be calculated in response to the launch of the game application 15a. For example, the number of wins or completed cycles may not be calculated while the game application 15a is not running, and the number of completed cycles and / or wins may be calculated based on the elapsed time from the start of the first auto mode M21 and the auto processing cycle at the time the game application 15a is launched. Computational resources can be saved by not calculating the number of wins or completed cycles while the game application 15a is not running. If the number of wins or completed cycles is not calculated while the game application 15a is not running, other processing related to the game mode may also not be performed. Thus, when the game application 15a is not running, no processing is performed to advance the game part. When the game application 15a is started, processing related to the execution of the game part (for example, calculation of the number of completed cycles, calculation of the number of wins, calculation of the remaining time) is performed. As a result, even if the game application 15a is terminated on the user device 10 after the processing of the game part in the first auto mode M21 has started, the execution of the game part in the first auto mode M21 can continue until the maximum execution time has elapsed. When the game application 15a is terminated and then started again, processing related to the execution of the game part (for example, calculation of the number of completed cycles) is performed, and the calculation result is displayed on the status screen 80. Therefore, the user can check the status of the game part in the first auto mode M21 when the game application 15a is started.In this way, even if no processing related to the execution of the game part is performed while the game application 15a is not running, displaying the status screen 80 when the game application 15a is started gives the user the impression that the game part is continuing to progress even when the game application 15a is not running.
[0135] The information used to calculate the number of completed cycles, namely the elapsed time from the start of the first auto mode M21 and the auto processing cycle, may be stored in the user device 10, in the server 20, or in both the user device 10 and the server 20.
[0136] The status screen 80 may be displayed on the user device 10 as a notification from the game application 15a running in the background. Based on the progress of the first auto mode M21 displayed on the status screen 80, the user can decide whether or not to bring the game application 15a back to the foreground. For example, if the remaining time for the first auto mode M21 is running low on the status screen 80, the user may bring the game application 15a back to the foreground.
[0137] The triggers for displaying the status screen 80 are not limited to the above embodiments. For example, the timing for displaying the status screen 80 may be determined when the first auto mode M21 is executed, and the status screen 80 may be displayed when this determined display timing arrives. In one embodiment, the timing for displaying the status screen 80 can be set to the timing when a predetermined number of game parts have been completed since the start of the first auto mode M21. For example, if the timing for displaying the status screen 80 is set to the timing when 10 cycles of game part processing have been completed since the start of the first auto mode M21, the status screen 80 will be displayed when a time equal to 10 times the auto processing cycle has elapsed since the start of the first auto mode M21. In another embodiment, the timing for displaying the status screen 80 can be set to the timing when a predetermined percentage (e.g., 1 / 2, 1 / 3, 1 / 5, etc.) of the maximum number of cycles has been completed. For example, the timing for displaying the status screen 80 can be set to the timing when 1 / 2 of the maximum number of cycles of game part processing has been completed. The timing of the display of the status screen 80 may be determined before transitioning to the first auto mode M21, or it may be determined after transitioning to the first auto mode M21.
[0138] If the exit button 84 is selected on the status screen 80, the first auto mode M21 will terminate even before the maximum execution time has elapsed. If the exit button 84 is selected, the game part that was running in the first auto mode M21 may also be terminated. When the exit button 84 is selected, the elapsed time that had been counted since the start of the first auto mode M21 is reset. Therefore, if the first auto mode M21 is started again, the elapsed time since the start of the first auto mode M21 will be counted from the time it was restarted.
[0139] Although not shown in the diagram, the status screen 80 may include buttons for mode transitions. For example, the status screen 80 may include at least one of a first transition button for transitioning to manual mode and a second transition button for transitioning to the second auto mode M22.
[0140] Next, referring to Figure 13, we will explain the process flow for advancing the game part in manual mode M11. In Figure 13, it is assumed that the user has selected the versus game part.
[0141] During game execution, multiple game parts that the user can select are displayed on the user device 10. The user selects one game part from among the multiple game parts displayed on the user device 10. Once a game part is selected by the user, in step S11, that game part is started in manual mode M11.
[0142] Next, in step S12, the battle between the user's character and the enemy character takes place. If the game part being played uses a turn-based system, the user character and the enemy character take turns attacking. Instructions from the user are entered during the user's attack turn. The user character takes actions according to the user's input. For example, the user character attacks the enemy character in accordance with the user's input to attack the enemy character. During the enemy character's attack turn, the user character is attacked by the enemy character.
[0143] While the game part is running in manual mode M11, the user device 10 displays a play screen 50, which includes a toggle button 51 for switching the game mode to the second auto mode M22, as shown in Figure 8. When the toggle button 51 is selected and the transition to the second auto mode M22 is confirmed, the transition process to the second auto mode M22 is performed in step S14. After the transition process to the second auto mode M22 is completed, the game part that was running in manual mode M11 before the switch is run in the second auto mode M22. In the second auto mode M22, the battle process proceeds without user input. The specific processing flow in the second auto mode M22 will be described later with reference to Figure 14.
[0144] The game part has an termination condition set to end the processing of one cycle. The termination condition for one cycle in the versus game part is, for example, when it is determined that the user has won or lost against the enemy character. As described, the user character's attack turn and the enemy character's attack turn may be performed alternately, and the user may be determined to have won when the enemy character's life becomes zero, and the user may be determined to have lost when the user character's life becomes zero. In step S15, the versus processing in step S12 is repeated until it is determined that the termination condition for one cycle of the game part has been met. If it is determined in step S15 that the termination condition has been met, in step S16, a results screen 70 showing the play result of the completed cycle is displayed on the user device 10.
[0145] If the transition selection button 73 included in the results screen 70 is selected, and the replay button 74 is selected while the transition selection button 73 is selected, in step S18, the currently running game part transitions from manual mode M11 to first auto mode M21. The transition to first auto mode M21 also occurs if the replay waiting time elapses while the transition selection button 73 is selected. The specific processing flow in first auto mode M21 will be described later with reference to Figure 15.
[0146] If the transition to the first auto mode M21 does not occur, and it is detected in step S19 that the exit command button 72 included in the results screen 70 has been selected, the currently running game part is terminated. After the game part is terminated, the main game screen or another game part may be displayed.
[0147] If the replay button 74 is selected while the transition selection button 73 included in the results screen 70 is not selected, the process returns to step S12 and the next cycle of the match is started. This match is performed in manual mode M11. If the replay waiting time elapses while the transition selection button 73 is not selected, the next cycle of the match is also started in manual mode M11.
[0148] As described above, the processing of the game part in manual mode M11 continues until it is selected to terminate the game part in step S19. If the transition to the second auto mode M22 is selected in step S13 while the game part is running in manual mode M11, the execution of the game part will continue in the second auto mode M22 thereafter. Also, if the transition to the first auto mode M21 is selected in step S17 while the game part is running in manual mode M11, the execution of the game part will continue in the first auto mode M21 thereafter.
[0149] Next, referring to Figure 14, we will explain the process flow for advancing the game part in the second auto mode M22. In Figure 14, it is assumed that the user has selected the versus game part.
[0150] First, in step S21, the execution of the game part in second auto mode M22 begins. The processing of the game part in second auto mode M22 may also begin in response to the selection of the toggle button 51 during the execution of the game part in manual mode M11. Some game parts may be configured to be executed in second auto mode M22.
[0151] Next, in step S22, a battle process takes place between the user's character and the enemy character. The battle process in step S22 proceeds according to a predetermined battle logic, without input from the user.
[0152] While the game part is running in the second auto mode M22, the user device 10 displays a play screen 50 that includes a toggle button 51 for switching the game mode to manual mode M11. In the second auto mode M22, the toggle button 51 displays "AUTO ON". When the toggle button 51 is selected and the transition to manual mode M11 is confirmed, the transition process to manual mode M11 is performed in step S24. After the transition process to manual mode M11 is completed, the game part that was running in the second auto mode M22 before the switch is run in manual mode M11.
[0153] In step S25, the match processing in step S22 continues until it is determined that the conditions for ending one cycle of the game part have been met. If it is determined in step S25 that the conditions for ending have been met, in step S26, a results screen 70 showing the results of the completed cycle is displayed on the user device 10.
[0154] If the transition selection button 73 included in the results screen 70 is selected, and the replay button 74 is selected while the transition selection button 73 is selected, in step S28, the currently running game part transitions from the second auto mode M22 to the first auto mode M21. The transition to the first auto mode M21 also occurs if the replay waiting time elapses while the transition selection button 73 is selected.
[0155] If the transition to the first auto mode M21 does not occur, and it is detected in step S29 that the exit command button 72 included in the results screen 70 has been selected, the currently running game part is terminated. After the game part is terminated, the main game screen or another game part may be displayed.
[0156] If the replay button 74 is selected while the transition selection button 73 included in the results screen 70 is not selected, the process returns to step S22 and the next cycle of the match is started. This match is performed in the second auto mode M22. If the replay waiting time elapses while the transition selection button 73 is not selected, the next cycle of the match is also started in the second auto mode M22.
[0157] As described above, the processing of the game part in the second auto mode M22 continues until it is selected to terminate the game part in step S29. If the transition to manual mode M11 is selected in step S23 while the game part is running in the second auto mode M22, the game part will continue to run in manual mode M11 from that point onward. Also, if the transition to the first auto mode M21 is selected in step S27 while the game part is running in the second auto mode M22, the game part will continue to run in the first auto mode M21 from that point onward.
[0158] Next, referring to Figure 15, the process flow for advancing the game part in the first auto mode M21 will be explained. In Figure 15, it is assumed that the user has selected the versus game part.
[0159] First, in step S31, the execution of the game part in the first auto mode M21 begins. Processing of the game part in the first auto mode M21 may also begin depending on whether the transition to the first auto mode M21 is selected on the results screen 70 displayed after the processing of one cycle of the game part in manual mode M11 or second auto mode M22 has finished.
[0160] Next, in step S32, the maximum execution time, which is the upper limit of the time that the first auto mode M21 can be continued, is calculated. The maximum execution time when a user plays the game part in the first auto mode M21 may be determined based on the user's user parameters, for example, rank.
[0161] Next, in step S33, the auto processing period is calculated, which represents the time required to process one cycle of the game part in the first auto mode M21. The auto processing period is calculated by adding the interval between cycles (for example, 20 seconds) to the clear time spent to clear one cycle of the game part immediately before transitioning to the first auto mode M21.
[0162] Next, in step S34, the maximum number of cycles is calculated, which indicates how many cycles of the game part can be executed from the start of the first auto mode M21 until the maximum execution time has elapsed. The maximum number of cycles is calculated based on the maximum execution time and the auto processing cycle. The quotient obtained by dividing the maximum execution time by the auto processing cycle can be used as the maximum number of cycles. For example, if the maximum execution time is 8 hours and the auto processing cycle is 2 minutes and 47 seconds, the maximum number of cycles is 172.
[0163] Next, in step S35, the battle process between the user character and the enemy character is executed without user input. For example, in step S35, at each auto-processing cycle, the outcome of the battle is determined probabilistically based on parameters indicating the abilities of the user character (attack power, defense power, life, etc.) and the abilities of the enemy character (attack power, defense power, life, etc.). This determination of the outcome completes one cycle of the game part in the first auto mode M21. If the auto-processing cycle is 2 minutes and 47 seconds, one cycle of processing is performed every 2 minutes and 47 seconds.
[0164] Next, in step S36, it is determined whether the cumulative number of cycles processed in step S35 from the start of the first auto mode M21 has reached the maximum number of cycles. In the example above, the maximum number of cycles is 172, so it is determined whether the cumulative number of cycles processed in step S35 has reached 172. If the cumulative number of processed cycles is less than the maximum number of cycles, the cycle-based battle processing in step S35 continues. If the cumulative number of processed cycles has reached the maximum number of cycles, then in step S37, it is determined whether the elapsed time since the start of the first auto mode M21 has reached the maximum execution time.
[0165] The processing of the first auto mode M21 in steps S32 to S37 described above may all be performed in the server 20 (for example, the auto processing unit 21c).
[0166] If the elapsed time since the start of the first auto mode M21 reaches the maximum execution time, in step S38, the first auto mode M21 is terminated and the reward to be given to the user is determined. The process of determining the reward to be given to the user may be performed as part of the first auto mode M21, or it may be performed as a separate process after the termination of the first auto mode M21. In one embodiment, the reward is determined, for example, based on the number of times the user is determined to have won from the start to the end of the first auto mode M21. In this case, the more times the user is determined to have won, the more reward may be given to the user. In another embodiment, the reward may be determined based on the number of times the user is determined to have won from the start to the end of the first auto mode M21 and the maximum number of cycles. The reward determination may be such that the reward increases with a larger maximum number of cycles. The reward determined in step S38 is given to the user. The reward given to the user may be determined based on a probability table. In one embodiment, the probability table may define the probability of winning a game medium (e.g., a game item) that may be awarded as a reward for each number of wins by the user or the number of cycles executed in the first auto mode M21 (number of completed cycles). In the probability table, the winning probabilities may be set such that the more wins or completed cycles the user has, the more likely they are to win a game medium. In another embodiment, a single probability table may be defined, and a lottery process based on that probability table may be performed only for the number of wins or completed cycles. For example, if the number of wins is 20, the lottery process based on the probability table is performed 20 times, and the game medium won in those 20 lottery processes is awarded to the user as a reward.
[0167] When the first auto mode M21 terminates, a termination notification may be displayed on the user device 10 to inform the user that the first auto mode M21 has terminated. Since the first auto mode M21 runs even when the game application 15a is running in the background or when the game application 15a is not running, the game application 15a may not be running in the foreground at the time the first auto mode M21 terminates. By displaying a termination notification on the user device 10, the user can be notified in a timely manner that the first auto mode M21 has terminated.
[0168] Next, in step S39, the game part ends. The game part in the first auto mode M21 is processed in this manner.
[0169] Next, we will explain some of the effects and benefits realized by the above embodiment.
[0170] In one embodiment, the game part is repeatedly executed within the maximum execution time without user input in the first auto mode M21, so the user can acquire the rewards given at the end of the game part with little effort. Furthermore, since the time that the first auto mode M21 can be continuously executed is limited to within the maximum execution time, the consumption of computing resources for processing the game part in the first auto mode M21 can be suppressed.
[0171] In one embodiment, increasing the maximum number of cycles increases the user's opportunities to earn rewards. Although the execution time of the first auto mode M21 is limited to the maximum execution time, the user can shorten the auto processing cycle by clearing the game part immediately preceding the transition to the first auto mode M21 in a short amount of time, thereby increasing the maximum number of cycles. Therefore, the user can increase their opportunities to earn rewards by clearing the game part immediately preceding the transition to the first auto mode M21 in a short amount of time.
[0172] In one embodiment, a results screen 70 is displayed on the user device 10 when a game part is completed in manual mode M11 or second auto mode M22. The results screen 70 includes a clear time display area 71 that shows the first play time spent clearing the game part cleared immediately before the results screen 70 was displayed, and a transition selection button 73 for selecting to transition to first auto mode M21. This allows the user to be presented with the first play time, which affects the efficiency of reward acquisition in first auto mode M21, when selecting whether or not to transition to first auto mode M21. If the first play time is long, the user can run the game part again in manual mode M11 or second auto mode M22 to clear it in a shorter time.
[0173] In one embodiment, the second auto mode M22 is executed in either restricted or unrestricted mode, depending on the user's selection. Therefore, the user can participate in the progress of the game in the second auto mode M22 by selecting either restricted or unrestricted mode, without having to make any input during the execution of the game part in the second auto mode M22. In this way, the game part executed in the second auto mode M22 can progress and be completed without requiring user input, but by accepting the user's selection of restricted or unrestricted mode, it is possible to reduce the effort required for user input while providing the user with a deeper gameplay experience.
[0174] In one embodiment, in the second auto mode M22, the availability of skills may be set for each user character or for each skill based on user instructions. This provides a deeper gameplay experience than simply choosing between restricted and unrestricted modes.
[0175] In one embodiment, in the first auto mode M21, the game part is executed even while the game application 15a is running in the background on the user device 10. This allows the game part to be executed in the first auto mode M21 even when another application is running in the foreground on the user device 10. Therefore, the user can earn game rewards while using an application other than the game application 15a on the user device 10.
[0176] In one embodiment, in the first auto mode M21, the game part is executed even when the game application 15a is not running on the user device 10. This allows the user to earn game rewards without using the computing resources of the user device 10.
[0177] In one embodiment, while the game part is running in the first auto mode M21, a status screen showing the status of the first auto mode M21 can be displayed on the user device 10. This allows the user to check the progress of the game part in the first auto mode M21 without interrupting the processing of the game part in the first auto mode M21. The user can check the progress of the first auto mode M21 (for example, the number of wins and the number of completed cycles calculated at the time the status screen 80 is displayed) and the remaining time on the status screen 80. For example, the user can decide whether to terminate the first auto mode M21 or continue running the first auto mode M21 until the maximum execution time based on the remaining time displayed on the status screen 80. The user can also decide whether to bring the game application 15a back to the foreground based on the remaining time displayed on the status screen 80.
[0178] The game system 1 shown in Figure 1 is an example of a system to which the present invention can be applied, and the game system to which the present invention can be applied is not limited to that shown in Figure 1. The game system 1 to which the present invention can be applied may not include some of the components shown in the figure. For example, the game system 1 may not include storage 30. The game system 1 may include components that are not shown. Although only one user device 10 is shown in Figure 1 for the sake of simplicity, the game system 1 may include any number of user devices 10, two or more. The game system 1 may include a cloud environment for distributing the processing that would otherwise be performed by the user devices 10 or the server 20.
[0179] In game system 1, there are no particular restrictions on the location of data storage. For example, various types of data that can be stored in storage 15 may be stored in a physically separate storage (e.g., storage 30) or a database server. In this specification, the data described as being stored in storage 15 may be stored in a single storage or distributed across multiple storages. Furthermore, in this specification and the claims, the term "storage" may refer to either a single storage or a collection of multiple storages, to the extent permitted by the context. The above description of data that can be stored in storage 15 also applies to data stored in storage 25 as far as possible.
[0180] The embodiments of the present invention are not limited to those described above, and various modifications are possible without departing from the spirit of the invention. For example, some or all of the functions performed by processor 11 and processor 21 may be implemented by processors not specified herein, without departing from the spirit of the invention. In Figure 1, processor 11 is shown as a single component, but processor 11 may be a collection of multiple physically separate processors. The same applies to processor 21. In this specification, programs or instructions contained in programs described as being performed by processor 11 and processor 21 may be executed by a single processor or may be executed in a distributed manner by multiple processors. Furthermore, programs or instructions contained in programs performed by processor 11 and processor 21 may be executed by one or more virtual processors.
[0181] Programs executed on processor 11 and / or processor 21 may be stored on various types of non-transitory computer-readable media other than those shown in the diagram. Non-transitory computer-readable media include various types of tangible storage media. Examples of non-transitory computer-readable media include magnetic recording media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (e.g., magneto-optical disks), Compact Disc Read Only Memory (CD-ROM), CD-R, CD-R / W, and semiconductor memory (e.g., mask ROM, programmable ROM (PROM), erasable PROM (EPROM), flash ROM, random access memory (RAM)).
[0182] Even if it is stated that the processes and procedures described herein are performed by a single device, software, component, or module, such processes or procedures may be performed by multiple devices, multiple software programs, multiple components, and / or multiple modules. Similarly, even if it is stated that the data, tables, or databases described herein are stored in a single memory, such data, tables, or databases may be stored in multiple memories on a single device or distributed across multiple devices. Furthermore, the software and hardware elements described herein can also be implemented by integrating them into fewer components or by decomposing them into more components.
[0183] In the processing procedures described herein, particularly those described using flowcharts or sequence diagrams, it is possible to omit some of the steps constituting the processing procedure, add steps not explicitly stated as constituting the processing procedure, and / or change the order of such steps. Processing procedures with such omissions, additions, or changes in order are also included within the scope of the present invention, as long as they do not depart from the spirit of the invention.
[0184] The designations such as "First," "Second," and "Third" in this specification and the claims are used to identify components and do not necessarily limit their number, order, or content. Furthermore, the numbers used to identify components are used context by context, and a number used in one context does not necessarily indicate the same component in another context. Moreover, this does not prevent a component identified by one number from also performing the function of a component identified by another number.
[0185] This specification also discloses the following technical details: This specification also discloses the technologies described in the following sections:
[0186] [Note 1] Equipped with one or more processors, The one or more processors described above are: In the first auto mode, the game part of the game is executed without user input. In manual mode, the game part of the game progresses based on the user's input. Based on the first play time spent to advance the game part by one cycle in the manual mode, the first processing cycle required to execute the game part by one cycle in the first auto mode is determined. In the first auto mode, the game part is executed one cycle at a time for each of the first processing cycles, thereby executing the game part for the maximum number of cycles. Game system.
[0187] [Note 2] The one or more processors, in response to the completion of the game part in manual mode, cause the user's device to display a mode switching button for selecting the first play time and transitioning to the first auto mode. The game system described in Appendix 1.
[0188] [Note 3] The one or more processors initiate the game part without requiring the consumption of points that increase over time. The game system described in Appendix 1 or Appendix 2.
[0189] [Note 4] The one or more processors, in the first auto mode, execute the game part even while the application for the game is running in the background. The game system described in Appendix 1.
[0190] [Note 5] The one or more processors cause the user's device to display status information indicating the status of the first auto mode while the game part is running in the first auto mode. The game system described in Appendix 1 or Appendix 2.
[0191] [Note 6] The status information includes a transition button for switching to the first auto mode. The game system described in Appendix 5.
[0192] [Note 7] The one or more processors cause the user's device to display status information indicating the status of the first auto mode while the game part is running in the first auto mode. The status information includes the elapsed time since the start of the first auto mode and the number of completed cycles determined based on the first processing cycle. The game system described in Appendix 1.
[0193] [Note 8] The one or more processors calculate the number of completed cycles in response to the launch of the application for the game on the user's user device. The game system described in Appendix 7.
[0194] [Note 9] The one or more processors calculate the number of completed cycles in the first auto mode, in accordance with the transition of the application for the game from background to foreground. The game system described in Appendix 7.
[0195] [Note 10] When the first auto mode is terminated, the one or more processors cause the user's device to display a termination notification indicating that the first auto mode has terminated. The game system described in Appendix 1 or Appendix 2.
[0196] [Note 11] The one or more processors, in the second auto mode, advance the game part without user input only when the application for the game is running in the foreground. The game system described in Appendix 1 or Appendix 2.
[0197] [Note 12] The one or more processors, upon completion of the game part in the second auto mode, cause the user's device to display the second play time spent to advance the game part for one cycle in the second auto mode and a mode switching button for switching back to the first auto mode. The game system is as described in Appendix 11.
[0198] [Note 13] The second auto mode includes a restricted mode in which the restricted game function among the multiple game functions is not used, and an unrestricted mode in which the restricted game function is available. The one or more processors, depending on the user's selection, advance the game part in either the restricted mode or the unrestricted mode. The game system is as described in Appendix 11.
[0199] [Note 14] In the aforementioned game part, a character capable of using multiple game functions is used, and for each of the multiple game functions, it is possible to set whether or not to use them in the second auto mode. The game system is as described in Appendix 11.
[0200] [Note 15] A game processing method in which one or more processors execute computer-readable instructions to process a game, In the first auto mode, the process involves executing the game part of the game without user input, In manual mode, the process involves advancing the game part based on the input from the user, A step of determining a first processing cycle required to execute the game part for one cycle in the first auto mode, based on the first play time spent to advance the game part for one cycle in the manual mode, In the first auto mode, the game part is executed one cycle at a time for each first processing cycle, thereby executing the game part for the maximum number of cycles. A game processing method comprising the following features.
[0201] [Note 16] One or more processors, In the first auto mode, the process involves executing the game part of the game without user input, In manual mode, the process involves advancing the game part based on the input from the user, A step of determining a first processing cycle required to execute the game part for one cycle in the first auto mode, based on the first play time spent to advance the game part for one cycle in the manual mode, In the first auto mode, the game part is executed one cycle at a time for each first processing cycle, thereby executing the game part for the maximum number of cycles. A game program that executes the game. [Explanation of Symbols]
[0202] 1. Game System 10 User devices 11 processors 11a Game Management Section 11b Game Part Processing Unit 11c mode switching section 15 Storage 15a Game applications 20 servers 21 processors 21a Game Control Unit 21b Mode setting section 21c Auto Processing Unit 25 storage 25a User management data 25b Game media management data 25c Mode Management Data 25d Status Data
Claims
1. Equipped with one or more processors, The one or more processors described above are: In the first auto mode, the game part of the game is executed without user input. In manual mode, the game part of the game progresses based on the user's input. Based on the first play time spent to advance the game part by one cycle in the manual mode, the first processing cycle required to execute the game part by one cycle in the first auto mode is determined. In the first auto mode, the game part is executed for the maximum number of cycles determined based on the first processing cycle. Upon completion of the first auto mode, the user is granted a reward determined to increase in proportion to the maximum number of cycles. Game system.
2. The one or more processors, in response to the termination of the game part in manual mode, cause the user's device to display a results screen including the first play time. The game system according to claim 1.
3. The results screen includes a mode switching button for selecting to switch to the first auto mode. The game system according to claim 2.
4. The one or more processors initiate the game part without requiring the consumption of points that increase over time. The game system according to claim 1 or 2.
5. The one or more processors, in the first auto mode, execute the game part even while the application for the game is running in the background. The game system according to claim 1 or 2.
6. The one or more processors, in the first auto mode, execute the game part even when the application for the game is not running on the user's device. The game system according to claim 1 or 2.
7. The reward is determined when transitioning from the manual mode to the first auto mode, based on the points earned in the manual mode. The game system according to claim 1 or 2.
8. The one or more processors cause the user's device to display status information indicating the status of the first auto mode while the game part is running in the first auto mode. The game system according to claim 1 or 2.
9. The status information includes a transition button for switching to the first auto mode. The game system according to claim 8.
10. The one or more processors cause the user's device to display status information indicating the status of the first auto mode while the game part is running in the first auto mode. The status information includes the elapsed time since the start of the first auto mode and the number of completed cycles determined based on the first processing cycle. The game system according to claim 1 or 2.
11. The one or more processors calculate the number of completed cycles in response to the launch of the application for the game on the user's user device. The game system according to claim 10.
12. The one or more processors calculate the number of completed cycles in the first auto mode, in accordance with the transition of the application for the game from background to foreground. The game system according to claim 10.
13. When the first auto mode is terminated, the one or more processors cause the user's device to display a termination notification indicating that the first auto mode has terminated. The game system according to claim 1 or 2.
14. The one or more processors, in the second auto mode, advance the game part without user input only when the application for the game is running in the foreground. The game system according to claim 1 or 2.
15. The one or more processors, upon completion of the game part in the second auto mode, cause the user's device to display the second play time spent to advance the game part for one cycle in the second auto mode and a mode switching button for switching back to the first auto mode. The game system according to claim 14.
16. The second auto mode includes a restricted mode in which the restricted game function among the multiple game functions is not used, and an unrestricted mode in which the restricted game function is available. The one or more processors, depending on the user's selection, advance the game part in either the restricted mode or the unrestricted mode. The game system according to claim 14.
17. In the aforementioned game part, a character capable of using multiple game functions is used. For each of the aforementioned multiple game functions, it is possible to set whether or not they can be used in the second auto mode. The game system according to claim 14.
18. A game processing method in which one or more processors execute computer-readable instructions to process a game, In the first auto mode, the process involves executing the game part of the game without user input, In manual mode, the process involves advancing the game part based on the input from the user, A step of determining a first processing cycle required to execute the game part for one cycle in the first auto mode, based on the first play time spent to advance the game part for one cycle in the manual mode, In the first auto mode, the game part is executed for the maximum number of cycles determined based on the first processing cycle, The process of granting the user a reward determined to increase in proportion to the maximum number of cycles upon completion of the first auto mode, A game processing method comprising the following features.
19. One or more processors, In the first auto mode, the process involves executing the game part of the game without user input, In manual mode, the process involves advancing the game part based on the input from the user, A step of determining a first processing cycle required to execute the game part for one cycle in the first auto mode, based on the first play time spent to advance the game part for one cycle in the manual mode, In the first auto mode, the game part is executed for the maximum number of cycles determined based on the first processing cycle, The process of granting the user a reward determined to increase in proportion to the maximum number of cycles upon completion of the first auto mode, A game program that executes the game.