JP7624582B2 - Information processing device, information processing method, and program - Google Patents

Description

The present invention relates to an information processing device, an information processing method, and a program.

It is important for game providers to keep users playing the game and not let them get bored. For this reason, they may manage the game play status of users of the game, and take measures to encourage users who have not played the game for a certain period of time to play the game again.

For example, as described in Patent Document 1, an event (an event within the game) may be held to encourage users who have not played a certain game for a long time to play the game again. This makes it possible to draw users who have not played for a long time back into the game.

JP 2018-187400 A

As part of a measure to attract users who have not played for a long time back to the game, attributes will be set for users according to whether they have not played the game for a specified period of time, and if a user with a specific attribute plays the above-mentioned event and meets certain conditions, a process such as granting a reward will be executed. In such a case, users hoping for the desired process to be executed will maintain their specific attribute until the event begins and participate in the event.

However, if a user with a particular attribute plays the game at a specific time before the event is held and the attribute changes as a result, the desired processing will not be executed even if the user attends the event thereafter. In such a case, it will be difficult to attract users who have not played the game for a certain period of time back to the game by holding an event, and there is a risk that the purpose of holding the event will not be achieved.

The present invention aims to provide an information processing device, information processing method, and program that can avoid missing an opportunity to execute a desired process in a configuration in which the content of the process executed during an in-game event is determined according to the game play situation before the event begins.

An information processing device according to one embodiment of the present invention includes a change unit that changes the attributes of a target user depending on whether or not a target user playing a game has not performed a predetermined play of the game for a predetermined period of time, and a processing unit that executes processing according to the attributes of the target user when the target user plays the game during an event period in the game, and is characterized in that the change unit does not change the attributes of the target user even if the target user performs a predetermined play from a predetermined point in time before the event period until the event is held.

According to one aspect of the present invention, when the content of the processing to be executed during an in-game event is determined based on the game play situation before the event is held, it is possible to prevent the target user from missing the opportunity to execute the desired processing.

FIG. 13 is a diagram showing a schedule for an event. 1 is a conceptual diagram of a gaming communication system including an information processing device according to one embodiment of the present invention. FIG. 2 is a diagram illustrating the hardware configuration of each of a terminal and an information processing device according to an embodiment of the present invention. FIG. 2 is an explanatory diagram of functions of a terminal according to an embodiment of the present invention. FIG. 13 shows how the home screen displayed during the game changes as attributes are changed. FIG. 2 is an explanatory diagram of functions of an information processing device according to an embodiment of the present invention. FIG. 13 is a diagram showing conditions for granting rewards. FIG. 13 is a diagram showing types of rewards. FIG. 13 is a diagram showing a process flow relating to playing an event (part 1). FIG. 13 is a diagram showing a process flow relating to playing an event (part 2).

The information processing device, information processing method, and program of the present invention will be described below with reference to a preferred embodiment (hereinafter, referred to as the present embodiment) shown in the attached drawings.

The embodiment described below is merely one of the specific examples given to facilitate understanding of the present invention, and is not intended to limit the present invention. In other words, the present invention may be modified or improved from the embodiment described below without departing from the spirit of the present invention. Naturally, the present invention also includes its equivalents.

The screen examples shown in the drawings referenced in the following explanation are merely examples, and the screen configuration examples, the content of the information displayed, and the GUI (Graphical User Interface), etc., can be freely designed according to the system design specifications and user preferences, and can be changed as appropriate.

[About the game according to this embodiment]
Prior to describing the information processing device according to this embodiment, a specific game (hereinafter simply referred to as a "game") that can be played through the information processing device will be described.

A game is game content that can be played by a user operating a game terminal, and more specifically, is an online game that uses data communication. Here, online games can include, for example, social games that can be used with only a web browser and a SNS (Social Networking Service) account.

When playing a game, the user performs a login operation on his/her own terminal. The login operation is an operation performed in order to play a game, and corresponds to, for example, an operation for starting an application program for the game, or an operation for inputting login information (specifically, a user name and a password, etc.). When the login operation is performed, communication begins between the information processing device according to this embodiment and the user's terminal.

After logging in, the user can play game components called quests or stages (hereafter referred to as quests). A quest is an in-game event that usually has a set time limit and is played with the goal of clearing it (satisfying the conditions for achievement) within the time limit.

In this embodiment, a user can play a quest alone, or can play the same quest together with other users. That is, multiple users can play the same quest together at the same time. Such collaborative play (multiplay) is realized by one user acting as a host and other users acting as guests.

A host is one form of participation in cooperative play, and invites guests to play quests together with the guests. When inviting guests, the user who will be the host selects the quest to be played on a selection screen (not shown), specifies cooperative play, and waits for applications from other users.
The host also has the authority to instruct the start of joint play and can start joint play at a timing determined by the host. In this embodiment, at least two users (in other words, a host and one or more guests) are required to start joint play.

A guest is a form of participation in which a user applies for a host's invitation and plays a quest together with the host. When applying for a invitation from a host, a user who is to become a guest selects the quest to be played on a selection screen (not shown), and if there is a host who is recruiting guests for the selected quest, the user specifies that host and applies to become a guest (for example, by touching the host's icon displayed on the screen).

Cooperative play can be realized using known communications technology. To be more specific, one user acts as a host and recruits guests. When other users respond to the recruitment, a communications path for cooperative play is established, and the data communication required for cooperative play is then carried out according to a known communications method.

In addition, in games, events are held according to a predetermined schedule. During an event, players can play quests (stages) that are specific to that event. Information about the event (for example, the event period, etc.) is usually announced through the home screen displayed within the game, or using media such as television or the Internet.

In this embodiment, the event is held for the purpose of encouraging users to play the game. More specifically, an event planned for the purpose of encouraging users with specific attributes to play the game is held for a predetermined period of time.

Here, the user's attribute is determined according to whether or not the user has not performed a specified play of the game for a specified period of time. If the user has not performed a specified play for a specified period of time, the user's attribute is a first attribute, and if the user has not performed a specified play for a specified period of time, the user's attribute is a second attribute.
"Predetermined play" includes playing a quest in a game, playing a quest together or alone, logging into a game, etc. Also, playing a game so that a status value (e.g., user rank, described later) is equal to or greater than a reference value also falls under "predetermined play".
The "predetermined period" is any period, and in this embodiment, it is set to N days (N is a natural number) as an example.
"A state in which a predetermined play has not been performed for a predetermined period of time" corresponds to, for example, a state in which N days have passed since the last login, or since the last time a quest was played (or the last time a cooperative play was performed). Also, a state in which a status value (for example, a user rank, described below) does not reach a reference value for a period of N days is also included in "a state in which a predetermined play has not been performed for a predetermined period of time". Furthermore, a state in which a player has never played a game before is also included in "a state in which a predetermined play has not been performed for a predetermined period of time".
In this embodiment, a state in which N days have elapsed since the last login, or a state in which the player has never played the game and has never logged in, is defined as a "state in which a specified play has not been performed for a specified period of time."

In this embodiment, the attributes are classified into three types: "defective", "new", and "existing".
Churn is an attribute when N days have elapsed since the last (most recent) login. The attribute may be churn when N days have elapsed since the last time a cooperative play was performed. Alternatively, for a user who has only logged in and not played a quest, the attribute may be churn when N days have elapsed since the user last played a quest.
The "new" attribute is for a user who has never played the game before and has never logged in to the game. The "dismissed" and "new" correspond to the first attribute that satisfies the above-mentioned predetermined condition.
The existing attribute is an attribute when the time elapsed since the last login has not reached N days. The existing attribute corresponds to the second attribute that does not satisfy the above-mentioned predetermined condition.

The classification of attributes is not limited to the three types mentioned above (i.e., defected, new, and existing). For example, an attribute when the user rank does not reach a reference value may be a first attribute, and an attribute when the user rank reaches the reference value may be a second attribute. User rank is a user's status value that increases according to, for example, the number of times a quest is cleared.

In this embodiment, an event is held for the purpose of inducing users whose attributes are lapsed or new to the game. In other words, by holding the event, it is possible to arouse interest or concern in the game among users whose attributes are lapsed or new, and in particular to bring users whose attributes are lapsed back to the game.
In the following description, "playing an event" means playing a quest for the event.

In this embodiment, in order to effectively achieve the purpose of the event described above, if a user meets a predetermined condition during the event period, the user is given a reward. Here, the predetermined condition is that the user plays together with other users and clears the event quest together with the other users. However, this is not limited to this, and the condition may be, for example, that the user plays the event together with other users, that the number of times the event quest has been cleared reaches a predetermined number, or that the number of times the user logs in during the event period reaches a predetermined number.

Regarding the conditions for granting rewards, if a user with a defecting or new attribute cooperates with another user to complete an event quest, a reward will be granted to the new or new attribute user. Also, if a user with an existing attribute acts as a host and cooperates with another user with a defecting or new attribute as a guest to complete an event quest, a reward will be granted to the existing attribute user.

Rewards are items and characters (hereinafter referred to as items, etc.) that can be used in the game, or valuable items that can be exchanged for items, etc. (for example, virtual currency that can be used in the game, or items necessary to conduct a lottery for items, etc. in the game, etc.). Rewards may also be given in the form of effects that can be enjoyed temporarily while the game is in progress (for example, an effect such as increasing a character's status value). Rewards may also be given in the form of coupons that can be used at real stores, etc.

Note that "granting a reward" means providing the user to whom the reward is to be granted with data for using the reward in the game or at a real store, etc. For example, when granting a reward that can be used in the game, such as an item, value that can be exchanged for an item, or efficacy, data for playing the game after obtaining the reward is provided. When granting a reward that can be used at a real store, such as a coupon, text data or image data for presenting the reward at the store, etc. is provided.

Users who expect to receive rewards in an event must either play the event with their own attributes of lapsed or new, or play the event together with other users with attributes of lapsed or new.

On the other hand, an event is announced before the event is held. Specifically, as shown in FIG 1, an event announcement period is set before the event is held, and the event is announced within this announcement period.
In this embodiment, the event period is set to, for example, one week to several weeks, or one month to several months, and the event announcement period is set to be shorter than the event period, for example, one day to several days, or one week to several weeks.

In the schedule shown in Figure 1, let us say that a user with the attribute of churn happens to play or log into the game at a certain point during the event announcement period (specifically, at the point indicated by the cross in Figure 1). In that case, the user's attribute will change from churn to existing. Even if the user plays the event after that, he or she will not be given a reward unless they play together with another user with the attribute of churn or new. Missing an opportunity to receive a reward in this way may discourage users from wanting to play the event, and as a result, the purpose of holding the event may not be achieved.

Therefore, in this embodiment, attribute changes that accompany game play during the event announcement period are forbidden. In other words, even if the user performs a specified play (e.g., playing a quest) from the start of the event announcement (the first day of announcement), which is a time point (predetermined time point) before the event period, until the event starts, the user's attributes do not change and remain the same as at the start of the announcement. In other words, the user's attributes at the start of the event are determined by the attributes at the start of the announcement. As a result, the user can maintain the attributes at the start of the announcement until the event starts and participate in the event with those attributes; for example, a user whose attributes are defecting or new at the start of the announcement can play the event with those attributes.

Here, the attribute at the time when the notification starts is determined depending on whether or not the time elapsed since the last login date and time reaches N days at that time (including a state where the user has never logged in before). If the time elapsed has reached N days, the attribute at that time will be churn or new. Conversely, if the time elapsed has not reached N days, the attribute at that time will be existing.
In addition, to add a supplement to the method of determining the attribute, even if the attribute is an existing attribute at the time of starting the announcement, there may be cases where the above-mentioned elapsed time reaches N days during the announcement period. In this embodiment, even in such a case, as long as the attribute is an existing attribute at the time of starting the announcement, the attribute is maintained as it is until the event is held. However, this is not limited to this, and when the above-mentioned elapsed time reaches N days during the announcement period, the attribute may be changed to defection at that point.

In addition, in this embodiment, when a user whose attribute is a defector or new at the start of an event plays an event and meets a predetermined condition, the user's attribute changes to the existing one, and the user's attribute is maintained as the existing one for the rest of the event period. Here, the predetermined condition is the same as the condition for granting a reward, and specifically, the user plays together with another user and clears a quest for the event together with the other user. However, this is not limited to this, and may be, for example, a condition that the event is played together with another user, a condition that a quest for the event has been cleared a predetermined number of times, or a condition that the number of logins during the event period has reached a predetermined number.

Note that even if an attribute is changed to an existing attribute during the event period, there may be cases in which the time elapsed since the last login date and time reaches N days during the subsequent event period. In this embodiment, even in such a case, since the attribute was changed to an existing attribute during the event period, the attribute will remain the existing attribute during the subsequent event period. However, this is not limited to this, and if the time elapsed reaches N days during the event period after the attribute was changed to an existing attribute, the attribute may be changed from existing to defected at that point.

[Game information processing system]
Next, a description will be given of an information processing system for a game (hereinafter, a game system S) including the information processing device according to this embodiment.
In the following, we will focus on one of the users who plays a game using the game system S, and refer to that user as the "target user," while the other users as "other users."

The gaming system S is an information processing system constructed for a target user to play a game. In the gaming system S, as shown in Fig. 2, terminals 10 of each user including the target user and a server 12 are communicatively connected via a communication network 14 such as the Internet and a mobile communication network.
In FIG. 2, for convenience of illustration, the number of terminals 10 is three, but this is not limited to this, and the number of terminals 10 may be any number, and when performing joint play of an event, it is sufficient to have at least two terminals 10.

The terminal 10 is a device that is operated by a user to play a game.
The server 12 is an example of an information processing device, which provides data for game progress to the terminal 10 and manages the game progress status and current attributes, etc., for each of multiple users including the target user. In addition, when multiple users play an event together, the server 12 communicates with the terminal 10 of each user and mediates the joint play of the event.
In this embodiment, the server 12 is configured by one computer, but is not limited to this and may be configured by a plurality of computers.

The communication network 14 is a communication line network between the terminal 10 and the server 12, and is mainly composed of the Internet and a mobile communication network, and may also include a LAN (Local Area Network), a WAN (Wide Area Network), an intranet, Ethernet (registered trademark), etc.

[Terminal and server configuration]
The configurations of the terminal 10 and the server 12 will be described with reference to Fig. 3. For convenience of illustration, only one terminal 10 is shown in Fig. 3.

The terminal 10 is a gaming terminal that can be carried by the target user, and specifically may be a smartphone, a mobile phone, a notebook PC, a tablet terminal, a wearable terminal, or a dedicated gaming device with communication capabilities.

As shown in FIG. 3, the terminal 10 has, as hardware devices, a processor 21, a memory 22, a communication interface 23, a storage 24, an input device 25, and an output device 26, and these devices are electrically connected via a bus 27.

In addition, the terminal 10 has installed thereon, as software, a program for an operating system (OS) and an application program for games. The processor 21 executes these programs, allowing the user to play games through the terminal 10.

To be more specific, the target user starts up a game application program on his/her own terminal 10 and performs a predetermined login operation (e.g., pressing a login button). The target user can then proceed through the game by performing operations to progress through the game while watching the play screen displayed on the display screen. Furthermore, if the target user specifies a quest for joint play in the manner described above, he/she can play the quest jointly with other users.

The server 12 is a server computer that distributes game data, and is, for example, a server computer for social games (specifically, an SNS server). As shown in FIG. 3, the server 12 has, as hardware devices, a processor 101, a memory 102, a communication interface 103, a storage 104, an input device 105, and an output device 106, and these devices are electrically connected via a bus 107.

Furthermore, an OS program and an information processing program for games are installed as software in the server 12. These programs correspond to the "programs" of the present invention, and are read by the processor 101 of the server 12.
The processor 101 executes the above program, and the server 12 executes various information processes related to the game as an information processing device for the game. Specifically, by executing the above program, the server 12 distributes game data to the terminal 10 of the target user, monitors the game play status of the target user, and updates the attributes of the target user according to the play status.

Of the hardware devices of the terminal 10 and the server 12, the processors 21 and 101 may be configured with a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), an MCU (Micro Controller Unit), a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), or the like.

The memories 22 and 102 may be configured with semiconductor memories such as a Read Only Memory (ROM) and a Random Access Memory (RAM).
The communication interfaces 23 and 103 may be configured, for example, by a network interface card or a communication interface board, etc. Incidentally, the standard of data communication by the communication interfaces 23 and 103 is not particularly limited, and examples thereof include communication by a wireless LAN based on Wi-fi (registered trademark), communication by a 3G, 4G or 5G mobile communication system, or communication based on LTE (Long Term Evolution), etc.

The storage 24 and 104 are a flash memory, a hard disk drive (HDD), and an SSD.
It may be configured using a solid state drive (Solid State Drive), a flexible disc (FD), a magneto-optical disc (MO disc), a compact disc (CD), a digital versatile disc (DVD), a secure digital card (SD card), a universal serial bus memory (USB memory), or the like.

The input devices 25 and 105 may be, for example, a keyboard, a mouse, or a touch panel. The output devices 26 and 106 may be, for example, a display and a speaker.

[Device Features]
Next, the configuration of the terminal 10 will be described again from a functional perspective with reference to FIG.
4, the terminal 10 has a terminal operation unit 31, a terminal transmission unit 32, a terminal reception unit 33, a terminal storage unit 34, and a terminal display unit 35. These functional units are realized by cooperation between the above-mentioned hardware devices of the terminal 10 and various programs as software installed in the terminal 10. Each functional unit will be described below.

The terminal operation unit 31 accepts a login operation performed by the target user to play the game, or various operations performed by the target user while playing the game. The operations during game play accepted by the terminal operation unit 31 include a designation operation, a selection operation, an application operation, and the like.
The designation operation is an operation for designating either solo play or cooperative play as the play format for a quest. The selection operation is an operation for selecting either host or guest as the participation format for cooperative play. The application operation is an operation for applying to become a guest when another user is recruiting guests as a host.

The terminal-side transmission unit 32 transmits various data related to the game, such as the login date and time of the target user and the content of operations performed by the target user while playing the game, to the server 12 via the communication network 14. The data transmitted by the terminal-side transmission unit 32 includes data indicating the content of each operation, such as the specification operation, selection operation, and application operation, received by the terminal-side operation unit 31.

The terminal-side receiving unit 33 receives various data sent from the server 12 via the communication network 14. The data sent from the server 12 includes data for game progress, data for information notifications, data related to other users participating in joint play, and data on rewards granted to the target user (strictly speaking, data for using the rewards), etc.

The terminal side memory unit 34 stores data received by the terminal side receiving unit 33 from the server 12, and information transmitted by the terminal side transmitting unit 32 to the server 12, etc.

The terminal display unit 35 expands the data received by the terminal receiving unit 33 from the server 12, and displays a game play screen or an information notification screen corresponding to the data on the display of the terminal 10. Screens displayed by the terminal display unit 35 include the home screen shown in FIG. 5, etc.

Regarding the home screen, as shown in FIG. 5, an icon I indicating the attributes of the target user during the event period is displayed on the screen. This icon I changes as the attributes change, and for example, when the attributes change from defection or new to existing, the display state shown in the upper part of FIG. 5 changes to the display state shown in the lower part.

[Server Functions]
Next, the configuration of the server 12 will be described again from a functional standpoint with reference to FIG.
6, the server 12 has a server-side transmitting unit 111, a server-side receiving unit 112, a server-side storage unit 113, a changing unit 114, and a processing unit 115. The processing unit 115 has a reward granting processing unit 116 and a user number determination unit 117. These functional units are realized by cooperation between the hardware devices of the server 12 and various programs as software installed in the server 12. Each functional unit will be described below.

The server-side transmission unit 111 transmits various data related to the game, including data for game progress, to the target user's terminal 10. The data transmitted by the server-side transmission unit 111 includes data for information notification, for example, display data for the home screen including the aforementioned icon I for confirming attributes.

The server-side receiving unit 112 receives various data related to the game sent from the target user's terminal 10, such as data indicating the content of operations performed by the target user while playing the game. The data received by the server-side receiving unit 112 includes, for example, data indicating the date and time when the target user performed a login operation.

The server-side memory unit 113 stores the current attributes of the target user and each of the other users. The server-side memory unit 113 also stores information indicated by the data received by the server-side receiving unit 112, including the target user's last login date and time. Furthermore, the server-side memory unit 113 stores the number of times the target user played the event collaboratively with other users during the event period (hereinafter referred to as the number of collaborative plays).

The change unit 114 changes the attributes of the target user stored in the server-side memory unit 113 depending on the game play status of the target user (i.e., whether or not the target user has not performed a specified play of the game for a specified period of time).
For example, when the target user's attribute is "leaving," when the target user logs in to play a game, the server-side receiving unit 112 receives data indicating the time of login from the target user's terminal 10. The change unit 114 uses this as a trigger to change the attribute of the target user stored in the server-side storage unit 113 from "leaving" to "existing."

Also, as described above, in this embodiment, even if a target user whose attribute is defector or new plays a game during the event announcement period, the change unit 114 does not change the attribute of the target user (postpones the attribute change) and leaves the attribute as defector or new.
Furthermore, when a target user with an attribute of defector or new plays an event together with other users and clears a quest for the event, the change unit 114 changes the attribute of the target user from defector or new to existing. After that, the attribute of the target user is maintained as it is during the event period.

The processing unit 115 executes a predetermined process on the target user when the target user plays a game during the event period. The content of the process executed by the processing unit 115 on the target user differs between when the target user's attribute is defection or new during the event period and when the target user's attribute is existing during the event period.

Specifically, when a target user plays a cooperative game with another user and clears a quest for an event, the reward granting processing unit 116 of the processing unit 115 executes a reward granting process to grant a reward according to the attributes of the target user. The reward granting rules will be explained with reference to FIG. 7. In the case where any of the following cases (1) to (3) applies, the reward granting processing unit 116 executes the reward granting process to grant a reward to the target user.
(1) When a target user whose attributes are a defector or new user becomes a host and plays an event together with another user as a guest.
(2) When a target user with an existing attribute acts as a host and plays an event together with another user with a defected or new attribute as a guest.
(3) When a target user whose attributes are a defector or new user becomes a guest and plays an event together with another user who is a host and is recruiting guests.
7, even if a target user with an existing attribute becomes a host and plays an event together with another user with an existing attribute, the reward granting process is not executed. Also, when a target user with an existing attribute becomes a guest and plays an event together with another user with a defected or new attribute as a host, a reward is granted to the other users, but no reward is granted to the target user.

Returning to the explanation of the reward granting process, the content of the reward granted to the target user in the reward granting process is determined according to the attributes of the target user at that time. The content of the reward also depends on the number of users (including the target user) who played the event together that have attributes of defecting or new users (hereinafter referred to as the number of co-play users).
The content of the reward will be explained with reference to the example shown in Fig. 8. For example, when a target user whose attribute is defector or new plays an event together with other users and clears a quest for the event, the target user is given a reward of "1 item A + 1 item B + reward C." This reward is given only when the target user's attribute is defector or new.
Here, when a defecting or new target user participates in a joint play of an event and clears a quest for the event, the attribute of the target user is changed to the existing attribute accordingly, and the existing attribute is maintained during the event period thereafter. Therefore, the number of times the above-mentioned reward is given during the event period is only one.

Also assume that a target user with an existing attribute becomes a host, and other users with defected or new attributes become guests, playing an event together with the other users to clear a quest for the event. In this case, the user number determination unit 117 of the processing unit 115 determines the number of users with defected or new attributes (hereinafter referred to as the number of cooperative play users) among the multiple users who performed cooperative play. The number of cooperative play users corresponds to the number of other users who played the event together with the target user and who have defected or new attributes.

The reward granting processing unit 116 then grants the target user a reward according to the number of co-play users. For example, if the number of co-play users is two, in the example shown in FIG. 8, a reward for two users (one item A, two items B, and special gift C) is granted.
Incidentally, in the example shown in Fig. 8, the number of co-play users is counted up and carried over to subsequent gameplays. For example, suppose that the number of co-play users at a certain point in time is two, and in the next co-play, the target user plays an event with three other users whose attributes are defectors or new users. In that case, the reward given to the target user is "1 item A + 2 items B + reward C" x 3 people, and the number of co-play users is counted up to 5 (= 2 people + 3 people).
8, when the number of co-play users reaches 5, all of the rewards prepared for the target user will be given. However, there is no need to set a particular limit on the number of rewards given to the target user, and even if there is a limit, the number (i.e., the upper limit of the number of rewards given) may be determined arbitrarily.

[Information processing flow according to this embodiment]
Next, the information processing flow by the gaming system S, particularly the flow related to playing an event, will be described with reference to FIGS.
The process flow described below employs the information processing method of the present invention. In other words, each step in the process described below corresponds to a component of the information processing method of the present invention.
In the following, the target user is assumed to be user X, and the flow from before the event announcement starts to the end of the event will be described.

The processing flow begins with user X logging in to the terminal 10 in order to play the game. Specifically, as shown in FIG. 9, when the flow starts, the terminal operation unit 31 of the terminal 10 accepts the login operation, and the terminal transmission unit 32 transmits data indicating the login date and time to the server 12 (S001). The server reception unit 112 receives the above data sent from the terminal 10 (S002).

Then, the server-side transmitting unit 111 transmits data for game progress to the terminal 10 of the user X (S003), and the terminal-side receiving unit 33 receives the transmitted data (S004). This allows the game to start being played on the terminal 10 of the user X.

On the other hand, when user X performs various operations while playing the game, the terminal operation unit 31 accepts the operations, and the terminal transmission unit 32 transmits data indicating the contents of the accepted operations to the server 12 (S005). The data transmitted by the terminal transmission unit 32 includes data indicating the contents of the designation operation, selection operation, application operation, etc. In the server 12, the server reception unit 112 receives the operation data sent from the terminal 10 (S006).

Next, the server 12 judges whether the current time is before the event is announced (S007), and if it is before the event is announced, it further judges whether the attribute of the user X stored in the server-side memory unit 113 is lapsed or new (S008).
If the attribute of user X is defected or new, the change unit 114 of the server 12 changes the attribute of user X stored in the server-side storage unit 113 to an existing attribute (S009). If the attribute of user X is an existing attribute, the attribute of user X is maintained as it is (S010).
If the current time is before the event is announced, the process flow ends when the game play ends (S011).

If the current time is not before the event announcement in step 007, it is determined whether the event is in the event announcement period or during the event (S012), as shown in Fig. 10. If the current time is during the event announcement period and the attribute of user X stored in the server-side storage unit 113 at the announcement start time is "leaving" or "new", the change unit 114 does not change the attribute of user X to the existing attribute even if user X logs into the game during the announcement period. Therefore, the attribute of user X is maintained as "leaving" or "new" during the event announcement period.
On the other hand, if the attributes of user X at the time of the start of the announcement are the existing ones, the attributes of user X are maintained as they are during the event announcement period.
During the event announcement period, the process flow ends when the game play ends (S011).

If it is determined in step S012 that the current time is during an event, when user X plays the event during that time and clears a quest for the event (S013), the server 12 determines the play style at that time (S014).
If the play mode determined in step S014 is cooperative play, the server 12 determines whether the user X is a host or a guest in the cooperative play (S015). After that, the server 12 further determines the attributes of the user X stored in the server-side storage unit 113 at the time of playing the event (strictly speaking, at the time of clearing the quest) (S016, S017).

The attributes of user X in steps S016 and S017 are determined according to the attributes at the start of the event period and whether or not the event quest has been cleared through cooperative play. The attributes at the start of the event period are the attributes that have been maintained since the start of the event announcement, and the attributes at the start of the announcement are determined according to the date and time 2 of the last login operation performed before the start of the announcement. Specifically, if N days have elapsed since the last login date and time (including cases where no login operation has been performed in the past), the attribute of user X becomes churn or churn, and if the above-mentioned elapsed time has not yet reached N days, the attribute of user X becomes existing.
In addition, if user X, whose attribute is defector or new at the start of the event period, has not yet cleared the event quest by playing together with other users, user X's attribute at that time will be defector or new.
In cases other than those mentioned above, such as when User X's attributes already exist at the time the event announcement begins, or when User X has cleared a quest for the event by playing together with another user, User X's attributes will be considered to be existing.

If the attribute of user X stored in the server-side storage unit 113 is defected or new in steps S016 and S017, the processing unit 115 (more specifically, the reward granting processing unit 116) of the server 12 executes a reward granting process (S018). As a result, a reward is granted to user X who clears the event quest by playing together with other users. At this time, the content of the reward granted to user X will be the content when user X's attribute is defected or new, for example, "1 item A + 2 items B + bonus C" in the case shown in FIG. 8.

In addition, if the attributes of user X stored in the server-side storage unit 113 are defected or new, when user X clears the event quest through cooperative play with another user, the change unit 114 changes user X's attributes to existing ones (S019). After that, user X's attributes are maintained as existing ones for the duration of the event.

In addition, when user X acts as a host and plays an event together, and the attributes of user X stored in the server-side memory unit 113 are existing, the server 12 determines whether or not the other users who played the event together with user X as guests include a user whose attribute is a defector or a new user (S020).
If the multiple users who have engaged in joint play include other users whose attributes are defecting or new, the user number determination unit 117 of the processing unit 115 determines the number of other users whose attributes are defecting or new, i.e., the number of joint play users (S021).
When the number of co-play users is one or more, the reward granting processing unit 116 of the processing unit 115 executes a reward granting process, and a reward is granted to the user X who cleared the event quest by co-playing with other users (S022). At this time, the content of the reward granted to the user X corresponds to the number of co-play users identified in step S021. For example, when the number of co-play users identified is two, for example, in the case shown in FIG. 8, a reward for "one item A + two items B + special gift C" x two people is granted to the user X.

On the other hand, if user X, whose attributes are existing, plays a co-op event as a guest, user X will not be given a reward even if he or she clears the event quest. Also, if existing user X plays a co-op event as a host, and the number of co-op users is zero, user X will not be given a reward even if he or she clears the event quest.

If an event is played during the event period, the process flow proceeds according to the procedure described above (specifically, the procedure shown in FIG. 10), and the process flow ends when the game play is finally completed (S011).

[summary]
The server 12 as an information processing device according to this embodiment includes a change unit 114 and a processing unit 115. The change unit 114 changes the attributes of the target user depending on whether the target user has not played a predetermined game for a predetermined period of time, and the processing unit 115 executes processing according to the attributes of the target user when the target user plays a game during an event period. The change unit 114 does not change the attributes of the target user even if the target user plays a game from a predetermined time point before the event period until the event is held. With this configuration, the target user can maintain the attributes at the predetermined time point before the event is held until the event is held, and can participate in the event with those attributes.
As a result, if a target user desires a process that would be executed if the user played a game with a specific attribute during the event period, the target user can ensure that the process is executed without missing an opportunity to execute the process. In other words, a target user whose attribute is a specific attribute at a predetermined time before the event is held can play the event while maintaining the specific attribute, since the attribute does not change between the predetermined time and the event. As a result, the target user can enjoy the benefit of the process that would be executed if the user played a game with a specific attribute during the event period.

In addition, in this embodiment, if a predetermined play has not been performed for a predetermined period of time at a predetermined time point before the event is held, the target user's attribute is set to the first attribute (defector or new), and otherwise the target user's attribute is set to the second attribute (existing). In other words, the target user's attribute is determined according to the state at a predetermined time point before the event is held, and the target user can maintain the attribute at that predetermined time point until the event is held and participate in the event.

In addition, in this embodiment, the content of the processing performed by the processing unit 115 when the attribute of the target user is departing or new during the event period differs from the content of the processing performed when the attribute of the target user is existing during the event period.
In the above configuration, there are cases where the target user is about to play an event in anticipation of a process that is executed when the attribute is, for example, defection or new. In such cases, a configuration that does not change the attribute even if the target player plays the game from a predetermined point before the event is held until the event is held is meaningful.

In addition, in this embodiment, if the play of a target user who has left or is new satisfies a predetermined condition during the event period (specifically, if a quest for the event is cleared in cooperative play), the change unit 114 changes the target user's attribute to the existing one. This makes it possible to limit the number of times that the process performed when the target user's attribute is left or new (specifically, the reward granting process when the target user's attribute is left or new) is performed during the event period. As a result, for example, it is possible to increase the rarity (scarcity) of the reward granted to the target user when the attribute is left or new.

In addition, in this embodiment, the attributes of a target user that are changed from churn or new to existing during the event period are maintained as existing during the event period thereafter. This makes it possible to limit the number of times that the reward granting process is executed when the target user's attributes are churn or new to one. As a result, it is possible to further increase the rarity (scarcity) of rewards granted to target users when their attributes are churn or new.

In addition, in this embodiment, the reward granting processing unit 116 of the processing unit 115 executes a reward granting process to grant a reward according to the attributes of a target user to a target user who plays an event together with other users during the event period and clears the event quest. In such a configuration, the target user tries to play the event with a defected or new attribute in order to obtain a reward. In such a case, a configuration in which the attributes are not changed even if the target player plays the game from a predetermined point before the event is held until the event is held is meaningful.

In addition, in this embodiment, when a target user with an existing attribute becomes a host during the event period and plays the event together with another user with a defecting or new attribute as a guest, the reward granting processing unit 116 executes the reward granting process. With this configuration, even if the target user has an existing attribute, a reward is granted by playing together with another user with a defecting or new attribute, which can stimulate the target user's motivation for playing together.

In addition, in this embodiment, when a target user whose attribute is defector or new becomes a host during the event period and plays the event together with other users as guests, the reward granting processing unit 116 executes the reward granting process. With this configuration, a reward is granted to the target user whose attribute is defector or new, regardless of the attributes of the other users, and this can stimulate the target user's motivation to play together.

In addition, in the reward granting process of this embodiment, the reward granting processing unit 116 grants the target user a reward according to the number of users who have defected or new attributes among multiple users who played the event together (i.e., the number of co-play users). This makes it possible to more effectively motivate the target user to play together with other users who have defected or new attributes.

In addition, in an embodiment different from this embodiment, the processing unit 115 may specify the number of times (number of times of joint play) when a target user with an existing attribute becomes a host during the start period of an event and plays an event jointly with another user with a defecting or new attribute as a guest. In this case, in the reward granting process, the reward granting processing unit 116 may grant the target user a reward according to the number of times of joint play. Even with such a configuration, it is possible to more effectively stimulate the target user's motivation to play jointly with other users with defecting or new attributes.

In addition, in this embodiment, the specified time point is the time when the announcement of the event begins. For example, when an announcement of an event begins, there is a tendency for an increasing number of users to react to the announcement by playing the game in a specified way (specifically, logging in or playing a quest). Even in such a situation, the attributes do not change even if the specified game play is performed from the time when the announcement begins until the event is held, so that target users whose attributes are defectors or new users at the time when the announcement begins can play the event while maintaining those attributes.

In addition, in the present embodiment, an example of an information processing method using the information processing device of the present invention has been described, but the present invention is not limited thereto. Any information processing method may be used in which a computer changes the attributes of a target user playing a game depending on whether or not the target user has not performed a predetermined play of the game for a predetermined period of time, and when the target user plays during an event period in the game, the computer executes processing according to the attributes of the target user, and the computer does not change the attributes of the target user even if the target user performs a predetermined play from a predetermined time point before the event period until the event is held.
With the above information processing method, the target user can maintain the attributes at a predetermined time before the event until the event starts, and can participate in the event with those attributes. This makes it possible to avoid a situation in which a process that would be executed if the user played the game with a specific attribute during the event period is not executed due to a change in attribute before the event starts.

The information processing method according to this embodiment is realized by the server 12 alone, or by a combination of the terminal 10 and the server 152. Here, the server 12 may be a server computer for an ASP (Application Service Provider), SaaS (Software as a Service), PaaS (Platform as a Service), or IaaS (Infrastructure as a Service). In this case, a series of information processes related to playing the game (excluding input and display of information) are executed by the server 12, so that the terminal 10 is only required to perform operations for progressing the game and display images, etc.

In addition, in this embodiment, a program that causes a computer that is the server 12 to function as an information processing device has been described. This program is a program that is read by the computer, and causes the computer to change the attributes of a target user playing a game depending on whether the target user has not performed a specified play of the game for a specified period of time, causes the computer to execute processing according to the attributes of the target user when the target user plays during an event period in the game, and does not cause the computer to change the attributes of the target user even if the target user performs a specified play from a specified point in time before the event period until the event is held.

The above program may be obtained by reading it from a computer-readable recording medium, or by receiving (downloading) it via a network such as the Internet or an intranet.

<<Other embodiments>>
Although the information processing device, information processing method, and program of the present invention have been described above using specific examples, the above-mentioned embodiment is merely an example, and other embodiments are also possible. For example, in the above embodiment, the server 12 functions as the information processing device of the present invention, but some or all of the functions of the server 12 may be provided in the terminal 10.

In the above embodiment, the processing executed by the processing unit 115 when the target user plays the game during the event period is a reward granting process, and whether or not a reward is granted and the content of the reward granted are determined according to the attributes of the target user during the event period. However, the processing executed according to the attributes of the target user during the event period may be processing other than the reward granting process, and may be, for example, processing to progress the story of the game according to the attributes of the target user. In this case, the content of the processing (for example, the content of the progress of the story, or more simply, the scenario) may be different depending on whether the target user's attributes are departing or new and whether the target user is an existing user, so that the target user's attributes can be effectively guided to the event.

In the above embodiment, a reward is granted to a target user whose attribute is defector or new when the target user plays an event together with another user and clears a quest for the event. However, this is not limited to this, and a reward may also be granted to the target user when a target user whose attribute is defector or new clears a quest for the event alone.

In the above embodiment, the predetermined time before the event is held is the start time of the announcement of the event, and the attributes of the target user are not changed even if the target user plays a predetermined game from the start time of the announcement to the start of the event. However, this is not limited to this, and for example, attribute changes due to a predetermined game play may be postponed from a time other than the start time of the announcement (but limited to a time before the event is held) to the start of the event.

10 Terminal 12 Server (information processing device)
14 Communication network 21 Processor 22 Memory 23 Communication interface 24 Storage 25 Input device 26 Output device 27 Bus 31 Terminal operation unit 32 Terminal transmission unit 33 Terminal reception unit 34 Terminal storage unit 35 Terminal display unit 101 Processor 102 Memory 103 Communication interface 104 Storage 105 Input device 106 Output device 107 Bus 111 Server transmission unit 112 Server reception unit 113 Server storage unit 114 Change unit 115 Processing unit 116 Reward granting processing unit 117 Number of users determination unit I Icon S Game system

Claims (4)

A processor is included.
The processor,
setting an attribute of the target user to a first attribute when a period during which the target user who plays a game has not performed a predetermined play reaches a reference value, and setting an attribute of the target user to a second attribute when a period during which the target user has not performed a predetermined play does not reach a reference value;
Even if the period during which the target user, who has the first attribute at a predetermined time point prior to the holding of the event, has not played the game and performed a predetermined play from the predetermined time point until the holding of the event does not reach a reference value, the attribute of the target user is not set to the second attribute,
displaying attributes of the target user on a display unit during the event period;
An information processing device that executes processing according to attributes of the target user when the target user plays the game during a period in which the event in the game is held. a processor sets an attribute of a target user who plays a game to a first attribute when a period during which the target user has not performed a predetermined play reaches a reference value, and sets an attribute of the target user to a second attribute when a period during which the target user has not performed a predetermined play does not reach a reference value;
a processor, even if a period during which the target user, who has the first attribute at a predetermined time point before the holding of an event, has not played the game and performed a predetermined play from the predetermined time point until the holding of the event does not reach a reference value, not setting the attribute of the target user to the second attribute;
The processor causes a display unit to display attributes of the target user during the event period;
A method comprising: a processor executing a process according to attributes of the target user when the target user plays the game during a period during which the event in the game is held. causing a processor to set an attribute of a target user who plays a game to a first attribute when a period during which the target user has not performed a predetermined play reaches a reference value, and to set an attribute of the target user to a second attribute when a period during which the target user has not performed a predetermined play does not reach a reference value;
causing a processor to not set an attribute of the target user to the second attribute even if a period during which the target user, who has the first attribute at a predetermined time point before the holding of an event, has not performed a predetermined play by playing the game from the predetermined time point until the holding of the event does not reach a reference value;
causing a processor to display attributes of the target user on a display unit during a period in which the event is held;
A program that causes a processor to execute processing according to attributes of the target user when the target user plays the game during a period in which the event in the game is held. A server and a terminal,
The server,
setting an attribute of the target user to a first attribute when a period during which the target user who plays a game has not performed a predetermined play reaches a reference value, and setting an attribute of the target user to a second attribute when a period during which the target user has not performed a predetermined play does not reach a reference value;
Even if the period during which the target user, who has the first attribute at a predetermined time point prior to the holding of the event, has not played the game and performed a predetermined play from the predetermined time point until the holding of the event does not reach a reference value, the attribute of the target user is not set to the second attribute,
displaying attributes of the target user on a display unit during the event period;
The system executes processing according to attributes of the target user when the target user plays the game during a period in which the event in the game is held.

Images