Programs, systems, information processing devices, servers, and methods

Abstract

This invention provides a game program, system, information processing device, server, and method that allows various users to enjoy autoplay. [Solution] A program is provided that causes the processor to perform the following steps: request a second user to play a requested quest specified by the first user; acquire requested play information including the results of playing the requested quest on the second information terminal using the first user's unit; compare past play information with the requested play information and determine which is superior or inferior to the past play information; if the requested play information is determined to be superior, enable the first user to auto-play the requested quest based on the requested play information; and if the past play information is determined to be superior, enable the first user to auto-play the requested quest based on the past play information.

Description

[Technical Field]

[0001] The present invention relates to a program, a system, an information processing device, a server, and a method. In particular, the present invention relates to a program, a system, an information processing device, a server, and a method for a game including an auto-play mode. [Background Art]

[0002] Conventionally, in a game system that provides an executable game on a player terminal, there have been proposed game systems including: an operation control unit that executes auto-play for automatically progressing a game based on a player's request via the player terminal; a remaining time calculation unit that calculates remaining time for which auto-play executed by the operation control unit will continue or a scheduled end time at which auto-play will end based on predetermined auto-play related information; and a display processing unit that displays the remaining time or the scheduled end time calculated by the remaining time calculation unit on a game screen (see, for example, Patent Document 1). According to the game system described in Patent Document 1, the remaining time for which auto-play continues can be easily grasped. [Prior Art Documents] [Non-Patent Literature]

[0003] [Patent Document 1] Japanese Unexamined Patent Publication No. 2023-133521 [Summary of the Invention] [Problem to be Solved by the Invention]

[0004] In the game system described in Patent Document 1, which includes an autoplay function that automatically controls in-game characters and an autoplay looping function, the time taken when the first user loops through autoplay using the same or similar party as the second user can be referenced by the second user (paragraph

[0061] of Patent Document 1). However, in conventional game systems, including the game system described in Patent Document 1, even if other users can refer to the content of one user's autoplay to help them with their own gameplay, it is not guaranteed that other users will be able to play the game in the same way as the first user, because their playing skills and the game elements they possess (e.g., characters and items) may differ from those of the first user. Therefore, other users may not be able to enjoy the autoplay or looping functions of the game.

[0005] Therefore, the object of the present invention is to provide a game program, system, information processing device, server, and method that allows various users to enjoy autoplay. [Means for solving the problem]

[0006] To achieve the above objective, the present invention provides a program for causing a computer equipped with a processor and memory to run a game including an autoplay mode, the program causing the processor to perform the following steps: request a second user to play a requested quest specified by the first user based on a request instruction from the first user; acquire requested play information including the results of playing the requested quest played by the second user on a second information terminal different from the first user's first information terminal using a unit composed of one or more game elements owned by the first user; if past play information for a quest corresponding to the requested quest exists, compare the past play information with the requested play information and determine the superiority or inferiority of the past play information and the requested play information; if the requested play information is determined to be superior, enable the first user to run an autoplay of the requested quest based on the requested play information, and if the past play information is determined to be superior, enable the first user to run an autoplay of the requested quest based on the past play information. [Effects of the Invention]

[0007] The program, system, information processing device, server, and method according to the present invention provide a game program, system, information processing device, server, and method that allows various users to enjoy autoplay. [Brief explanation of the drawing]

[0008] [Figure 1] This is a schematic diagram of the system according to this embodiment. [Figure 2] This is a functional configuration diagram of the system according to this embodiment. [Figure 3] This is a data configuration diagram of each storage section of the storage unit according to this embodiment. [Figure 4] This is a flowchart of the processing in the system according to this embodiment. [Figure 5] This is a flowchart of the process in a modified example of the system according to this embodiment. [Modes for carrying out the invention]

[0009] [Embodiment] <Background of one embodiment> In various games, an auto-play mode is implemented that allows the user to specify game elements (e.g., trading cards or characters) or assemble units composed of multiple game elements (e.g., decks made up of multiple trading cards or parties made up of multiple characters), and then automatically progress through a predetermined quest by automatically controlling the specified game elements or assembled units (each game element that makes up the unit). Furthermore, the auto-play mode may also include a loop mode that automatically repeats a predetermined quest multiple times, depending on the user's settings. Here, as an example, let's assume that the game elements are the characters that appear in the game, and the units are parties composed of multiple characters.

[0010] A quest is, for example, a predetermined unit of gameplay to achieve a specific objective within a game. A quest may be completed by the player consuming in-game resources (e.g., stamina, life, cost, etc.), or it may be possible to complete it without consuming resources. A time limit may be set for quests, and if the completion conditions for the quest are met within the time limit, the user will be given a reward predetermined for each quest. Furthermore, the outcome of a quest may affect the content of the reward, the progress of the game, and / or the development of the game's story. Quests may also have difficulty levels. And even if a player fails to complete a quest because they did not meet the completion conditions, they may be able to replay it. In this way, quests are an in-game feature designed to encourage players to continue playing the game.

[0011] Here, each game may have at least one autoplay mode set up, for example, like the following:

[0012] (Example a) The auto-play mode and loop mode, or either the auto-play mode or the loop mode, of a given quest on the condition that the user clears the quest at least once.

[0013] (Example b) Even if a user is unable to complete a given quest, the auto-play mode and loop mode for that quest will be available up to the point in the game that the user has progressed through gameplay (in this case, the point in the quest from the start of the game to the point in which it has progressed will be considered one set, and multiple sets will be repeated).

[0014] (Example c) In games where the outcome is determined by the user, such as competitive games, the game will remember not only the player's winning plays but also their losing plays, making auto-play mode and loop mode available. In this case, losing a match may not count as clearing the game, but the losing play will also be remembered, and in auto-play mode, the losing play will be automatically executed, and in loop mode, the losing play will be automatically repeated multiple times.

[0015] For example, in the case of (Example a) above, suppose there are two users playing the same game. Suppose that one user clears a quest using a party composed of multiple characters they own, and that user becomes able to use the auto-play mode for that quest (that is, by clearing the quest once, the user becomes able to use the auto-play mode, which automatically plays and clears the quest with the party, as well as the loop mode, which allows the party to automatically execute and clear the quest multiple times).

[0016] On the other hand, other users can refer to the party used by one user to clear a quest, and even if another user uses that party to create their own party (another party), it does not necessarily mean that the other user will be able to clear the quest using that other party, depending on their gameplay skills (for example, if one user is an experienced player and the other user is a beginner who has just started playing, the first user may have superior gameplay skills). Also, in games where characters are obtained through a predetermined lottery, it is likely that not all users will be able to possess the same character. Therefore, in such situations, it is not guaranteed that other users will be able to create a party that was available to one user when they cleared a quest. In this case, other users may not be able to clear the quest in the same way as the first user.

[0017] In other words, even if one user can clear a quest using the same characters as another user, or using the same party that can be formed from characters owned by another user, it does not necessarily mean that other users can clear that quest. Furthermore, other users may not own some or all of the characters that make up the party used by one user to clear a quest. Therefore, if auto-play is enabled on the condition that certain quests are cleared, users who cannot clear those quests may not be able to enjoy repeatedly playing the game using auto-play.

[0018] Furthermore, even in the case of (Example b) above, if the game play skill of another user differs from that of the one user, or the character owned by another user differs from the character owned by the one user, the other user cannot necessarily play the game in the same way as the one user (that is, the progression from game start to a point where the game can progress may differ between the one user and the other user). Therefore, another user cannot necessarily execute the same auto-play mode or round mode as the one user.

[0019] Furthermore, in the case of (Example c) above, even if another user can refer to content where the one user won a competitive game or the like, the other user does not necessarily own the same character as the one user, and cannot necessarily execute the same auto-play mode or round mode as the one user. Furthermore, even when another user owns the same character as the one user, depending on the game play skill of the other user, the other user cannot necessarily operate the character in the same way as the one user. As a result, another user cannot win in competitive games or the like, which may result in only being able to execute an auto-play mode for when the user loses a match, or a round mode in which multiple match losses are automatically repeated.

[0020] Therefore, even if the game is equipped with an auto-play mode and / or a round mode, another user may not be able to fully receive the benefits of these modes, and may not be able to enjoy the game.

[0021] Accordingly, the present inventors have conducted studies from the viewpoint of enabling various users to enjoy the auto-play mode and the lap-clearing mode regardless of differences in skill and differences in owned characters in games implementing an auto-play mode and an auto-play lap-clearing mode, and have arrived at the idea of enabling other users to use a party formed using a character of one user or a character owned by one user. That is, the present inventors have conceived the present invention upon realizing that by having one user request another user to play a game using a character already owned by the one user, it can be expected to clear a quest that was difficult for the one user or to progress the quest to a phase that was difficult for the one user to reach.

[0022] <Overview of Configuration of System 1> Figure 1 shows an overview of a system according to the present embodiment. Specifically, Figure 1(a) shows an overview of the configuration of System 1 according to the present embodiment, and Figure 1(b) shows an overview of the flow of processing in System 1 according to the present embodiment.

[0023] As shown in Figure 1(a), System 1 according to the present embodiment comprises: an information terminal 3 on which one user can execute game play; an information terminal 4 on which another user can execute game play; and a server 7 that executes and controls various game processes.

[0024] In System 1, information terminals 3 and 4, and / or server 7 receive predetermined instructions from one user and / or other users and perform processes to store information about characters owned by each user, play information for predetermined quests, etc., and / or perform various processes related to auto-play mode and loop play. System 1 may be a server-client type system. Furthermore, in System 1, the game program (app) may be installed on information terminals 3 and 4, and various game-related processes may be executed on information terminals 3 and 4 while communicating with server 7 as needed. Moreover, in System 1, if the game program according to this embodiment is installed on information terminals 3 and 4, various processes may be executed between information terminals 3 and 4 without communicating with server 7.

[0025] In Figure 1, an example is shown where information terminal 3 used by one user and information terminal 4 used by another user are each connected to server 7 via communication network 5. However, information terminals of multiple other users may also be connected to server 7 and / or other information terminals, including information terminals 3 and 4, via communication network 5. For the sake of simplicity, the following explanation will mainly describe an example where information terminal 3 (information terminal 3 of one user) and information terminal 4 (information terminal 4 of another user) are connected to server 7 via communication network 5.

[0026] <Assumptions in System 1> The game run on System 1 is a game in which the auto-play mode and loop mode of a predetermined game (for example, a predetermined quest that constitutes a predetermined game unit; hereinafter sometimes simply referred to as "quest") become available once the user completes the quest. If the quest is a competitive game, completing the quest may mean the user winning against the opponent, losing, or drawing. Furthermore, the game run on System 1 may be a game in which the auto-play mode and loop mode of the quest become available from the start to the point where the user completes the quest, even if the user does not complete the quest, simply by playing part of the quest. The quest may also be a stamina-based game.

[0027] Here, the loop mode is defined as follows: When a user plays a predetermined quest and clears it once, System 1 generates clear data for the cleared quest. The clear data includes information such as instructions entered by the user from the start to the completion of the predetermined quest, actions taken by characters in the quest in the virtual space in response to those instructions, and effects received from other characters (NPCs, etc.). Based on the clear data, System 1 generates data (play information) for executing loops of the quest via autoplay. System 1 uses the play information to enable the autoplay mode or loop mode of the predetermined quest in response to instructions from the user. For example, System 1 may execute the loop mode in any of the following forms.

[0028] i) A mode in which the user's gameplay is reproduced on the output unit (e.g., the display unit) of the information terminal 3. In this case, System 1, in response to the user's instruction to execute autoplay or loop mode, starts a quest based on play information including clear data, calculates the quest's progress, and automatically outputs the content that reproduces the quest's progress based on the calculation results to the output unit until the quest is completed. In this case, the output unit outputs the entire process from the start to the completion of one autoplay session of the quest. Therefore, the user will refer to the output unit for the entire process from the start to the completion of one autoplay session of the quest. If multiple autoplay sessions of the quest are executed in response to the user's instruction (i.e., loop mode is executed), System 1 outputs the entire process from the start to the completion of each of the multiple autoplay sessions of the quest to the output unit. If the quest is a stamina-based game, System 1 may start executing the autoplay session of the quest in response to the user's instruction, consume the stamina required to execute the quest each time the quest is executed, and repeat the autoplay session multiple times until all the stamina is consumed.

[0029] ii) A mode that calculates the time taken from the start to the completion of a quest from the clear data included in the play information, and considers the quest to have been completed once for each calculated time that has elapsed. In this case, System 1 calculates the time the user spent from the start to the completion of a quest (hereinafter sometimes referred to as "completion time") from the play information, including the clear data, and starts autoplay according to the user's instructions. System 1 then considers the quest to be completed once each time the completion time has elapsed since the start of autoplay for the quest. System 1 terminates autoplay (or loop mode if multiple autoplays have been performed) in response to the user's instruction to end autoplay, or when a predetermined number of autoplays have been completed. In this case, the output unit of Information Terminal 3 does not output the content of the gameplay during autoplay, and after each or all autoplays have finished, it outputs information indicating that autoplay or loop mode has ended.

[0030] iii) A mode that allows the auto-play loop mode to be executed at any time, regardless of whether the user has cleared the designated quest through gameplay. In this case, System 1 generates clear data that includes information such as the instructions the user inputs from the start to the end of a predetermined quest, and the actions taken and effects received by characters in the virtual space in response to those instructions. In this case, "end of quest" refers to either the time when the predetermined quest is completed, or the time when the predetermined quest ends prematurely due to a game over or the like. Therefore, if the user fails to complete the quest, it means that the user was able to progress through the game partway through the quest without completing it. In the auto-play loop mode, the period from the start of the quest to that point is considered one loop unit, and this loop unit is repeated (if the user completes the quest, it is the same as in i) above). In a mode where this loop mode can be executed at any time, System 1 may output the period from the start to the end of one auto-play of a quest to the output unit as in i) above, or it may consider the quest to have ended once each time the time taken by the user from the start to the end of the auto-play of a quest has elapsed, as in ii) above.

[0031] <Overview of an example of processing in System 1> First, one user selects a quest on information terminal 3 that they wish another user to play. The user also selects characters to use in the quest on information terminal 3, or forms a party consisting of multiple characters. The characters that a user can select, and the characters that can be used to form a party, are all characters that the user owns, and do not include characters that the user does not own. Then, as shown in Figure 1(b), system 1 supplies information requesting the other user to play the quest selected by the first user (request information) and information regarding the characters selected or the party formed by the first user (unit information) from information terminal 3 to the other user's information terminal 4, in response to the first user's instructions.

[0032] Other users refer to the request information and unit information on information terminal 4 and consider whether or not to accept the request from user one. If other users do not accept the request, system 1 can, in accordance with user one's instructions, supply the request information and unit information to other users' information terminals. On the other hand, if other users accept the request, they play the quest (request quest) specified by the request information on information terminal 4 using the characters or party specified based on the unit information. In other words, other users play the quest selected by user one using characters owned by user one or a party composed of characters owned by user one (borrowing them from user one).

[0033] When another user completes a requested quest on information terminal 4, system 1 stores information related to that play (play information). System 1 also grants the other user a predetermined reward. Here, play information is information about the situation in which the user (in this case, the other user) played the game, such as the content of the other user's instructions to control characters, etc., or the content of predetermined input instructions given by the other user. System 1 makes the stored play information available to one user on information terminal 3. This allows one user to use the play information stored by system 1 to execute the auto-play mode and loop mode of the requested quest on information terminal 3. System 1 generates and stores play information not only when the other user completes the requested quest, but also when they do not. Here, play information when the other user completes the requested quest is generated based on the completion data from the start to the completion of the requested quest, and play information when the other user does not complete the requested quest (for example, when the requested quest fails or ends due to a game over midway through the requested quest) is generated based on the completion data from the start to the end of the requested quest midway through.

[0034] In other words, System 1 lends one or more characters owned by one user, or a party composed of one or more characters owned by one user, to other users, and enables other users to play quests selected by one user on their information terminal 4 using the characters or party lent by the first user. System 1 then generates and stores play information, including the results of other users' play on the information terminal 4, as play information for the first user, for auto-play mode and / or loop mode. As a result, the user can use the play information generated by System 1 based on other users' gameplay on their own information terminal 3 to execute auto-play mode and loop mode for the quest in question.

[0035] Therefore, according to system 1, any user can enjoy the auto-play mode and / or the looping mode, or receive benefits from the auto-play mode and / or the looping mode, regardless of the user's game-play skill or their character possession status. For example, in system 1, a user may permit another user skilled in game play to use a party composed of characters owned by that user on the other user's information terminal 4, and request the other user to play a predetermined quest using that party. Then, system 1 enables play information generated based on clear data including the play content of the predetermined quest by the other user to be used in the auto-play mode or the looping mode on the user's information terminal 3. Therefore, even if the user cannot execute the auto-play mode or the looping mode due to issues such as lack of confidence in game play or not knowing how to clear a predetermined quest, the user can overcome that situation by using play information based on another user's play.

[0036] It should be noted that there is no particular limitation on the type of game executed in system 1, and for example, various games can be executed, such as training games, card games, racing games, role-playing games, simulation games, strategy games, puzzle games, shooting games, action games, competitive games, sleep games, health games, sports games, location-based games, and idle games.

[0037] Furthermore, the information terminal is a device that can be operated by the user. The information terminal may be, for example, a portable information terminal such as a mobile phone, smartphone, or tablet that is compatible with a mobile communication system. The information terminal may also be, for example, a stationary Personal Computer (PC), laptop PC, notebook PC, portable game console, home game console (stationary game device), and / or a dedicated game console, or an information terminal / head-mounted display / AR glasses with Augmented Reality (AR) functionality. Furthermore, the communication network 5 is a mobile phone network and / or a communication network such as the Internet. The communication network 5 may also include communication networks such as wired LAN and wireless LAN. The details of System 1 according to this embodiment will be described below, but it should be noted that the names and numerical values ​​in the above and below descriptions are merely examples, and the present invention is not limited to these proper names and numerical values, and these proper names and numerical values ​​are not necessarily related to actual proper names and numerical values.

[0038] <Details of System 1> Figure 2 shows an example of the functional configuration of the system according to this embodiment.

[0039] [Overview of System 1 Configuration] The system 1 according to this embodiment includes an output unit 100 that outputs various types of information, an input unit 102 that receives input such as instructions from the user, a play information acquisition unit 108 that acquires information about the game played by the user, a superiority / inferiority determination unit 110 that updates the play information, a control unit 120 that controls various processes of the game, an autoplay unit 124 that enables the execution of the game's autoplay mode and loop mode, a storage unit 130 having a storage unit for storing various types of information, and a communication unit 140 that communicates with various external devices. The storage unit 130 also includes a user information storage unit 132 that stores information about the user, a character information storage unit 134 that stores information about characters, and a quest information storage unit 136 that stores information about quests.

[0040] System 1 may not only have the above-mentioned multiple components and / or functions physically in the same device or location, but some of the above-mentioned multiple components and / or functions may be installed in physically separate locations (which may be within Japan or outside Japan). In this case, each component may be connected by a communication network such as the Internet. For example, System 1 may have some of the functions of its components handled by an external server. System 1 may also be configured as one or more servers. In this case, System 1 is configured by combining information terminals, as well as the components of one server and the components of other servers. Furthermore, in this embodiment, a set of predetermined components can be understood as a single "information processing device," and System 1 may be formed as a set of multiple information processing devices. The method of distributing the multiple functions required to realize System 1 according to this embodiment to one or more hardware can be appropriately determined in consideration of the processing capacity of each hardware and / or the specifications required for System 1. Furthermore, information terminals 3 and / or 4 may have some or all of the configuration and functions of server 7, and server 7 may have some of the configuration and functions of information terminals 3 and / or 4. Furthermore, the various types of information stored in the storage unit 130 may be updated based on user instructions and information received via the input unit 102, or may be updated as needed by obtaining predetermined information from a predetermined server located outside the system 1.

[0041] [Details of System 1 configuration] In the following explanation, we will use as an example a case in which one user requests another user to play a predetermined quest via information terminal 3 and makes their own character available to the other user, and the result of the other user playing the requested quest using the first user's character on information terminal 4 is made available to the first user on information terminal 3. Furthermore, information terminals 3 and 4 are each configured to have at least an output unit 100 as a display unit, an input unit 102, and a communication unit for the information terminal. The information terminal 3 of one user and the information terminal 4 of another user have substantially the same configuration and / or functions, and the same applies whether "one user" is replaced with "another user" or "another user" is replaced with "one user" (that is, the same applies whether information terminal 3 is replaced with information terminal 4 in the following explanation), so in the following explanation, we will mainly describe the functions and outputs of information terminal 3 used by one user, and unless otherwise specified, detailed descriptions of the functions and outputs of information terminal 4 will be omitted.

[0042] Furthermore, the information terminal 3 or the server 7 may have some or all of the configuration and / or functions of the control unit 120 and / or storage unit 130 described below. The information terminal 3 can also connect to the server 7, other servers (servers different from server 7; not shown), and / or other information terminals (including other information terminals such as information terminal 4) via the communication network 5 using wired and / or wireless communication, enabling bidirectional communication and the transmission and reception of predetermined data. The same applies to server 7.

[0043] (Control unit 120) The control unit 120 controls various processes related to the game's progress, autoplay mode, and loop mode based on predetermined game data. Furthermore, for example, the control unit 120 controls various processes in the game executed by System 1 based on game-related information and instructions received from the user. These processes may include, but are not limited to, the following: • Login / logout processing for System 1. • Initial setup process at the start of the game in System 1. The process of forming a unit (party) consisting of one or more characters, according to the user's instructions. • A process that selects a predetermined quest according to the user's instructions. • A process that executes / controls a predetermined quest according to the user's instructions. • A process in which one user requests another user to play a specific quest or other task. • Controlling the movements of each character appearing in the game. • Control over the development of characters owned by the user. • Switching between autoplay mode and / or loop mode. - Processing for interrupting and resuming autoplay mode and / or loop mode. • Processing of in-game mini-games. • Determining the predetermined rewards to be given to users, and processing the distribution of the determined rewards to users. • Processing of predetermined draws (e.g., draws for game elements). • Processing sales and billing for specified items and objects. • Processing notifications of specified information to the user. • Data communication processing between information terminal 3 and server 7. • Data communication processing between information terminal 3 and information terminal 4. • Other various game processing.

[0044] Furthermore, the control unit 120 communicates with the information terminal 3 and the server 7, and controls and advances the user's gameplay based on various information received from the information terminal 3. The control unit 120 can also control the operation of each component of the system 1 (that is, the control unit 120 may have some or all of the functions of other components of the system 1). For example, the control unit 120 controls predetermined lottery processes and / or processes such as granting predetermined characters or items to the user based on various user instructions obtained as the gameplay progresses.

[0045] Furthermore, the control unit 120 executes various game processes in response to user operation input received via the input unit 102. For example, the control unit 120 executes game processes such as storing the user's own information in the storage unit 130, storing information about game elements acquired by the user (e.g., characters and items that can be used in the game) in the storage unit 130, processing the acquisition of items and / or characters by the user for a fee or free of charge, processing the acquisition of in-game virtual currency, processing the consumption of items owned by the user, and issuing instructions to the output control unit to output predetermined information to the output unit 100.

[0046] (Storage unit 130) The storage unit 130 stores various programs executed on the information terminal 3 and / or the server 7, and / or various data used in those programs. Specifically, the storage unit 130 stores game programs executed on system 1, various information supplied from each component of system 1, and / or various information related to games executed on system 1. The storage unit 130 supplies predetermined information to predetermined components in response to requests from other components of system 1. In the various IDs described below, if one ID is associated with another ID, and yet another ID is associated with yet another ID, predetermined information can be made available by tracing the IDs.

[0047] (Storage unit 130: User information storage unit 132) The user information storage unit 132 stores user information, possession information, unit information, play information, and / or friend information, associated with a user ID that identifies the user.

[0048] User information includes, for example, the user's name, a username (a name chosen by the user), login ID, password, gender and date of birth, and / or information about the in-game virtual currency the user possesses (information about the amount of virtual currency held and consumed; for example, information about the amount of virtual currency given to the user free of charge and information about the amount of virtual currency given to the user for a fee).

[0049] Possession information refers to information about characters, items, and other objects that a user has acquired in the game. Examples of possession information include information about characters (for example, a character ID to identify the character, character type and name, and various character parameters such as experience points, level, attack power, defense power, and hit points), and / or information about objects (for example, an object ID to identify the object, object type and name, and information about the object's characteristics and properties). Possession information may also include reward information related to rewards given to the user.

[0050] Furthermore, the user information storage unit 132 updates the initial values ​​of various parameters, such as character experience points and level, within the character information, to the changed parameter values ​​if those parameter values ​​change from their initial values ​​due to the user's gameplay. Therefore, while the values ​​of various parameters of a character stored in the character information storage unit 134 (described later) in association with the character ID of a single character are initial values, the values ​​of various parameters of a single character stored in the user information storage unit 132 in association with the user ID and character ID are not necessarily initial values, and may be values ​​that have increased or decreased from their initial values ​​based on the user's gameplay.

[0051] Unit information is information about a unit (e.g., a party) composed of multiple game elements (e.g., characters) owned by the user. Unit information includes, for example, a unit ID that identifies the unit, the type / name of the unit, the character IDs of each of the multiple characters that make up the unit (these character IDs are the same as the character IDs in the owned information), and / or information about the date and time the unit was formed. The user information storage unit 132 stores this information in association with the unit ID.

[0052] The game elements and units may differ depending on the type of game. For example, the game elements may be characters, trading cards, pieces, etc. The units may be a party composed of multiple characters, a deck composed of multiple trading cards, etc. In this embodiment, an example in which the game elements are characters and the units are a party will be described.

[0053] Play information refers to information about the user's manual play of the game (quest). In addition to the user ID, the play information is associated with at least the quest ID and stored in the user information storage unit 132. The autoplay unit 124 can then use at least some of the information contained in the play information to enable autoplay mode and / or loop mode.

[0054] For example, play information includes various types of information such as the date and time the user played the quest, the party the user used to play the quest, the number of times the quest was played, information about the user's inputs from the start to the end of the quest (i.e., information about all operations performed by the user during the quest), information showing the progress of the game from the start to the end of the quest (including information such as the timing of character placement, the types of techniques and skills used, and the timing of their use), information about the character the user controlled from the start to the end of the quest (for example, coordinate information showing the character's position in the in-game virtual space, information about the character's actions, etc.), the time taken from the start to the end of the quest, information indicating whether or not the quest was completed, and information about the rewards the user obtained by completing the quest. In this case, "end of quest" may refer to any of the following: the time when the quest is completed, the time when the quest is stopped midway through its progression (for example, the time when the quest is not completed and is stopped midway), or the time when the predetermined end is reached even if the quest was not completed (for example, in a competitive quest where the quest is completed if the user wins against the opponent and not completed if the user loses, the predetermined end of the quest is reached when the user loses).

[0055] Furthermore, the play information may be associated with a flag indicating that the auto-play mode and / or loop mode for the quest in question are available. Quests for which the play information is associated with this flag can be executed in auto-play mode and / or loop mode based on user instructions. The user information storage unit 132 stores this information by associating it with the quest ID of the quest, and then associating it with the user ID and the play ID that identifies the play information.

[0056] Furthermore, the user information storage unit 132 may store play information (request play information) for quests that a user has requested other users to play (request quests) by associating it with the quest ID of the request quest and the user ID of the other user who performed the play at the request, and then associating it with a play ID that identifies the request play information. The content of the request play information is the same as the content of the play information.

[0057] Furthermore, if a user responds to a request from another user and plays a quest specified by that user using a party consisting of one or more characters owned by that user, the play information may store information about the user's play of that quest, associated with the other user's user ID. In addition, the play information may include information about the user's performance on the requested quests played in response to requests from other users (e.g., number of plays, number of clears, completion rate, etc.).

[0058] Friend information is information about other users with whom a user is friends. Friend information includes, for example, the other user's user ID and name.

[0059] (Storage unit 130: Character information storage unit 134) The character information storage unit 134 stores character information, which is information about a character, associated with a character ID that identifies the character. Characters include characters that the user can possess, field characters and enemy characters that appear in the game, and other NPCs.

[0060] Character information refers to various pieces of information about characters used in System 1 games. Character information includes the following types of information that are associated with a character ID. For example, this information may include the character's name, character's rarity, character's characteristics, character's image (including still and moving images), and / or character's description (including character's attributes, descriptions of character's skills, etc.).

[0061] Character characteristics include, for example, the character's attributes and gender (male, female, genderless, etc.), personality, skills, techniques used in combat, and / or various parameters. Here, various parameters include, for example, parameters related to the character's growth and evolution (e.g., experience points and level; the experience points required for leveling up and evolving may be set for each level and evolution), and parameters such as the character's attack power, defense power, and hit points. The character information storage unit 134 stores the initial values ​​for each of the various parameters of each character. Furthermore, the maximum values ​​of the character's skills, techniques, and / or various parameters may be variable according to the character's level.

[0062] When a user uses a character (including characters in a party) to play a game such as a quest, the control unit 120 grants the character a predetermined amount of experience points. The control unit 120 then levels up the character each time the cumulative value of the experience points granted to the character exceeds a predetermined threshold. The character's predetermined parameters (e.g., hit points, attack power, etc.) change according to the level up. Therefore, from the perspective of gaining an advantage in games such as quests, it is preferable to use the character in gameplay to allow the character to gain experience points and raise the character's level. In addition, rewards that increase the character's experience points (such as dropped items) may be set as rewards for quests given to the user. In this case, the control unit 120 can increase the experience points of a predetermined character by using the reward on that character according to the user's instructions. Raising the character's level by allowing the character to gain experience points in this way is referred to as "training the character."

[0063] Furthermore, attributes are information assigned to each character, such as the character's type, state, nature, or abilities, and are characteristics that the character possesses. Attributes are not particularly limited, but examples include attributes with names like fire, water, and grass. A single character may have multiple attributes. Attributes may also be attributes of "techniques" or "skills" that a character knows. In this case, for example, a character may have both the character's own attributes and the attributes of the "techniques" they know (which may be the same as or different from the character's own attributes).

[0064] (Storage unit 130: Quest information storage unit 136) The quest information storage unit 136 stores quest information in association with a quest ID that identifies a predetermined quest, which constitutes a predetermined game unit. Examples of quest information include the quest name, quest content, quest completion conditions, quest completion rewards, and / or information regarding whether the quest is always playable (i.e., whether there is a set period during which the quest can be played).

[0065] (Output control unit, output unit 100) The output control unit is controlled by the control unit 120 and causes the output unit 100 to output various information related to the game. The output unit 100 outputs various processing results in system 1 and various information stored in the storage unit 130 in a way that is perceptible to the user. Specifically, the output control unit causes the output unit 100 to output various processing results in each component and information stored in the storage unit 130 as data in a predetermined format, still images, moving images, and / or text and audio. The output control unit may also cause the output unit 100 to output information received from an external server. Note that if the information terminal 3 is a smartphone or the like, the output unit 100 is the display unit of the information terminal 3. Furthermore, the output unit 100 may be configured to include elements such as an audio output unit that outputs sound, a vibration unit that emits vibrations, and / or a light-emitting unit that emits light.

[0066] (Input section 102) The input unit 102 receives input such as predetermined instructions or operations from the user. The input unit 102 supplies the instructions to predetermined components of the system 1. Each component that receives the instructions performs a predetermined function. For example, the input unit 102 is an input device for receiving operation input from the user (e.g., a touch panel, touchpad, pointing device such as a mouse, keyboard, motion sensor, controller, microphone, etc.). In this embodiment, an example is described in which the input unit 102 is a touch panel provided by the information terminal 3. The touch panel may be capable of multi-touch detection. Specifically, the touch panel as the input unit 102 has an input surface 104 into which user operations are input and an input control unit 106 that acquires information about the operations input to the input surface 104. The touch panel is placed on top of the display unit of the information terminal 3, and the surface of the touch panel corresponds to the input surface 104. For example, the display unit of the information terminal 3 displays an area that accepts a predetermined instruction, and the input surface 104 detects the predetermined instruction at a specified location based on the user's operation on that area of ​​the input surface 104 (e.g., touch operation, tap operation, swipe operation, etc.). The input surface 104 supplies the detected information, that is, information indicating the predetermined instruction at the detected location, to the input control unit 106. The input control unit 106 acquires the information indicating the predetermined instruction from the input surface 104 and supplies this information to a predetermined component of the system 1.

[0067] In this embodiment, unless otherwise specified, when a predetermined instruction is given by a predetermined operation / action of the user, such as "responding to user instructions," "based on user instructions," or "receiving user instructions," it refers to the instruction being acquired via the input unit 102.

[0068] (Play information acquisition unit 108) The play information acquisition unit 108 acquires play information related to the user's play of quests. Specifically, the play information acquisition unit 108 acquires play information for quests played by the user on the information terminal 3, associating it with the date and time the quest was played, the quest ID, and the user ID. The play information acquisition unit 108 then stores the acquired play information in the user information storage unit 132. The play information acquisition unit 108 also supplies the acquired play information to the superiority / inferiority determination unit 110.

[0069] (Superiority judgment part 110) The superiority determination unit 110 compares multiple play information for a single quest, determines the superiority of the compared play information, and executes predetermined processing. When past play information for a single quest exists for a user and / or other users, and the play information acquisition unit 108 acquires new play information for that quest, the superiority determination unit 110 determines the superiority of the past play information and the new play information and executes predetermined processing. Specifically, the superiority determination unit 110 determines the superiority of the user's play information and / or other users' play information stored in the user information storage unit 132 and the new play information of the user and / or other users that the user information storage unit 132 has newly acquired (however, both the play information and the new play information are information on the results of the same quest) based on predetermined conditions, and stores the play information that is determined to be superior or information indicating that the new play information is superior (superiority information) in association with it in the user information storage unit 132. In other words, based on the superiority or inferiority of the play information and the new play information (for example, requested play information), the superiority determination unit 110 associates the superior information with the superior information and stores the play information and the new play information in the user information storage unit 132. Regardless of whether or not superior information has been associated, the superiority determination unit 110 may leave the play information stored in the user information storage unit 132, and if there is one or more new play information based on the play of one or more other users, it may overwrite the play information determined to be inferior with the play information determined to be inferior for each of the new play information of one or more other users and store them in the user information storage unit 132.

[0070] Furthermore, the superiority / inferiority determination unit 110 may compare the past play information of other users stored in the user information storage unit 132 with the new play information (new play information) newly stored in the user information storage unit 132. In this case, if the superiority / inferiority determination unit 110 determines that the new play information is superior to the past play information, it may update the past play information of other users with the new play information. Alternatively, if the superiority / inferiority determination unit 110 determines that the past play information is superior to the new play information, it may maintain the past play information as is.

[0071] Furthermore, for example, the superiority / inferiority determination unit 110 compares the user's play information or another user's play information (new play information) for a quest acquired by the play information acquisition unit 108 with the user's play information (old play information) for that quest stored in the user information storage unit 132, which is associated with the user's user ID. If the superiority / inferiority determination unit 110 determines that the new play information meets predetermined conditions based on the comparison of superiority / inferiority with the old play information, it associates superiority information with the new play information. In this case, the superiority / inferiority determination unit 110 may update the old play information with the new play information and store the updated play information (new play information) in the user information storage unit 132 (however, in this case, the old play information may also be left as is).

[0072] Here, satisfying the predetermined conditions means that the content indicated by a predetermined type of information included in the new play information is superior to the content indicated by the same predetermined type of information included in the old play information. In this case, the new play information is superior to the old play information, and the old play information is inferior to the new play information. For example, if the predetermined type of information is information about the time from the start to the completion of a quest (completion time information), the shorter the time indicated by the completion time information, the more superior it may be. Also, if the predetermined type of information is information about a predetermined score that the user earns in a quest, the higher the score, the more superior it may be. Furthermore, if the predetermined type of information is information indicating whether or not a quest has been completed, the case where the user completes a quest is considered superior to the case where they do not complete it. The predetermined conditions can be set as appropriate depending on the type and content of the quest.

[0073] (Autoplay section 124) The autoplay unit 124 enables a mode that automatically progresses a predetermined quest without manual instructions from the user, in response to user instructions, that is, an autoplay mode and / or loop mode for the predetermined quest. Specifically, the autoplay unit 124 refers to the user information storage unit 132 based on the user's instruction to execute the autoplay mode and / or loop mode for the predetermined quest. If the user information storage unit 132 stores play information for a predetermined quest specified by a user, and that play information is associated with the user ID of that user, the autoplay unit 124 executes autoplay for the predetermined quest or enables loop mode based on the user's instructions. On the other hand, if the user information storage unit 132 does not store play information for a predetermined quest specified by a user, and that play information is associated with the user ID of that user, the autoplay unit 124 outputs to the output unit 100 that autoplay and loop mode for the predetermined quest cannot be executed.

[0074] (Communications Section 140) The communication unit 140 enables bidirectional communication between information terminals 3 and / or 4 and predetermined components of server 7. The communication unit 140 supplies predetermined information from predetermined components of server 7 to predetermined components of information terminals 3 and / or 4 via a communication network such as the Internet. Note that information terminals 3 and 4, and server 7, may each have their own communication unit.

[0075] [Processing flow of System 1] The following describes an example of the game processing flow, including the autoplay mode and loop mode, executed in System 1 according to this embodiment. Here, in System 1, an example is described in which autoplay is executed using one user's information terminal 3 and another user's information terminal 4. Unless otherwise specified, "user" in the following description refers to "one user".

[0076] Furthermore, in the following description, various processes are primarily performed by the play information acquisition unit 108, the superiority / inferiority determination unit 110, the control unit 120, and / or the autoplay unit 124. The processing results from the control unit 120, etc., are output to the output unit 100. Each user can play the game while understanding the game's progress and current status based on the information (e.g., image information, text information, audio information, etc.) output to the output unit of their own information terminal. In addition, unless otherwise specified, the various instructions and operations accepted by the control unit 120 may be various instruction inputs accepted by the input unit 102 of information terminal 3 from one user, or various instruction inputs accepted by the input unit 102 of information terminal 4 from another user.

[0077] <Example 1 of processing in System 1> Figure 4 shows an overview of an example of the processing flow in the system according to this embodiment.

[0078] The following describes an example in which a user requests a specific quest from another user's information terminal 4 via information terminal 3, using a party composed of one or more characters owned by the user, and the user makes available on information terminal 3 the play information resulting from the other user manually playing the specific quest using that party on information terminal 4.

[0079] First, the control unit 120, in response to instructions from the user received via the input unit 102, organizes a unit (hereinafter, an example of a unit, "party") consisting of one or more game elements (hereinafter, an example of a game element, "character") owned by the user (step 10; hereinafter, steps will be denoted as "S"). For example, the control unit 120 receives an instruction from the user to organize a party, refers to the ownership information stored in the user information storage unit 132 associated with the user's user ID, and outputs a list of one or more characters owned by the user to the output unit 100 of the information terminal 3. Then, based on the user's instruction to select a character, the control unit 120 organizes a party consisting of the one or more selected characters. The control unit 120 stores information about the organized party as one of the unit information in the user information storage unit 132.

[0080] Next, the control unit 120 selects one quest from one or more quests that the user wishes to play, based on the user's instructions. That is, the control unit 120 receives the user's instruction to select a quest and outputs quest information (for example, quest name, quest summary, etc.) for one or more quests stored in the quest information storage unit 136 to the output unit 100 of the information terminal 3. Then, after receiving the user's instruction to select one quest from one or more quests based on the quest information, the control unit 120 sets the selected quest to be playable on the information terminal 3.

[0081] The control unit 120 receives an instruction from the user to start playing a quest, enables the user to manually play the quest using the party they have formed, and the user plays the quest on the information terminal 3 (S12). The play information acquisition unit 108 then acquires information (play information) about the user's play of the quest from the start to the end (clearance of the quest or termination of the quest). In other words, the play information acquisition unit 108 acquires play information of the user's play of a quest executed on the information terminal 3 using the formed party. The play information acquisition unit 108 associates the acquired play information with the user's user ID and the quest (for example, the quest ID of the quest) and stores it in the user information storage unit 132. Here, if the quest played by the user is a quest that becomes available in auto-play mode and loop mode after being cleared once, the control unit 120 may associate a flag with the play information indicating that the auto-play mode and loop mode for that quest are available when the user clears the quest.

[0082] The user information storage unit 132 may also store play information for quests that the user has not played. In this case, the user information storage unit 132 may associate a "null" value with the play information for quests that the user has not played and store it accordingly.

[0083] Furthermore, if there are multiple quests, the control unit 120 may execute a series of flows for each quest according to the user's instructions, including processing from S10 to S12, the process of acquiring play information by the play information acquisition unit 108, and the process of storing the acquired play information in the user information storage unit 132, and store the user's play information for each quest in the user information storage unit 132. This allows the system 1 to store the user's play information for each quest in the user information storage unit 132 (including information indicating whether the user played each quest, information indicating whether the user cleared each quest, information indicating the time it took the user to clear each quest, information indicating the time taken from the start of the quest to the end of the quest (game over) if the user was unable to clear each quest, and information on flags indicating whether the user can execute auto-play mode and loop mode for each quest).

[0084] The control unit 120 then receives a request from the user via the information terminal 3 for a quest that the user wishes another user to play (a requested quest). Specifically, the control unit 120 designates a requested quest, which is a quest that the user requests another user to play, based on the user's instructions. For example, based on the user's instructions, the control unit 120 accepts the user's selection of one quest from among one or more quests that the user wishes another user to play. That is, the control unit 120 receives instructions from the user and outputs quest information for one or more quests stored in the quest information storage unit 136 to the output unit 100 of the information terminal 3. Then, the user, having referred to the quest information, requests the designation of one quest from among the one or more quests, and the control unit 120 designates the designated quest as a requested quest (S14).

[0085] The control unit 120 can set a requested quest as a quest selected from a group consisting of one or more quests that the user has completed, one or more quests that the user has not completed, one or more quests that the user has progressed partway through, and one or more quests that the user has not played.

[0086] Here, the control unit 120 may restrict the quests that can be set as request quests based on predetermined setting conditions. For example, the control unit 120 can set a condition that the quests that the user can designate as request quests are limited to quests that the user has not yet cleared. For example, if the auto-play mode and loop mode are made available on the condition that the user clears a quest once, the control unit 120 may allow the user to designate a request quest from a group consisting of quests that the user has not cleared, quests that the user has progressed partway through playing, and quests that the user has not played.

[0087] After a requested quest is set, the control unit 120 requests other users to play the requested quest specified by the user, based on the user's request instructions. For example, the control unit 120 receives a request instruction from the user via the input unit of the information terminal 3 to request a third party to play the requested quest. In response to this request instruction, the control unit 120 causes the output unit 100 of the information terminal 3 to output a list of one or more other third parties. The control unit 120 receives the user's instruction to select other users and supplies the information terminal 4 of the other user selected by the user with the request information from the user to play the requested quest, as well as information about the party formed by the user (S14).

[0088] In this case, the other user may be either a user included in the friend information stored in the user information storage unit 132, a user not included in the friend information (a user who is not a friend of the user), or both (it may be possible to select either a group of users included in the friend information or a group of users not included in the friend information, and to select one or more other users from the selected group). Furthermore, the other user may be a specific user or an unspecified user. In addition, the other user may be a user who has already cleared the prescribed quest, or a user who is attempting to clear the prescribed quest with a character that the user does not possess.

[0089] Other users who refer to the request information and party information output to the output unit of the information terminal 4 input information via the input unit of the information terminal 4 indicating whether or not they accept the request from the user. If the control unit 120 receives rejection information from another user indicating that they do not accept the request (No in S16), it repeats the processing from S14 onwards or terminates processing. On the other hand, if the control unit 120 receives acceptance information from another user indicating that they accept the request (Yes in S16), it enables the other user to play the request quest on the information terminal 4. The control unit 120 can also choose not to require acceptance from other users. In this case, processing S16 is omitted. That is, in response to a request to play the request quest from another user who refers to the request information and party information output to the output unit of the information terminal 4, the control unit 120 enables the other user to play the request quest on the information terminal 4 without requiring information from the other user indicating whether or not they accept the request.

[0090] The play information acquisition unit 108 acquires play information (request play information) including the results of the request quest played by the other user on another user's information terminal 4, which is different from the user's information terminal 3, after the other user has accepted the request instruction (or after giving the play instruction if acceptance by the other user is not required). Specifically, the control unit 120 receives an instruction from the other user to start playing the request quest and makes it possible for the other user to play the request quest using the party formed by the user on the other user's information terminal 4. In this case, the control unit 120 makes the user's party stored in the user information storage unit 132 available for use by the other user in playing the request quest.

[0091] Here, the control unit 120 may make one or more characters owned by the user accessible to other users via their information terminal 4, and, based on instructions from other users, form a party consisting of one or more characters selected by those other users from that list. In other words, the control unit 120 may make a list of characters owned by the user accessible to other users, and, based on instructions from those other users, form a party consisting of one or more characters selected by those other users from that list. Specifically, the control unit 120 responds to party formation instructions from other users received through the input section of the information terminal 4, and outputs a list of one or more characters owned by the user to the output section of the information terminal 4. Then, the control unit 120 forms a new party based on the character selection instructions received from other users. The control unit 120 makes the newly formed party available for other users to use when playing the requested quest. As a result, even if another user who has referenced the information on the party formed by the user, received along with the request information, believes that it will be difficult to clear the requested quest with the party formed by the user, the system 1 can form a party using the characters owned by the user that it deems optimal for playing the requested quest.

[0092] Then, other users manually play the requested quest on information terminal 4 (S18). The play information acquisition unit 108 acquires requested play information as play information regarding the other user's play of the requested quest from the start to the end of the play (completion of the quest or termination of the quest midway). In other words, the play information acquisition unit 108 acquires requested play information of the other user's play of the requested quest on information terminal 4 using a party formed by the user or a party formed by another user. The play information acquisition unit 108 stores the acquired requested play information in user information storage unit 132, associating it with the other user's user ID and the quest ID of the requested quest.

[0093] Furthermore, when another user plays a requested quest, specifically when another user finishes playing the requested quest, the control unit 120 grants a predetermined reward to the other user and / or the user (S20). In other words, even if another user plays a requested quest using the user's party, the control unit 120 grants the other user the same reward as if the other user had played the requested quest using a party composed of their own characters (i.e., another user's party composed of one or more characters owned by the other user), and may also grant the same reward to the user. The control unit 120 stores the rewards granted to other users in the user information storage unit 132, associated with the other user's user ID, and stores the rewards granted to the user in the user information storage unit 132, associated with the user's user ID.

[0094] The rewards may be, for example, predetermined points, predetermined items, experience points for each of the one or more characters in the party that completed the requested quest, and / or in-game virtual currency. The rewards may differ depending on whether another user completes the requested quest or whether another user completes the quest but progresses it partway. The control unit 120 may also grant rewards to the user and other users after processing in S24.

[0095] The superiority determination unit 110 then compares the user's play information for the quest corresponding to the requested quest with the requested play information and determines the superiority or inferiority of the play information and the requested play information. That is, the superiority determination unit 110 compares the user's play information stored in the user information storage unit 132, which is associated with the quest ID of the requested quest, with the requested play information stored in the user information storage unit 132, which is associated with the quest ID and the user IDs of other users. The superiority determination unit 110 then determines whether or not to associate superiority information with the requested play information based on whether or not the content indicated by the requested play information is superior to the content indicated by the play information (S22).

[0096] The superiority determination unit 110 may determine that the requested play information is superior to the user's play information in the following cases:

[0097] a) When the user has not completed the quest corresponding to the requested quest, but the requested play information includes information indicating that the quest has been completed. Furthermore, if a request quest played by another user is a quest that becomes available in auto-play mode and loop mode after being completed once, the control unit 120 may associate a flag with the request play information indicating that the auto-play mode and loop mode for that request quest are available when the other user completes the request quest. b) When a user has completed the quest corresponding to the requested quest, but the specified game result in another user's requested play information is better than the specified game result in the user's play information. For example, a predetermined game result could be the time from the start to the completion of a quest (completion time), the score obtained when playing and completing a quest (score earned), or predetermined parameter values ​​consumed during the quest (values ​​such as hit points or magic points). Furthermore, a request play information game result (request result) being superior to the play information game result (user result) could be, for example, if the completion time shown in the request result is faster than the user result, if the score earned in the request result is higher than the score earned in the user result, or if the amount of predetermined parameter values ​​consumed in the request result is less than the amount of predetermined parameter values ​​consumed in the user result. c) When a user requests that play information be updated with the requested play information. In this case, regardless of the content of the play information and the requested play information, the content of the requested play information may be considered superior to the content of the play information.

[0098] Furthermore, the superiority / inferiority determination unit 110 may update (overwrite) the play information of a predetermined quest stored in the user information storage unit 132 if a null value is stored and there is play information for a request quest corresponding to that quest.

[0099] If the superiority determination unit 110 determines that the requested play information is superior to the play information (Yes in S22), the control unit 120 enables the user to autoplay the quest corresponding to the requested quest on the information terminal 3 based on the requested play information (i.e., the requested play information to which the superiority information is associated) (S24). On the other hand, if the superiority determination unit 110 determines that the requested play information is inferior to the play information (i.e., past play information) (No in S22), the control unit 120 enables the user to autoplay the quest corresponding to the requested quest on the information terminal 3 based on the play information (past play information to which the superiority information is associated) (S26). The autoplay unit 124, in response to the user's instruction to execute an autoplay mode or loop mode, executes the autoplay mode or loop mode on the information terminal 3 using the updated or pre-update play information for the quest specified by the user.

[0100] Here, the control unit 120 can output the autoplay mode and loop mode to the output unit of the information terminal 3 in the following manner, for example.

[0101] i) A method of outputting the progress of a quest during autoplay as a video. The control unit 120 outputs the progress of the requested quest, from start to finish, as contained in the requested play information, to the output unit of the information terminal 3. In this case, when the output of the video from start to finish of the requested quest is complete, one autoplay is considered to have ended. The control unit 120 may also vary the playback speed of the video in response to user instructions. ii) A method in which a video showing the process during autoplay is not output, and the time from the start to the end of the quest included in the request play information is calculated, and the quest is considered to have ended once the calculated time has elapsed. The control unit 120 calculates the time other users played from the start to the end of a requested quest based on the start and end timing information of the requested quest included in the requested play information, and when the time calculated from the time the user instructed the start of auto-play mode and loop mode has elapsed, it may be considered that the quest in auto-play mode and loop mode has ended. iii) A mode in which the actions of other users, such as controlling characters, are output as they are during autoplay. The control unit 120 may refer to all operation history during other users' requested quests included in the requested play information, and output content that completely traces the other user's gameplay based on the instructions the other user entered from the start to the end of the requested quest.

[0102] This allows users to reflect the results of other users' requested quests in the autoplay of the corresponding quest on their own information terminal 3. In other words, users can use other users' requested quest play information, which may include better results than their own, to play the autoplay and / or loop mode of the quest. Therefore, even if a user lacks confidence in their own skills or doesn't know how to use their characters effectively, they can still enjoy the autoplay and loop mode of the quest.

[0103] Furthermore, the control unit 120 can also grant a predetermined reward to other users each time a user executes auto-play mode or loop mode using request play information generated by other users' gameplay on information terminal 3. Specifically, the control unit 120 generates request play information when another user plays and completes a request quest on information terminal 4 or progresses partway through the game. Each time a user executes auto-play mode or loop mode for a quest corresponding to a request quest on information terminal 3 using the generated request play information, the control unit 120 grants a predetermined reward to the other user. As a result, when another user plays a request quest based on the user's request information and causes system 1 to generate request play information, the other user can receive a reward without playing the game each time the user executes auto-play mode or loop mode using that request play information. Therefore, system 1 provides an incentive for other users to play request quests for the user.

[0104] Furthermore, the control unit 120 may count the number of times the requested play information has been used each time a user uses the requested play information to execute the auto-play mode or loop mode on the information terminal 3. That is, the control unit 120 generates requested play information when another user plays and completes a requested quest on the information terminal 4 or progresses partway through the game, and each time a user uses the generated requested play information to execute the auto-play mode or loop mode of the quest corresponding to the requested quest on the information terminal 3, the control unit 120 cumulatively adds up the number of times the requested play information has been used. The control unit 120 may then output the number of times the requested play information has been used to the output units of the user's information terminal 3 and the other user's information terminal 4 at predetermined timings (for example, each time the number of times the requested play information has been used reaches a predetermined number), or at any time.

[0105] <Example of processing in System 1, Part 2> In Processing Example 2, the process is almost identical to Processing Example 1, except that when another user plays a requested quest and requested play information is generated, information about the other user who played the game that generated the requested play information can be output to at least one of the user's information terminal 3, the other user's information terminal 4, and / or the information terminal of yet another user. Therefore, a detailed explanation is omitted except for the differences.

[0106] The control unit 120 outputs information about other users who performed the play that generated the requested play information, which has been stored in the user information storage unit 132 by the play information acquisition unit 108 in association with other users, to the user's information terminal 3 at a predetermined timing. For example, the control unit 120 outputs information about other users who performed the play that generated the requested play information to the output unit of the information terminal 3 at the timing when it receives an instruction from the user to execute an auto-play mode or loop mode using the requested play information, and / or while the auto-play mode or loop mode is being executed in response to the instruction. The control unit 120 can also output information about other users who performed the play that generated the requested play information to the information terminal 4 of other users, and / or to the information terminals of yet other users. Furthermore, the control unit 120 may also output some or all of the various information included in the requested play information, along with the information about the other users, to the information terminals 3, 4, and / or to the information terminals of yet other users.

[0107] Here, information about other users may include, for example, the name of the other user, their performance on requested quests (such as the number of times the user has played, completed, and completed the requested quests so far), and / or information such as the date and time the requested quest play information was generated.

[0108] Therefore, in System 1, not only the user and other users, but also other users can access information on their own information terminals, such as whether other users have completed requested quests and details of how those quests were played (various details such as how other users controlled their characters). This also increases the likelihood that other users will receive requests for specific quests from other users.

[0109] <Example 3 of processing in System 1> In Processing Example 3, one or more characters owned by the user are made accessible on another user's information terminal 4. Based on the other user's instructions, a party is formed consisting of one or more characters selected by the other user from the user's list of one or more characters, and one or more characters specified by the user. In other words, Processing Example 3 is almost identical to Processing Example 1, except that when the user requests a quest from another user, the user requests the use of one or more characters specified by the user (hereinafter sometimes referred to as "specified characters") in the requested quest. Therefore, a detailed explanation will be omitted except for the differences.

[0110] The control unit 120 receives a request from the user via the information terminal 3 for a requested quest that another user wishes to play, and sets the specified quest as the requested quest. After the requested quest is set, the control unit 120 supplies information to the other user's information terminal 4 requesting that the user play the requested quest specified by the user, based on the user's request instructions. In this case, the control unit 120 receives a request from the user for one or more characters to be used in the requested quest. The specified characters are characters designated by the user from among the one or more characters stored in the user information storage unit 132 associated with the user's user ID (i.e., characters owned by the user). The control unit 120 also supplies information to the information terminal 4 requesting that one or more specified characters be used in the requested quest, along with the request to the other user to play the requested quest. This requested information may be, for example, text data (for example, information such as "Please use the specified character A in the quest").

[0111] When the control unit 120 receives acceptance information from another user's information terminal 4 to accept a request, it forms a party including one or more designated characters specified by the user, based on the instructions from the other user. For example, the control unit 120 outputs a list of one or more characters owned by the user, along with information identifying the one or more designated characters specified by the user (e.g., character names), to the output unit of the other user's information terminal 4. The control unit 120 then forms a party consisting of one or more designated characters and one or more characters selected by the other user. The control unit 120 then enables the other user to play the requested quest on their information terminal 4 using this party. When the other user finishes playing the requested quest, the control unit 120 grants the other user and / or the user a predetermined reward.

[0112] Therefore, in Processing Example 3, for example, if a reward is given that grants experience points to one or more characters that make up the party used in the requested quest, the experience points will be granted to the character specified by the user. Thus, in Processing Example 3, the user entrusts the character they wish to train to another user, and that character is incorporated into a party formed by the other user, and the other user uses that party to execute the quest. As a result, the user can efficiently train the specified character without having to execute the quest using a party that includes that character on the information terminal 3.

[0113] <Example 4 of processing in System 1> In Example 4 of the process, the execution is almost identical to that of Example 1, except that the auto-play mode and loop mode for a quest become available only after that quest has been cleared at least once. Therefore, a detailed explanation will be omitted except for the differences.

[0114] First, steps S10 to S12, as explained in Figure 4, are the same as in Example 1 of the process. Then, the control unit 120 receives a request quest specification from the user via the information terminal 3. Here, the control unit 120 selects a request quest from among one or more quests that the user has not yet completed, based on the user's specified instructions. For example, based on the user's instructions, the control unit 120 accepts the selection of one quest from among one or more quests that the user has not yet completed and that the user wishes another user to play. The control unit 120 receives a specification instruction from the user for one quest from among one or more quests, and sets the specified quest as the request quest. After that, the process from S14 onwards, as explained in Figure 4, is executed in the same way as in Example 1 of the process. Then, the control unit 120 makes the request play information, if another user has completed the request quest, or the request quest information, if another user has progressed partway through the request quest, available to the user for execution of the auto-play mode and loop mode on the information terminal 3.

[0115] <Example 5 of processing in System 1> In Processing Example 5, the process is almost identical to that in Processing Example 1, except that other users play the requested quest to generate requested quest play information, and predetermined information is output based on the number of times the generated requested quest play information is used by the user. Therefore, a detailed explanation will be omitted except for the differences.

[0116] The control unit 120 generates request play information based on the play of request quests by other users on the information terminal 4 and stores it in the user information storage unit 132. The control unit 120 stores the request play information in the user information storage unit 132, associating it with the user's user ID, the user IDs of other users who played the request quest, and the quest ID of the request quest. The control unit 120 then receives a selection instruction from the user for a quest for which request play information has been generated and which corresponds to the request quest, as well as an instruction to execute the auto-play mode and loop mode of the quest, and executes the auto-play mode and loop mode of the quest on the information terminal 3 using the request play information of the quest. Each time this is executed, the control unit 120 stores in the user information storage unit 132 the number of times the auto-play mode and loop mode have been executed, i.e., the number of times the request play information used in the auto-play mode and loop mode has been used, associating it with the user ID, other user IDs, and quest ID.

[0117] The control unit 120 then outputs the number of times requested play information has been used, for example, in a ranking format, to the user's information terminal 3, other users' information terminals 4, and / or even more users' information terminals. That is, the control unit 120 outputs information (ranking information) in a ranking format to the output unit of each information terminal, for example, the name of another user, the quest name corresponding to the quest ID, and the number of uses, in descending order of usage count, which is stored in the user information storage unit 132 associated with the user ID, quest ID, and other user IDs. This allows other users to see on their own information terminal 4 whether the requested play information generated by their own play is being used by the user, or whether there is requested play information that has been used multiple times, and they can feel that they are contributing to the user's gameplay.

[0118] Furthermore, the control unit 120 may also make the contents of the requested play information associated with each quest ID accessible on each user's information terminal, along with the ranking information. The control unit 120 may then have a third-party user (a user different from the user and other users) who has accessed the contents of the requested play information corresponding to a quest ID, execute a request for other users to play the requested quest. In this case, the third-party user replaces the user, and the various processes described in "Processing Example 1" to "Processing Example 5" above are executed.

[0119] For example, suppose that request play information for a user's auto-play mode and loop mode is generated by another user's gameplay, and a third-party user refers to the contents of that request play information and attempts to reproduce the contents of that request play information themselves. In this case, if the third-party user does not have one or more characters that make up the party assembled by the user, even if they refer to the request play information, the third-party user may not be able to perform the same gameplay as the other user. Therefore, by making the contents of the request play information accessible not only to the user and other users but also to third-party users, System 1 can enable a third-party user to request other users to play request quests if the third-party user who referred to the request play information acknowledges the skills of the other user, etc.

[0120] <Example 6 of processing in System 1> In processing example 6, System 1 grants a predetermined reward to the user when the user executes auto-play mode or loop mode using the requested play information.

[0121] The control unit 120 accepts the user's instructions received via the input section of the information terminal 3 and selects a quest for which play information or requested play information exists. The autoplay unit 124 then accepts the user's instruction to execute autoplay mode and / or loop mode and makes the autoplay mode and / or loop mode for the quest executable. When the autoplay mode and / or loop mode for the quest is completed, the control unit 120 grants the user a predetermined reward.

[0122] Here, the control unit 120 may differentiate between the reward given to the user when they manually play and complete a quest (first reward) and the reward given to the user after executing the auto-play mode and / or loop mode of a quest in response to the user's instructions (second reward). For example, the first reward may be more advantageous in the game than the second reward. As an example, if the reward is a predetermined number of points, the points for the first reward may be greater than the points for the second reward.

[0123] Furthermore, when the control unit 120 executes the loop mode, it will execute the autoplay mode multiple times. In this case, the control unit 120 can either grant the user a reward each time the autoplay mode is executed, or it can grant the user a lump sum of rewards after the autoplay mode has been executed a predetermined number of times.

[0124] <Example 7 of processing in System 1> In processing example 7, system 1 outputs to the output unit of the user's information terminal 3 the number of times the other user has played the requested quest that the user has asked to play, the play results, and / or the play details.

[0125] The play information acquisition unit 108 acquires the details of a requested quest that a user has requested another user to play, and which the other user has manually played on the information terminal 4, as requested play information. Here, the requested play information includes various types of information such as the date and time the other user played the quest, the party the other user used to play the quest, the number of times the quest was played, information about the other user's operation inputs from the start to the end of the quest (information about all operation history by the other user during the quest), information showing the progress of the game from the start to the end of the quest (including information such as the timing of character placement, the type of techniques and skills used and the timing of their use), information about the characters the other user controlled from the start to the end of the quest, the time taken from the start to the end of the quest, and information indicating whether or not the quest was cleared.

[0126] The control unit 120, in response to user instructions received via the information terminal 3, outputs the request play information stored in the user information storage unit 132 for a given request quest to the output unit of the information terminal 3. The control unit 120 performs predetermined processing on the request play information and outputs to the output unit, for example, the following content in a way that is perceptible to the user.

[0127] i) The number of times other users have played the same request quest. The number in question may be the total number of times another user has completed a single quest (number of completions) and the number of times they have failed to complete it (number of failures). Alternatively, the number of completions and the number of failures may be output separately.

[0128] ii) As a result of another user playing a quest. The output will show whether or not other users have completed the first quest. If other users play the first quest multiple times, the output may show whether or not they completed the quest for each individual playthrough.

[0129] iii) The progress of other users playing the same quest. For example, in a given quest, the system can output information about the actions of other users' characters, including what they did at different points in the game and what mistakes they made.

[0130] By referring to the number of times other users have played a requested quest, the results of their play, and / or the content of their play, users can formulate strategies for their own future gameplay. For example, if another user has failed to complete a requested quest even once, the user can recognize that one or more of their own characters have low parameters and consider training those characters. Furthermore, the user can recognize that it is difficult or impossible to complete the requested quest with a party composed of one or more of their own characters and consider acquiring characters they do not yet possess. In addition, users can consider improving their own skills by referring to the gameplay of other users.

[0131] <Example 8 of processing in System 1> In Processing Example 8, user play information and requested play information from other users (first requested play information) are generated, and then requested play information from a third user different from the other users (second requested play information) is generated. The process is almost identical to that of Processing Example 1, except that the priority between the first and second requested play information is determined. Therefore, a detailed explanation will be omitted except for the differences.

[0132] The control unit 120 generates first request play information based on the play of a request quest by another user on the information terminal 4 and stores it in the user information storage unit 132. Here, the control unit 120 generates second request play information based on the play of the same request quest by a third user on the third user's information terminal. In this case, the superiority / inferiority determination unit 110 compares the first request play information and the second request play information and determines superiority or inferiority. If the superiority / inferiority determination unit 110 determines that one request play information is superior to the other request play information, it updates the other request play information with the request play information that was determined to be superior.

[0133] For example, suppose the superiority determination unit 110 compares the first request play information and the second request play information and determines that the second request play information is superior. In this case, the superiority determination unit 110 updates the information by overwriting the first request play information stored in the user information storage unit 132 with the second request play information. Alternatively, suppose the superiority determination unit 110 compares the first request play information and the second request play information and determines that the first request play information is superior. In this case, the superiority determination unit 110 updates the information by maintaining the first request play information stored in the user information storage unit 132 as is (the update date and time are updated). Furthermore, if the user's play information for the quest corresponding to the request quest is stored in the user information storage unit 132, the control unit 120 will leave the play information as is in the user information storage unit 132, even if the first request play information and / or the second request play information exist.

[0134] Furthermore, the control unit 120 enables the output of information (e.g., names, etc.) to the user's information terminal 3 that identifies the other user who performed the play that generated the first request play information, and the third user who performed the play that generated the second request play information. (For example, it enables the identification that the user who generated the first request play information is another user, and the user who generated the second request play information is a third user, and then enables the output of the first request play information and the second request play information to the output unit of the information terminal 3.)

[0135] Furthermore, the superiority / inferiority determination unit 110 can also compare the user's play information for the quest corresponding to the requested quest with the first request play information and the second request play information, and determine which is superior or inferior. If the superiority / inferiority determination unit 110 determines that the play information is superior to the first request play information and the second request play information, the control unit 120 enables the user to autoplay the quest corresponding to the requested quest on the information terminal 3 based on the play information. On the other hand, if the superiority / inferiority determination unit 110 determines that the play information is inferior to the first request play information and the second request play information, the superiority / inferiority determination unit 110 compares the first request play information and the second request play information to determine which is superior. Then, the control unit 120 enables the user to autoplay the quest corresponding to the requested quest on the information terminal 3 based on the request play information that was determined to be superior.

[0136] [Processing flow in modified example 1 of System 1] Figure 5 shows an example of the processing flow in Modification 1 of the system according to this embodiment.

[0137] In Modification 1 of System 1, the user borrows the quest completion method from another user or third party who has played and completed the quest, and applies the borrowed completion method to their own character to execute the quest's auto-play mode and / or loop mode.

[0138] First, the control unit 120 receives instructions from another user or a third party (hereinafter simply referred to as "the other user") via the input unit of the other user's information terminal 4 and forms a party consisting of one or more characters owned by the other user (S30). The process in S30 is the same as the process in S10 in the explanation of Figure 4. Next, based on the instructions from the other user, the control unit 120 selects one quest that the other user wishes to play from one or more quests. That is, the control unit 120 receives a quest selection instruction from the other user and outputs quest information for one or more quests stored in the quest information storage unit 136 to the output unit of the information terminal 4. Then, the control unit 120 sets the one quest selected by the other user from one or more quests, after referring to the quest information, to be playable on the information terminal 4. The control unit 120 receives an instruction from the other user to start playing the one quest, makes it possible for the other user to play the one quest using the party formed by the other user, and the other user manually plays the one quest on the information terminal 4 (S32).

[0139] Next, the play information acquisition unit 108 acquires play information (manual play) of another user on the information terminal 4 of another user for a quest using the assembled party. The play information acquisition unit 108 stores the acquired play information in the user information storage unit 132, associating it with at least the other user's user ID and the quest ID of the quest (S34).

[0140] The control unit 120 then makes available on the information terminals of multiple users other than other users at least a portion of the play information generated by other users, along with information about the quest on which the play information was generated (for example, a summary of the quest). Furthermore, the control unit 120 makes it possible to receive a request to use the play information via the information terminal of one user. When the control unit 120 receives such a request via the information terminal (for example, information terminal 3) of one user (hereinafter simply referred to as "user") (S36), it determines whether the user can use the play information (S38).

[0141] The control unit 120 determines that a user can use the play information if the user possesses all the characters whose names are identical to at least all the characters that make up the party used by the other user in the quest. In other words, the control unit 120 compares the information of the party (a party formed by the other user) used in the quest play (played by the other user) included in the play information with the information of the characters that the user possesses, which is stored in the user information storage unit 132 and associated with the user's user ID. Specifically, the control unit 120 checks whether all of the characters that make up one or more characters that the other user formed in order to play a quest are included in the information of the characters that the user possesses, which is stored in the user information storage unit 132 and associated with the user's user ID. The control unit 120 determines that the user can use the other user's play information if the user possesses all the characters that make up the party formed by the other user, and determines that the user cannot use the play information if the user does not possess at least one of the characters that make up the party formed by the other user.

[0142] If the control unit 120 determines that the user cannot use the play information (No in S38), it terminates the process. On the other hand, if the control unit 120 determines that the user can use the play information (Yes in S38), it receives instructions from the user or automatically forms a party for the user to play based on information about parties used by other users to play a quest included in the play information (S40).

[0143] Here, the control unit 120 uses characters owned by the user that have the same names as all the characters that make up the other user's party (characters owned by the other user) identified by the other user's play information, to form a party for the user to use in playing a quest. Therefore, even if a character owned by the other user (first character) and a character owned by the user (second character) have the same name, the parameters of the first character and the parameters of the second character are not necessarily the same. Parameters may be, for example, experience points, level, attack power, defense power, hit points, and / or magic points. In this case, the control unit 120 may output to the information terminal 3 in a comparable manner the information of each character that makes up the other user's party (information such as character name and parameters) and the information of each character owned by the user corresponding to each character (information such as character name and parameters).

[0144] Regardless of whether the parameters of the first character and the second character are different or the same, the control unit 120 will use the second character to form the user's party if the first character of another user and the user's second character have the same name. Therefore, even if one or more characters that make up another user's party and one or more characters that make up the user's party have the same name, the parameters of each of the one or more characters of the other user and the parameters of each of the one or more characters of the user are not necessarily the same. Consequently, for example, the first parameter of the first character of another user and the first parameter of the second character of the user may not be the same and may be different.

[0145] After the user forms a party, the autoplay unit 124 enables the execution of an autoplay mode and / or loop mode for a quest using that party. In Modification 1, the autoplay unit 124 enables the execution of an autoplay mode and / or loop mode based on various information required for autoplaying a quest (for example, information regarding the other user's input from the start to the end of the quest, information indicating the game's progress from the start to the end of the quest (including information such as the timing of character placement, the type of techniques / skills used and the timing of their use), information about the characters operated by the other user from the start to the end of the quest, and various information such as the time taken from the start to the end of the quest) from the play information generated by other users' play.

[0146] Then, the control unit 120 receives instructions from the user and instructs the autoplay unit 124 to execute the autoplay mode and / or loop mode of the quest using a party composition that was used when another user played and cleared a quest, while each character in the party is the user's character (S42). Accordingly, the control unit 120 and the autoplay unit 124 use (i.e., reproduce) the placement / timing of characters, character movements, and the timing of skill activation by characters in the gameplay of the quest by another user, and execute the autoplay mode and / or loop mode. After the autoplay and / or loop of the quest is completed, the control unit 120 grants the user a predetermined reward (S44).

[0147] Furthermore, during processing in S42, the control unit 120 can receive instructions from the user to switch gameplay from automatic (autoplay) to manual (manual switching instructions). In response to the manual switching instructions, the control unit 120 enables the user to play a quest manually. That is, after the manual switching instructions, the control unit 120 proceeds with the quest based on user instructions received via the input section of the information terminal 3. The control unit 120 can also receive instructions to switch gameplay from manual to automatic (autoplay) (automatic switching instructions). If the control unit 120 receives an automatic switching instruction while a quest is being played manually, it resumes execution of the quest in autoplay mode and / or loop mode.

[0148] In Modification 1, when a user runs an auto-play mode and / or loop mode using gameplay data from another user's completion of a quest (for example, the operation of one or more characters from the start to the end of a quest), each character constituting the other user's party is replaced with a character owned by the user (including characters that the user has leveled up through gameplay such as quests). In other words, in Modification 1, the user can use, or borrow, the gameplay information of another user (a friend or third party, etc.) who has completed a quest using a party composed of characters with the same names as the user's owned characters. However, in Modification 1, if the user does not own at least some of the characters that make up the other user's party, the user cannot use the other user's gameplay information.

[0149] Furthermore, in Modification 1, the parameters of one or more characters that make up a user's party may not be the same as the parameters of one or more characters that make up another user's party. Therefore, when executing autoplay mode and / or loop mode, the gameplay of other users may not be reproduced exactly, and the content of autoplay mode and / or loop mode may change depending on the parameters of the characters owned by the user. For example, if we compare one character that makes up a party assembled by another user (first character) with one character that makes up the user's party and is owned by the user (second character) (the first and second characters have the same name), suppose the parameters of the first character are more advantageous for progressing through the quest than the parameters of the second character. In this case, even if the user uses a party that includes the second character to execute autoplay mode and / or loop mode for a quest, the progress of the quest shown in the other user's gameplay information may not be the same as the progress of the quest executed by the autoplay mode and / or loop mode.

[0150] Therefore, in Modification 1, even if a user utilizes other users' gameplay information, they may not be able to clear a quest if their character's development status differs from that of other users. However, when forming their own party, the user can compare and refer to the characters they own with those owned by other users. This allows the user to consider which of their own characters to develop in order to form a party that can achieve the same quest results as other users. Furthermore, in Modification 1, the user can also manually execute quests in response to their instructions while the auto-play mode and / or loop mode are running. This allows the user to improve upon other users' gameplay and makes it easier to construct a method for clearing quests using a party composed of their own characters.

[0151] Thus, in Modification 1, if a user possesses the same character as another user, even if the character's parameters differ from those of the other user's character, the user can still access play information about quests completed by the other user on their own information terminal 3. Furthermore, in Modification 1, due to differences in the development status of the user's character and the other user's character, even if the user utilizes the other user's play information, the content of the quest played by the other user may not be reproduced exactly. Therefore, in Modification 1, even when using the play information of another user, the user can still achieve different quest results due to differences in the parameters of their own character, thus providing a more varied game.

[0152] [Processing flow in modified example 2 of System 1] In Modification 2 of System 1, predetermined rewards (clear rewards) are granted while running a predetermined quest loop mode, and the user's character used to run the loop mode can be trained based on the clear rewards.

[0153] First, the control unit 120 accepts the user's instruction received via the input section of the information terminal 3 and selects a quest for which play information or requested play information exists. Then, the autoplay unit 124 accepts the user's instruction to execute loop mode and makes loop mode for the quest available. The autoplay unit 124 repeatedly executes autoplay in loop mode for the number of times specified by the user, or a predetermined number of times.

[0154] The control unit 120 then grants the user a clear reward each time it executes an autoplay (i.e., each time a quest is automatically executed). If the control unit 120 receives a predetermined instruction from the user between one autoplay and the next autoplay (i.e., an instruction to temporarily suspend the loop mode and an instruction to train characters), it suspends the loop mode and trains one or more characters that make up the party used in the loop mode based on the clear reward granted to the user. For example, the clear reward may be a reward that increases the character's level. The control unit 120 may consume the clear reward granted to the user to increase the character's level and increase the character's parameter values ​​according to the increased level. Then, the control unit 120 receives an instruction from the user to resume the loop mode and resumes the quest's loop mode using the party that includes the trained characters.

[0155] Therefore, for example, while running in loop mode, the user can interrupt loop mode at the end of the first quest and use the rewards for clearing the first quest to train one or more characters that make up the party. Then, the user can restart loop mode and run autoplay for the second and subsequent quests using the party that includes the trained characters. If the user is unable to interrupt loop mode at the end of the first quest, the control unit 120 will respond to the user's instructions before the end of the second quest and train one or more characters included in the party using the rewards for clearing the first quest (in this case, autoplay for the second quest will be run with a party of characters that have not been trained). The control unit 120 can then respond to the user's instructions or automatically interrupt loop mode at the end of the second quest and enable autoplay for the third and subsequent quests using the party that includes the trained characters.

[0156] Furthermore, the control unit 120 may output a predetermined notification to the output unit of the information terminal 3 when the user becomes eligible to obtain a clear reward while the loop mode is running. This predetermined notification may be a text notification, an audio notification, or the like. In this case, the control unit 120 may use the notification function of the operating system of the information terminal 3 to output the predetermined notification to the output unit, even if the game in system 1 is not running on the information terminal 3.

[0157] Furthermore, the control unit 120 may grant the user rewards such as experience points to one or more characters in the party, in addition to the clear reward, each time it runs autoplay. In this case, even if the control unit 120 does not receive instructions from the user to temporarily suspend the loop mode or to train characters, it may automatically grant experience points to one or more characters that make up the party used in the loop mode and train them.

[0158] Furthermore, the control unit 120 may, based on the user's choice, set two modes for the clear rewards granted to the user each time autoplay is executed: one mode for using the clear rewards during loop mode on one or more characters in the party used for autoplay (immediate use mode), and another mode for accumulating the clear rewards without using them during loop mode (storage mode). If the user sets the storage mode, the control unit 120 may also use the accumulated clear rewards on a character of the user's choice (including characters other than the one or more characters in the party used for loop mode).

[0159] Thus, in Modification 2, when multiple autoplays are performed, one or more characters that make up the party used by the user in loop mode are given a predetermined reward for each autoplay. As a result, one or more characters are leveled up during loop mode, and with each additional autoplay, they gradually acquire parameters that are advantageous for completing quests. Therefore, in Modification 2, the efficiency of loop mode using a party composed of characters owned by the user can be improved. In other words, in Modification 2, characters can be leveled up during loop mode, so the time from the start to the end of multiple autoplays, which would not occur if characters were not leveled up, can be shortened according to the number of autoplays performed in loop mode.

[0160] [Processing flow in modified example 3 of System 1] In Modification 3 of System 1, during the execution of the autoplay mode and / or loop mode, the user-controllable characters are output to the output unit along with the characters that operate based on the play information or requested play information. Modification 3 assumes that the user is required to refer to the output unit until the mode described in "i) Mode in which the user's gameplay is reproduced on the output unit (e.g., display unit) of the information terminal 3" above, that is, until the autoplay mode and loop mode are completed.

[0161] In Modification 3, the processing is almost identical to "Example 1 of Processing in System 1" as described in Figure 4, except that in the processing from S24 and S26 onward, the execution details of the autoplay mode and / or loop mode are output during the autoplay mode and / or loop mode, and a character that accepts manual user input is output along with the autoplay. Therefore, except for the differences, a detailed explanation is omitted.

[0162] When the autoplay unit 124 enables autoplay of a predetermined quest on the information terminal 3 based on request play information generated by another user's play, or when it enables autoplay of a predetermined quest on the information terminal 3 based on play information generated by the user's play, it executes the autoplay mode or loop mode on the information terminal 3 using the request play information or play information of the quest specified by the user, in response to the user's instruction to execute the autoplay mode or loop mode. The same applies when play information is replaced with request play information, so the following explanation will mainly describe an example in which the autoplay mode and / or loop mode are executed using play information (sometimes referred to as "original play information"). In addition, multiple autoplays are executed in loop mode, and the processing in each of the multiple autoplays is the same, so the following explanation will describe a single autoplay.

[0163] When autoplay is executed, the control unit 120 outputs a character based on play information (hereinafter referred to as "auto character") to the output unit, and also outputs a character that the user can control during autoplay (hereinafter referred to as "ghost character") to the output unit. The ghost character may be the same character as the auto character, but the control unit 120 outputs the ghost character in a way that distinguishes it from the auto character. For example, the control unit 120 sets the transparency of the ghost character to be higher than the transparency of the auto character to be output to the output unit.

[0164] The control unit 120 automatically operates the auto-character based on play information, while operating the ghost character in response to user operation instructions received via the input section of the information terminal 3. In other words, the ghost character is a character that the user can manually operate in the same in-game virtual space as the auto-character, even while auto-play is in progress. The play information acquisition unit 108 acquires play information regarding the user's operation of the ghost character from the start of auto-play based on the play information until the end of auto-play. In this way, the user can operate the ghost character and compete with the auto-character, which is operating automatically, to complete quests.

[0165] When a quest is cleared by a ghost character operated by the user, the control unit 120 compares the results of the quest cleared by the ghost character (e.g., clear time, score obtained, etc.) with the results of the quest cleared by the ghost character (e.g., clear time, score obtained, etc.) included in the play information. If the results of the quest cleared by the ghost character are better than the results of the quest cleared by the play information included in the play information (e.g., the clear time using the ghost character is shorter or the score obtained is higher), the control unit 120 updates the original play information with the play information from the ghost character. After the update, the control unit 120 enables the autoplay mode and / or loop mode to be executed by the autoplay unit 124 using the updated play information.

[0166] Therefore, in Modification 3, the user can refer to the output unit that outputs the autoplay mode, and at the same output unit, attempt to generate new play information using a ghost character. As a result, in System 1 according to Modification 3, the user can not only refer to the autoplay process, but also play using the ghost character to update the play information that formed the basis of the autoplay, for example, to improve records such as clear time and score.

[0167] Furthermore, if the user completes a quest by playing with a ghost character while simultaneously executing autoplay, the control unit 120 may grant the user two types of rewards: a reward for executing autoplay and a reward for manually completing the quest using the ghost character. The control unit 120 grants the user two types of rewards even if the play information in autoplay is not updated with play information generated using the user's ghost character. However, the control unit 120 can make the reward for updating the play information by executing the quest with the ghost character different from the reward for not updating the play information (for example, making the reward for updating the play information more advantageous in gameplay than the reward for not updating it). As a result, the user can earn more rewards by playing quests with autoplay using a ghost character compared to simply referencing autoplay at the output unit.

[0168] In Modification 3, the user can play quests using ghost characters even while in autoplay mode and / or loop mode. Therefore, the user can not only refer to autoplay mode and / or loop mode in the output unit, but also play quests simultaneously with autoplay mode and / or loop mode, thus making effective use of the time while autoplay mode and / or loop mode are running.

[0169] [program] Each component of System 1 according to this embodiment, as shown in Figures 1 to 5, can be realized by having a processing unit (processor), such as a Central Processing Unit (CPU), execute a program (for example, a program capable of running various games, including an autoplay mode), that is, by software processing. Alternatively, it can be realized by pre-writing a program to hardware, such as an integrated circuit (IC), which is an electronic component. The processor is hardware for executing the instruction set described in the program, and is composed of an arithmetic unit, registers, peripheral circuits, etc. Furthermore, software and hardware can be used in combination.

[0170] In other words, the program according to this embodiment is a program that causes a computer equipped with a processor and memory to run a game including an autoplay mode. The program according to this embodiment can be pre-installed in, for example, an IC or ROM. The program can also be provided as a computer program by recording it on a computer-readable recording medium such as a magnetic recording medium, optical recording medium, or semiconductor recording medium in an installable or executable file format. The recording medium storing the program may be a non-transient recording medium such as a CD-ROM or DVD. Furthermore, the program can also be pre-stored on a computer connected to a communication network such as the Internet, and made available for download via the communication network.

[0171] The program according to this embodiment interacts with the CPU and other components to cause the program to function as the output unit 100, input unit 102, play information acquisition unit 108, superiority / inferiority determination unit 110, control unit 120, autoplay unit 124, storage unit 130, and communication unit 140, as described in Figures 1 to 5.

[0172] [Effects of the embodiment] In this embodiment, System 1, when a user requests another user to play a quest specified by the user, makes a party composed of the user's characters available for the other user to play the quest. System 1 then stores the content of the other user's play of the quest, and the user can use the stored content to run autoplay mode and / or loop mode on their own information terminal 3. As a result, with System 1, even if a user is not confident in their gameplay skills or finds it difficult to complete a given quest, they can perform autoplay while obtaining hints for clearing, completing, and / or clearing the quest based on the play of other users. Therefore, with System 1, various users can enjoy autoplaying the game.

[0173] Although embodiments of the present invention have been described above, the embodiments described above do not limit the invention as defined in the claims. Furthermore, it should be noted that not all combinations of features described in the embodiments are necessarily essential for solving the problem of the invention. Moreover, the technical elements of the embodiments described above may be applied individually or may be divided into multiple parts, such as program components and hardware components, and applied accordingly.

[0174] Furthermore, the functions realized by the components described herein may be implemented in a circuit or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, Application Specific Integrated Circuits (ASICs), a Central Processing Unit (CPU), conventional circuits, and / or combinations thereof, programmed to realize the described functions. A processor, including transistors and other circuits, is considered a circuit or processing circuitry. A processor may be a programmed processor that executes a program stored in memory. In this specification, circuitry, unit, and means are hardware programmed to realize or perform the described functions. Such hardware may be any hardware disclosed herein, or any hardware known to be programmed to realize or perform the described functions. If such hardware is a processor that is considered a type of circuitry, then such circuitry, means, or unit is a combination of hardware and software used to constitute such hardware and / or processor.

[0175] Furthermore, the program according to this embodiment may also be referred to in the following supplementary information, which should not be confused with the claims.

[0176] (Additional note 1) A program for causing a computer, which has a processor and memory, to run a game including an autoplay mode, The program is provided to the processor: The steps include: requesting the second user to play a quest specified by the first user that the first user has not yet completed, based on the first user's request instructions; The steps include: the second user accepting the request instructions and obtaining request play information including the results of the request quest played manually by the second user on a second information terminal different from the first user's first information terminal using a unit composed of one or more game elements possessed by the first user; A step of enabling the first user to perform an autoplay of the requested quest based on the requested play information. A program that executes the command.

[0177] (Additional note 2) A program for causing a computer, which has a processor and memory, to run a game including an autoplay mode, The program is provided to the processor: The steps include generating play information including the result of the user playing a quest specified by the user on a first information terminal using a unit composed of one or more game elements owned by the user, or generating request play information including the result of another user playing the quest on a second information terminal different from the first information terminal using the unit, The steps include making the aforementioned play information or the aforementioned requested play information available for use on the user's first information terminal, A predetermined reward is given to the user each time the quest is auto-played multiple times on the first information terminal based on the play information or the requested play information, and during the multiple auto-plays, a predetermined parameter of at least one of the one or more game elements included in the unit is changed. A program that executes the command.

[0178] (Additional note 3) A program for causing a computer, which has a processor and memory, to run a game including an autoplay mode, The program is provided to the processor: The steps include generating play information including the result of the user playing a quest specified by the user on a first information terminal using a unit composed of one or more game elements owned by the user, or generating request play information including the result of another user playing the quest on a second information terminal different from the first information terminal using the unit, The steps include making the aforementioned play information or the aforementioned requested play information available for use on the user's first information terminal, The steps include: causing the first information terminal to perform an autoplay of the quest based on the aforementioned play information or the aforementioned requested play information; During the execution of the autoplay, the contents of the autoplay are output, and predetermined game elements that can be manually operated by the user are output along with the output of the autoplay. A program that executes the command. [Explanation of Symbols]

[0179] 1 System 3, 4 Information terminals 5. Communication Network 7 Servers 100 Output section 102 Input section 104 Input surface 106 Input Control Unit 108 Play Information Acquisition Section 110 Superiority Judgment Department 120 Control Unit 124 Autoplay Section 130 Storage Unit 132 User Information Storage Unit 134 Character Information Storage Unit 136 Quest Information Storage Section 140 Communications Department

Claims

1. A program for causing a computer, which has a processor and memory, to run a game including an autoplay mode, The program is provided to the processor: The first step is to request the second user to play the requested quest specified by the first user, based on the first user's instructions. The steps include obtaining request play information, including the results of playing the request quest, which was played by the second user on a second information terminal different from the first user's first information terminal, using a unit composed of one or more game elements owned by the first user; If past play information exists for a quest corresponding to the aforementioned request quest, the step of comparing the past play information with the aforementioned request play information and determining the superiority or inferiority of the past play information and the aforementioned request play information, If the requested play information is determined to be superior, the first user is enabled to perform an autoplay of the requested quest based on the requested play information; if the past play information is determined to be superior, the first user is enabled to perform an autoplay of the requested quest based on the past play information. A program that executes the command.

2. Steps to store the requested play information in association with the second user. The program according to claim 1, which further executes the following.

3. The step of forming the unit consisting of one or more game elements owned by the first user. The program according to claim 1, which further executes the following.

4. The program according to claim 3, wherein the organizing step makes the one or more game elements possessed by the first user accessible on the second information terminal, and organizes a unit consisting of one or more game elements selected by the second user from the list of the one or more game elements based on the instructions of the second user.

5. The program according to claim 3, wherein the organizing step makes the one or more game elements possessed by the first user accessible on the second information terminal, and, based on the instructions of the second user, organizes a unit consisting of one or more game elements selected by the second user from the list of one or more game elements and one or more game elements specified by the first user.

6. The program according to claim 1, wherein the requested quest is a quest designated by the first user from one or more quests that the first user has not completed or one or more quests that the first user has not played.

7. The step of making information about the second user who performed the play that formed the basis for generating the requested play information available for output to the information terminal of at least one user selected from the first user, the second user, and other users different from the second user. The program according to claim 1, which further executes the following.

8. If the second user plays the requested quest, the first user and the second user are each given a reward. The program according to claim 1, which further executes the following.

9. If the aforementioned request play information is determined to be superior, the second user is rewarded each time the first user uses the request play information to perform an autoplay of the request quest. The program according to claim 1, which further executes the following.

10. A system comprising means for performing all steps performed in the invention according to any one of claims 1 to 9.

11. An information processing apparatus comprising a control unit and a storage unit, wherein the control unit performs all steps performed in the invention according to any one of claims 1 to 9.

12. A server comprising a control unit and a storage unit, wherein the control unit performs all steps performed in the invention according to any one of claims 1 to 9.

13. A method to be performed on a computer having a processor and memory, A method by which the processor performs all the steps performed in the invention according to any one of claims 1 to 9.

14. A program for causing a computer, which has a processor and memory, to run a game including an autoplay mode, The program is provided to the processor: The first user makes available to the second user a unit composed of one or more game elements owned by the first user, The steps include: enabling the second user to play the requested quest specified by the first user using the unit, on a second information terminal different from the first user's first information terminal, based on the request from the first user; The steps include obtaining request play information, which includes the results of the request quest played by the second user, The steps include making the requested play information available to the first user on the first information terminal. A program that executes the command.

15. Steps to store the requested play information in association with the second user. The program according to claim 14, which further executes the following.

Images