JP7421127B2 - 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 games without getting bored. Therefore, the game play status and the like of the game users are managed, and measures may be taken to induce the users who have not played the game for a predetermined period of time to play the game.

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

Japanese Patent Application Publication No. 2018-187400

In addition, as part of measures to attract users who have not played the game for a long time to the game, attributes are set for users depending on whether they have not played the game for a certain period of time, and specific attributes are set for the user. It is assumed that when a certain user plays the above event and satisfies a predetermined condition, processing such as awarding a reward is executed. In such a case, a user who expects a desired process to be executed will attend the event by maintaining the attributes as specific until the event.

However, if a user with a specific attribute plays a game at a predetermined time before an event is held, and the attribute changes accordingly, the desired process will not be executed even if the user attends the event after that. In such a case, it becomes difficult to attract users who have not played the game for a predetermined period of time back to the game by holding an event, and there is a possibility that the purpose of holding the event will not be achieved.

Therefore, the present invention makes it possible to avoid missing an opportunity to execute a desired process in a configuration in which the content of the process to be executed during an in-game event is determined according to the game play situation before the event is held. An object of the present invention is to provide an information processing device, an information processing method, and a program.

An information processing device according to an embodiment of the present invention includes a changing unit that changes an attribute of a target user depending on whether or not the target user who plays the game has not played 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 the event period in the game, and the changing unit is configured to perform a process according to the attribute of the target user when the target user plays the game during the event period. It is characterized in that the attributes of the target user are not changed from the time until the event is held even if the target user performs a predetermined play.

According to one aspect of the present invention, when the content of the process to be executed in an in-game event is determined according to the game play situation before the event, a target user may miss an opportunity to execute the desired process. You can prevent it from happening.

FIG. 3 is a diagram showing a schedule regarding events. 1 is a conceptual diagram of a game communication system including an information processing device according to an embodiment of the present invention. FIG. 1 is a diagram showing the hardware configurations 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. 6 is a diagram illustrating how a home screen displayed during a 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. It is a diagram showing conditions for granting remuneration. It is a diagram showing types of rewards. FIG. 3 is a diagram (part 1) showing a processing flow related to playing an event. FIG. 2 is a diagram showing a processing flow related to playing an event (Part 2).

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

Note that the embodiment described below is only one specific example given to facilitate understanding of the present invention, and does not limit the present invention. That is, the present invention may be modified or improved from the embodiments described below without departing from the spirit thereof. Naturally, the present invention also includes equivalents thereof.

In addition, the screen examples shown in the drawings referred to in the following explanation are only examples, and the screen configuration examples, displayed information contents, GUI (Graphical User Interface), etc. are based on system design specifications and user It can be freely designed according to one's preferences, etc., and can be changed as appropriate.

[About the game according to this embodiment]
Prior to describing the information processing device according to the present 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 a user can play by operating a game terminal, and more specifically, it is an online game that uses data communication. Here, online games may include, for example, social games that can be used only with a web browser and an SNS (Social Networking Service) account.

When playing the game, the user performs a login operation on his/her own terminal. A login operation is an operation performed to play a game, such as an operation to start a game application program, or an operation to input login information (specifically, a user name and password, etc.) The operation is applicable. When the login operation is performed, the information processing apparatus according to this embodiment and the user's terminal start communication.

After performing the login operation, the user can play a game constituent unit called a quest or a stage (hereinafter referred to collectively as a quest) within the game. A quest is an in-game event that usually has a set time limit and is played with the aim of clearing the quest (fulfilling the achievement conditions) within the time limit.

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

The host is one of the forms of participation in joint play, and recruits guests and plays quests together with the guests. When recruiting guests, the host user selects a quest to play on a selection screen (not shown), specifies joint play, and waits until applications are received from other users.
Further, the host has the authority to instruct the start of joint play, and can start joint play at a timing determined by the host. Note that in this embodiment, at least two or more users (in other words, a host and one or more guests) are required to start a joint play.

Guests apply for recruitment from hosts and play quests together with the hosts. When applying for recruitment from a host, a user who becomes a guest selects a quest to play on a selection screen (not shown), and if there is a host recruiting guests for the selected quest, that host Specify the host and apply to become a guest (for example, by touching the host icon displayed on the screen).

Note that collaborative play can be realized using known communication technology. Specifically, when one user acts as a host and recruits guests, and other users apply for the recruitment, a communication path for collaborative play is established, and after that, the data communication required for collaborative play is This is done according to the communication method.

Furthermore, in games, events are held according to a predetermined schedule. At the event, you can play event-specific quests (stages). Information about the event (for example, the event period, etc.) is usually announced through a home screen displayed within the game or by using media such as television or the Internet.

By the way, in this embodiment, the event is implemented for the purpose of guiding the user to play the game. Specifically, an event planned for the purpose of having users with a specific attribute play the game is held in a predetermined period.

Here, the user's attributes are determined depending on whether or not the user has not performed a predetermined play of the game for a predetermined period, and if the user has not performed a predetermined play for a predetermined period, the If the predetermined play is not performed for a predetermined period of time, it becomes the second attribute.
Examples of the "predetermined play" include playing a quest in a game, playing a quest together or alone, or logging into a game. Furthermore, playing the game so that the status value (for example, user rank described below) is equal to or higher than a reference value also corresponds to "predetermined play."
The "predetermined period" is an arbitrary period, and in this embodiment, it is assumed to be N days (N is a natural number) as an example.
"A state in which the specified play has not been performed for a specified period of time" refers to, for example, the amount of time that has passed since the last login, or the amount of time that has passed since the last time the quest was played (or the last time the cooperative play was performed). This corresponds to a state in which time has reached N days. Furthermore, a state in which a status value (for example, a user rank described below) does not meet a reference value for N days is also included in the "state in which a predetermined play has not been performed for a predetermined period of time." Furthermore, a state in which the player has never played a game is also included in the "state in which no predetermined play has been performed for a predetermined period of time."
In addition, in this embodiment, a state in which the elapsed time since the last login has reached N days, or a state in which you have never played a game and have never logged in is defined as "a predetermined play has been performed for a predetermined period of time". "The state of not having done so."

In this embodiment, attributes are classified into three types: "departure", "new", and "existing".
Abandonment is an attribute that occurs when the elapsed time from the last (most recent) login point reaches N days. Note that the attribute may be set to be a defection when the elapsed time since the last joint play has reached N days. Alternatively, for a user who has only performed a login operation and has not played a quest, if the elapsed time since the last time the user played a quest has reached N days, the attribute may be set to defect.
New is an attribute for a user who has never played a game or logged in to a game. Departure and newness correspond to the first attribute that satisfies the above predetermined condition.
Existing is an attribute when the time elapsed since the last login has not reached N days. Existing corresponds to the second attribute that does not satisfy the above predetermined condition.

Note that the classification of attributes is not limited to the three types described above (ie, defection, new, and existing). For example, the attribute when the user rank has not reached the reference value may be the first attribute, and the attribute when the user rank has reached the reference value may be the second attribute. A user rank is a user's status value that increases depending on, for example, the number of times a quest is cleared.

In this embodiment, an event is held for the purpose of guiding users whose attributes are defective or new to the game. That is, by holding an event, it is possible to arouse interest in the game among users whose attributes are those who have left or who are new to the game, and in particular, to invite users whose attributes are those who have quit to the game again.
Note that in the following description, "playing an event" means playing a quest for an event.

In this embodiment, in order to effectively achieve the purpose of the event described above, when a user satisfies a predetermined condition during the event period, a reward is given to the user. Here, the predetermined condition is that the user performs joint play with another user and clears the event quest jointly with the other user. However, it is not limited to this; for example, the condition may be that the event is played jointly with other users, or the condition may be that the number of times the quest for the event has been cleared has reached a predetermined number of times. Alternatively, the condition may be that the number of logins during the event period has reached a predetermined number.

To explain the conditions for granting a reward, if a user whose attribute is a defector or a new user clears an event quest jointly with another user, a reward is given to the user whose attribute is a new or new user. In addition, if a user with an existing attribute becomes a host and another user with a defective or new attribute is a guest and clears an event quest, the user with an existing attribute Rewards will be given.

Rewards are items and characters that can be used in the game (hereinafter referred to as items, etc.), or valuable items that can be exchanged for items (for example, virtual currency that can be used in the game, or a lottery for items, etc. in the game). (items necessary to do so). Further, an effect that can be temporarily enjoyed while the game is in progress (for example, an effect such as increasing a character's status value) may be provided as a reward. Further, a coupon or the like that can be used at an existing store or the like may be given as a reward.

Note that "granting a reward" means providing data for using the reward in a game or at an actual store to a user who is a target of reward granting. For example, when providing rewards that can be used in the game, such as items, values that can be exchanged for items, and efficacy, data for proceeding with the game with the rewards obtained is provided. When giving a reward such as a coupon that can be used at an existing store, text data or image data for presenting the reward at the store is provided.

A user who expects to receive a reward at an event needs to play the event in a state where his/her own attribute is a defector or a new user, or play the event jointly with another user whose attribute is a defector or a new user.

On the other hand, event announcements are made before the event takes place. Specifically, as shown in FIG. 1, an event notification period is set before the event period, and the event is announced within this notification 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 notification period is shorter than the event period, for example, one to several days, or one week. ~ Set for several weeks.

In the schedule shown in Figure 1, a user whose attribute is defection happened to play the game at a certain point during the event announcement period (specifically, the time indicated by the cross in Figure 1), or Suppose you are logged in. In that case, the user's attribute is changed from defection to existing. Even if the user plays the event after that, no reward will be given unless the user plays jointly with another user whose attributes are defective or new. By missing the opportunity to receive a reward in this way, the user's desire to play the event may be lost, and as a result, the purpose of holding the event may not be achieved.

Therefore, in this embodiment, it has been decided to postpone attribute changes associated with game play during the event notification period. In other words, even if the user performs a prescribed play (for example, playing a quest) from the start of the event announcement (first day of announcement), which is a point before the event period (predetermined point), until the event is held, the user's The attributes do not change and remain as they were at the time the announcement started. In other words, the user's attributes at the time the event starts are determined by the attributes at the time the announcement starts. As a result, the user can maintain the attributes at the time of the start of the announcement until the event is held, and can face the event with those attributes. For example, a user whose attributes at the time of the start of the announcement are defective or new, You can play events.

Here, the attribute at the time of starting the notification depends on whether or not the elapsed time from the last login date and time has reached N days (including the state where you have never logged in in the past). It is decided. If the above-mentioned elapsed time has reached N days, the attribute at that point becomes defective or new. On the other hand, if the above elapsed time has not reached N days, the attribute at that time becomes existing.
As a supplementary note regarding how to determine the attribute, even if the attribute at the time of the start of the announcement is already existing, there may be a case in which the above elapsed time reaches N days during the announcement period. In this embodiment, even in such a case, as long as the attributes already exist at the time of starting the announcement, the attributes will be maintained as they are until the event is held. However, the present invention is not limited to this, and when the above elapsed time reaches N days during the notification period, the attribute may be changed to defection at that time.

In addition, in this embodiment, when a user whose attribute at the start of the event is a defector or a new user plays the event and meets a predetermined condition, the user's attribute changes to existing, and from then on during the event period. , the attributes of the user are maintained as they are. Here, the predetermined conditions are the same conditions as the conditions for granting rewards, and specifically, the user performs joint play with other users and clears the event quest jointly with the other users. That's true. However, it is not limited to this; for example, the condition may be that the event is played jointly with other users, or the condition may be that the number of times the quest for the event has been cleared has reached a predetermined number of times. Alternatively, the condition may be that the number of logins during the event period has reached a predetermined number.

Note that even if the attribute changes to existing during the event period, the elapsed time from the last login date and time may reach N days in the subsequent event period. In this embodiment, even in such a case, as long as the attribute changes to the existing one during the event period, the attribute will be maintained as existing during the subsequent event period. However, the present invention is not limited to this, and when the above elapsed time reaches N days during the event period after the attribute changes to existing, the attribute may be changed from existing to defected at that time.

[Information processing system for games]
Next, a game information processing system (hereinafter referred to as game system S) including the information processing apparatus according to the present embodiment will be described.
Note that in the following, we will focus on one user who plays a game using the gaming system S, and will refer to that user as the "target user" and the other users as "other users." .

The game system S is an information processing system constructed for a target user to play a game. In the game system S, as shown in FIG. 2, the terminals 10 of each user including the target user and the server 12 are communicably connected via a communication network 14 such as the Internet and a mobile communication network.
Note that in FIG. 2, the number of terminals 10 is three for convenience of illustration, but the number is not limited to this, and the number of terminals 10 may be any number. When playing, it is sufficient if there are at least two or more devices.

The terminal 10 is a device operated by a user for game play.
The server 12 is an example of an information processing device, and provides data for game progress to the terminal 10, and manages the game progress, current attributes, etc. for each of a plurality of users including the target user. Furthermore, when a plurality of users jointly play an event, the server 12 communicates with each user's terminal 10 to mediate the joint play of the event.
Although the server 12 is configured by one computer in this embodiment, the server 12 is not limited to this, and may be configured by multiple computers.

The communication network 14 is a communication line network between the terminal 10 and the server 12, and mainly consists of the Internet and mobile communication networks, and includes LAN (Local Area Network), WAN (Wide Area Network), intranet, and Ethernet (registered trademark). ) etc. may be included.

[Terminal and server configuration]
The respective configurations of the terminal 10 and the server 12 will be explained with reference to FIG. 3. Note that in FIG. 3, only one terminal 10 is shown for convenience of illustration.

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

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

Moreover, an operating system (OS) program and a game application program are installed in the terminal 10 as software. The processor 21 executes these programs, allowing the user to play the game through the terminal 10.

Specifically, the target user starts a game application program on his/her own terminal 10 and performs a predetermined login operation (for example, an operation of pressing a login button). Thereafter, the target user can proceed with the game by performing operations for proceeding with the game while viewing the play screen displayed on the display screen. Furthermore, if the target user specifies joint play of the quest as described above, the target user can play the quest jointly with other users.

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

Furthermore, the server 12 has an OS program and a game information processing program installed as software. These programs correspond to "programs" of the present invention and are read by the processor 101 of the server 12.
When the processor 101 executes the above program, the server 12 executes various information processing 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 target user's terminal 10, monitors the target user's game play status, and executes the game according to the play status. Update the target user's attributes, etc.

Among the hardware devices of the terminal 10 and the server 12, the processors 21 and 101 are CPUs (Central Processing Units), MPUs (Micro-Processing Units), MCUs (Micro Controller Units), GPUs (Graphics Processing Units), or DSPs ( It is preferable to use a digital signal processor (Digital Signal Processor) or the like.

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

The storages 24 and 104 include flash memory, HDD (Hard Disc Drive), SSD (Solid State Drive), FD (Flexible Disc), MO disk (Magneto-Optical disc), CD (Compact Disc), and DVD (Digital Versatile Disc). , an SD card (Secure Digital card), or a USB memory (Universal Serial Bus memory).

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

[Terminal functions]
Next, with reference to FIG. 4, the configuration of the terminal 10 will be explained again from a functional perspective.
As shown in FIG. 4, the terminal 10 includes a terminal-side operating section 31, a terminal-side transmitting section 32, a terminal-side receiving section 33, a terminal-side storage section 34, and a terminal-side display section 35. These functional units are realized by the cooperation of the hardware devices of the terminal 10 described above and various programs as software installed in the terminal 10. Each functional unit will be explained below.

The terminal-side operation unit 31 receives a login operation performed by the target user to play the game, or various operations performed by the target user while playing the game. Operations during game play that the terminal-side operation unit 31 accepts include designation operations, selection operations, application operations, and the like.
The designation operation is an operation for designating either solo play or collaborative play as the play mode of the quest. The selection operation is an operation for selecting either the host or the guest as the mode of participation in the joint 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 transmitter 32 transmits various data related to the game, such as the login date and time of the target user and the contents of operations performed by the target user during game play, to the server 12 through the communication network 14 . The data transmitted by the terminal-side transmitter 32 includes data indicating the contents of each operation received by the terminal-side operation unit 31, such as a designation operation, a selection operation, and an application operation.

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, information notification data, data regarding other users participating in joint play, and data on rewards given to target users (strictly speaking, data for using rewards), etc.

The terminal-side storage unit 34 stores data received by the terminal-side reception unit 33 from the server 12, information transmitted to the server 12 by the terminal-side transmission unit 32, and the like.

The terminal-side display section 35 develops the data that the terminal-side receiving section 33 receives from the server 12 and displays a game play screen or an information notification screen according to the data on the display of the terminal 10. The screens displayed by the terminal-side display unit 35 include a home screen shown in FIG. 5, and the like.

To explain 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 home screen. This icon I changes as the attribute changes. For example, when the attribute is abandoned or changed from new to existing, the icon I changes from the display state shown in the upper diagram of FIG. 5 to the display state shown in the lower diagram.

[Server functions]
Next, with reference to FIG. 6, the configuration of the server 12 will be explained again from a functional perspective.
As shown in FIG. 6, the server 12 includes a server-side transmitting section 111, a server-side receiving section 112, a server-side storage section 113, a changing section 114, and a processing section 115. The processing unit 115 includes a remuneration processing unit 116 and a user number identification unit 117. These functional units are realized by the cooperation of the hardware devices of the server 12 described above and various programs as software installed in the server 12. Each functional unit will be explained 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 transmitter 111 includes information notification data, and includes, for example, home screen display data including the attribute confirmation icon I described above.

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 details of operations performed by the target user during game play. 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 storage unit 113 stores the current attributes of each of the target user and other users. Additionally, the server-side storage unit 113 stores information indicated by the data received by the server-side reception unit 112, including the date and time of the last login of the target user. Furthermore, the server-side storage unit 113 stores the number of times the target user played the event jointly with other users during the event period (hereinafter referred to as the number of joint plays).

The changing unit 114 changes the target user's attributes stored in the server-side storage unit 113 to the target user's game play status (i.e., whether or not the target user has not played a predetermined game for a predetermined period of time). Change accordingly.
For example, when the target user's attribute is defection, when the target user logs in to play a game, the server-side reception unit 112 receives data indicating the login time from the target user's terminal 10. Taking this as an opportunity, the changing unit 114 changes the target user's attribute stored in the server-side storage unit 113 from defection to existing.

Furthermore, as described above, in the present embodiment, the changing unit 114 does not change the attributes of the target user even if the target user whose attributes are defective or new plays the game during the event notification period. (defer attribute change), leave or leave as new.
Further, when a target user whose attribute is defective or new plays an event together with other users and clears a quest for the event, the changing unit 114 changes the target user's attribute from defective or new to existing. . After that, the target user's attributes will remain as they are during the event period.

The processing unit 115 executes a predetermined process on the target user when the target user plays the game during the event period. The content of the process that the processing unit 115 executes on the target user varies between cases where the target user's attributes are defective or new during the event period and cases where the target user's attributes are existing during the event period. It's different.

To be more specific, the reward granting processing unit 116 of the processing unit 115 grants rewards according to the attributes of the target user when the target user clears the event quest by performing joint play with other users. Execute the reward granting process. To explain the reward granting rules with reference to FIG. 7, if any of the following cases (1) to (3) apply, the reward granting processing unit 116 executes the reward granting process to provide the target user with a reward. and give rewards.
(1) When a target user whose attributes are a defector or a new user becomes a host and plays an event jointly with another user as a guest.
(2) When a target user with an existing attribute becomes a host and another user whose attribute is a defector or a new user plays an event together with the other user as a guest.
(3) When a target user whose attributes are defective or new becomes a guest and plays an event jointly with other users who are recruiting guests as a host.
Note that, as shown in FIG. 7, even if a target user with an existing attribute becomes a host and plays an event jointly with another user with an existing attribute, the reward granting process is not executed. In addition, if a target user with an existing attribute becomes a guest and another user with a defective or new attribute becomes the host and a joint play event is carried out, the other users will receive rewards, but the target user will not receive a reward. will not be rewarded.

Returning to the explanation of the reward granting process, the content of the reward given to the target user in the reward granting process is determined according to the attributes of the target user at that time. In addition, the content of the reward also depends on the number of users who have defected or are new users (hereinafter referred to as the number of co-playing users) among the multiple users (including the target user) who played the event together. .
To explain the content of the reward using the example shown in Figure 8, for example, if a target user whose attributes are defective or new, plays an event jointly with other users and clears the event quest, the target user will be given a reward of "1 item A + 1 item B + benefit C". This reward is given only when the target user's attributes are defection or newness.
Here, when a defective or new target user performs co-op play for the event and clears the event quest, the target user's attributes will be changed to existing, and from then on during the event period. It will remain as it exists. Therefore, during the event period, the above-mentioned reward will be awarded only once.

Further, suppose that a target user with an existing attribute becomes a host, and another user whose attribute is a defector or a new user becomes a guest, plays an event jointly with the other user, and clears a quest for the event. In this case, the number of users identifying unit 117 of the processing unit 115 identifies the number of users whose attributes are defectors or new users (hereinafter referred to as the number of jointly playing users) among the plurality of users who have performed joint play. The number of joint play users corresponds to the number of other users who jointly play an event with the target user and whose attributes are defective or new.

Then, the reward grant processing unit 116 grants a reward to the target user according to the number of co-playing users. For example, if the number of co-play users is two, in the example shown in FIG. 8, rewards for "1 item A + 2 items B + benefit C" x 2 people will be given.
Incidentally, in the example shown in FIG. 8, the number of co-playing users is counted up and carried over to subsequent game play. For example, suppose that the number of co-play users at a certain point is two, and in the next co-op 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 will be "1 item A + 2 items B + Benefit C" x 3 people, and the number of co-play users is 5 (= 2 + 3) It is counted up to.
In the example shown in FIG. 8, when the number of co-play users reaches five, all of the rewards prepared for the target user will be given. However, it is not necessary to set a particular limit on the number of rewards to be given to the target user, or even if there is a limit, the number (i.e., the upper limit of the number of rewards to be given) is You may decide arbitrarily.

[About the information processing flow according to this embodiment]
Next, the flow of information processing by the game system S, particularly the flow related to playing an event, will be described with reference to FIGS. 9 and 10.
Note that the processing flow described below employs the information processing method of the present invention. In other words, each step in the flow described below corresponds to a component of the information processing method of the present invention.
Furthermore, in the following, the target user is User X, and the flow from before the start of event notification to the end of the event will be explained.

The processing flow begins when user X performs a login operation on terminal 10 in order to play the game. Specifically, as shown in FIG. 9, at the start of the flow, the terminal-side operating unit 31 of the terminal 10 accepts a login operation, and the terminal-side transmitting unit 32 sends data indicating the login date and time to the server 12. Send (S001). The server side receiving unit 112 receives the above data sent from the terminal 10 side (S002).

Thereafter, the server-side transmitter 111 transmits data for game progress to the terminal 10 of user X (S003), and the terminal-side receiver 33 receives the sent data (S004). As a result, play of the game is started on user X's terminal 10.

On the other hand, when user X performs various operations during game play, the terminal side operation unit 31 accepts the operation, and the terminal side transmission unit 32 transmits data indicating the content of the accepted operation to the server 12. (S005). The data transmitted by the terminal-side transmitter 32 includes data indicating the contents of the designation operation, selection operation, application operation, and the like. In the server 12, the server side receiving unit 112 receives operation data sent from the terminal 10 side (S006).

Next, the server 12 determines whether the current time is before the event announcement (S007), and if the current time is before the event announcement, the user It is determined whether it is (S008).
If the attribute of the user X is defective or new, the changing unit 114 of the server 12 changes the attribute of the user X stored in the server-side storage unit 113 to existing (S009). If the attributes of user X already exist, the attributes of user X are maintained as they are (S010).
If the current time is before the event announcement, the processing flow ends with the end of the game play (S011).

If the current time is not before the event announcement in step 007, it is determined whether the current time is during the event announcement period or the event holding period, as shown in FIG. 10 (S012). If the current time is during the event notification period and the attribute of user Even if it does, the attributes of user X will not be changed to the existing attributes. Therefore, during the event notification period, the attributes of user X will remain as defective or new.
On the other hand, if the attributes of user X already exist at the time of starting the announcement, the attributes of user X are maintained as they are during the event announcement period.
Then, during the event notification period, the processing flow ends with the end of the game play (S011).

If the current time is during the event period in step S012, when user X plays the event and clears the event quest during the same period (S013), the server 12 determines the play form at that time (S014) ).
If the play form determined in step S014 is collaborative play, the server 12 determines whether user X is a host or a guest in the collaborative 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 depending on the attributes at the start of the event period and whether or not the quest for the event has been cleared through joint play. The attributes at the start of the event period are the attributes maintained from the start of the event announcement, and the attributes at the start of the announcement are determined according to the date and time of the last login operation performed before the start of the announcement. Specifically, if the elapsed time from the last login date and time has reached N days (including cases where no login operation has been performed in the past), the attribute of user If the elapsed time has not reached N days, the attribute of user X becomes existing.
In addition, if user Leave or become new.
In cases other than the above, for example, cases where user X's attributes already exist at the time the event announcement begins, and cases where user User X's attributes become existing.

In steps S016 and S017, if the attribute of user (S018). As a result, the user X who clears the event quest through joint play with other users is given a reward. At this time, the content of the reward given to user X is the content when the attribute of user X is defection or new. For example, in the case shown in FIG. ”.

In addition, if the attribute of user The attributes of user X are changed to existing (S019). Thereafter, the attributes of user X are maintained as they are during the implementation period of the event.

Furthermore, if user X becomes a host and performs a joint play event, and the attributes of user It is determined whether or not the other users who played the game include a user whose attribute is a defector or a new user (S020).
If the plurality of users who have performed joint play include other users whose attributes are defective or new, the user number specifying unit 117 of the processing unit 115 identifies the other users whose attributes are defective or new. , that is, the number of co-playing users (S021).
When the number of joint play users is one or more, the reward granting processing unit 116 of the processing unit 115 executes the reward granting process to the user X who has cleared the event quest through joint play with other users. , a reward is given (S022). At this time, the content of the reward given to user X corresponds to the number of co-playing users specified in step S021. For example, when the number of identified co-play users is two, for example, in the case shown in FIG. Ru.

On the other hand, if user X, who has an existing attribute, plays the event together as a guest, no reward will be given to user X even if the event quest is cleared. Further, when the existing user X performs a joint play of an event as a host, if the number of joint play users is 0, no reward will be given to the user X even if he clears the quest for the event.

If the event is played during the event period, the processing flow will proceed according to the procedure described above (specifically, the procedure shown in Figure 10), and the process will be processed when the game play is finally finished. The flow ends (S011).

[summary]
The server 12 as an information processing device according to the present embodiment includes a changing unit 114 and a processing unit 115, and the changing unit 114 determines whether or not the target user has not played a predetermined game for a predetermined period of time. Accordingly, the attributes of the target user are changed, and the processing unit 115 executes processing according to the attributes of the target user when the target user plays the game during the event period. Further, the changing unit 114 does not change the attributes of the target user even if the target user plays the game from a predetermined time point before the event period until the event is held. With such a configuration, the target user can maintain the attributes at a predetermined point in time before the event is held until the event, and can face the event with those attributes.
As described above, if the target user desires a process that will be executed when playing the game with a specific attribute during the event period, the target user can secure the opportunity to execute the process without losing the opportunity. Can be done. In other words, a target user whose attribute is a specific attribute at a predetermined time before the event is held will not change from the predetermined time until the event is held, so it is possible to play the event while maintaining the specific attribute. can. As a result, the target user can enjoy the benefits of the processing that is executed when the game is played with the attribute being a specific attribute during the event period.

In addition, in this embodiment, if a predetermined play has not been performed for a predetermined time at a predetermined time before an event is held, the target user's attribute is set as the first attribute (leave or new), and in other cases In this case, the target user's attribute was set as the second attribute (existing). That is, the attributes of the target user are determined according to the state at a predetermined time before the event is held, and the target user can attend the event while maintaining the attributes at the predetermined time until the event is held.

In addition, in the present embodiment, the contents of the process executed by the processing unit 115 when the target user's attributes are defective or new during the event period, and the contents of the process executed when the target user's attributes are existing during the event period. The content of the processing is different.
In the above configuration, the target user may try to play the event, for example, expecting a process to be executed when the attribute is defective or new. In such a case, a configuration in which the attributes are not changed even if the target player plays the game from a predetermined time before the event to the event becomes meaningful.

Furthermore, in the present embodiment, the changing unit 114 controls the changing unit 114 when the play of a target user who is a defector or a new user satisfies a predetermined condition during the event period (specifically, when the target user who is a defector or a new target user clears a quest for the event through collaborative play). ), change the target user's attributes to existing. As a result, during the event period, the number of times the process to be performed when the target user's attribute is defection or new (specifically, the reward granting process when the target user's attribute is defector or new) is performed. can be restricted. As a result, for example, the degree of rarity of the reward given to the target user when the attribute is defective or new can be increased.

Furthermore, in the present embodiment, the attributes of the target user who defected or changed from new to existing during the event period are maintained as they are during the subsequent event period. This makes it possible to limit the number of executions of the remuneration process when the target user's attributes are defection or new to one time. As a result, the degree of rarity of the reward given to the target user when the attribute is defective or new can be further increased.

In addition, in the present embodiment, the reward grant processing unit 116 of the processing unit 115 rewards the target user for playing the event together with other users and clearing the quest for the event during the event period. Execute reward granting processing that grants rewards according to attributes. In such a configuration, the target user attempts to play the event in a state where the attribute is defective or new 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 time before the event to the event becomes meaningful.

In addition, in this embodiment, if a target user with an existing attribute becomes a host during the event period, and plays the event jointly with another user whose attribute is a defector or a new user, with the other user as a guest. , the reward grant processing unit 116 executes the reward grant process. With such a configuration, even if the target user has existing attributes, rewards will be given by performing joint play with other users who have defected or are new to the attribute, so It can arouse motivation.

In addition, in this embodiment, when a target user whose attributes are a defector or a new user becomes a host during the event period, and plays the event jointly with another user as a guest, the reward grant processing unit 116 executes reward grant processing. With such a configuration, a reward is given to a target user whose attribute is a defector or a new user, regardless of the attributes of other users, so that it is possible to arouse the target user's desire for cooperative play.

In addition, in the reward granting process of the present embodiment, the reward granting processing unit 116 responds to the number of users whose attributes are defective or new among the plurality of users who jointly played the event (i.e., the number of jointly playing users). The reward will be given to the target user. Thereby, it is possible to more effectively arouse the target user's desire to perform a joint play with another user whose attributes are defective or new.

Note that although this embodiment is different from this embodiment, the processing unit 115 allows a target user with an existing attribute to become a host during the event start period, and to host an event with another user whose attribute is a defector or a new user as a guest. If the user plays the game jointly with the other user, the number of times the user plays the game (number of times of joint play) may be specified. In this case, in the reward granting process, the reward granting processing unit 116 may grant a reward to the target user according to the number of times of joint play. Even with such a configuration, it is possible to more effectively arouse the target user's desire to perform a joint play with another user whose attributes are defective or new.

Furthermore, in this embodiment, the predetermined time point is the time point at which event notification starts. For example, when an event notification is started, the number of users who respond to the notification by playing a predetermined game (specifically, logging in or playing a quest) tends to increase. Even in such a situation, the attributes will not change even if the prescribed play of the game is performed from the time the announcement starts until the event is held, so target users whose attributes at the time of the announcement start are those who have defected or are new, will not change their attributes. You can play the event while keeping the .

Further, in this embodiment, an example of an information processing method using the information processing apparatus of the present invention has been described, but the present invention is not limited to this. The computer changes the attributes of the target user depending on whether or not the target user who plays the game has not played the game for a predetermined period of time, and if the target user plays the game during the event period. When playing, the computer executes processing according to the attributes of the target user, and the computer executes processing according to the attributes of the target user. Any information processing method that does not change the attributes of the target user may be used.
With the above information processing method, the target user can maintain the attributes at a predetermined time before the event is held until the event is held, and can face the event with those attributes. This makes it possible to avoid a situation where a process that would be executed when playing a game with a specific attribute during the event period is no longer executed due to a change in the attribute before the event is held.

Note that 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 12. Here, the server 12 may be a server computer for 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 processing related to playing the game (excluding inputting and displaying information) is executed by the server 12, so the terminal 10 only performs operations for progressing the game and displays images, etc. That would be a good thing.

Furthermore, in the present embodiment, a program has been described that causes the computer, which is the server 12, to function as an information processing device. The attributes of the target user are changed depending on whether or not the target user has not performed the specified play for a specified period, and when the target user plays during the event period in the game, the attribute of the target user is changed to the computer. This is a program that causes a computer to execute processing according to the event, and does not cause the computer to change the attributes of the target user even if the target user performs a predetermined play from a predetermined time before the event holding period until the event is held.

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

<<Other embodiments>>
Up to this point, the information processing device, information processing method, and program of the present invention have been described using specific examples, but the embodiments described above are merely examples, and other embodiments may also be considered. For example, in the embodiment described above, the server 12 functions as the information processing device of the present invention, but the terminal 10 may have some or all of the functions that the server 12 has.

Furthermore, in the above embodiment, the processing that the processing unit 115 executes when the target user plays the game during the event period is the reward granting process, and the reward granting process is performed according to the attributes of the target user during the event period. It was decided whether or not to do so, as well as the details of the remuneration to be granted. However, the process executed according to the attributes of the target user during the event period may be a process other than the reward granting process, for example, a process that advances the story of the game according to the attribute of the target user. Good too. At this time, in order to effectively guide target users whose attributes are those who have defected or who are new to the event, the content of the process (for example, the progress of the story, or simply the scenario) is It may be changed depending on whether it is new or existing.

In addition, in the above embodiment, when a target user whose attributes are defective or new plays an event jointly with other users and clears a quest for the event, a reward is given to the target user. . However, the present invention is not limited to this, and a reward may be given to the target user even when the target user whose attribute is a defector or a new user clears the event quest alone.

In addition, in the above embodiment, the predetermined time before the event is the start time of the event notification, and even if the target user plays the predetermined game from the time the notification starts until the event, the target user We decided not to change the attributes of However, this is not limited to this, and for example, it may be possible to postpone attribute changes due to a prescribed play of the game from a time other than the start of the announcement (but limited to the time before the event) until 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-side transmitting section 112 Server-side receiving section 113 Server-side storage section 114 Changing section 115 Processing section 116 Reward grant processing section 117 Number of users identification section I Icon S Game system for

Claims (4)

has a processor;
The processor sets the attribute of the target user to a first attribute if the period in which the target user who plays the game has not performed the prescribed play reaches a reference value at a predetermined time point before the event is held ;
The processor sets the attribute of the target user to a second attribute if the period during which the target user is not performing a predetermined play has not reached a reference value at the predetermined time ;
The processor executes processing according to the attribute of the target user when the target user plays the game during the event period in the game,
The processor sets the attribute of the target user to the first attribute even if a period during which the target user, which is the first attribute , does not perform a predetermined play does not reach a reference value from the predetermined time until the event is held. Do not set it to the second attribute,
The processor sets the attribute of the target user to the first attribute if a period during which the target user, which is the second attribute, does not perform a predetermined play reaches a reference value after the predetermined time. Information processing device. The processor sets an attribute of the target user to a first attribute if a period in which the target user who plays the game has not performed the prescribed play reaches a reference value at a predetermined time point before the event is held ;
the processor sets the attribute of the target user to a second attribute if the period during which the target user has not performed a prescribed play has not reached a reference value at the predetermined time ;
a processor, when the target user plays the game during the event period in the game, executes processing according to the attribute of the target user;
The processor sets the attribute of the target user to the first attribute even if the period during which the target user, which is the first attribute , does not perform a predetermined play does not reach a reference value from the predetermined time until the event is held. Do not set it to the second attribute,
Information that the processor sets the attribute of the target user to the first attribute when the period during which the target user, which is the second attribute, does not perform a predetermined play reaches a reference value after the predetermined time point. Processing method. causing the processor to set an attribute of the target user to a first attribute if a period in which the target user who plays the game has not performed a prescribed play reaches a reference value at a predetermined time point before the event is held ;
causing the processor to set the attribute of the target user to a second attribute if the period during which the target user has not performed a predetermined play at the predetermined time has not reached a reference value;
causing a processor to execute processing according to the attributes of the target user when the target user plays the game during the event period in the game;
The processor is configured to set the attribute of the target user as the first attribute even if the period during which the target user, which is the first attribute, does not perform the predetermined play does not reach a reference value from the predetermined time until the event is held. Do not set it to the second attribute,
A program that causes a processor to set an attribute of the target user to the first attribute when a period during which the target user, which is the second attribute, does not perform a predetermined play reaches a reference value after the predetermined time point. . A system comprising a server and a terminal,
The server is
At a predetermined time point before the event is held, if the period in which the target user who plays the game has not performed the predetermined play reaches a reference value, the attribute of the target user is set as a first attribute,
At the predetermined time point, if the period in which the target user has not performed a predetermined play has not reached a reference value, setting the attribute of the target user to a second attribute;
When the target user plays the game during the event period in the game, executing a process according to the attribute of the target user,
Even if the period during which the target user, which is the first attribute, does not perform the prescribed play from the predetermined time point until the holding of the event does not reach the reference value, the attribute of the target user is set to the second attribute. without setting it to
The system sets the attribute of the target user to the first attribute when a period during which the target user, which is the second attribute, does not perform a predetermined play reaches a reference value after the predetermined time point.

Images