JP7436883B2 - Information processing system, information processing device and program - Google Patents

Description

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

Patent Document 1 discloses that the reservation date and time of the account that has requested participation from the game terminal is compared with the current date and time, and if the current date and time is within a predetermined time after the reservation date and time, the player is not allowed to participate in the game play of the online network game. , a technique is disclosed that allows a player to participate in game play if the current date and time is within a predetermined time after the reserved date and time.

Patent No. 3822835

There is room for improvement in leveling the demand for users to play games in games.

In view of the above circumstances, this disclosure aims to reduce the imbalance in demand for games.

(1) According to one aspect of the present disclosure, an information processing system is provided. In the game processing step in this information processing system, game processing related to the game played by the user is executed in response to the user's instructions. The identification step identifies data for predicting trends in demand for playing the game, where the demand is the demand in a population of users who play the game, and the prediction is based on factors that influence the demand. be exposed. In the variation processing step, variation processing is executed when the element used for prediction based on the specified data satisfies variation conditions, and the variation processing is performed when a user included in the group performs a game action in the game, or , includes a process of varying the result of the game action so as to offset a predicted trend in demand when the variation condition is satisfied compared to a case where the variation condition is not satisfied.

According to such an aspect, it is possible to reduce uneven demand for games.

FIG. 1 is a block diagram showing the hardware configuration of a game system 1 according to the present embodiment. FIG. 3 is a diagram showing the functional configuration of a control section of each device. 3 is a flowchart showing the flow of information processing. It is a figure showing an example of data for prediction. FIG. 3 is a diagram showing an example of prediction results when a multiplayer event is held. It is a figure showing an example of a prediction result at the time of a single play event. It is a figure showing an example of a game screen of single play. It is a figure which shows an example of the game screen which shows a list of quests. FIG. 3 is a diagram showing an example of a multiplayer game screen. It is a figure which shows an example of the game screen which shows a list of quests. It is a figure showing an example of a lottery table of gacha. It is a figure showing an example of data for prediction. It is a figure which shows another example of data for prediction. FIG. 3 is a diagram showing the history of variation processing. FIG. 7 is a diagram illustrating another example of the functional configuration of the control unit of each device. It is a figure which shows another example of a game screen. It is a figure which shows another example of a game screen.

[Embodiment]
Embodiments of the present disclosure will be described below with reference to the drawings. Various features shown in the embodiments described below can be combined with each other.

By the way, the program for implementing the software appearing in this embodiment may be provided as a non-transitory computer-readable recording medium, or may be downloaded from an external server. The program may be provided in a manner that allows the program to be started on an external computer and the function thereof is realized on the client terminal (so-called cloud computing).

Furthermore, in this embodiment, the term "unit" may include, for example, a combination of hardware resources implemented by circuits in a broad sense and software information processing that can be concretely implemented by these hardware resources. . In addition, various types of information are handled in this embodiment, and these information include, for example, the physical value of a signal value representing voltage and current, and the signal value as a binary bit collection consisting of 0 or 1. It is expressed by high and low levels or quantum superposition (so-called quantum bits), and communication and calculations can be performed on circuits in a broad sense.

Further, a circuit in a broad sense is a circuit realized by at least appropriately combining a circuit, a circuit, a processor, a memory, and the like. That is, Application Specific Integrated Circuit (ASIC), programmable logic device (for example, Simple Programmable Logic Device (SPLD)), Complex Programmable Logic Device (Complex Pr) ogrammable Logic Device: CPLD), and fields This includes a field programmable gate array (FPGA) and the like.

1. Game Description FIG. 1 is a block diagram showing the hardware configuration of a game system 1 according to the present embodiment. In the game system 1 shown in FIG. 1, a game management device 2 and a plurality of game devices 3 are communicably connected to each other via a communication network 11, and a game is executed on the game devices 3. Each device connected to the game system 1 is an information processing device, and the game system 1 is an information processing system including these information processing devices.

The game according to this embodiment is an online game executed by the game system 1. In this game, the user of the game device 3 causes one or more player characters to act in a virtual game space, and causes the player character to compete against an enemy character that is a non-player character (NPC). Further, a character is an example of an object.

The above games can be played on home game consoles such as PlayStation (registered trademark), portable game consoles such as Nintendo Switch (registered trademark), or game devices 3 that are electronic devices such as personal computers, smartphones, and tablet terminals. It is executed using

2. Overview of Game System 1 As shown in FIG. 1, the game system 1 includes a game management device 2 and a plurality of game devices 3. The game management device 2 stores game programs and game data, and manages the game data of the game device 3 (for each account information described below). The game management device 2 is configured by, for example, a server. Each of the plurality of game devices 3 has the same configuration. Note that in this embodiment, the system is composed of one or more devices or components. Therefore, for example, even a single game management device 2 or game device 3, which will be described later, can be an example of the game system 1.

The game device 3 executes a predetermined game based on a user's operation. For this purpose, the game device 3 receives (specifically downloads and installs) the game program and game data from the game management device 2 via the communication network 11. Account information including identification information and a password is assigned to each user in association with the game device 3. This account information is transmitted from the game device 3 to the game management device 2 at the time of login, and is used for user authentication in the game management device 2.

After user authentication, mutual communication between the game management device 2 and the game device 3 becomes possible. After logging in, the game device 3 receives data necessary for the game progress (data related to the game progress status) from the game management device 2, and then outputs game images and sounds to the display 4a and speaker 4b based on the user's operations. , advance the game.

2.1 Hardware Configuration Hereinafter, each hardware configuration of the game system 1 will be explained with reference to FIG.

<Game management device 2>
As shown in FIG. 1, the game management device 2 includes a communication section 21, a storage section 22, and a control section 23. The communication unit 21 and the storage unit 22 are electrically connected to the control unit 23 via the communication bus 20.

The communication unit 21 is a so-called network interface that is communicably connected to each game device 3 via the communication network 11 such as the Internet and a LAN. The main information that the game management device 2 receives via the communication unit 21 includes game program download request information, gacha lottery request in response to user operations, quest execution request, autoplay execution/termination request, Examples include account information and game data. The main information that the game management device 2 transmits via the communication unit 21 includes information for confirming that the game device 3 has received the game program, information regarding game media obtained through gacha, etc. .

The storage unit 22 includes a HDD (Hard Disk Drive), a RAM (Random Access Memory), a ROM (Read Only Memory), an SSD (Solid State Drive), and the like. The storage unit 22 stores various programs including a part of the game program according to the present embodiment, various data related to games, and the like.

Specifically, for example, the storage unit 22 stores a user DB, a lottery list, and the like. The user DB contains information such as the user name, user rank, and status regarding the player character operated by the user, the amount of consumption media that can be used in the virtual game space, and parameters for each identification number of the user who plays the game. Information etc. are stored in association with each other. The lottery list is used for a lottery process generally called gacha, and includes a plurality of pieces of information regarding game media to be selected. In the lottery list, information regarding the game medium (name, ability parameters, rarity, level, etc.) is associated with selection ratios based on the lottery. Further, the ability parameters include, for example, when the game medium is a player character, military strength, HP, attack power, defense power, intelligence, or speed.

The control unit 23 is composed of a microcomputer including a CPU and a semiconductor memory, and controls the operation of the game management device 2, which is its own device. In particular, the control section 23 realizes various functions related to the game management device 2, which is its own device, by reading out a predetermined program stored in the storage section 22. That is, information processing by software stored in the storage unit 22 is specifically implemented by the control unit 23, which is an example of hardware, so that each functional unit described below can be executed. Note that the control section 23 is not limited to a single control section, and may be implemented so as to have a plurality of control sections 23 for each function. It may also be a combination thereof.

Examples of the information processing executed by the control unit 23 include billing settlement processing, user account authentication processing, gacha lottery selection processing, and the like. The billing settlement process is executed, for example, based on a billing request necessary to recover a predetermined amount of parameters during the game. The user account authentication process is executed using user identification information received from the game device 3, for example. The gacha lottery selection process is a process of selecting one or more game media by lottery from a lottery list based on the selection probability for each game medium in response to a gacha lottery request. According to the gacha lottery selection process, the information regarding the selected game medium and the identification information of the user who performed the operation to send the lottery request are associated in the user DB, and this allows the user to: You will receive the game content you won as a result of pulling the gacha yourself.

To further supplement the above, "game media" is electronic data representing elements related to the game, including the name of the character used as the player character, and the items used by the player character in the virtual game space. Includes weapons, armor, tools, etc. Users can obtain game media through a lottery method called gacha, in addition to direct purchase through payment and quest clearing. The obtained game content is stored and managed in the user DB in association with the identification information of the user who owns the game content. Furthermore, "gacha" is a method in which the game management device 2 selects an arbitrary game medium from a lottery list based on a predetermined selection ratio. The selected arbitrary game content is provided to the user's game device 3. "The game content selected in the gacha is given to the user/owned by the user" is synonymous with "the game content selected in the lottery process is/is associated with identification information indicating the user". be.

<Game device 3>
A display 4a, a speaker 4b, and an input device 4c are externally connected or built into the game device 3. The game device 3 also includes a communication section 31, a storage section 32, a control section 33, a graphics processing section 34a, an audio processing section 34b, and an operation section 34c. The communication section 31, the storage section 32, the graphic processing section 34a, the audio processing section 34b, and the operation section 34c are electrically connected to the control section 33 via the communication bus 30.

The communication unit 31 is a so-called network interface that is communicably connected to the communication network 11 in order to transmit and receive various data between the game device 3 and the game management device 2. The main information that the game device 3 receives via the communication unit 31 includes account information, new game data download request information, gacha execution request, quest execution request, and the like. The main information that the game device 3 transmits via the communication unit 31 includes new game data sent from the game management device 2 in response to download request information, information regarding the game content selected in the lottery process, etc. Can be mentioned.

The storage unit 32 includes an HDD, SSD, RAM, ROM, and the like. The storage unit 32 stores game data downloaded from the game management device 2, various programs including a part of the game program, account information of the game device 3, which is the own device, user information, etc. Note that the user information is at least part of information in the user DB stored in the storage unit 22 of the game management device 2. The user DB manages a master of user information, and the storage unit 32 of the game device 3 receives at least part of the information of this master from the game management device 2 and stores it.

The control unit 33 is composed of a microcomputer including a CPU and a semiconductor memory, and controls the operation of the game device 3, which is its own device. In particular, the control section 33 realizes various functions related to the game device 3, which is the own device, by reading out a predetermined program stored in the storage section 32. That is, information processing by software stored in the storage unit 32 is specifically implemented by the control unit 33, which is an example of hardware, so that each functional unit described below can be executed. Note that the control section 33 is not limited to a single control section, and may be implemented so as to have a plurality of control sections 33 for each function. It may also be a combination thereof.

In particular, the control unit 33 is configured to execute the game in accordance with input by the user of the game device 3, which is its own device, via the input device 4c. Specifically, the control unit 33 reads data such as virtual game space objects and textures included in the game data from the storage unit 32, or uses data received from the game management device 2 to create two-dimensional or three-dimensional Generates game image information. As the game image information is processed by the graphic processing unit 34a, the processed game images are sequentially displayed on the display 4a. In other words, the control unit 33 is configured to perform display control on the display 4a and audio output control on the speaker 4b in response to operations by the user of the game device 3, which is the own device, when executing the game.

The graphic processing unit 34a draws a game image including characters and various objects related to the virtual game space in a moving image format according to the game image information output from the control unit 33. The graphic processing unit 34a is connected to, for example, a liquid crystal display 4a, and a game image drawn in a moving image format is displayed on the display 4a as a game screen. The audio processing section 34b is connected to the speaker 4b, and when the game sound is reproduced and synthesized according to instructions from the control section 33, it is output from the speaker 4b. The operation unit 34c is connected to the input device 4c, and transmits and receives data related to operation inputs to and from the input device 4c. The user inputs an operation signal to the game device 3 via the input device 4c. Note that the input device 4c is a general term for a touch panel integrated with the display 4a, an external game pad, a mouse, a keyboard, and the like.

2.2 Functional Configuration This section describes the functional configuration of this embodiment. As described above, the information processing by the software stored in the storage section of each device is specifically implemented by the control section, which is an example of hardware, so that each functional section included in the control section can be executed.

FIG. 2 is a diagram showing the functional configuration of the control section of each device. The control unit 23 of the game management device 2 includes a game processing unit 201 , a setting management unit 202 , a prediction generation unit 203 , a prediction execution unit 204 , and a variation processing unit 205 . The game device 3 includes a game processing section 301 and an operation reception section 302.

The game processing unit 201 of the game management device 2 executes game processing related to the game played by the user in response to instructions from the user. In this embodiment, a game is played in which the overall story progresses while characters participate in quests and fight in battles. The game processing unit 201 executes, as game processing, processing related to characters, processing related to quests, processing related to battle, processing related to progress of the story, etc., for example. Furthermore, the game processing unit 201 executes single-play game processing in which one user plays a game, and multi-play game processing in which two or more users play the same game at the same time.

The settings management unit 202 manages settings of parameters related to the game. In games, there are various parameters such as the character's attack power, defense power, physical strength, and speed, the weapon's attack power, durability, and number of attacks, and the size of the item's effect and the number of times it can be used. parameters are used. The setting management unit 202 stores these parameters, and if there is a change as the game progresses, the change is reflected in the parameters. The game processing unit 201 executes game processing based on parameters stored in the setting management unit 202.

The prediction generation unit 203 generates data (hereinafter referred to as "prediction data") for predicting trends in demand for playing games. The prediction data is, for example, an estimation formula that calculates a numerical value indicating the magnitude of demand from elements used for prediction (hereinafter referred to as "prediction elements"). Predictive factors are factors that affect the demand for game play, such as in-game events, out-of-game events, or specific times in the real world. The prediction execution unit 204 executes prediction of demand trends using prediction elements and prediction data.

The variation processing unit 205 executes variation processing to vary the compensation or result for executing a game action. Game actions are actions that the user performs in the game, such as various actions in battle (attack, defense, magic, use of items, etc.), various actions in situations other than battle (conversation with in-game characters, etc.) , buying and selling items, selecting quests, etc.) and actions related to billing (purchasing virtual currency, gacha, etc.). Further, the game behavior includes game behavior in single play and game behavior in multiplayer.

The game processing unit 301 of the game device 3 cooperates with the game processing unit 201 of the game management device 2 to execute processing related to the game. The operation accepting unit 302 accepts operations by the user. The operations performed by the user are mainly operations performed when playing the game, and are operations for instructing actions (battle, movement, etc.) within the game.

3. Flow of Operation of Game System 1 In this section, the flow of operation of the game system 1 described above will be explained. As an example of a preferred embodiment, a game will be described in which a user operates a character and progresses through a quest while acquiring items and the like.

3.1 Overview of Information Processing The flow of information processing executed by the game system 1 will be outlined below with reference to FIG.

FIG. 3 is a flowchart showing the flow of information processing. First, when a user plays a game, the game management device 2 and the game device 3 execute game processing at A11, with the game processing section 201, the game processing section 301, and the operation reception section 302 working together. More specifically, the game processing unit 201 generates screen data indicating a game screen that changes as the game progresses, and transmits it to the game device 3. The game device 3 uses the game processing unit 301 to display the game screen indicated by the received screen data. The game device 3 uses the operation reception unit 302 to accept game operations performed by the user while viewing the displayed game screen.

The game processing unit 201 executes single-play game processing and multi-play game processing. Multiplayer game processing includes, for example, game processing in which users compete against each other, game processing in which users cooperate with each other to advance battles or quests against a computer opponent, and game processing in which users are divided into multiple teams and play against each other. This includes game processing, etc. The game processing unit 201 executes, as game processing, a process of advancing the game while referring to parameters stored in the setting management unit 202 in both single play and multiplay.

Next, in A12, the game management device 2 uses the game processing unit 201 to accumulate play results by the user. Specifically, the game processing unit 201 accumulates the user ID of the user who played the game, the play date and time, the play mode (single play or multiplay), participation in an event, etc. as play results. An event is an event held within a game, and includes, for example, participation in a special quest, battle with a special enemy, acquisition of special items, and the like. There are events in which players participate in single play and events in which they participate in multiplayer. A11 and A12 are accumulation processes that are executed every time the user plays the game.

After the play results are accumulated by the accumulation process, the game management device 2 executes the generation process to generate the above-mentioned prediction data (data for predicting the trend of demand for playing the game). First, in A21, the game management device 2 uses the prediction generation unit 203 to acquire prediction elements. The prediction generation unit 203 obtains, for example, time information indicating the current date and time and event information indicating an event scheduled in the game as prediction elements.

Then, in A22, the game management device 2 causes the prediction generation unit 203 to generate prediction data based on the acquired prediction elements. Details of the method for generating prediction data will be described later. The prediction generation unit 203 stores the generated prediction data. The generation process of A21 and A22 is performed periodically, for example, at predetermined time intervals (once a month, etc.).

Further, the game management device 2 periodically performs the fluctuation processing described below at predetermined time intervals (daily, etc.). The variation process is a process of varying the compensation for a user included in a group to perform a game action in a game or the result of a game action. The consideration for the game action is, for example, virtual currency necessary for executing the game action, specific parameters (such as stamina), or money used for actual payment. Game actions include, for example, actions by users to acquire items through gacha or item purchases, actions by users such as participation in in-game content or events such as quests, actions by characters during the quests, and the like.

The result of a game action is, for example, if the game action is to obtain an item through a gacha, the item/character, etc. that will be drawn, a bonus item that will be given to the user in conjunction with the drawing, etc. In the case of items acquired through purchase, these are bonus items given to the user in conjunction with the purchase, and are based on rankings based on points awarded to the user for clearing in-game content and events such as quests, and playing. It includes various rewards given to users depending on the determined ranking of the users. In the case of a character's actions during a quest, it includes the success or failure of various actions such as attacks, and the degree of effectiveness of various actions such as the value of damage to enemy characters.

In A31, the game management device 2 uses the variation processing unit 205 to determine whether the prediction element used in the prediction generation process satisfies the variation condition. The fluctuation condition is a condition for determining whether or not to execute the fluctuation process, and is satisfied, for example, when a specific event in the game is being held at the present time. The fluctuation processing unit 205 repeatedly executes the process of A31 until the fluctuation condition is satisfied, and if it is determined that the fluctuation condition is satisfied, then executes the process for predicting the demand trend. Note that the process for predicting demand trends may be performed at any frequency, such as constantly, periodically, or regularly, without determining whether the fluctuation conditions are satisfied.

First, in A32, the game management device 2 uses the prediction execution unit 204 to specify prediction data to be used for prediction. A plurality of pieces of prediction data are generated by the above prediction generation process. The prediction execution unit 204 identifies, for example, the latest prediction data from among the prediction data stored in the prediction generation unit 203. Note that the prediction data may be stored in an external device. Further, the prediction data may be generated based on a function corresponding to the prediction generation unit 203 provided in an external device or based on a human operation.

Next, in A33, the game management device 2 uses the prediction execution unit 204 to acquire prediction elements to be used for prediction using the prediction data. The prediction execution unit 204 obtains, for example, the above-mentioned time information and event information as prediction elements. Subsequently, in A34, the game management device 2 uses the prediction execution unit 204 to predict the demand trend based on the acquired prediction elements and the specified prediction data.

Then, in A35, the game management device 2 causes the variation processing unit 205 to execute a variation process to vary the compensation for executing the game action described above or the result of the game action. The fluctuation processing unit 205 compares these prices or results with the case where the fluctuation conditions are not satisfied, and executes a process of changing these prices or results so as to offset the predicted demand trend when the fluctuation conditions are satisfied, as a fluctuation processing. do. "Offsetting the demand trend" means to reduce demand when demand is increasing or high, and to increase demand when demand is decreasing or low. . Details of the fluctuation processing will be described later.

Assume that the user plays the game after the variation process is executed. In that case as well, in A36, the game management device 2 and the game device 3 execute the game processing with the game processing section 201, the game processing section 301, and the operation reception section 302 working together. At this time, the game processing unit 201 executes the game processing so that the compensation or result when the user performs the game action becomes the compensation or result that has been varied by the variation processing.

To summarize the above, the game system 1 according to the present embodiment includes the following components: a game processing section (game processing section 201), a specifying section (prediction execution section 204), and a variation processing section (variation processing section 205). ). The game processing unit executes game processing related to the game played by the user in response to instructions from the user. The identification unit identifies data for predicting trends in demand for playing the game. The demand here is the demand among a group of users who play the game, and prediction is performed based on factors that affect demand.

The variation processing unit executes variation processing when a prediction element used for prediction based on the prediction data specified by the identification unit satisfies a variation condition. Fluctuation processing is predicted when the fluctuation condition is satisfied by comparing the compensation for the user included in the group to perform the game action in the game or the result of the game action when the fluctuation condition is not satisfied. Includes processing to offset demand trends.

According to such an aspect, it is possible to reduce bias in demand for the game compared to a case where no fluctuation processing is performed and there is no change in the compensation for executing the game action or the result of the game action. .

3.2 Details of Information Processing Next, details of the information processing outlined above will be explained.

First, details of the prediction generation process performed in FIG. 3 will be explained. In A22, the prediction generation unit 203 generates a prediction that predicts the number of game players and the number of various game sessions to be executed by each player in a future predetermined period based on the play performance in the past predetermined period, for example. Generate data for use. A game session includes game actions by the user, such as acquiring items through the aforementioned gacha or purchasing items, participating in in-game content and events such as quests, and the number of game sessions is determined by the server based on the user's request. This is the number of times the game has been executed by the game management device 2. For example, the prediction generation unit 203 calculates the number of users and the number of game sessions in each time period (predetermined period in the future) on each day of the week based on the play performance during a period without an event (predetermined period in the past). Generate prediction data for each of single play and multiplay.

FIG. 4 is a diagram showing an example of prediction data. In FIG. 4, a graph is shown in which the vertical axis shows the number of users playing the game, and the horizontal axis shows each day of the week and each time period. In FIG. 4(a), the number of users in multi-play is shown, and in FIG. 4(b), the number of users in single-play is shown. The number of sessions is the number of users multiplied by the number of sessions each user performs. Although the number of sessions executed differs depending on the user, the overall number of sessions generally varies depending on the number of users, so the following explanation will focus on the number of users. For example, the number of users is counted as one from when the same user logs in, starts the game, ends the game, and logs off. Therefore, if the same user plays the game every day, it will be counted as one person each day, and even on the same day, if the same user logs in and logs off in the morning and afternoon, for example, it will be counted as two people.

In the example of FIG. 4, on any day of the week, the number of users is small in the morning, and increases from the afternoon to late at night. Additionally, the number of users is small on Monday, the first day of the week, and gradually increases over the weekend, reaching its peak on Saturday night. Additionally, the number of users is generally larger in multiplayer than in singleplayer.

Next, the prediction generation unit 203 generates prediction data for predicting the number of users during the event period based on the play performance during the period in which the event was held.

FIG. 5 is a diagram illustrating an example of prediction results when a multiplayer event is held. In the example of FIG. 5, a graph similar to that of FIG. 4 shows the number of users when a multiplayer event is held from Thursday to Sunday. The number of multiplayer users shown in FIG. 5(a) increases to about twice that of the example shown in FIG. 4 during the event period. The number of single-play users shown in FIG. 5(b) slightly decreases during the event period compared to the example in FIG. 4. Note that during an event, the number of sessions executed by each user tends to be larger than usual, so the number of sessions increases even more as the number of users increases.

FIG. 6 is a diagram illustrating an example of a prediction result when a single-play event is held. In the example of FIG. 6, a graph similar to that of FIG. 4 shows the number of users when a single-play event is held from Thursday to Sunday. The number of multiplayer users shown in FIG. 6(a) decreases by about 40% during the event period compared to the example shown in FIG. The number of single play users shown in FIG. 6(b) increases by more than twice as much as the example in FIG. 4 during the event period. Note that during an event, the number of sessions executed by each user tends to be larger than usual, so the number of sessions increases even more as the number of users increases.

The prediction results shown in FIGS. 4 to 6 are the prediction results of prediction data that uses the day of the week, time of day, and presence or absence of an in-game event (multiplayer event or single play event) as prediction elements. shows the prediction results of demand trends in the population. The prediction generation unit 203 calculates a calculation formula that allows the number of users and the corresponding number of game sessions shown in FIGS. 4 to 6 to be obtained as prediction results when the day of the week, time of day, and the presence or absence of an in-game event are used as prediction elements. , generated as prediction data.

The prediction execution unit 204 predicts the demand for game play using the generated prediction data and the acquired prediction elements. For example, when event information indicating that a multiplayer event will be held on a Saturday and Sunday is acquired as a prediction element, the prediction execution unit 204 calculates the period up to the Friday before the event as shown in FIGS. 4(a) and 4(b). The demand for single-play and multi-play gameplay is predicted using the prediction data shown. The prediction execution unit 204 uses the prediction data shown in FIGS. 5A and 5B to predict the demand for single-play and multi-play game play for the Saturday and Sunday period when the event is held.

Next, details of the variation processing performed in FIG. 3 will be explained. For example, the game system 1 performs the fluctuation condition determination process of A31 at 0:00 every day, and when determining that the fluctuation condition is satisfied, executes the processes from A32 onwards. As a result, for example, at A23, event information indicating that today is a multiplayer event period is acquired as a prediction element, and at A24, a demand trend indicating that the number of multiplayer users will increase is predicted, as shown in FIG. Suppose that

In that case, the fluctuation processing unit 205 changes the process of changing the price or result of the game action so as to offset the trend of demand that the number of multiplayer users increases, that is, to reduce the number of multiplayer users. Execute as a process. For example, the variation processing unit 205 varies the stamina consumed when participating in a quest as compensation for a game action. The fluctuation processing unit 205 executes a process of increasing the stamina consumption of a multiplayer quest and decreasing the consumption stamina of a single play quest as a fluctuation process.

Specifically, the variation processing unit 205 executes, as a variation process, a process of reading out and changing parameters that define the consumption stamina of each quest from the setting management unit 202. Further, the variation processing unit 205 executes a process of changing the screen that displays the consumed stamina of each quest as a variation process. The game processing unit 201 generates screen data indicating a game screen on which the variation processing is reflected, and transmits it to the game device 3. The game processing unit 301 of the game device 3 displays the game screen indicated by the received screen data.

The transition of the game screen related to the fluctuation process will be explained with reference to FIG. 7 and subsequent figures. 7 and 8, the transition of the single play game screen will be explained.
FIG. 7 is a diagram showing an example of a single play game screen. A gacha button B1, a composition button B2, a quest button B3, an item button B4, and a billing button B5 are displayed on the single play game screen G1 shown in FIG. 7(a).

When the gacha button B1 is operated, a game screen for performing a gacha lottery is displayed. When the formation button B2 is operated, a game screen for forming characters is displayed. When the quest button B3 is operated, a game screen is displayed that shows a list of quests that the user playing single play can currently participate in. When the item button B4 is operated, a game screen is displayed on which the player can decide which item he/she owns, use the item, etc. When the billing button B5 is operated, a game screen for paying for paid items such as virtual currency is displayed.

A single play game screen G2 shown in FIG. 7(b) is displayed when the quest button B3 is operated. The game screen G2 shows consideration information C1 and consideration information C2 as information indicating the consideration (consumed stamina) for participating in the quest. The consideration information C1 is information indicating that the consumption stamina in the standard period is a value (reference value) that serves as a reference for dynamic pricing. Dynamic pricing is a method of changing prices depending on the situation. In the game system 1, dynamic pricing refers to not only the price used for buying and selling, but also changing the compensation for some game action, such as stamina consumed when participating in a quest, depending on the situation. Hereinafter, the period during which dynamic pricing is applied will be referred to as the "DP period." On the other hand, the aforementioned "standard period" is a period to which dynamic pricing is not applied.

In the example of FIG. 7, it is assumed that an event is held during the DP period in which users who play multiplayer games can participate. Therefore, it is predicted that demand will tend to increase in the number of multiplayer users during the DP period. Therefore, in order to increase the number of single-player users, the fluctuation processing unit 205 executes a process of reducing the consumption stamina of single-player quests as a fluctuation process. The consideration information C2 is information indicating the consumed stamina that has been changed in this way. Specifically, consideration information C2 indicates that the stamina consumed in the DP period is a value obtained by discounting the stamina consumed in the standard period (=reference value) by 20%.

Period information D1 and period information D2 are shown on the game screen G2. Period information D1 indicates that the current period is a standard period. Period information D2 indicates that there are three days left until the DP period. After three days have passed, the period information D2 will indicate that the current period is the DP period, and the period information D1 will indicate the number of days until the next standard period. By displaying such period information, the user can determine whether the current time is an advantageous or unfavorable time to complete the quest, and if it is an unfavorable time, when it will become an advantageous time. You can make decisions regarding when to play.

Note that when forecasting the demand trend at the start of the DP period or immediately before, that is, when dynamic pricing is executed based on more real-time data, it is not possible to perform fluctuation processing during the DP period. In this case, instead of displaying the content of the variation process on the game screen G2, content that foretells that the variation process will be performed during the DP period may be displayed. In this case, users should be informed that fluctuation processing will be performed based on a predetermined estimation formula, and that as a result of fluctuation processing, the compensation and results of game actions may be treated poorly by users compared to the standard period. It is preferable.

A quest list display button B6 is shown on the game screen G2. The game screen when the display button B6 is operated will be described with reference to FIG. 8.
FIG. 8 is a diagram showing an example of a game screen showing a list of quests. In the case of the standard period, a game screen G3 shown in FIG. 8(a) is displayed. The game screen G3 shows a list C3 of quests associated with consumed stamina in the standard period and a participation button B7 for accepting an instruction to participate in a quest.

List C3 shows that the consumed stamina for quests "1", "2", "3", and "4" are "20", "30", "25", and "40". These consumed stamina are "reference values" when changing the consumed stamina by dynamic pricing. The setting management unit 202 stores these reference values as the stamina consumption for each quest. If the variation condition is not satisfied, the game processing unit 201 uses the reference value stored in the setting management unit 202 to consume the stamina of the user participating in the quest.

In the case of the DP period, a game screen G4 shown in FIG. 8(b) is displayed. The game screen G4 shows a list C4 of quests associated with the stamina consumed during the DP period and a participation button B7. In list C4, the stamina consumption for quests "1", "2", "3", and "4" is "20 → 16 (20% OFF)", "30 → 24 (20% OFF)", "25 → 20 (20% OFF)" and "40→32 (20% OFF)." These consumed stamina values are values obtained by changing the "reference value" through variation processing. By reducing the stamina consumed in single play in this way, it is possible to induce the user to play single play.

The above was the transition of the game screen in single play. Next, the transition of the multi-play game screen will be explained with reference to FIGS. 9 and 10.
FIG. 9 is a diagram showing an example of a multiplayer game screen. The multiplayer game screen G11 shown in FIG. 9(a) displays a gacha button B1, a composition button B2, a quest button B3, an item button B4, a charge button B5, and a raid battle button B8. . The gacha button B1 to the billing button B5 are the same as those described in FIG. 7(a).

When the raid battle button B8 is operated, a raid battle game screen is displayed. A raid battle is an event in which multiple users cooperate to fight against powerful enemies, and is one of the events held in a multiplayer game. The raid battle button B8 is displayed during the period in which a raid battle is held. That is, the example in FIG. 9 shows a game screen displayed during the DP period. In multi-play, the stamina of all participating users may be consumed, the stamina of only the host user, or the stamina of any user may be consumed.

Here, when the quest button B3 is operated, the game processing unit 201 displays a multiplay game screen G12 shown in FIG. 9(b). The game screen G12 shows consideration information C11 and consideration information C12. The consideration information C11 is information indicating that the consumption stamina in the standard period is the reference value for dynamic pricing. The consideration information C12 is information indicating that the consumption stamina during the DP period is a value obtained by increasing the reference value shown in the consideration information C11 by 20%.

The game screen G12 shows period information D11 and period information D12. Period information D12 indicates that the current period is the DP period. Period information D11 indicates that there are three days left until the next standard period. After three days have passed, the period information D11 will indicate that the current period is the standard period, and the period information D12 will indicate the number of days until the next DP period. In this case as well, similarly to the example of FIG. 7(b), the user can make a determination regarding when to play. Note that, as in the case of single play, the contents of the variation process may not be displayed.

A quest list display button B6 is shown on the game screen G12. The game screen when the display button B6 is operated will be described with reference to FIG. 10.
FIG. 10 is a diagram showing an example of a game screen showing a list of quests. In the case of the standard period, a game screen G13 shown in FIG. 10(a) is displayed. The game screen G13 shows a list C13 of quests associated with the stamina consumed in the standard period and a participation button B7.

In list C13, the stamina consumed for quests "1", "2", "3", and "4" are "20", "30", "25", and "40", which are the same as the standard values for single play. It has been shown that Here, for example, if the variable condition that a multiplayer event is held is satisfied and the DP period begins, a game screen G14 shown in FIG. 10(b) is displayed.

The game screen G14 shows a list C14 of quests associated with the stamina consumed during the DP period and a participation button B7. In list C14, the stamina consumption for quests "1", "2", "3", and "4" is "20 → 24 (20% UP)", "30 → 36 (20% UP)", "25 → 30 (20% UP)" and "40→48 (20% UP)". These consumed stamina values are values obtained by changing the "reference value" through variation processing. By increasing the stamina consumption in multiplayer in this way, it is possible to induce users to play single play.

When a multiplayer event is held, the demand for multiplayer tends to increase due to the effect of the event. Therefore, as shown in FIGS. 7 to 10, the fluctuation processing unit 205 executes fluctuation processing to offset the demand trend by lowering the price for single play and increasing the price for multiplayer. Thereby, the user can be guided to the side where the demand is low, and the bias in demand can be reduced compared to the case where the fluctuation process is not executed.

Next, a case will be described in which the variation processing unit 205 executes a variation process that varies the result of a game action. For example, the variation processing unit 205 executes a process of varying the result of a game action of pulling a gacha as a variation process. The lottery probability in the gacha is set, for example, by a lottery table stored in the setting management section 202. There are lottery tables for the standard period and for the DP period, and for example, the table to be used is indicated by a flag.

FIG. 11 is a diagram showing an example of a gacha lottery table. In FIG. 11(a), a lottery table L1 used in the standard period is shown. In lottery table L1, the lottery probability of items with rarity of "N" (normal), "R" (rare), "SR" (super rare), and "SSR" (super special rare) is "50%" and " 30%,” “15%,” and “5%.” During the standard period, the setting management section 202 stores a flag indicating the lottery table L1, and the game processing section 201 performs a gacha lottery using the lottery table L1 indicated by the flag.

In FIG. 11(b), a lottery table L2 used in the DP period is shown. In lottery table L2, the lottery probability for items with rarity of "N", "R", "SR", and "SSR" is "20%", "40%", "25%", and "15%". It has been shown that there is. In FIG. 11(c), a lottery table L3 used in the DP period is shown. In lottery table L3, the lottery probability for items with rarity of "N", "R", "SR", and "SSR" is "68%", "20%", "10%", and "2%". It has been shown that there is. In this way, when the lottery table L2 is used, rare items are more likely to be drawn than during the standard period, and when the lottery table L3 is used, rare items are less likely to be drawn than during the standard period.

For example, when a single-player event is held, the demand for single-player games tends to increase due to the effect of the event. Therefore, in order to offset this demand trend, the fluctuation processing unit 205 changes the flag to indicate lottery table L3 in which rare items are difficult to be drawn in single-play gachas, and rare items are not drawn in multi-player gachas. A process of changing the flag to indicate the lottery table L2 that is likely to be used is executed as a variation process. By varying the results of game actions to be advantageous or unfavorable to the user in this way, it is possible to reduce the bias in demand for game play compared to the case where no variation processing is performed.

Further, in the above example, when the demand for game play is predicted to decrease, the fluctuation processing unit 205 performs processing for giving preferential treatment to the compensation for game actions or the results of game actions (hereinafter referred to as "preferential treatment"). ) is executed as a variable process. The preferential treatment is, for example, a process that reduces the compensation for a game action or a process that makes it easier to obtain a result with high scarcity value when a game action is performed.

In addition, when it is predicted that the demand for game play will increase, the variation processing unit 205 changes the processing for treating the compensation of the game action or the result of the game action (hereinafter referred to as "disrespect processing"). Execute as a process. The cold treatment is, for example, a process that increases the compensation for a game action or a process that makes it difficult to obtain a result with high scarcity value when a game action is performed. By executing these preferential treatment and cold treatment, users can be guided against the trend of demand.

[others]
In the embodiment, the prediction data is data for predicting the number of users who will play the game, but the prediction data is not limited to this. For example, data for predicting the load on the game management device 2, which is a server that provides games, may be used as the prediction data. The load on the game management device 2 is expressed, for example, by the amount of resources used when the game management device 2 performs game processing. The amount of resources used is expressed by, for example, CPU usage rate, memory usage rate, number of times of reading and writing of storage, and the like.

FIG. 12 is a diagram showing an example of prediction data. In the example of FIG. 12, prediction data indicating the relationship between prediction elements, play results, and server load is shown. For example, when "holding a single-play event" is a prediction element, it is shown that the "number of times a single quest is played" increases by M1% during peak times, and increases by M2% during off-peak times (M2<M1).

Peak hours are the times when game play is most intense, and off-peak hours are other times. A single quest is a quest in which single-player users can participate. In single play, the game management device 2 does not need to synchronize between users, and the proportion of processing in the game device 3 is larger than in multiplayer, so even if the number of plays increases, the load on the server (game management device 2) will be reduced. is "small".

It is also shown that the "number of single play gachas" increases by M3% within the elapsed time T1 after the event, and increases by M4% after the elapsed time T1 after the event (M4<M3). . There is a tendency for the number of gachas to increase at the time of an event, and this tendency is particularly noticeable at the beginning of the event (within elapsed time T1). Gacha does not require much time to process, but the processing load increases in proportion to the number of times it is played, so the server load is set to "medium".

Furthermore, it is shown that the "number of times multi-quests have been played" decreases by M5% during peak hours, and decreases by M6% during off-peak hours (M6<M5). A multi-quest is a quest in which multiplayer users can participate. In multiplay, the game management device 2 needs to synchronize between users, and the proportion of processing by the game management device 2 is larger than in single play, so even if the number of plays decreases, the server load remains "heavy". It becomes.

In addition, the "peak time" and "off-peak time" that classify play results as described above, and the elements indicating the time "within elapsed time T1" and "after elapsed time T1" from the event, respectively, are based on the game. It affects the demand for play and is one of the forecasting factors. As described above, the prediction generation unit 203 generates prediction data for predicting the server load based on the prediction elements of "single-play event holding", "peak", and "elapsed time since event holding". The fluctuation processing unit 205 executes fluctuation processing so as to offset the trend of game play demand predicted by the prediction data generated in this way.

In the example of FIG. 12, the variation processing unit 205 executes variation processing using "single play event holding" as a variation condition. When this fluctuation condition is satisfied, the fluctuation processing unit 205 executes, as a fluctuation processing, a process of increasing the consumption stamina of a single quest by N1% during peak hours and by N2% during off-peak times (N2<N1), for example. . This suppresses the increase in single-player users and offsets the demand trend. Note that the fluctuation processing unit 205 may offset the demand trend by reducing the reward for clearing the quest instead of increasing the consumed stamina.

In addition, the fluctuation processing unit 205 increases the price of single-play gacha by N3% at the beginning of the event (within elapsed time T1), and increases it by N4% after that (after elapsed time T1) (N4<N3). By executing this process as a variable process, trends in demand are offset. In addition, instead of increasing the consideration for gacha, the fluctuation processing unit 205 adjusts the lottery probability, decreases the bonuses given in gachas, decreases the bonuses given when purchasing virtual currency for gachas, etc. to increase demand. Trends may be offset.

Further, the variation processing unit 205 does not perform variation processing regarding multi-quests. This is because even if a single-play event is held, the server load due to multi-play is still greater than that from single-play. If single-player users are induced to play multiplayer in this state, users with a small server load will be converted to users with a large server load, and the server load will actually increase. Therefore, as described above, by not executing variable processing related to multi-quests even when a single-player event is held, it is possible to prevent the server load from becoming unbalanced.

Furthermore, when "holding a multiplayer event" is a prediction element, it is shown that "number of times a single quest is played" decreases by M7% during peak times, and decreases by M8% during off-peak times (M8<M7). As mentioned above, single play requires a larger proportion of processing on the game device 3 than multiplayer, so even if the number of plays decreases, there is not much difference in the server load compared to when the number of plays increases, and the server load is "small". ” remains.

It is also shown that the "number of times multi-quests have been played" increases by M9% during peak times and by M10% during off-peak times (M10<M9). As mentioned above, in multi-play, the proportion of processing by the game management device 2 is larger than in single-play, so as the number of plays increases, the server load increases, so the load on the server (game management device 2) increases. ” remains.

In the example of FIG. 12, the variation processing unit 205 also executes variation processing using “holding a multiplayer event” as a variation condition. When this variation condition is satisfied, the variation processing unit 205 executes, as a variation process, a process of reducing the consumption stamina of a single quest by N7% during peak hours and by N8% during off-peak hours (N8<N7), for example. . This has encouraged single-player user growth and offset demand trends. Note that the fluctuation processing unit 205 may offset the demand trend by increasing the reward for clearing the quest instead of decreasing the consumed stamina.

Further, the variation processing unit 205 executes, as a variation process, a process in which, for example, the stamina consumption of the multi-quest is increased by N9% during peak times and by N10% during off-peak times (N10<N9). This suppresses the increase in the number of multiplayer users and offsets the demand trend. Note that the fluctuation processing unit 205 may offset the demand trend by reducing the reward for clearing the quest instead of increasing the consumed stamina.

The prediction data shown in FIG. 12 is based on the height of the server load in the past first period (duration of single-play or multiplayer events that have already been held), This is data for predicting the height of the server load during a play or multiplay event period. Fluctuation processing is executed to offset the demand trends predicted by this forecast data, thereby eliminating imbalances in server loads over a certain length of time in the future (period of scheduled events). It can be reduced.

In addition, the prediction data shown in FIG. 12 is based on the number of users playing by game behavior (single play and multiplayer) in the first period and the load on the server due to the execution of game behavior. This is data for predicting the height of the load. By executing fluctuation processing to offset the demand trend predicted by this prediction data, the user's game behavior is guided from a game behavior with a high load (multiplayer) to a game behavior with a low load (single play). can do.

In the embodiments described above, in-game events are used as prediction elements, but the invention is not limited to this. The prediction element may be the timing at which an actual event that affects the demand for game play occurs (hereinafter referred to as "impact timing"). In this case, the fluctuation processing unit 205 determines that the fluctuation condition is satisfied when the influence period is included in the second period in the future in which the height of the server load is predicted based on the prediction data.

FIG. 13 is a diagram showing another example of prediction data. In the example of FIG. 13, for example, if "rainy day" is a prediction factor, there is a play record in which the "average number of game active users" increases, and the load on the server (game management device 2) in that case is "medium". It has been shown that there is. Thereby, the prediction generation unit 203 generates prediction data that predicts the server load based on the prediction element "rainy day." The fluctuation processing unit 205 executes fluctuation processing so as to offset the trend of game play demand predicted by the prediction data generated in this way.

For example, the fluctuation processing unit 205 obtains the announcement date of the rainy season from a weather forecast service on the Internet, and determines that the fluctuation conditions are satisfied for one month from the announcement date. When this variation condition is satisfied, the variation processing unit 205 executes, as a variation process, a process of increasing the stamina consumption of a single quest by N11% and increasing the stamina consumption of a multi-quest by N12% (N11<N12), for example. do. By suppressing the increase in single-player users and more strongly suppressing the increase in multiplayer users, which has a greater impact on demand, this will offset the demand trend of an increase in users playing games during rainy weather. ing.

In addition, when "one week from payday" is the prediction factor, there is a play record where "number of gacha executions" and "number of virtual currency purchases" increase, and in those cases the load on the server (game management device 2) is " ``Medium'' and ``Small''. Thereby, the prediction generation unit 203 generates prediction data that predicts the server load based on the prediction element "one week from payday." The fluctuation processing unit 205 executes fluctuation processing so as to offset the trend of game play demand predicted by the prediction data generated in this way.

For example, the fluctuation processing unit 205 determines that the fluctuation conditions are satisfied for one week from the general bonus payment date or the bonus payment date registered by the user. When this fluctuation condition is satisfied, the fluctuation processing unit 205 performs a fluctuation processing such as increasing the price of the gacha by N13% and decreasing the cost or quantity of the bonus when purchasing virtual currency for the gacha by N14%. Run as . This suppresses the purchase of gacha and offsets the demand trend where the amount of gacha purchased increases after bonuses are paid.

In addition, when the prediction factor is ``the date of a high-profile sporting event,'' there is a play history in which the ``average number of game active users'' decreases, and the ``number of gacha runs'' and ``number of virtual currency purchases'' increase. It is shown that the load on the server (game management device 2) in the case of 1 is "small", "medium", and "small". Thereby, the prediction generation unit 203 generates prediction data that predicts the server load based on the prediction element of "highly-attention sporting event date." The fluctuation processing unit 205 executes fluctuation processing so as to offset the trend of game play demand predicted by the prediction data generated in this way.

For example, the fluctuation processing unit 205 determines that the fluctuation condition is satisfied during a period in which an event with a predicted audience rating of M15% or more provided by a television station or the like is being held. When this variation condition is satisfied, the variation processing unit 205 executes, for example, a process of reducing the consumption stamina of single quests and multi-quests by N15% as a variation process. This encourages more Quest play and offsets the demand trend of less Quest play during high profile sporting events.

In addition, when the above fluctuation conditions are met, the fluctuation processing unit 205 performs a process of increasing the price of the gacha by N16% or decreasing the cost or quantity of the bonus when purchasing virtual currency for the gacha by N18%. Execute as variable processing. This offsets the demand trend where gacha purchases increase during high-profile sporting events due to the celebratory or festive mood.

As mentioned above, if there are multiple times when an in-game event will be held and multiple times when it will have an impact, these times may overlap. In that case, the variation processing unit 205 may add values that vary by variation processing, may use a maximum value, or may use an average value.

The fluctuation processing unit 205 does not execute the fluctuation processing after the game action becomes possible to execute, but before the reference period has elapsed, regardless of the demand trend predicted by the prediction data, and after the reference period has elapsed. may perform variation processing. For example, when events are frequently held in a game, only the compensation or result of a changed game action is provided, and the user may not be aware of the reference value. If the reference value is not recognized, the effect of guiding the user with the price or result after the change may be weakened. Therefore, by securing the reference period as described above, compared to the case where there is no reference period, it is easier for users to recognize the standard of consideration or results, and the user guidance effect is prevented from decreasing. I can do it. The reference period may be a fixed period such as "3 days" or "1 week", or may be a fixed period such as 10% of the event period to be held, 15% of the expected rainy season period, 20% of the DP period, etc. It may be set as a period according to a period or a DP period.

FIG. 14 is a diagram showing the history of the fluctuation processing. In FIG. 14, a graph is shown in which the vertical axis shows the compensation for game action and the horizontal axis shows time. In this figure, the vertical axis shows the compensation for each game action as a relative value of the compensation in the base period. Although the horizontal axis indicates the start time of each event, the changes in consideration for each game action do not have to occur at the same time. In the example of FIG. 14, first, a raid battle event that is a multiplayer event is being held.

The fluctuation processing unit 205 does not execute the fluctuation processing during the initial reference period of the event period, and allows the user to recognize the reference value of each consideration (consumed stamina, gacha consideration). Then, after the reference period has elapsed, the fluctuation processing unit 205 executes fluctuation processing to fluctuate each consideration. During this event period, when the demand is 5, the fluctuation processing unit 205 does not perform the fluctuation processing on the gacha consideration if the rainy season has started, as shown in the example of FIG.

Next, before the rainy season ends, the conditions for variation depending on the bonus payment date are satisfied. In this case as well, the variation processing unit 205 does not perform variation processing based on the bonus pay date during the initial reference period. During this standard period, the standard value within the event period of the bonus payment date will be applied to the gacha consideration and consumption stamina. In this case, the reference value is applied to the gacha price and consumed stamina immediately before the start of the event called the bonus payment day after the fluctuation process due to the start of the rainy season has been executed. Note that a common reference value may be applied before the variation processing in any period is applied.

Immediately before the bonus payment date, the change processing due to the rainy season has not yet been performed on the gacha consideration, so the standard value is recognized by the user as it is. On the other hand, the consumed stamina of the quest has already fluctuated due to the fluctuation processing at the beginning of the rainy season, and the consumed stamina after the fluctuation is maintained even during the base period. Then, after the reference period has elapsed, the variation processing unit 205 executes a variation process that increases the gacha consideration for both multiplay and single play. Note that, as shown in the example of FIG. 13, the fluctuation processing unit 205 does not perform the fluctuation processing on the consumption stamina on the bonus pay day, so the consumption stamina that fluctuated at the beginning of the rainy season is maintained as it is.

After that, it is assumed that the fluctuation condition that the World Cup is held and an event with a predicted audience rating of M15% or more is being held is satisfied. In this case as well, the fluctuation processing unit 205 does not perform fluctuation processing during the initial reference period. In this reference period, the gacha consideration and quest stamina consumption have already changed due to the fluctuation process, and the gacha consideration and consumption stamina after the change are maintained. Note that, as described above, a common reference value may be applied before the fluctuation processing in any period is applied. Then, after the reference period has elapsed, the variation processing unit 205 executes a variation process that increases the gacha consideration for both multiplayer and single play, and also executes a variation process that reduces the consumed stamina for both multiplayer and single quest. Running.

As described above, by satisfying the fluctuation conditions at various impact periods and executing fluctuation processing according to each period, the imbalance in game play demand is reduced compared to the case where these fluctuation processing is not performed. can do.

Further, the demand for playing the game may be the demand for playing the content included in the game by operating the game medium (player character, etc.) associated with the user. The content included in the game refers to, for example, a group that allows players to recognize breaks in the progress of the game. Content is called by various names depending on the game, such as quest, mission, scenario, stage, etc.

The prediction generation unit 203 divides the user's play performance in units of content, and generates prediction data based on the divided play performance. As a result, for example, when an in-game event is held, the fluctuation processing unit 205 can identify the users who are playing the early quests, the users who are playing the middle quests, and the users who are playing the final quests. With this, it is possible to execute fluctuation processing according to each demand trend. The fluctuation processing unit 205 also handles fluctuations according to the demand trends of users who are playing, for example, quests that mainly consist of searching for items, quests that mainly involve fighting monsters, and quests that mainly involve progressing through scenarios. Processing may be executed. In either case, it is possible to reduce demand imbalance in units of played content. In addition, by dividing a user's play history based on the number of sessions and generating predictive data based on the number of sessions, it is possible to determine play trends such as whether the user is an avid player or a user who only logs in or plays gacha. You may also perform variation processing based on this.

In each of the above embodiments, by providing profit to the user in advance through fluctuation processing, the user is guided to disperse the demand for game play. However, if the demand is dispersed due to the user's effort, You may also provide benefits.
FIG. 15 is a diagram showing another example of the functional configuration of the control section of each device. In the example shown in FIG. 15, the game management device 2 includes a return processing section 206 in addition to each section shown in FIG.

The rebate processing unit 206 first predicts the demand trend based on the prediction data specified by the prediction execution unit 204, and then determines whether the rebate condition is satisfied based on the demand record. The return condition is satisfied, for example, when the demand performance achieves the demand target value. The target value of demand is, for example, determined to be a value indicating a demand for which the load on the server is smaller than the demand predicted by the prediction execution unit 204. The value indicating demand is, for example, a value indicating server load such as CPU usage rate.

If the return processing unit 206 determines that the return conditions are satisfied, it executes a return process that returns at least a portion of the profit obtained when the change processing unit 205 executes the change processing. The rebate processing unit 206 executes rebate processing for the users involved in the demand performance. For example, when a multi-play event is held, the return processing unit 206 identifies a user who plays a single play as a user who is involved in the demand performance.

FIG. 16 is a diagram showing another example of the game screen. In the example of FIG. 16, the game processing unit 201 causes the game device 3 to display the game screen G21. The game screen G21 is a screen that notifies the user of the conditions under which the redemption process is performed. The game screen G21 shows the title "Off-peak play return campaign!", guide information E1, current server load information F1, and target server load information F2. Guide information E1 provides an overview of the campaign, ``If the server load in the morning falls within H1% of the server load during peak hours, a portion of the stamina earned by playing during off-peak hours will be returned!'' ing.

In the example of FIG. 16, it is displayed that the current server load information F1 is "H2%" and the target server load information F2 is "H1%". In other words, increasing "H2%" to "H1%" or more indicates the condition for executing the return process. In this campaign, as the number of users who play during the morning hours when the server load is low increases and the number of users who play during peak hours decreases, the server load information F2 changes to a larger value, increasing the target H1%. becomes easier to achieve.

FIG. 17 is a diagram showing another example of the game screen. In the example of FIG. 17, the game processing unit 201 causes the game device 3 to display the game screen G22. The game screen G22 is a screen displayed while a user participating in the campaign is playing. On the game screen G22, a character string "*During the off-peak play period!" and a quest list C22 are displayed. That is, the game screen G22 is a screen displayed during play during the off-peak period.

The quest list C22 shows that the stamina consumption of quest "1" is "20" and the load coefficient is "0.8", and the stamina consumption of quest "2" is "30" and the load coefficient is "2.0". ”. The load coefficient is a value for converting the value of consumed stamina into server load. Quest "1" is a single-player quest and the load on the server is small, so it has a small value of "0.8". On the other hand, quest "2" is a multiplayer quest and has a large load on the server, so it has a large value of "2.0".

During off-peak periods, the more you play and put a load on the server, the more likely it will be to approach the server load during peak periods. In other words, playing quest "2" contributes more to load distribution than playing quest "1". Therefore, the game screen G22 displays an image indicating that quest "2" has a "larger contribution!" The user participates in the campaign while looking at the game screens G21 and G22, and adjusts the playing time of the game so as to eliminate uneven server load.

Assume that as a result of each user adjusting their playing time, the actual demand reaches the target demand at the end of the campaign period. In this case, the return processing unit 206 determines that the return condition is satisfied and executes the return processing. For example, the rebate processing unit 206 extracts users who played the game during off-peak periods as users who were involved in the demand performance. The refund processing unit 206 executes a process of returning a predetermined percentage of the stamina consumed during the off-peak period to the extracted user as a refund process.

Note that the return processing unit 206 may fix the ratio of stamina to be converted at a predetermined value, or may increase the ratio as the consumption amount increases. Further, the refund processing unit 206 may execute the refund processing for all users who were involved in the demand performance, or may execute the refund processing for only a portion of the users who have made a high degree of contribution, for example. In either case, users can be encouraged to actively participate in efforts to disperse demand for game play.

The overall configuration shown in FIG. 1 is an example, and the present invention is not limited to this. For example, the game management device 2, the application distribution device 5, and the EC management device 6 may be integrated into one or two devices, or may be distributed among four or more devices. Additionally, these devices may be replaced by cloud computing systems.

Moreover, the functional configuration shown in FIG. 2 is also an example, and is not limited to this. For example, the functions of the game management device 2 and the EC management device 6 may be realized by one device, or conversely, the functions of the game management device 2 may be realized by being distributed among two or more devices. Furthermore, two functions may be integrated into one function, or one function may be decomposed into two or more functions. In short, any configuration may be adopted as long as the game system 1 as a whole implements functions corresponding to the functions shown in FIG. 2 .

The aspect of the embodiment described above may be an information processing apparatus. The information processing device includes each part of an information processing system such as the game system 1. Moreover, the aspect of the embodiment described above may be an information processing method. The information processing method includes each part of a similar information processing system. Moreover, the aspect of the embodiment described above may be a program. The program causes the computer to execute each step of the information processing system.

<Additional notes>
Furthermore, each aspect described below may be provided.

(2) In the information processing system, the data is data for predicting a load on a server that provides the game.

According to this aspect, it is possible to reduce the unbalanced load on the servers.

(3) In the information processing system, the data is data for predicting the height of the load on the server in a second period in the future based on the height of the load on the server in the past first period. some stuff.

According to this aspect, it is possible to reduce the unbalanced load on the server over a period of a certain length.

(4) In the information processing system, the data is calculated based on the number of users playing each game action in the first period and the load on the server due to execution of the game action. Data for predicting load height.

According to this aspect, it is possible to guide the player from a game action with a large load to a game action with a light load.

(5) In the information processing system, the element is a time when an actual event that affects the demand occurs, and the fluctuation condition is satisfied when the time is included in the second period. .

According to this aspect, it is possible to reduce the influence of real events on demand for games.

(6) In the information processing system, in the fluctuation processing step, after the game action becomes executable, the fluctuation processing is executed regardless of the predicted demand trend before the reference period has elapsed. First, the variation process is executed after the reference period has elapsed.

According to such an aspect, it is possible to make it easier for the user to recognize the standard of consideration or result.

(7) In the information processing system, in the variation processing step, when the demand is predicted to decrease, processing for giving preferential treatment to the consideration or the result is executed as the variation processing, and the demand is reduced. If an increase is predicted, a process for discounting the consideration or the result is executed as the variation process.

According to such an aspect, users can be guided against the trend of demand.

(8) In the information processing system, the demand is a demand for playing content included in the game by operating game media associated with the user.

According to this aspect, it is possible to reduce demand bias in units of played content.

(9) In the information processing system, in the return processing step, after the demand trend is predicted based on the identified data, if the return condition is satisfied based on the demand performance, the fluctuation processing is executed. A return process is executed to return at least a part of the profit obtained when the demand is met, and the return process is executed to a user who was involved in the demand performance.

According to this aspect, it is possible to encourage users to actively participate in demand distribution.

(10) An information processing device configured to execute each step of the information processing system.

(11) A program that causes a computer to execute each step of the information processing system.
Of course, this is not the case.
Furthermore, the embodiments and modifications described above may be implemented in any combination.

Finally, although various embodiments according to the present disclosure have been described, these are presented as examples and are not intended to limit the scope of the disclosure. The new embodiments can be implemented in various other forms, and various omissions, substitutions, and changes can be made without departing from the gist of the disclosure. The embodiments and their modifications are included within the scope and gist of the disclosure, as well as within the scope of the disclosure described in the claims and its equivalents.

1: Game system 2: Game management device 3: Game device 5: Application distribution device 6: EC management device 11: Communication network 23: Control unit 33: Control unit 201: Game processing unit 202: Setting management unit 203: Prediction generation unit 204: Prediction execution unit 205: Fluctuation processing unit 206: Reduction processing unit 301: Game processing unit 302: Operation reception unit

Claims (10)

An information processing system,
The information processing system,
In the game processing step, a game process related to a game played by the user is executed in accordance with a user's instruction, and the game process includes a single-play game process in which one user plays the game, and a game process in which two or more users play the game. It includes multiplayer game processing where users play the same game at the same time.
In the identifying step, data for predicting a trend in demand for playing the game is identified, the demand being a demand among a group of users playing the game, and the prediction affecting the demand. is carried out for each of the single play and the multiplayer gameplay based on the elements to be played,
In the variation processing step, a variation process is executed when the element used for prediction based on the identified data satisfies a variation condition, and the variation process includes a user included in the group performing a game action in the game. or giving preferential treatment to the case where the single play is performed compared to the case where the multiplayer is performed, or the result of the game action is given preferential treatment when the multiplayer is performed compared to the case where the single play is performed. An information processing system comprising processing to vary the demand trend so as to offset a predicted trend in demand when the variation condition is satisfied by giving preferential treatment to cases where the variation condition is satisfied. An information processing system,
The information processing system,
The game processing step executes game processing related to the game played by the user in response to instructions from the user;
In the identifying step, data for predicting a trend in demand for playing the game is identified, the demand being a demand among a group of users playing the game, and the prediction affecting the demand. It is done based on the factors that
In the variation processing step, a variation process is executed when the element used for prediction based on the identified data satisfies a variation condition, and the variation process includes a user included in the group performing a game action in the game. or a process of varying the result of the game action so as to offset a predicted trend in demand when the variation condition is satisfied, compared to a case where the variation condition is not satisfied,
In the fluctuation processing step, after the execution of the game action becomes possible, the fluctuation processing is not executed before the reference period has elapsed, regardless of the predicted demand trend, and after the reference period has elapsed. executes the variation processing,
Information processing system. An information processing system,
The information processing system,
The game processing step executes game processing related to the game played by the user in response to instructions from the user;
In the identifying step, data for predicting a trend in demand for playing the game is identified, the demand being a demand among a group of users playing the game, and the prediction affecting the demand. It is done based on the factors that
In the variation processing step, a variation process is executed when the element used for prediction based on the identified data satisfies a variation condition, and the variation process includes a user included in the group performing a game action in the game. or a process of varying the result of the game action so as to offset a predicted trend in demand when the variation condition is satisfied, compared to a case where the variation condition is not satisfied,
In the rebate processing step, after the demand trend is predicted based on the identified data, if the rebate condition is satisfied based on the demand performance, the profit obtained when the fluctuation process is executed is calculated. executing a return process for returning at least a portion of the money; the return process is executed for users involved in the demand performance;
Information processing system. In the information processing system according to any one of claims 1 to 3 ,
An information processing system, wherein the data is data for predicting a load on a server that provides the game. The information processing system according to claim 4 ,
The information processing system is characterized in that the data is data for predicting the height of the load on the server in a second period in the future based on the height of the load on the server in the past first period. The information processing system according to claim 5 ,
The data is for predicting the height of the load on the server in the second period based on the number of users playing by game action in the first period and the load on the server due to execution of the game action. An information processing system that is data. In the information processing system according to any one of claims 1 to 3 ,
The information processing system,
In the variation processing step, when the demand is predicted to decrease, processing for giving preferential treatment to the consideration or the result is executed as the variation processing, and when the demand is predicted to increase, is an information processing system that executes a process for treating the consideration or the result as the variable process. In the information processing system according to any one of claims 1 to 3 ,
The information processing system, wherein the demand is a demand for playing content included in the game by operating game media associated with the user. An information processing device,
An information processing device configured to execute each step of the information processing system according to any one of claims 1 to 3 . A program,
A program that causes a computer to execute each step of the information processing system according to any one of claims 1 to 3 .