JP7124044B2 - Information processing system, information processing method, information processing program - Google Patents

Description

The present disclosure relates to an information processing system, an information processing method, and an information processing program.

An information processing technology applicable to a game having a competitive game part (for example, a competitive game part called a raid) in which a plurality of users form a group and compete against a specific opponent (computer-controlled enemy character) is known. It is

Japanese Patent Application Laid-Open No. 2020-162773

In a raid or similar competitive game part as described above, when the number of users becomes enormous, the processing load for updating the HP (HitPoint) value of a specific opponent tends to increase.

Accordingly, in one aspect, an object of the present invention is to appropriately distribute the processing load in a game having a competitive game part between a plurality of users and a specific opponent.

In one aspect, a game part setting unit that sets a competitive game part between a plurality of users and a specific opponent;
a first updating unit that updates the value of a first parameter associated with the specific opponent based on the progress of the competitive game part;
a second updating unit that updates the value of a second parameter associated with the specific opponent based on the progress of the competitive game part;
The information processing system, wherein the first update unit updates the value of the first parameter with a lower update frequency than the second update unit, based on the value of the second parameter updated by the second update unit. is provided.

In one aspect, according to the present invention, it is possible to appropriately distribute the processing load for a game having a competitive game part between a plurality of users and specific opponents.

1 is a block diagram of a game system according to one embodiment of the present invention; FIG. FIG. 11 is an explanatory diagram of the concept of a raid game part according to a comparative example; FIG. 4 is an explanatory diagram of the concept of a raid game part according to the present embodiment; FIG. 11 is an explanatory diagram of processing load in a raid game part according to a comparative example; FIG. 10 is an explanatory diagram of the processing load in the raid game part according to the embodiment; It is a figure which shows an example of user information. FIG. 4 is a diagram showing an example of information about game media; FIG. 5 is a diagram showing an example of boss character information; FIG. 4 is an explanatory diagram of functions related to a raid game part among various functions realized by the server device; FIG. 4 is an explanatory diagram of game data in a game data storage unit; FIG. 10 is a diagram showing an example of a game image related to a minor boss battle part; FIG. 12 is a diagram showing an example of a game image showing the update of the HP value of the big boss upon completion of the small boss battle part; FIG. 10 is a schematic flow chart showing an example of processing related to a small boss battle part setting request from each user; FIG. FIG. 14 is a schematic flowchart showing an example of selection image generation processing (step S1104) in FIG. 13; FIG. FIG. 14 is a schematic flow chart showing another example of the selection image generation process (step S1104) in FIG. 13; FIG. FIG. 11 is a schematic flow chart showing an example of subtraction instruction generation processing in a minor boss battle part; FIG. FIG. 10 is a schematic flow chart showing an example of HP subtraction processing in a big boss battle part; FIG.

Hereinafter, each embodiment will be described in detail with reference to the accompanying drawings. In this specification, with respect to the term "association" or the like, "A and B are associated" means not only that A and B are directly associated, but also that A and B are associated with each other through C and the like.

(Overview of game system)
An overview of a game system 1 according to an embodiment of the present invention will be described with reference to FIG. The game system 1 includes a server device 10 and one or more terminal devices 20 (an example of user terminals). Although three terminal devices 20 are illustrated in FIG. 1 for the sake of simplicity, the number of terminal devices 20 may be two or more.

The server device 10 is an information processing device such as a server managed by, for example, a game operator. The terminal device 20 is an information processing device used by a user, such as a mobile phone, a smart phone, a tablet terminal, a PC (Personal Computer), a head-mounted display, or a game machine. The terminal device 20 can execute a game application according to the present embodiment. The game application may be received by the terminal device 20 from a predetermined application distribution server via the network 30, or may be a storage device provided in the terminal device 20 or a storage medium such as a memory card readable by the terminal device 20. may be stored in advance. The server device 10 and the terminal device 20 are communicably connected via a network 30 . For example, the server device 10 and the terminal device 20 cooperate to execute various processes related to the game.

Note that the network 30 may include a wireless communication network, the Internet, a VPN (Virtual Private Network), a WAN (Wide Area Network), a wired network, or any combination thereof.
(Overview of the game)
An overview of the game according to this embodiment will be described. A game according to this embodiment includes one or more game parts. At least one game part of the one or more game parts may be performed using game media.

Game media are electronic data used in games, and include arbitrary media such as cards, items, points, virtual currency, tickets, characters, avatars, and parameters. Game media are electronic data that can be acquired, owned, used, managed, exchanged, combined, enhanced, sold, discarded, or gifted by the user in the game. It is not limited to what is specified. The game content may be game-related information such as level information, status information, parameter information (physical strength, attack power, etc.) or ability information (skills, abilities, spells, jobs, etc.).

Hereinafter, unless otherwise specified, "game media owned by a user" refers to game media associated with a user ID that can uniquely identify the user as owned game media. Also, "providing game media to the user" indicates that the game media are associated with the user ID as possessed game media. Also, "destroy the game media owned by the user" indicates canceling the correspondence between the user ID and the owned game media. Also, "consuming game content owned by the user" indicates that some kind of effect or influence can be generated in the game according to the cancellation of the correspondence between the user ID and the owned game content. Also, "selling the game media owned by the user" means canceling the association between the user ID and the owned game media, and adding other game media (for example, virtual currency, items, etc.) to the user ID. Indicates that it is associated as a game medium.

A game part is content that a user can play in a game, and includes, for example, quests, missions, mini games, development, enhancement, and synthesis of game media, game media acquisition events, virtual space search events, and opponents ( For example, it may include battle events against other users, enemy characters, enemy buildings, etc.).

The one or more game parts may include a single-play game part and a multi-play game part. The single-play game part may include, for example, a game part (for example, a single-player game part) that is executed based on a user operation on one terminal device 20 used by one user. On the other hand, a game part for multiplay is, for example, a game part common to two or more users (for example, , multiplayer game parts). A game part common to two or more users is, for example, a game part in which at least part of the progress processing of the game part and at least part of the processing results are commonly applied to the two or more users. may include For example, two or more terminal devices 20 cooperate, or two or more terminal devices 20 and the server device 10 cooperate to execute a multi-play game part.

In this embodiment, the one or more game parts include a raid game part as one of the game parts for multiplay. A raid game part is a battle game part in which a plurality of users form a group and battle against a specific opponent (hereinafter referred to as "big boss m1"). The big boss m1 is a very powerful character called a raid boss or the like, and is a game medium such as an NPC (Non-Player Character) that is automatically operated. However, in a modified example, the big boss m1 may be manually operated by a predetermined player. In this case, the big boss m1 may be manually operated by a predetermined player for a certain period of time, or may be manually operated by a predetermined player for the entire period.

FIG. 2 is an explanatory diagram of the concept of the raid game part according to the comparative example, and FIG. 3 is an explanatory diagram of the concept of the raid game part according to this embodiment.

The raid game part according to the comparative example, as conceptually shown in FIG. m0 directly attacks the big boss m1. A battle game part between the big boss m1 and the user's first game medium m0 is executed on the terminal device 20 of each user. Since each user operates the first game medium m0 via the terminal device 20, attack timing and the like may vary. In such a raid game part, the processing load for updating the HP value for the big boss m1 tends to increase when the number of users (the number of terminal devices 20) becomes enormous.

On the other hand, in the raid game part according to the present embodiment, as conceptually shown in FIG. receive. Like the big boss m1, the small boss m2 is, for example, an automatically operated game medium such as an NPC. However, in a modification, the small boss m2 may be manually operated by a predetermined player. For example, some of the plurality of small bosses m2 may be manually operated by a predetermined player, or one or more small bosses m2 may be manually operated by a predetermined player for a certain period of time. good too. The terminal device 20 of each user executes a battle game part between each small boss m2 and his/her own first game medium m0. Each user operates the first game medium m0 via the terminal device 20 . When the small boss m2 is defeated by an attack from the first game medium m0 of each user, the HP value of the small boss m2 is subtracted from the HP value of the big boss m1. That is, the HP of the small boss m2 is associated with the big boss. In this way, each user can reduce the HP value of the big boss m1 by attacking the small boss m2. It should be noted that the small bosses m2 will appear one after another even if they are defeated until the HP value of the large bosses m1 becomes zero. That is, the number of small bosses m2 is prepared such that the HP value of the large boss m1 can finally become zero. In this way, by introducing the concept of the small boss m2 as an alter ego of the big boss m1, the processing load for updating the HP value of the big boss m1 can be reduced.

FIG. 4 is an explanatory diagram of the processing load in the raid game part according to the comparative example shown in FIG. 2, and FIG. 5 is an explanatory diagram of the processing load in the raid game part according to this embodiment.

In FIGS. 4 and 5, the horizontal axis represents time, and the timing of each process is schematically shown. 4 and 5, arrows A1 to A4 schematically represent attack timings from each user, and sections P1 to P4, Q1, and Q2 schematically represent corresponding processing timings.

In the raid game part according to the comparative example shown in FIG. 4, sections P1 to P4 correspond to processing for subtracting the HP value of the big boss m1 in response to attacks from each user (see arrows A1 to A4). do. Note that the process of subtracting the HP value of the big boss m1 may also include the process of updating the HP display of the big boss m1 on the terminal device 20 of each user.

As described above, in the raid game part according to the comparative example shown in FIG. 4, a process of subtracting the HP value of the big boss m1 occurs for each attack from each user (see arrows A1 to A4). For example, the process of subtracting the HP value of the big boss m1 is executed four times for four attacks.

On the other hand, in the raid game part according to the present embodiment shown in FIG. 5, when attacks (see arrows A1 to A4) from the same users as in the comparative example occur, each responds to the small boss. This HP subtraction process and the HP subtraction process for the big boss m1 occur. Specifically, in FIG. 5, a section 501 represents HP subtraction processing for one small boss m2, a section 502 represents HP subtraction processing for another small boss m2, and a section 600 represents a large boss m2. FIG. 11 shows HP subtraction processing for boss m1. FIG.

In the raid game part according to the present embodiment shown in FIG. 5, unlike the comparative example, a process of subtracting the HP value of the big boss m1 occurs for each attack from each user (see arrows A1 to A4). never do. For example, for four attacks, the HP subtraction process for the big boss m1 is executed twice in sections Q1 and Q2 (see arrows A10 and A20).

In this way, according to the present embodiment, the HP related to the big boss m1 is increased less frequently (see arrows A10 and A20) than when the big boss m1 is attacked by each user (see arrows A1 to A4). Subtraction processing can be performed. As a result, the load of HP subtraction processing for the big boss m1 in the raid game part can be reduced. In other words, according to the present embodiment, the HP subtraction process for the big boss m1 can be realized through the HP subtraction process for the small boss m2, so that the processing load is distributed. The load of HP subtraction processing for m1 can be reduced.

4 and 5 relate to the HP subtraction process for the big boss m1 when the big boss m1 is attacked by each user. The same applies to the processing and the like when giving to the game medium m0. For example, when an attack is directly given from the big boss m1 to each first game medium m0, a process for reducing the HP value of the first game medium m0 by the number of first game mediums m0 per attack is required. can occur. On the other hand, the large boss m1 attacks the plurality of first game media m0 via the plurality of small bosses m2, thereby reducing the processing load associated with the large boss m1 in the raid game part. In this case, the plurality of small bosses m2 may implement the attacks of the large bosses m1 as they are, or may implement attacks by dividing the attacks of the large bosses m1 by the number of small bosses m2. Alternatively, the attack of each small boss m2 may be implemented independently without being triggered by the attack of the big boss m1. In this case, the processing related to the direct attack of the big boss m1 can be eliminated. Alternatively, there may be no concept of attacking the big boss m1, and the attacking of each small boss m2 may be implemented independently.

Next, while referring to FIG. 1 again, the game system 1 according to the present embodiment will be described in more detail with reference to FIG. 6 and subsequent figures.

(Configuration of server device)
The configuration of the server device 10 will be specifically described. The server device 10 is configured by a server computer. The server device 10 may be implemented in cooperation with a plurality of server computers. Also, the server device 10 may include a web server. In this case, some of the functions of the terminal device 20, which will be described later, may be realized by the browser processing the HTML document received from the web server and various programs (Javascript) attached thereto.

The server device 10 includes a server communication section 11 , a server storage section 12 and a server control section 13 .

The server communication unit 11 includes an interface that performs wireless or wired communication with an external device to transmit and receive information. The server communication unit 11 may include, for example, a wireless LAN (Local Area Network) communication module or a wired LAN communication module. The server communication unit 11 can transmit and receive information to and from the terminal device 20 via the network 30 .

The server storage unit 12 includes, for example, a primary storage device and a secondary storage device. For example, the server storage unit 12 may include semiconductor memory, magnetic memory, optical memory, or the like. The server storage unit 12 stores various information and programs used for game processing. At least part of the information and programs stored in the server storage unit 12 may be shared and synchronized with the terminal device 20 . Examples of information stored in the server storage unit 12 will be specifically described below.
(Information about the user)
The server storage unit 12 (an example of a user information storage unit) stores information (also referred to as “user information”) regarding each of a plurality of users. User information will be described with reference to FIG. FIG. 6 shows information about each of the two users. User information includes various information unique to the user. For example, the user information includes a user ID, user name, rank, information on owned game media, information on used game media, and friend information. In the user information, each of a plurality of users is associated with information on owned game media, information on used game media, and friend information.

A user ID is information that can uniquely identify a user. Hereinafter, the user ID will be simply referred to as a user.

A user name is information indicating a user's name. A user name, unlike a user ID, may not uniquely identify a user. The user name may be arbitrarily determined and changed according to user operations on the terminal device 20 .

A rank is a parameter that indicates a user's proficiency level with respect to a game. In this embodiment, the rank value may increase as the user plays the game. The higher the rank, the higher the skill level of the user regarding the game.

The information about owned game media includes various information unique to the game media owned by the user in the game (owned game media). When game media are acquired by a user, the game media are associated with the user as owned game media. The details of the information about owned game media will be described later.

The information about the used game media is information indicating the game media (first game media) that the user is allowed to use in the battle game part (for example, the raid game part). The first game media is selected from owned game media.

Friend information represents user IDs in a friend relationship. For example, when user A is friends with users B and C, friend information associated with user A includes user IDs of users B and C. FIG. Note that a friend relationship is realized through a friend application or the like. Thus, friend information includes user IDs of other users who are unidirectionally or bidirectionally associated with the user. Note that users who are in a friend relationship may be able to communicate with each other, such as sending and receiving messages, on the game system 1, for example. Note that the user information may include information indicating the guild or party to which the user belongs instead of or in addition to the friend information.

The contents of the user information are not limited to those described above. For example, the user information may further include information indicating predetermined points that the user has in the game. The points are consumed for the user to play the game part. The consumption amount of the points may differ for each game part. The points may increase, for example, according to the passage of time or according to the use of predetermined game media.

Now, with reference to FIG. 7, an example of the above-described information regarding owned game content will be described in detail. FIG. 7 shows information about two owned game media associated with one user. For example, the information about each possessed game medium includes the game medium ID, game medium name, rarity, level, cost, initial value of HP, attack power, recovery power, and information on game functions. include.

A game medium ID is information that can uniquely identify a game medium. The game medium ID may be stored in the server storage unit 12 in advance. Alternatively, the game media ID may be determined by the server device 10 when allowing the user to acquire the game media.

The game medium name is information indicating the name of the game medium. Unlike the game medium ID, the game medium name may not uniquely identify the game medium. Note that the game content name may change according to the game played by the user who acquired the game content.

Rarity is information indicating the degree of rarity (rarity value) of a game medium.

A level is information indicating the degree of growth of a game medium. For example, the higher the level value, the higher the degree of growth of the game medium. The level value may increase as the user plays the game. Also, for the level related to the first game medium, an upper limit level may be set for each first game medium. In this case, for example, the upper limit level of the first game content may be set in such a manner that the higher the rarity, the higher the upper limit level. Also, the upper limit level of the first game content may be raised by specific enhancement (for example, limit breakthrough).

The cost is a parameter used when deciding which deck to use for the battle game part. For example, a maximum of five first game media may be included in one deck as long as the total cost of each first game media does not exceed a predetermined upper limit HP. In this case, the maximum HP may be increased according to, for example, an increase in the rank of the user.

HP is a parameter used to determine whether the user wins or loses in the competitive game part. For example, when a deck is constructed to realize a battle game part, the smaller of the sum of the initial HP values of all the first game media included in the deck and a predetermined upper limit HP is used for the battle game part. It is used as the initial value of the HP of the deck at the start of the game part. During execution of the battle game part, if the user is damaged by an opponent's attack, for example, the HP value is reduced by the amount of the damage. For example, when a recovery item is obtained during the execution of the battle game part, the HP value increases. When the HP value decreases by a predetermined value or more, it is determined that the user has lost. The predetermined value corresponds to the initial value of HP. In this case, when the HP value decreases to 0, it is determined that the user has lost. Therefore, the larger the initial value of the HP of each first game medium is, the more advantageous it is for the user. The initial value of HP may increase as the level increases.

Attack power is, for example, information that contributes to the amount of damage inflicted on the opponent by the attack of the game media. The higher the attack power value, the greater the amount of damage dealt to the opponent. Therefore, the greater the offensive power of the game media, the more advantageous it is for the user. Attack power may increase as the level increases.

Resilience is a parameter used during execution of the competitive game part. For example, when a deck is constructed to implement a battle game part, the sum of the resilience of all the first game media included in the deck is used. For example, if a recovery item is obtained during the execution of the battle game part, the user's resilience increases. The higher the healing power value, the larger the amount of increase in the HP value. Therefore, the greater the resilience of each first game content included in the deck is, the more advantageous it is for the user. As the level increases, resilience may increase.

The information on game functions includes information on game functions associated with game media. A game function may be a special function (skill or ability) associated with a game medium. Also, any number of game functions may be associated with one game medium. When the game function is exhibited, a predetermined game effect can occur, for example, in a battle game part. The content of the game effect may be determined arbitrarily. For example, there may be a game effect that gives the opponent greater damage than a normal attack, or a game effect that weakens the opponent's attack. The generated game effect may continue for a predetermined period of time.

The contents of the information regarding the game function are not limited to those described above. For example, information about a game function may further include the level and experience of the game function. For example, the experience value of a game function may be increased by consuming predetermined game media owned by the user. Also, the various types of information associated with the game content ID are not limited to those described above with reference to FIG. 7, and are arbitrary.
(Information about the game media that is the opponent)
The server storage unit 12 shown in FIG. 1 stores information (hereinafter also referred to as "boss character information") regarding game media (for example, NPCs) that are opponents in the battle game part.

Now, with reference to FIG. 8, an example of the boss character information described above will be described in detail. In this embodiment, the boss character information includes information about the big boss m1 and its small boss m2. FIG. 8 shows information about two big bosses m1. For example, the information about each big boss m1 includes a game medium ID (an example of a first identifier), a game medium name, an attribute, an initial value of HP, attack power, recovery power, and information on game functions. including. Since the game medium ID, game medium name, initial value of HP, attack power, etc. are the same as the above-described information related to the owned game medium, description thereof is omitted. However, since the big boss m1 is very strong, the initial value of HP, attack power, etc. are very large. This also applies to the small boss m2. The attribute is information indicating that the player is the big boss m1. The information about the small boss m2 includes a game medium ID (an example of a second identifier), a game medium name, attributes, an initial HP value, attack power, recovery power, and information about game functions. In this case, the attribute is information indicating that the small boss m2 is the small boss m2, and also information indicating which big boss m1 the small boss m2 is for (that is, the game medium ID of the big boss m1 and the game medium ID of the small boss m2). information to be associated). For example, in the example shown in FIG. 8, the minor boss m2 with the game medium ID "W01" is the minor boss m2 that functions as an alter ego of the major boss m1 with the game medium ID "V01". Note that the initial value of HP associated with the small boss m2 functioning as an alter ego of the one big boss m1 is significantly smaller than the initial value of HP associated with the one big boss m1. For example, the initial value of HP associated with the small boss m2 functioning as an alter ego of the one big boss m1 may be 1/1000 or less of the initial value of HP associated with the one big boss m1. and may be smaller. However, as will be described later, the initial value of HP associated with the small boss m2 may be set in a manner that changes as appropriate. On the other hand, at least one of the information regarding the attack power, recovery power, and game function of the small boss m2 may be the same as the information regarding the attack power, recovery power, and game function of the big boss m1.

In the boss character information, as shown in FIG. 8, drawing information may be associated with the game medium ID. The drawing information is information for drawing the game medium associated with the associated game medium ID, and if the drawing information is the same, the drawn game medium will basically have the same appearance (shape and shape). becomes. In this embodiment, it is assumed that the drawing information associated with one big boss m1 is the same as the drawing information associated with the small boss m2, which is the alter ego of the one big boss m1. Therefore, the big boss m1 and the small boss m2 look the same on the game image. However, the small boss m2 may be drawn in a smaller size than the large boss m1. In this case, it is possible to suggest to the user that the minor boss m2 is the "alternate" of the major boss m1. However, in the modified example, the drawing information associated with the one big boss m1 and the drawing information associated with the small boss m2, which is the alter ego of the one big boss m1, are associated with each other, so there is only a small amount of information. A difference may be set.

The server control unit 13 shown in FIG. 1 includes one or more processors. The processor may include a general-purpose processor that implements a specific function by reading a specific program, and a dedicated processor that specializes in specific processing. The server control unit 13 controls the operation of the server device 10 as a whole.

The server control unit 13 stores various information and programs used for game processing in the server storage unit 12 . Information used for game processing may include the above-described user information, boss character information, and the like.

The server control unit 13 transmits and receives information via the server communication unit 11 . For example, the server control section 13 may transmit at least part of the information stored in the server storage section 12 to the terminal device 20 . In this way, the information stored in the server storage unit 12 and the information stored in the terminal device 20 are shared and synchronized. The timing for sharing and synchronizing information may include, for example, the timing when new information is stored in the server storage unit 12 and the timing when the information stored in the server storage unit 12 is updated. good too.

The server control unit 13 cooperates with the terminal device 20 to execute the game. For example, the server control unit 13 cooperates with one or more terminal devices 20 to execute a competitive game part (for example, a raid game part).
(Configuration of terminal device)
The configuration of the terminal device 20 will be specifically described. As shown in FIG. 1 , the terminal device 20 includes a terminal communication section 21 , a terminal storage section 22 , a display section 23 , an input section 24 and a terminal control section 25 .

The terminal communication unit 21 includes an interface that communicates with an external device wirelessly or by wire to transmit and receive information. The terminal communication unit 21 may include a wireless communication module, a wireless LAN communication module, a wired LAN communication module, or the like compatible with mobile communication standards such as LTE (Long Term Evolution) (registered trademark). The terminal communication unit 21 can transmit and receive information to and from the server device 10 via the network 30 .

The terminal storage unit 22 includes, for example, a primary storage device and a secondary storage device. For example, the terminal storage unit 22 may include semiconductor memory, magnetic memory, optical memory, or the like. The terminal storage unit 22 stores various information and programs received from the server device 10 and used for game processing. Information and programs used for game processing may be obtained from an external device via the terminal communication unit 21 . For example, a game application program may be obtained from a predetermined application distribution server. Hereinafter, the application program will also simply be referred to as an application. Also, for example, part or all of the above-described user information and information related to the game content of the opponent may be acquired from the server device 10 .

The display unit 23 includes a display device such as a liquid crystal display or an organic EL (Electro-Luminescence) display. The display unit 23 can display various images (for example, various game images).

The input unit 24 includes an input interface including a touch panel provided integrally with the display unit 23, for example. The input unit 24 can accept user input to the terminal device 20 . Also, the input unit 24 may include physical keys, and may further include any input interface including a pointing device such as a mouse.

Terminal control unit 25 includes one or more processors. The terminal control unit 25 controls the operation of the terminal device 20 as a whole.

The terminal control section 25 transmits and receives information via the terminal communication section 21 . For example, the terminal control unit 25 receives various information and programs used for game processing from at least one of the server device 10 and other external servers. The terminal control section 25 stores the received information and program in the terminal storage section 22 .

The terminal control unit 25 activates the game application according to the user's operation. The terminal control unit 25 cooperates with the server device 10 to execute the game. For example, the terminal control unit 25 causes the display unit 23 to display various game images used in the game. For example, a GUI (Graphic User Interface) for detecting user operations may be superimposed on the game image. The terminal control unit 25 can detect, via the input unit 24, a user's operation on the screen displaying the game image.
(Configuration related to the raid game part)
Next, mainly referring to FIG. 9 and subsequent figures, the configuration related to the raid game part will be described. In the following, the server device 10 related to the raid game part implements an example of an information processing system, but as will be described later, each element of a specific terminal device 20 (see FIG. 1) is the information processing system. An example may be implemented, and a plurality of terminal devices 20 may cooperate to implement an example of an information processing system. Also, the server device 10 and one or more terminal devices 20 may cooperate to implement an example of an information processing system.

FIG. 9 is an explanatory diagram of functions related to the raid game part among the various functions realized by the server device 10. As shown in FIG. Some or all of the functions of the server device 10 described below may be realized by the terminal device 20 as appropriate. FIG. 10 is an explanatory diagram of game data in the game data storage unit 160. As shown in FIG. In addition, in the tables such as FIG. 10, "***" indicates a state in which some information is stored, and "..." indicates repetition of the same.

The server device 10 includes a game part setting unit 150, a participation management unit 151, a small boss battle setting unit 152 (an example of a second parameter setting unit), a big boss related processing unit 153, a small boss battle processing unit 154, a relief It includes a request processing unit 155 , a game state management unit 156 , a simultaneous play detection unit 157 (an example of a third determination unit), an image generation unit 158 , a reward provision unit 159 and a game data storage unit 160 .

Note that the game part setting unit 150 to the reward giving unit 159 can be realized by the server control unit 13 shown in FIG. In addition, the function part that performs communication with the terminal device 20 in the game part setting part 150 to the reward giving part 159 can be realized by the server communication part 11 together with the server control part 13 shown in FIG. Also, the game data storage unit 160 can be realized by the server storage unit 12 shown in FIG.

The game part setting unit 150 sets a raid game part (and accordingly, a big boss battle part and the like included in the raid game part). It should be noted that hereinafter, the process of "setting a game part" refers to the process of making the game part available for the user to participate in or play.

For example, the game part setting unit 150 may set a raid game part for a limited time. In this case, for example, an announcement may be made to the effect that an event related to the raid game part will be held from what day, what day, and what time. Alternatively, the game part setting unit 150 may set the raid game part at random timing or when a predetermined setting condition is satisfied.

A raid game part includes one or more big boss battle parts. When one raid game part includes a plurality of big boss battle parts, the plurality of big boss battle parts may progress simultaneously in parallel, or may progress one by one. Each of the big boss battle parts includes a small boss battle part in which the first game media m0 associated with one or more users fight against the small boss m2. A plurality of small boss battle parts can progress in parallel, as will be described later. In the raid game part, as will be described later, small boss battle parts are set one after another.

In this embodiment, as an example, a plurality of big boss battle parts are set in one raid game part. One big boss m1 is associated with each of the plurality of big boss battle parts. The big boss m1 associated with each of the plurality of big boss battle parts may be different from each other. In this case, the game part setting unit 150 may sequentially set a plurality of scheduled big boss battle parts, such as setting the next big boss battle part after one big boss battle part ends. . Each of the plurality of big boss battle parts may be randomly selected, and the number of big boss battle parts per raid game part may also be variable. Further, another game part may intervene between the plurality of big boss battle parts. Also, a specification may be such that a user participating in a raid game part can play an out game in the middle of the raid game part. For example, a user who is participating in a raid game part may use the idle time between the big boss battle parts to strengthen or nurture the first game medium m0. Alternatively, the user who is participating in the raid game part may temporarily stop (interrupt) the progress of the big boss battle part and strengthen or train the first game medium m0.

Once the raid game part has started progressing, it continues until the final big boss battle part ends. Hereinafter, the progress of the raid game part refers to the time from when the progress of the raid game part starts to when the HP values of all the big bosses m1 become zero.

The participation management unit 151 updates/manages the user's participation in the raid game part. User participation in a raid game part may be enabled at any time while the raid game part is in progress. The method of user participation in the raid game part is arbitrary. For example, when a participation button (not shown) that may be set in a game image on the terminal device 20 is operated, a participation request is transmitted to the server device 10 . Note that a display representing the big boss m1 may be drawn on the participation button using the drawing information (see FIG. 8) related to the big boss m1.

In this case, the participation management unit 151 realizes the corresponding user's participation state in the raid game part based on such a participation request. For example, the participation management unit 151 shifts the game image on the terminal device 20 associated with the user participating in the raid game part to a game image including a lobby image. Also, a user who has once participated in a raid game part may be allowed to leave at any time while the raid game part is in progress. The user's exit method from the raid game part is arbitrary. For example, when an exit button (not shown) that may be set in the game image on the terminal device 20 is operated, an exit request is transmitted to the server device 10 . In this case, the participation management unit 151 realizes the corresponding user's withdrawal based on such a withdrawal request.

The participation management section 151 updates the game data in the game data storage section 160 each time the participation status changes. FIG. 10 shows an example of participation status data 900 of the game data in the game data storage unit 160. As shown in FIG. Participation status data 900 includes a participation status for each user ID. For example, participation status may include "playing", "waiting", "leaving", and the like. "Waiting" corresponds to the state in which the lobby image is displayed, etc., while "Exited" corresponds to the state in which the user is logged in but not participating in the raid game part. good.

Also, the participation status data 900 may include the number of defeats of the small boss m2 for each user ID. The number of defeated small bosses m2 is the number of small bosses m2 defeated in the small boss battle part described later. Also, the participation status data 900 may include the number of defeats of the big boss m1 for each user ID. The number of subjugated large bosses m1 is the number of large bosses m1 defeated in the large boss battle part.

The minor boss battle setting unit 152 sets a minor boss battle part in response to a setting request from each user (terminal device 20). The small boss battle part is a game part in which the first game media m0 associated with one or more users fight against the small boss m2. The method of setting the minor boss battle part by the user is arbitrary. For example, when the user operates a play button (not shown) that may be set in the lobby image on the terminal device 20 , the terminal device 20 transmits a setting request to the server device 10 . In this case, the minor boss battle setting unit 152 sets a minor boss battle part associated with the corresponding user based on such a setting request. Note that a display representing the small boss m2 may be drawn on the play button using drawing information (see FIG. 8) related to the small boss m2. Also, sending a setting request (that is, playing a small boss battle part) may involve consumption of predetermined game media (for example, predetermined points held by the user in the game).

The small boss battle setting unit 152 can set small boss battle parts in various modes. For example, the minor boss battle setting unit 152 may always set the minor boss battle part in a fixed manner. In this case, the minor boss battle setting unit 152 may set a minor boss battle part for each user in such a manner that one user is associated with one minor boss battle part. Also, in this case, the minor boss battle setting unit 152 may immediately set one minor boss battle part associated with one user in response to a setting request from one user.

Alternatively, the small boss battle setting unit 152 may set a small boss battle part for each of the predetermined number N1 of users in such a manner that one small boss battle part is associated with the predetermined number N1 of users. In this case, the predetermined number N1 may be constant or variable. For example, the predetermined number N1 may be set to a larger number as the number of participating users increases. In this case, when the setting requests from the predetermined number N1 of users are accumulated, the small boss battle setting unit 152 responds to the setting requests from the predetermined number N1 of users, and sets the one associated with the predetermined number N1 of users. A small boss battle part may be set. Alternatively, the small boss battle setting unit 152 may associate the same one small boss battle part with each user in response to a setting request from each user until one small boss battle part is associated with a predetermined number N1 of users. good. In this case, after one small boss battle part is set, each user who newly sends a setting request until a predetermined number N1 of users are associated with the one small boss battle part It will be a form to participate in the part from the middle.

Further, when setting requests from N2 users, which are significantly larger than the predetermined number N1, of the small boss battle setting unit 152 accumulate, the small boss battle setting unit 152 responds to the setting requests from the N2 users. , you may set each small boss battle part. In this case, the method of dividing the number N2 of users into a plurality of groups (groups for each of the predetermined number N1 of users) may be random. Alternatively, the minor boss battle setting unit 152 may associate the same minor boss battle part with a plurality of users having a predetermined relationship. The predetermined relationship is arbitrary and may be determined based on user information or the like, or may be determined based on other information. For example, the minor boss battle setting unit 152 may associate the same minor boss battle part with users who are friends based on friend information included in the user information. Alternatively, from a similar point of view, the minor boss battle setting unit 152 may associate users belonging to the same guild or party with the same minor boss battle part based on information indicating the guild or party to which each user belongs. In such a case, it is possible to enhance the sense of solidarity and the degree of cooperation between the users in the group. Also in this case, a mode may be realized in which some of the plurality of users having a predetermined relationship participate in the minor boss battle part from the middle.

Further, the small boss battle setting unit 152 may dynamically change the predetermined number N1 according to the processing load of the big boss related processing unit 153. For example, the larger the predetermined number N1, the smaller the number of small boss battle parts per certain number of players, and therefore the processing load on the big boss-related processing unit 153 tends to be smaller. Therefore, the minor boss battle setting section 152 may increase the predetermined number N1 when the processing load of the major boss related processing section 153 is relatively high. Note that the processing load of the big boss-related processing unit 153 may be determined based on the operating state of the big boss-related processing unit 153 or the like.

For example, the minor boss battle setting unit 152 determines that the number of users whose participation status is “in battle” exceeds the threshold based on the participation status data (see participation status data 900 in FIG. 10) in the game data storage unit 160. In this case, the minor boss battle parts may be set in such a manner that one minor boss battle part is associated with each of two or more users. In this case, the threshold may be adapted according to the relationship between the processing load of the big boss-related processor 153 and the capability of the hardware configuration that implements the big boss-related processor 153 .

The big boss related processing unit 153 performs various processes related to the big boss battle part. For example, the big boss-related processing unit 153 updates the HP value of the big boss m1 based on the progress of the big boss battle part. In this embodiment, the big boss-related processing unit 153 updates the HP value of the big boss m1 each time the small boss battle part ends.

In this embodiment, once the progress of the big boss battle part is started, the HP value of the big boss m1 associated with the big boss battle part is changed from the initial value (an example of the first initial value) to the first When it decreases by a predetermined value α1 or more and becomes 0, the big boss m1 is defeated and the process ends. The first predetermined value α1 is arbitrary, but in this embodiment, the first predetermined value α1 related to one big boss m1 is the initial HP value of the big boss m1. However, in a modified example, the first predetermined value α1 may be a value corresponding to a predetermined percentage (for example, 90%) of the initial value of the HP of the big boss m1. In this case, once the progress of the big boss battle part is started, when the HP value of the big boss m1 associated with the big boss battle part decreases by a predetermined percentage or more from its initial value, the big boss m1 is defeated.

Further, in this embodiment, one raid game part includes a plurality of big boss battle parts in a manner in which the plurality of big boss battle parts are executed sequentially. Also, in the present embodiment, one big boss battle part may end when other end conditions are satisfied. For example, one big boss battle part may end without defeating the big boss m1 (that is, the big boss m1 wins) when the elapsed time after the start exceeds a predetermined time ΔT3.

In the example shown in FIG. 9 , the big boss-related processing section 153 includes a first setting section 1531 , a first updating section 1532 and a first determining section 1533 .

When one big boss battle part is set by the game part setting unit 150, the first setting unit 1531 sets the big boss m1 associated with the one big boss battle part. For example, the first setting unit 1531 associates one big boss m1 with each big boss battle part based on the boss character information shown in FIG. In this case, the first setting unit 1531 preferably sets the initial value of the HP of the associated big boss m1 to the previous value (immediately before One big boss m1 is associated with each big boss battle part so that the initial value of the HP of the big boss m1 related to the big boss battle part) or more. For example, the big boss m1 associated with each big boss battle part may be defined in advance (for example, may be defined by the management side). In this case, the first setting unit 1531 sets a predetermined big boss m1 for each big boss battle part.

As described above, in the present embodiment, each big boss m1 is associated in advance with an initial HP value (see FIG. 8). Therefore, when the first setting unit 1531 sets the big boss m1 associated with the one big boss battle part, the initial HP of the big boss m1 of the one big boss battle part is accordingly set in the one big boss battle part. values will be associated. Note that, in a modified example, the initial value of the HP of the big boss m1 may be appropriately corrected or the like when the big boss battle part is set.

The first updating unit 1532 updates the value (remaining value) of HP (an example of the first parameter) associated with the big boss m1 based on the progress of the big boss battle part in the raid game part.

In this embodiment, as described above with reference to FIGS. 3 and 5, the first updating unit 1532 updates the big boss m1 each time the small boss battle part ends (that is, each time the small boss m2 is defeated). Updates the HP value of . Thereby, as described above, the frequency of the HP subtraction process for the big boss m1 can be effectively reduced.

For example, when the small boss battle part ends when the small boss m2 is defeated, the first updating unit 1532 subtracts the initial HP value of the small boss m2 from the HP value of the big boss m1, Update the HP value of the big boss m1. However, in the modified example, the first updating unit 1532 subtracts a value obtained by multiplying the initial value of the HP of the small boss m2 by a predetermined coefficient K1 from the HP value of the big boss m1. value can be updated. The predetermined coefficient K1 is arbitrary and may be a variable value.

On the other hand, when the minor boss battle part ends without defeating the minor boss m2 (for example, when the user's first game medium m0 is defeated, or when the minor boss battle part is interrupted in the middle), the first updating unit 1532 may not update the HP value of the big boss m1. Alternatively, the first updating unit 1532 may update the HP value of the big boss m1 by subtracting the HP value of the big boss m1 by the decrease in the HP of the small boss m2 at that time.

The first determination unit 1533 determines whether or not the HP value updated by the first update unit 1532 has become zero. When the first determination unit 1533 determines that the HP value updated by the first update unit 1532 has become 0, it instructs the processing for ending the current big boss battle part. If the current big boss battle part is the final big boss battle part, the first determination unit 1533 instructs the process for ending the current raid game part.

By the way, in the present embodiment, as described above, the first updating unit 1532 updates the HP value associated with the big boss m1 each time the small boss battle part ends. corresponds to the end timing of one small boss battle part. Therefore, when the big boss battle part ends with the end of a certain small boss battle part, other small boss battle parts that may be in progress at that time are also forcibly ended. In this case, information indicating that the other small boss battle part has ended due to the defeat of the big boss m1 may be notified so that the user associated with the other small boss battle part can understand it. . For example, when the value of HP updated by the first updating unit 1532 becomes 0 and the small boss battle part is progressing on one or more terminal devices 20, the game image on the one or more terminal devices 20 , the retreat of the small boss m2 may be drawn, and then the defeat of the big boss m1 may be drawn. Alternatively, in the game image on each terminal device 20, a state in which the big boss m1 is defeated may be rendered by an interrupt. Further, when a small boss m2 required to set the HP value associated with the big boss m1 to 0 is set, at the end of the big boss battle part, the small boss battle associated with the big boss All parts may also be finished.

The small boss battle processing unit 154 performs various processes related to the small boss battle part. For example, the minor boss battle processing unit 154 updates the HP value of the minor boss m2 based on the progress of the major boss battle part (and the progress of one or more minor boss battle parts accompanying this). At this time, the minor boss battle processing unit 154 functions for each minor boss battle part.

In this embodiment, in the small boss battle part, when the HP value of the corresponding small boss m2 decreases from its initial value (an example of the second initial value) by a second predetermined value α2 or more and becomes 0, the small boss m2 It ends when you are defeated. The second predetermined value α2 is arbitrary, but in this embodiment, the second predetermined value α2 related to one small boss m2 (or one small boss battle part) is the initial HP value of the small boss m2. . In this case, the minor boss battle part ends when the HP value of the minor boss m2 becomes zero. However, in a modified example, the second predetermined value α2 may be a value corresponding to a predetermined percentage (for example, 90%) of the initial HP value of the small boss m2. In this case, once the progress of the first child boss battle part is started, when the HP value of the small boss m2 associated with the small boss battle part decreases by a predetermined percentage or more from its initial value, the small boss It ends when m2 is defeated.

Also, in this embodiment, the minor boss battle part may end when other end conditions are satisfied. For example, when the HP value of the user's first game medium m0 becomes 0, the small boss battle part may end without defeating the small boss m2 (that is, the small boss m2 wins). However, in this case, the specifications may be such that the same user can play (re-challenge) the same small boss battle part again from the beginning or from the middle.

In the example shown in FIG. 9 , the minor boss battle processing section 154 includes a second setting section 1541 , a second updating section 1542 and a second determining section 1543 .

When one small boss battle part is set by the small boss battle setting unit 152, the second setting unit 1541 associates the small boss m2 with the one small boss battle part. As a result, one or more users associated with one minor boss battle part are associated with the minor boss m2 associated with the one minor boss battle part. In other words, associating one user with small boss m2 (or the initial value of its HP) is substantially synonymous with associating the one user with a small boss battle part.

In this embodiment, the second setting unit 1541, based on the boss character information shown in FIG. is associated with the small boss m2. This makes it easier for the user to understand the relationship between the big boss m1 and the small boss m2 (that is, the relationship that the small boss m2 is the alter ego of the big boss m1).

As described above, in the present embodiment, each small boss m2 is associated in advance with an initial HP value (see FIG. 8). Therefore, when the second setting unit 1541 sets the minor boss m2 associated with one minor boss battle part, the initial HP value of the minor boss m2 is associated with the one minor boss battle part. .

Here, in a modified example, the second setting unit 1541 may appropriately change the initial HP value of the small boss m2 associated with one small boss battle part. For example, the second setting unit 1541 may set an initial value that is appropriately increased or decreased with respect to the initial value of HP defined by boss character information as shown in FIG. In this case, since the drawing information associated with the small boss m2 is not changed, the appearance is not affected, and only the initial value of HP is changed. In place of or in addition to the initial value of HP, attack power and recovery power defined by boss character information as shown in FIG. 8 may also be changed.

Specifically, the second setting unit 1541 determines the initial HP of the small boss m2 associated with the one small boss battle part based on user information related to one or more users associated with the one small boss battle part. You can set the value. In this case, the second setting unit 1541 sets the initial value of the HP of the small boss m2 to be higher as the level of the first game medium or the initial value of the HP of the user associated with the one small boss battle part is higher. , the initial value of the HP of the small boss m2 may be set. In this case, the initial values of the HP of a plurality of small bosses m2 may be set in advance according to the level range of the user based on the user information, and the initial values may be set according to the level. As a result, the small boss m2 having an initial HP value corresponding to each user's level can be associated with the small boss battle part associated with each user.

In addition, when a plurality of users are associated with one small boss battle part, the second setting unit 1541 sets the initial value of the small boss to a larger initial value than when one user is associated with one small boss battle part. m2 may be associated with the one minor boss battle part. When a plurality of users are associated with one minor boss battle part, the second setting unit 1541 determines the HP of the minor boss m2 associated with the one minor boss battle part based on the user information of each user. An initial value may be set. In this case, the second setting unit 1541 determines that the higher the average value or total value of the level of the first game medium of each user associated with one small boss battle part, the initial HP value, etc., the higher the HP of the small boss m2. The initial value of the HP of the small boss m2 may be set in such a manner that the initial value is high. As a result, the small boss m2 having initial HP values corresponding to the levels of multiple users can be associated with each small boss battle part associated with multiple users.

Further, the second setting unit 1541 may set the initial value of the HP of the small boss m2 associated with one small boss battle part based on the initial value of the HP of the large boss m1 associated with the small boss m2. For example, the initial value of HP associated with the small boss m2 functioning as an alter ego of one big boss m1 may be 1/M of the initial value of HP associated with the one big boss m1. Here, M is a large number such as 1000 or more. In this case, the initial value of the HP of one small boss m2 increases as the initial value of HP of the large boss m1 related to the one small boss m2 increases. As a result, it is possible to set the strength of the small boss m2 according to the strength of the large boss m1, so that the relationship between the large boss m1 and the small boss m2 is consistent with the strength of the large boss m1. can be done.

In addition, the second setting unit 1541 sets the initial value of the HP of the small boss m2 associated with one small boss battle part to the value of the HP of the large boss m1 related to the small boss m2 (the value updated by the first updating unit 1532). ) may be set based on For example, when the small boss battle setting unit 152 sets one small boss battle part, the second setting unit 1541 acquires the HP value (current value) of the big boss m1 from the first updating unit 1532 . Then, the second setting unit 1541 determines the initial HP value of the small boss m2 associated with the one small boss battle part based on the HP value of the big boss m1. At this time, for example, the second setting unit 1541 may determine the initial HP value of the small boss m2 in such a manner that the larger the HP value of the big boss m1, the larger the initial HP value of the small boss m2. . As a result, the initial HP value of the small boss m2 can be set according to the HP value of the big boss m1 at that time, so the initial HP value of the small boss m2 can be set according to the game situation.

Also, the second setting unit 1541 may change the initial value of the HP of the small boss m2 according to the processing load of the big boss related processing unit 153 . For example, the larger the initial value of the HP of the small boss m2, the less frequently the small boss battle part ends, and therefore the processing load on the big boss-related processing unit 153 tends to decrease. Therefore, the second setting unit 1541 may increase the initial value of the HP of the small boss m2 when the processing load of the big boss related processing unit 153 is relatively high. Note that the processing load of the big boss-related processing unit 153 may be determined based on the operating state of the big boss-related processing unit 153 or the like. For example, the processing load of the big boss-related processing unit 153 may be determined based on the update frequency by the first updating unit 1532 . This is because there is a tendency that the higher the update frequency by the first update unit 1532, the higher the processing load on the big boss-related processing unit 153.

Here, in the first big boss battle part, the initial value of the HP of the big boss m1 is set to the first predetermined value α1, the initial value of the HP of the small boss m2 is set to the second predetermined value α2, and the small boss battle setting unit 152 sets the small boss battle When N3 parts are set, the sum of the initial HP values of the small boss m2=α2×N3. At this time, if the predetermined upper limit is γ, then α1≦α2×N3≦γ if it is possible to defeat the big boss m1. Further, with respect to the number of small boss battle parts per one large boss battle part, a predetermined upper limit number is set to M1, a second predetermined value α2 is a fixed value, and M2 is a minimum integer M that satisfies α1≦M×α2. Then, M2≤N3≤M1. In this case, when the small boss m2 is defeated in all of the M2 small boss battle parts, the big boss m1 related to the one big boss battle part is defeated. At this time, the N3-M small boss battle parts are spare game parts. In this case, when the second predetermined value α2 is set to a fixed value, the minor boss battle setting unit 152 sets a number larger than the value obtained by dividing the first predetermined value α1 by the second predetermined value α2, The number of small boss battle parts that does not exceed the upper limit number M1 is set. In addition, the small boss battle setting unit 152 sets small boss battle parts so that each user is not associated with a number of small boss battle parts exceeding a predetermined upper limit number M3 during the progress of one big boss battle part. may be set. In this case, the predetermined upper limit number M3 may be the same as the predetermined upper limit number M1 described above, or may be smaller than the predetermined upper limit number M1.

The second updating unit 1542 updates the value (remaining value) of HP (an example of the second parameter) associated with each minor boss m2 based on the progress of each minor boss battle part. In one small boss battle part, when the small boss m2 is attacked by the user's first game medium m0, the second updating unit 1542 updates the HP value of the small boss m2 by the HP value corresponding to the attack. to update the HP value of the small boss m2. In this manner, the second updating unit 1542 updates the HP value of the small boss m2 each time the user is attacked by the first game medium m0.

Further, the second updating unit 1542 may update the HP value of the small boss m2 by appropriately increasing the HP value of the small boss m2 when the recovery condition is satisfied.

The second determination unit 1543 determines whether or not the HP value updated by the second update unit 1542 has become zero. When the second determination unit 1543 determines that the HP value updated by the second update unit 1542 has become 0, it instructs a process for ending the corresponding minor boss battle part. In this case, in the game image on the terminal device 20 in which the corresponding minor boss battle part is being executed, a scene in which the minor boss m2 is defeated may be drawn.

Here, the operation of the minor boss battle processing section 154 accompanying the progress of one minor boss battle part will be described. When the minor boss battle part is started, the minor boss battle processing section 154 sets the action points of the minor boss m2 to an initial value (for example, zero points).

During the execution of the small boss battle part, for example, the first period and the second period occur alternately and repeatedly.

The first period is, for example, a period during which the action points of the small boss m2, which increases over time, increase from an initial value (eg, zero points) to an upper limit value (eg, 100 points). Specifically, the minor boss battle processing unit 154 starts processing (increase processing) to increase the action points of the minor boss m2 over time. The start timing of the increase processing corresponds to the start timing of the first period. The minor boss battle processing unit 154 ends the increase processing when the action points of the minor boss m2 reach the upper limit (for example, 100 points). The end timing of the increase processing corresponds to the end timing of the first period.

The second period is the period from the end timing of the first period to the timing when the action points of the small boss m2 are reset to the initial value. Specifically, after the second period starts, the minor boss battle processing unit 154 causes the minor boss m2 to perform a predetermined action (for example, attack the user). Note that if the first game medium does not perform an action (for example, attacking the small boss m2), the small boss battle processing unit 154 may cause the small boss m2 to perform a predetermined action immediately after the start of the second period, for example. good. On the other hand, when causing the first game medium to perform an action, the small boss battle processing section 154 may cause the small boss m2 to perform a predetermined action after waiting for the action by the first game medium to end. In such a case, the action by the small boss m2 is executed after the action by the first game content ends. In this manner, the first period and the second period alternately occur repeatedly.

Note that, during the first period, the minor boss battle processing unit 154 may cause a predetermined item to appear in the virtual space. The minor boss battle processing unit 154 increases the action points of the first game medium according to the acquisition of the item by the second game medium. When the action points of the first game medium are equal to or greater than a predetermined reference value, the small boss battle processing unit 154 causes the first game medium to perform a predetermined action (for example, attacking the small boss m2), and reduces the action points to the Decrease by the reference value. The minor boss battle processing unit 154 causes the first game medium to repeatedly perform actions until the action points of the first game medium become less than the reference value. When the action points of the first game content decrease and become less than the reference value, the action of the first game content ends.

It should be noted that the manner in which the small boss battle part progresses, the manner in which it ends, and the like can be varied and arbitrary. For example, a plurality of small bosses m2 may appear. In this case, the initial HP values of a plurality of small bosses m2 may be assigned to one small boss battle part. Also, a minion character may appear before the small boss m2. In this case, the initial value of the HP of the minion character may additionally be assigned to one minor boss battle part. Also, in the small boss battle part, a deck composed of a plurality of first game media may battle the small boss m2. Further, when there is a request for help, which will be described later, in the minor boss battle part, the first game media m0 (or their decks) associated with a plurality of users may battle the minor boss m2. Also, the minor boss battle part may end when a predetermined end condition is satisfied even when the HP value updated by the second update unit 1542 does not become 0. For example, the small boss battle part may end when the number of attacks (the number of turns) by the user with the first game medium m0 reaches a predetermined number. Also, the minor boss battle part may be realized by a real-time battle or the like other than the active time battle.

When a rescue request is received from one user (terminal device 20), the rescue request processing unit 155 performs a rescue process for associating the rescue user with the minor boss battle part associated with the one user. Run. The relief request processing unit 155 may select a user for relief in any manner. For example, the help request processing unit 155 may select a help user from a group of users whose participation status is "waiting". Alternatively, the help request processing unit 155 may select a user for help from a group of users whose participation status is “waiting” and who are in a friend relationship. Instead of or in addition to the group of users whose participation status is "waiting", a group of users whose participation status is "playing" or "leaving" may be included. Moreover, the relief request processing unit 155 may select only one user for relief, or may select a plurality of users at the same time.

When a rescue user is selected, the rescue request processing unit 155 transmits a rescue request to the selected rescue user. An accept button may be displayed on the game image of the terminal device 20 of the user who has received the help request. In this case, the user who has received the help request can transmit the acceptance of help to the server device 10 via the terminal device 20 by pressing an acceptance button or the like. Note that the accept button may have a small boss m2 of the corresponding small boss battle part drawn thereon.

When the relief request processing unit 155 receives a relief acceptance from one or more users (terminal devices 20) who have transmitted the relief request, the relief request processing unit 155 assigns the user who has accepted the relief request a small message associated with the user who issued the relief request. Associate the boss battle part.

The game state management unit 156 updates/manages the game state according to the progress of the raid game part. The game state management section 156 updates the game data in the game data storage section 160 each time the game state changes.

FIG. 10 shows an example of game state data 902 of the game data in the game data storage unit 160. As shown in FIG. As shown in FIG. 10, the game state data 902 associates the game medium ID of the small boss m2, the game status, the associated user ID, the participation attribute, the result, the subtracted HP, the presence or absence of simultaneous play, etc. for each battle ID. may be generated by

A battle ID is an identifier that identifies each minor boss battle part. A battle ID is set each time a small boss battle is set by the small boss battle setting unit 152 . The battle ID may be stored in the server storage unit 12 in advance, or may be determined by the server device 10 when the small boss battle is set by the small boss battle setting unit 152 .

The game medium ID of the small boss m2 is the game medium ID of the small boss m2 associated with the corresponding small boss battle part. Game status may include "in progress", "finished", and the like. The associated user ID is the user ID of the user associated with the corresponding minor boss battle part. The participation attribute is a small boss battle part (written as "host") set by the corresponding user's setting request (new setting request to be described later), or is associated in response to a rescue request from another user. It indicates whether it is a small boss battle part (written as “rescue”) or voluntary participation (support) in a small boss battle part hosted by another user. The result is the result of the corresponding minor boss battle part. The subtracted HP represents how much the HP of the small boss m2 was reduced in the corresponding small boss battle part. In the case of a minor boss battle part associated with only one user, if the result is "user victory", the subtracted HP corresponds to the initial value of the HP of the minor boss m2 associated with the minor boss battle part. do.

The simultaneous play detection unit 157 determines whether or not there is a user associated with two or more minor boss battle parts. For example, the game state management unit 156 can determine, based on the game data in the game data storage unit 160, whether or not there is a user associated with two or more minor boss battle parts. Hereinafter, a user associated with two or more minor boss battle parts is also referred to as a "simultaneous player". As described above, the simultaneous play user can be a user who has accepted the help request in response to the help request. Note that the simultaneous play detection unit 157 may be omitted in the case of a game specification that does not generate simultaneous play users.

The image generator 158 generates display image information for displaying various game images on the terminal device 20 associated with each user.

FIG. 11 is a diagram showing an example of a game image relating to a minor boss battle part. 11 (and later-described FIG. 12), the small boss m2 refers to the small boss m2 associated with the small boss battle part related to the game image shown in FIG. , indicates the large boss m1 related to the small boss m2.

In FIG. 11, the game image G1100 related to the small boss battle part includes an HP display (gauge) 45 related to the user's first game medium m0 and an HP display 48 related to the small boss m2. The HP display 48 related to the small boss m2 is updated each time the HP value of the small boss m2 is updated by the second updating unit 1542 described above. In FIG. 11, the HP display 45 is associated with the image portion G11004 representing the user's first game medium m0, and the HP display 48 is associated with the image portion G11003 representing the small boss m2.

In FIG. 11, the game image G1100 related to the small boss battle part includes an image portion G11001 drawn based on the drawing information associated with the big boss m1, and a drawing associated with the user's first game medium m0. and an image portion G11002 drawn based on the information for use. As described above, in this embodiment, the drawing information for drawing the big boss m1 is the same as the drawing information for drawing the minor boss m2, which is its alter ego. In other words, the big boss m1 and its alter ego, the small boss m2, cannot be distinguished from each other in the game image. This allows the user to have an image of fighting the big boss m1 even though the user is fighting the small boss m2.

FIG. 12 is a diagram showing an example of a game image showing the update of the HP value of the big boss m1 following the end of the small boss battle part.

In FIG. 12, the game image G1200 showing the update of the HP value of the big boss m1 includes the HP display 49 related to the big boss m1. The HP display 49 is updated each time the HP value of the big boss m1 is updated by the first updating unit 1532 described above. In FIG. 12, the HP display 49 is associated with an image portion G12001 representing the big boss m1. In this case, the image portion G12001 may be rendered larger than the image portion G11003 shown in FIG. The HP display 49 may include a numerical display 491 . As a result, even if the HP value of the big boss m1 is only slightly reduced in one update, it is possible for the user to understand that the HP value has been slightly reduced. The order of the numerical value display 491 (the order up to the decimal point) may be appropriately set according to the minimum change unit of the HP value of the big boss m1.

In this manner, in the present embodiment, the image generator 158 generates an image related to the big boss m1 (see the image part G12001 in FIG. 12) each time the first update unit 1532 updates the HP value of the big boss m1. ) and an image representing the updated HP value of the big boss m1 (see HP display 49 in FIG. 12). In this case, each terminal device 20 can output a display image (see game image G1200 in FIG. 12) showing that the HP value of the big boss m1 has been reduced, based on the display image information.

In addition, every time the second update unit 1542 updates the HP value of the small boss m2, the image generation unit 158 generates an image related to the big boss m1 (see the image portion G11001 in FIG. 11) and the updated small boss m2. Display image information (an example of second display image information) for displaying an image representing the HP value of m2 (HP display 48 in FIG. 11) is generated. In this case, each terminal device 20 can output a display image (see game image G1100 in FIG. 11) showing that the HP value of small boss m2 has been reduced, based on the display image information.

In this way, in the present embodiment, the image generator 158 generates a display for displaying the game image G1100 as shown in FIG. Generate image information for When the HP value of the small boss m2 updated by the second update unit 1542 reaches 0 (that is, when the small boss m2 is defeated), the display image information is changed so that the defeat scene of the small boss m2 is drawn. to generate In this case, the corresponding terminal device 20 can output a display image (not shown) representing that the small boss m2 has been defeated based on the display image information.

Here, if the defeat scene of the small boss m2 and the defeat scene of the big boss m1 are drawn in the same manner, the user may be confused. Therefore, the defeat scene of the small boss m2 is drawn based on the drawing information for drawing the big boss m1 so that it is easy to understand that the small boss m2, which is the "alter ego" of the big boss m1, has been defeated. Game media may be rendered at a relatively small size. In other words, the "small boss m2" may be drawn by drawing the game medium in a relatively small size based on the drawing information for drawing the big boss m1. In this way, in a predetermined case, the image generation unit 158 displays the game content related to the big boss m1 in association with the HP value of the big boss m1, and the game content associated with the HP value of the small boss m2. The display image information may be generated so that the opponent is drawn in a different manner when displaying the game media related to the small boss m2. It should be noted that different aspects may differ in drawing details instead of or in addition to size.

Further, in the present embodiment, the image generation unit 158 generates the display image information for displaying the game image G1200 as shown in FIG. 12 each time the first update unit 1532 updates the HP value of the big boss m1. to generate When the HP value of the big boss m1 updated by the first update unit 1532 reaches 0 (that is, when the big boss m1 is defeated), the display image information is changed so that the defeat scene of the big boss m1 is drawn. to generate In this case, each terminal device 20 can output a display image (not shown) representing that the big boss m1 has been defeated based on the display image information.

Here, as described above, if the defeat scene of the small boss m2 and the defeat sheet of the big boss m1 are drawn in the same manner, the user may be confused. Therefore, in the defeat scene of the big boss m1, drawing information for drawing the big boss m1 is provided so that it is easy to understand the difference in the defeat sheet when the small boss m2, which is the "alternate" of the big boss m1, is defeated. The game media rendered based on may be rendered in a relatively large size. In other words, the "big boss m1" may be drawn by drawing the game medium in a relatively large size based on the drawing information for drawing the big boss m1.

In addition, the image generation unit 158 is in the simultaneous play detection unit 157, and when it is determined that there is a user associated with two or more small boss battle parts, the user has two or more small boss battle parts. Display image information for displaying on the terminal device 20 a game image including a selection image from which only one of them can be selected may be generated. In this case, the user can make a desired selection such as, for example, preferentially playing the minor boss battle part of the person who received the rescue request. Alternatively, the user may be able to advance two or more minor boss battle parts in parallel by using an automatic mode or the like. In these cases, the second updating unit 1542 updates two or more small bosses m2 based on user input (for example, manual or automatic operation input) associated with two or more small boss battle parts. It will update the value of each or part of HP.

As described above, part or all of the functions of the server device 10 shown in FIG. 9 and described above may be realized by the terminal device 20 as appropriate. For example, at least a part of the game image displayed on the terminal device 20 (the game image shown in FIGS. 11 and 12) is displayed on the terminal device 20 based on the data generated by the server device 10 as a web display, At least part of the game image may be displayed as native display by a native application installed in the terminal device 20 .

The reward giving unit 159 gives a reward to each user who participates in the raid game part. Any method of awarding rewards may be used. For example, the reward granting unit 159 may grant a specific reward to one or more users who defeated the minor boss m2 for each minor boss battle part, and/or may award a particular reward to one or more users who defeated the minor boss m2 for each major boss battle part. A specific reward may be given to each user who contributes to defeating the . In addition, the reward granting unit 159 gives special rewards to one or more users who played the small boss battle part when the big boss m1 was defeated (that is, one or more users who gave the final blow to the big boss m1). Rewards may be given. Further, the reward granting unit 159 may generate ranking information based on the participation status data 900 (see FIG. 10) or the like after the raid game part ends. In this case, the ranking information may be generated in such a manner that the user IDs are ranked in descending order of the number of defeated small bosses m2 (defeated number).

By the way, in the present embodiment, as described above, the first update unit 1532 updates the HP value of the small boss m2 updated by the second update unit 1542 with a lower update frequency than the second update unit 1542. Update the HP value of the big boss m1. This reduces the processing load of the first updating unit 1532 even when the number of users whose participation status is “playing” is enormous. On the other hand, if the number of users whose participation status is “playing” becomes enormous, the processing load of the second updating unit 1542 as a whole increases.

In this regard, in the present embodiment, the second updating unit 1542 can operate independently for each minor boss battle part, so it can be easily implemented in a distributed manner using a plurality of server computers and/or a plurality of CPUs. In this case, the processing load can be appropriately distributed without limiting the processing unit for realizing the second updating unit 1542 to limited hardware resources. Alternatively, the second updating unit 1542 may be implemented by the terminal device 20 since it can operate independently for each minor boss battle part. Also in this case, the processing load can be appropriately distributed without limiting the processing unit for realizing the second updating unit 1542 to limited hardware resources. In this way, the second updating unit 1542 can be realized by more computers than the first updating unit 1532, so the processing load can be distributed appropriately.

Next, an operation example of a configuration related to the raid game part in the server device 10 will be described with reference to FIG. 13 and subsequent figures.

FIG. 13 is a schematic flow chart showing an example of processing related to a small boss battle part setting request from each user.

In step S1102, the server device 10 determines whether or not a request to generate a lobby image for the minor boss battle part has been received from any terminal device 20 (that is, any user). If the determination result is "YES", the process advances to step S1306; otherwise, the process for this cycle ends.

In step S1104, the server device 10 performs selection image generation processing (hereinafter also referred to as "selection image generation processing") for the user to select a small boss battle part to play from among several small boss battle parts. conduct. That is, the server device 10 generates a user interface (selection image) (not shown) that allows the user to select one minor boss battle part from one or more minor boss battle parts. The user interface is displayed on the terminal device 20 associated with the requesting user (hereinafter simply referred to as "requesting user") related to the lobby image generation request received this time, and one or more selectable small boss battles. It may include select buttons representing the parts. The selection buttons may include information (for example, information about the user currently playing) and the like regarding the corresponding minor boss battle part. When the user operates a desired selection button, a setting request for the corresponding small boss battle part is sent to the server device 10 . Below, as an example, the setting request includes a setting request requesting setting of a new small boss battle part hosted by the requesting user (himself) (hereinafter also referred to as a “new setting request”), and a setting request that already has other A setting request for requesting participation in a small boss battle part that has already been set with the user as the host (hereinafter also referred to as a "participatory setting request"). Note that, in a modified example, the new setting request may include a setting request requesting setting of a minor boss battle part for a group together with other users (users having a predetermined relationship).

In step S1106, the server device 10 determines whether or not the user has operated the selection button (that is, the user has selected a small boss battle part). If the determination result is "YES", the process advances to step S1108; otherwise, the process waits for the operation of the selection button by the user. The operation waiting state ends as appropriate, for example, when a certain amount of time has passed, or when one of the one or more selectable small boss battle parts ends. Also, in the operation waiting state, step S1104 may be periodically executed.

In step S1108, the server apparatus 10 sets the setting request (new setting request or participation-type setting request) received by the user's operation of the selection button this time in the waiting queue. In this way, the setting request (new setting request or participation type setting request) set in the waiting queue is processed in the subtraction instruction generation process (FIG. 15) in the small boss battle part (step S1304). and step S1327A).

FIG. 14A is a schematic flow chart showing an example of the selection image generation process (step S1104) in FIG.

In step S1200, server device 10 extracts a battle ID whose game status is "in progress" based on the game data in game data storage unit 160 (see game state data 902 in FIG. 10).

In step S1202, the server device 10 extracts a user ID having a predetermined relationship with the requesting user. For example, the server device 10 extracts the user ID of the user who is friends with the requesting user based on the friend information included in the user information.

In step S1204, the server device 10 adds the user ID extracted in step S1202 to the user IDs associated with the battle IDs extracted in step S1200 (see the associated user IDs of the game state data 902 in FIG. 10). Determine whether ID is included. That is, the server device 10 selects, among the minor boss battle parts associated with each battle ID extracted in step S1200, a minor boss battle part played by a user having a predetermined relationship with the requesting user (for example, a user having a friend relationship). exists. If the determination result is "YES", the process proceeds to step S1206; otherwise, the process proceeds to step S1208.

In step S1206, the server device 10 selects one or more small boss battle parts played by a user who is in a friend relationship with the requesting user and a new small boss battle part as a play target. A selection image that can be selected by the requesting user as a small boss battle part is generated. In this case, the server device 10 may appropriately set the arrangement of selection buttons related to one or more small boss battle parts in the selection image based on the game state. For example, the server device 10 selects, among one or more minor boss battle parts played by a user who is friends with the user who made the request, the HP value of the minor boss m2 in descending order (or in descending order). One or more arranged in such a way that they are likely to be preferentially selected in ascending order (or in ascending order) of the HP value of one game medium m0, or in ascending order (or in ascending order) of the duration of the small boss battle part. You may set the placement of the selection button related to the small boss battle part. Note that in the modified example, instead of or in addition to one or more minor boss battle parts played by a user who has a predetermined relationship with the requesting user, a minor boss battle part that satisfies other conditions is extracted (as a selection image). placement).

In step S1208, the server device 10 generates a selection image that allows the requesting user to select the new minor boss battle part as the minor boss battle part to be played.

In step S1220, the server device 10 displays the selection image generated in step S1206 or step S1208 on the terminal device 20 of the requesting user.

In this way, according to the process shown in FIG. 14A, the requesting user selects a minor boss battle part that is being played by a user having a predetermined relationship, or a minor boss battle part that the user becomes the host and newly sets. can be played with Also, when setting requests are sent to the server device 10 one after another, each user is adaptively distributed. load can be evened out.

FIG. 14B is a schematic flow chart showing another example of the selection image generation process (step S1104) in FIG.

The process shown in FIG. 14B differs from the process shown in FIG. 14A in that step S1210 is executed when the determination result in step S1204 is "YES". Differences will be mainly described below.

In step S1210, the server device 10 determines whether or not the number of one or more minor boss battle parts being played by users who are friends with the requesting user exceeds a certain number. The fixed number is arbitrary, but may correspond to the upper limit of the appropriate number of selection candidates to be presented to the user. If the determination result is "YES", the process proceeds to step S1212; otherwise, the process proceeds to step S1216. In a modified example, a minor boss battle part that satisfies other conditions may be extracted instead of or in addition to one or more minor boss battle parts played by a user who has a predetermined relationship with the requesting user. In this case, the server device 10 may determine whether or not the number of all extracted minor boss battle parts including these exceeds a certain number.

In step S1212, the server device 10 extracts only a certain number of minor boss battle parts from one or more minor boss battle parts played by users who are friends with the requesting user.

The extraction method in this case is arbitrary, but the game state may be considered. For example, the server device 10 selects, among one or more minor boss battle parts played by a user who is friends with the user who made the request, the HP value of the minor boss m2 in descending order (or in descending order). In descending order (or in descending order) of the HP value of one game medium m0, in descending order (or in descending order) of the duration of the small boss battle part, in descending order (or in ascending order) of the number of participants of other users, or A certain number of small boss battle parts are extracted in descending order (or in descending order) of other users' level bands (for example, user level bands based on user information), or according to the order of a combination of two or more of these. may

In step S1214, the server device 10 generates a selection image that allows the requesting user to select one of the fixed number of minor boss battle parts extracted in step S1212 and the new minor boss battle part.

In step S1216, the server device 10 selects one or more minor boss battle parts (all of which are equal to or less than a certain number) being played by users who are friends with the requesting user and new minor boss battle parts. or one is generated as a small boss battle part to be played by the requesting user.

In this way, according to the process shown in FIG. 14B, when the number of minor boss battle parts being played by a user having a predetermined relationship is relatively large, only the extracted fixed number of minor boss battle parts are selected as selection targets. It can be presented to the requesting user as a small boss battle part.

Further, according to the process shown in FIG. 14B, a certain number of minor boss battle parts to be presented to the requesting user are extracted according to the game state, so it is possible to average out the unprocessable parts. For example, by appropriately distributing the number of participants in the small bosses to make it easier for specific small bosses to be defeated quickly, by staggering the timing at which each small boss is likely to be defeated, It is possible to prevent a temporary increase in processing load by staggering the update timing of the HP value.

FIG. 15 is a schematic flow chart showing an example of subtraction instruction generation processing in the small boss battle part. The process shown in FIG. 15 may be repeatedly executed at predetermined intervals during the progress of the raid game part.

In step S1302, the server device 10 determines whether or not the first flag F1 indicating the setting state of the new minor boss battle part is "0". When the first flag F1 is "0", it corresponds to the setting waiting state of a new small boss battle part, and when the first flag F1 is "1", it corresponds to the setting completed state of a new small boss battle part. do. The first flag F1 is set for each minor boss battle part (that is, for each battle ID). If the determination result is "YES", the process proceeds to step S1304; otherwise, the process proceeds to step S1312.

In step S1304, the server device 10 determines whether or not a new setting request for the minor boss battle part has been received from any terminal device 20 (that is, any user). For example, the server device 10 determines whether or not there is a new setting request in the waiting queue (see step S1108 in FIG. 13). If the determination result is "YES", the process advances to step S1306; otherwise, the process for this cycle ends.

In step S1306, in response to the setting request obtained in step S1304, the server device 10 creates a new small boss battle part associated with the user, with the current user (the user who made the new setting request this time) as a host. set. In this case, the user's current participation status is changed (updated) to "in competition".

In step S1308, the server device 10 sets the first flag F1 to "1".

In step S1310, the server device 10 associates the small boss m2 with the small boss battle part, and starts the small boss battle part.

In step S1312, the server device 10 determines whether or not the condition for updating the HP value of the small boss m2 is satisfied. The condition for updating the HP value of the small boss m2 is met, for example, when the small boss m2 is attacked by the user's first game medium m0. If the determination result is "YES", the process proceeds to step S1314; otherwise, the process proceeds to step S1316.

In step S1314, the server device 10 updates the HP value of the small boss m2.

In step S1316, the server device 10 determines whether or not the condition for updating the HP value of the user's first game medium m0 is satisfied. The condition for updating the HP value of the user's first game medium m0 is met, for example, when the user's first game medium m0 is attacked by the small boss m2. If the determination result is "YES", the process proceeds to step S1318; otherwise, the process proceeds to step S1320.

In step S1318, the server device 10 updates the HP value of the user's first game medium m0.

In step S1320, the server device 10 determines whether or not a request for help has been received from the current user. If the determination result is "YES", the process proceeds to step S1322; otherwise, the process proceeds to step S1323.

In step S1322, the server device 10 transmits a help request to other users and sets a help waiting timer. The help-waiting timer is a timer that times out at a predetermined time ΔT1.

In step S1323, the server device 10 determines whether or not the help-waiting timer is counting. It should be noted that the rescue waiting timer times out and ends the time measurement when a predetermined time ΔT1 has elapsed from the start of time measurement. If the determination result is "YES", the process proceeds to step S1324, otherwise (when the waiting for help timer has timed out, or when the timer for waiting for help has not started), the process proceeds to step S1327A.

In step S1324, the server device 10 determines whether or not a relief acceptance for the relief request has been received. If the determination result is "YES", the process advances to step S1326. On the other hand, if the determination result is "NO", the processing for this cycle is terminated as is, as in step S1322. In this case, for a predetermined period of time ΔT1, the system waits for reception of acceptance of the rescue request.

In step S1326, the server device 10 associates the new user who accepted the help with the current minor boss battle part. That is, the new user who has accepted the help is added to the user group associated with the current minor boss battle part. At this time, the game data (see FIG. 10) in the game data storage unit 160 is updated. In this case, the participation status of the new user who has accepted the help may be changed (updated) to "in-fight", and the participation status may be changed to "help".

In step S1327A, whether or not the server device 10 has received from any terminal device 20 (that is, from any user) a setting request relating to the minor boss battle part, which is a participation type setting request for the current minor boss battle part. determine whether For example, the server device 10 determines whether or not there is a participation-type setting request in the waiting queue (see step S1108 in FIG. 13). If the determination result is "YES", the process proceeds to step S1327B; otherwise, the process proceeds to step S1328.

In step S1327B, server device 10 associates the new user who has made the participation type setting request with the current minor boss battle part. In other words, a new user who has made a participation type setting request is added to the user group associated with the current minor boss battle part. At this time, the game data (see FIG. 10) in the game data storage unit 160 is updated. Note that, in this case, the participation status of the new user who has made the participation type setting request may be changed (updated) to "playing", and the participation status may be changed to "support".

In step S1328, the server device 10 determines whether or not the conditions for ending the minor boss battle part are satisfied. The end condition of the small boss battle part is satisfied, for example, when either the HP value of the small boss m2 or the HP value of the user's first game medium m0 becomes 0. If the determination result is "YES", the process proceeds to step S1332; otherwise, the process proceeds to step S1330.

In step S1330, the server device 10 advances the minor boss battle part, and ends the processing for this cycle.

In step S1332, the server device 10 sets the first flag F1 to "0" and starts the process of ending the current minor boss battle part. In this case, the participation status data 900 and the like are updated in such a manner that the current participation status of the user is changed (updated) to "waiting".

In step S1334, the server device 10 determines whether or not the small boss m2 has been defeated as a result of the current small boss battle part. That is, it is determined whether or not the subjugation of the small boss m2 was successful. If the determination result is "YES", the process proceeds to step S1336; otherwise, the process proceeds to step S1340.

In step S1336, the server device 10 generates an HP subtraction instruction for subtracting the HP of the big boss m1 by the initial value of the HP of the small boss m2. If the initial value of the HP of the small boss m2 is fixed, the HP subtraction instruction may not include information on the amount of subtraction (the initial value of the HP of the small boss m2).

In step S1338, the server device 10 determines that the game image including the end image in which the defeat scene of the small boss m2 is drawn is displayed on the terminal of the corresponding user (one or more users associated with the current small boss battle part). Image information for display is generated for display on device 20 . Also, in this case, the end image may depict how the HP value of the big boss m1 is updated by defeating (defeating) the small boss m2.

In step S1340, the server device 10 generates display image information so that the game image including the ending image in which the victory scene of the small boss m2 is drawn is displayed on the terminal device 20 of the corresponding user.

Such processing shown in FIG. 15 is executed for each minor boss battle part when the minor boss battle part is set. Therefore, when a plurality of minor boss battle parts are set in succession, the processing shown in FIG. 15 is executed in parallel for each minor boss battle part. When the small boss m2 is defeated and the small boss battle part ends, the process shown in FIG. 15 for each small boss battle part generates an HP subtraction instruction (step S1336) and ends. Therefore, the HP subtraction instruction can be generated at random timing.

FIG. 16 is a schematic flowchart showing an example of HP subtraction processing in the big boss battle part, which is executed in parallel with the subtraction instruction generation processing shown in FIG. The process shown in FIG. 16 may be repeatedly executed at predetermined intervals during the progress of the raid game part.

In step S1402, the server device 10 determines whether or not the second flag F2 indicating the progress of the new big boss battle part is "0". When the second flag F2 is "0", it corresponds to the state of waiting for the start of a new big boss battle part, and when the second flag F2 is "1", it corresponds to the state of progress of a new big boss battle part. do. If the determination result is "YES", the process proceeds to step S1404; otherwise, the process proceeds to step S1412.

In step S1404, the server device 10 determines whether or not the conditions for starting a new big boss battle part are satisfied. The conditions for starting a new big boss battle part are arbitrary. For example, the condition for starting the first big boss battle part may be met when a predetermined time has come. The condition for starting the second and subsequent big boss battle parts may be satisfied when a predetermined time ΔT2 has passed since the previous big boss battle part ended. If the determination result is "YES", the process advances to step S1406; otherwise, the process for this cycle ends.

In step S1406, the server device 10 sets the second flag F2 to "1".

In step S1408, the server apparatus 10 associates the new big boss battle part with the big boss m1, and starts the new big boss battle part.

In step S1410, the server device 10 generates display image information so that each terminal device 20 displays a game image for starting accepting a setting request from the user (setting request related to the small boss battle part).

In step S1412, the server device 10 determines whether or not an HP subtraction instruction (step S1336) has been generated by the subtraction instruction generation process shown in FIG. If the determination result is "YES", the process advances to step S1414; otherwise, the process for this cycle ends.

In step S1414, the server device 10 updates the HP value of the big boss m1. That is, the server device 10 updates the HP value of the big boss m1 by reducing the HP value of the big boss m1 by the subtraction amount (initial HP value of the small boss m2) included in the HP subtraction instruction.

In step S1416, the server device 10 determines whether or not the condition for ending the current big boss battle part is satisfied. The end condition of the big boss battle part is satisfied, for example, when the HP value of the big boss m1 becomes 0, or when the duration of the current big boss battle part exceeds a predetermined time ΔT3. If the determination result is "YES", the process advances to step S1418; otherwise, the process for this cycle ends.

In step S1418, the server device 10 sets the second flag F2 to "0" and starts the process of ending the current big boss battle part. In this case, if there is a minor boss battle part currently in progress (a minor boss battle part in which the HP value of the minor boss m2 is greater than 0), an instruction to end the minor boss battle part is generated.

In step S1420, the server device 10 causes the terminal device 20 of each user (for example, each user whose participation status is other than "exiting") to display a game image including an end image in which the defeat scene of the big boss m1 is drawn. Display image information is generated as shown in FIG.

In step S1422, the server device 10 determines whether or not the current big boss battle part is the final big boss battle part of the current raid game part. That is, it is determined whether or not the big boss m1 associated with the current raid game part is the final big boss m1 (so-called "last boss"). If the determination result is "YES", the process advances to step S1424; otherwise, the process for this cycle ends.

In step S1424, the server device 10 ends the current raid game part. In this case, the server device 10 displays the game image including the end image of the raid game part on the terminal device 20 of each user (for example, all users whose participation status is "waiting" and "leaving"). Display image information may be generated as follows.

In the process shown in FIG. 16, only when the HP subtraction instruction is generated by the subtraction instruction generation process shown in FIG. Processing load can be reduced. That is, the process shown in FIG. 16 monitors the generation status of the HP subtraction instruction by the subtraction instruction generation process shown in FIG. The subsequent substantial processing can be performed. As a result, as described above, even in a situation where a large number of users participate in the raid game part, it is possible to reduce the processing load by reducing the update frequency of the HP value of the big boss m1.

Although the embodiment of the present invention has been described in detail with reference to the drawings, the specific configuration is not limited to this embodiment, and design and the like are included within the scope of the gist of the present invention.

For example, in the embodiment described above, one minor boss m2 is associated with one minor boss battle part, but a plurality of minor bosses m2 may be associated with one minor boss battle part. In this case, when the one small boss battle part ends with the plurality of small bosses m2 defeated, the sum of the initial HP values of the plurality of small bosses m2 is subtracted from the HP value of the large boss m1. By doing so, the HP value of the big boss m1 may be updated.

In the above-described embodiment, HP is associated with the big boss m1 as the first parameter, and HP is associated with the small boss m2 as the second parameter. Also, the HP value of the big boss m1 is reduced, but it is not limited to this. For example, the first parameter and/or the second parameter may be parameters other than HP. Specifically, the first parameter and the second parameter may be the suppression amount when suppressing a predetermined area. In this case, the small areas may be set in the same manner as the "small boss", and the game progresses in such a manner that each time a small area is conquered, a larger large area ("big boss") is conquered. good too. Also, the first parameter and the second parameter may be points or marks. In this case, the acquisition status of points and scores is updated for each user, but the overall acquired points and scores are equal to or greater than a predetermined amount (corresponding to the second predetermined value α2) for each user. may be updated every time.

HP is associated with the big boss m1 as a first parameter, and a second parameter other than HP, such as points, is associated with the small boss m2. The HP value of the big boss m1 may be decreased each time it decreases. Alternatively, one or more grandchild bosses may be set for the small boss m2, similar to the relationship between the big boss m1 and the small boss m2, and all the grandchild bosses associated with one small boss m2 are It may be designed such that when defeated, the small boss m2 is defeated.

In the above-described embodiment, the small boss battle part is associated with the small boss m2, but the concept of the small boss m2 may be eliminated and the small boss battle part may be associated with the big boss m1. In this case, as the second parameter, a point is set that increases according to the attack from the first game medium m0 to the big boss m1. The HP value of the boss m1 may be subtracted. Note that the configuration that eliminates the concept of the small boss m2 is not limited to this, and configurations that eliminate the concept of the small boss m2 can be realized in the various embodiments and their modifications described above. For example, in a configuration where small areas are set in the same manner as "small bosses", and each time a small area is conquered, a larger large area ("big boss") is conquered, there are no small areas. , as the second parameter, a point that increases according to the amount of suppression may be set, and only when the point changes by a second predetermined value α2 or more, the suppression state of the large area may be updated by the change in the point.

1 game system 10 server device 11 server communication unit 12 server storage unit 13 server control unit 20 terminal device 21 terminal communication unit 22 terminal storage unit 23 display unit 24 input unit 25 terminal control unit 30 network 150 game part setting unit 151 participation management unit 152 Small boss battle setting unit 153 Big boss related processing unit 1531 First setting unit 1532 First update unit 1533 First determination unit 154 Small boss battle processing unit 1541 Second setting unit 1542 Second update unit 1543 Second determination unit 155 Help request processing Unit 156 Game state management unit 157 Simultaneous play detection unit 158 Image generation unit 159 Reward giving unit 160 Game data storage unit

Claims (24)

a game part setting unit for setting a competitive game part between a plurality of users and a specific opponent;
a first updating unit that updates the value of a first parameter associated with one first specific opponent based on the progress of the competitive game part;
a second updating unit that updates values of second parameters associated with a plurality of second specific opponents based on the progress of the competitive game part;
The first update unit updates the value of the first parameter with an update frequency lower than that of the second update unit, based on the value of the second parameter updated by the second update unit;
until it is determined that the value of the first parameter associated with the one first specific opponent has changed by a first predetermined value or more from the first initial value, and then the second specific two or more wherein the second specific opponents are newly set one after another in such a manner that each game relating to the opponents of the above can proceed in parallel . a game part setting unit for setting a competitive game part between a plurality of users and a specific opponent;
a first updating unit that updates the value of a first parameter associated with a first specific opponent based on the progress of the competitive game part;
a second updating unit that updates the value of a second parameter associated with a second specific opponent based on the progress of the competitive game part;
The first update unit updates the value of the first parameter with an update frequency lower than that of the second update unit, based on the value of the second parameter updated by the second update unit;
about the second parameter based on one of a first predetermined value indicating a change in the first parameter and a value of the first parameter updated by the first update unit; is set in such a manner that the second predetermined value changes depending on one of the values . a first setting unit that sets the first initial value, which is the initial value of the first parameter, and the first predetermined value, which is a fixed value or a variable value;
a second setting unit that sets a second initial value, which is the initial value of the second parameter, and a second predetermined value, which is a fixed value or a variable value smaller than the first predetermined value;
a first determination unit that determines whether the value of the first parameter updated by the first update unit has changed from the first initial value by the first predetermined value or more;
a second determination unit that determines whether the value of the second parameter updated by the second update unit has changed from the second initial value by the second predetermined value or more;
The first update unit, when the second determination unit determines that the value of the second parameter has changed from the second initial value by the second predetermined value or more, 2. The information processing system according to claim 1, wherein the value of said first parameter is updated by changing the value of said first parameter by a value equal to said value. a first setting unit that sets a first initial value, which is an initial value of the first parameter, and the first predetermined value, which is a fixed value or a variable value;
a second setting unit that sets a second initial value, which is the initial value of the second parameter, and the second predetermined value, which is a fixed value or variable value smaller than the first predetermined value;
a first determination unit that determines whether the value of the first parameter updated by the first update unit has changed from the first initial value by the first predetermined value or more;
a second determination unit that determines whether the value of the second parameter updated by the second update unit has changed from the second initial value by the second predetermined value or more;
The first update unit, when the second determination unit determines that the value of the second parameter has changed from the second initial value by the second predetermined value or more, 3. The information processing system according to claim 2 , wherein the value of said first parameter is updated by changing the value of said first parameter by a value equal to said value. When the first determination unit determines that the value of the first parameter has changed by the first predetermined value or more from the first initial value, the game part setting unit sets the new first specific value. newly setting the battle game part related to the opponent,
The first setting unit sets the first predetermined value in such a manner that the first predetermined value becomes equal to or greater than the previous value each time the competitive game part is newly set by the game part setting unit. 5. The information processing system according to 3 or 4 . Further comprising a second parameter setting unit for setting a plurality of the second parameters,
The second setting unit, the second update unit, and the second determination unit function for each of the second parameters set by the second parameter setting unit,
The first update unit updates the first parameter each time the second determination unit determines that the value of any of the second parameters has changed from the second initial value by the second predetermined value or more. 6. The information processing system according to any one of claims 3 to 5 , wherein the value of is updated. 7. The second parameter according to claim 6 , wherein the second parameter setting unit sets the second parameter for each of the one or more users in such a manner that one second parameter is associated with the one or more users. Information processing system. In the competitive game part, a new user can join later and a participating user can leave partway through in a manner in which the configuration of the plurality of participating users changes,
further comprising a participation management unit that updates the user's participation status in the competitive game part;
8. The information processing system according to claim 7 , wherein said second parameter setting unit sets said second parameter according to said participation status. The second parameter setting unit causes the value of the first parameter associated with one first specific opponent to change from the first initial value by the first predetermined value or more by the first determination unit. 9. The information processing system according to claim 8, wherein the second parameter associated with the second specific opponent is newly set one after another along with the second specific opponent until it is determined that the . The second parameter setting unit sets a predetermined upper limit value larger than the first predetermined value, although the total value of the second predetermined values for the number of the set second parameters exceeds the first predetermined value. 10. The information processing system according to claim 9, wherein said second parameter is set so as not to exceed. The second predetermined value is a fixed value,
The second parameter setting unit sets the second parameter by a number that is larger than a value obtained by dividing the first predetermined value by the second predetermined value and does not exceed a predetermined upper limit number. The information processing system according to claim 9, wherein 10. The second parameter setting unit according to claim 9, wherein the second parameter setting unit sets the second parameter so as not to create a state in which a number of the second parameters exceeding a predetermined upper limit is associated with each user. Information processing system. The information according to claim 9, wherein the second parameter setting unit newly sets one of the second parameters for two or more users when the number of the plurality of users exceeds a threshold. processing system. The second parameter setting unit newly sets the second parameter associated with the one user in response to a setting request from the one user, or sets the second parameter already set in association with another user. 14. The information processing system according to any one of claims 7 to 13 , further associating said second parameter with said one user. When two or more of the second parameters are associated with one user by the second parameter setting unit, the second update unit is configured to set the user with which the two or more second parameters are associated. 15. The information processing system according to any one of claims 6 to 14 , wherein the values of each or some of the two or more second parameters are updated based on a manual or automatic operation input from. Further comprising a user information storage unit for storing user information,
The second setting unit, when the second parameter is newly set by the second parameter setting unit, differs depending on the user information based on the user information related to the user associated with the second parameter. The information processing system according to any one of claims 6 to 15 , wherein said second predetermined value is set. The second setting unit, based on one of the first predetermined value and the value of the first parameter updated by the first update unit, sets the value to one of the values 17. The information processing system according to any one of claims 6 to 16 , wherein said second predetermined value is set in such a manner that said second predetermined value changes accordingly. The first update unit is implemented by one or more computers,
18. The information processing system according to any one of claims 6 to 17 , wherein said second updating unit is realized by more computers than said first updating unit. further comprising an image generation unit that generates display image information for displaying an image on a user terminal associated with each user;
Each time the value of the first parameter is updated by the first update unit, the image generation unit generates an image of the first specific opponent and an image representing the updated value of the first parameter. 19. The information processing system according to any one of claims 3 to 18 , wherein the first display image information for displaying . Each time the value of the second parameter is updated by the second update unit, the image generation unit generates an image of the second specific opponent and an image representing the updated value of the second parameter. 20. The information processing system according to claim 19 , which generates the second display image information for displaying and. a game part setting step of setting a competitive game part between a plurality of users and a specific opponent;
a first update step of updating the value of a first parameter associated with one first specific opponent based on the progress of the competitive game part;
a second updating step of updating values of second parameters associated with a plurality of second specific opponents based on the progress of the competitive game part;
The first updating step updates the value of the first parameter with an update frequency less than that of the second updating step, based on the value of the second parameter;
until it is determined that the value of the first parameter associated with the one first specific opponent has changed by a first predetermined value or more from the first initial value, and then the second specific two or more A computer-executed information processing method, wherein the second specific opponents are successively set anew in such a manner that each game relating to the opponents can proceed in parallel . a game part setting process for setting a competitive game part between a plurality of users and a specific opponent;
a first update process for updating the value of a first parameter associated with a first specific opponent based on the progress of the competitive game part;
causing a computer to execute a second update process of updating values of second parameters associated with a plurality of second specific opponents based on the progress of the competitive game part;
The first update process updates the value of the first parameter with an update frequency lower than that of the second update process, based on the value of the second parameter;
until it is determined that the value of the first parameter associated with the one first specific opponent has changed by a first predetermined value or more from the first initial value, and then the second specific two or more The information processing program, wherein the second specific opponents are newly set one after another in a manner in which each game related to the opponents can progress in parallel . a game part setting step of setting a competitive game part between a plurality of users and a specific opponent;
a first updating step of updating a value of a first parameter associated with a first specific opponent based on progress of the competitive game part;
a second updating step of updating the value of a second parameter associated with a second specific opponent based on the progress of the competitive game part;
The first updating step updates the value of the first parameter with an update frequency less than that of the second updating step, based on the value of the second parameter;
about the second parameter based on one of a first predetermined value indicating a change in the first parameter and the value of the first parameter updated by the first updating step; is set in such a manner that the second predetermined value changes according to one of the values . a game part setting process for setting a competitive game part between a plurality of users and a specific opponent;
a first update process for updating the value of a first parameter associated with a first specific opponent based on the progress of the competitive game part;
causing a computer to execute a second update process of updating the value of a second parameter associated with a second specific opponent based on the progress of the competitive game part;
The first update process updates the value of the first parameter with an update frequency lower than that of the second update process, based on the value of the second parameter;
about the second parameter based on one of a first predetermined value indicating a change in the first parameter and the value of the first parameter updated by the first update process; is set in such a manner that the second predetermined value changes according to one of the values .

Images