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

Description

Article 30, Paragraph 2 of the Patent Act applies [Disclosure fact 1] Website publication date: January 30, 2020, website address: https://www. youtube. com/watch? v=kKpgNBvMVxc&feature=youtu. be, Publisher: Mixi Co., Ltd. [Disclosure Fact 2] Website publication date: January 30, 2020, Website address: https://www. monster-strike. com/news/20200130_7. html, Publisher: Mixi Co., Ltd.

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

2. Description of the Related Art Conventionally, games such as online games are known in which the user selects various events that occur and plays the game while progressing through the selected events.

For example, Patent Document 1 discloses an information processing device that can easily select an event that can be played for a limited time (referred to as a "quest" in Patent Document 1), which is a unit of play in a game. ing.

Japanese Patent Application Publication No. 2019-188132

However, since the event shown in Patent Document 1 has a limited playable period, the user often loses the opportunity to play when the period set for the event ends. Therefore, users will be dissatisfied.

SUMMARY OF THE INVENTION Therefore, the present invention provides an information processing device and an information processing system that can improve a user's game satisfaction by making it possible to play even an event in which an opportunity to play is lost due to the end of the time range defined for the event. The objective is to provide methods and programs.

An information processing device according to one aspect of the present invention includes a control unit that controls whether or not an event can be played based on a relationship between a time range defined for an event in a game and the current time, and the control unit After the range ends, if a predetermined condition is satisfied according to a predetermined operation by the user, the user who performed the predetermined operation is allowed to play the event for a predetermined time.

According to one aspect of the present invention, it is possible to play an event even if the time range defined for the event has ended and the opportunity to play has been lost, thereby improving the user's game satisfaction.

1 is a conceptual diagram of a game system including an information processing device according to an embodiment of the present invention. FIG. 2 is an explanatory diagram showing an example of a time range that is an event implementation period. It is a figure showing an example of an event list screen. FIG. 6 is a diagram illustrating an example of a list screen of end events that can be revived. FIG. 7 is a diagram illustrating an example of an end event restoration confirmation screen. FIG. 7 is a diagram illustrating an example of an end event overwrite confirmation screen. It is a figure showing an example of an event list screen. 1 is a diagram showing the hardware configurations of an information processing device and a terminal according to an embodiment of the present invention. FIG. FIG. 2 is an explanatory diagram of functions of a terminal according to an embodiment of the present invention. FIG. 2 is an explanatory diagram of functions of a server that constitutes an information processing apparatus according to an embodiment of the present invention. It is a flowchart which shows the flow of event play permission determination processing. 3 is a flowchart showing the flow of end event restoration processing. 12 is a flowchart showing another flow of the end event restoration process. It is a flowchart which shows the flow of end event revival processing in joint play.

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, an information processing apparatus, an information processing method, and a program according to the present invention will be described in detail with reference to preferred embodiments shown in the accompanying drawings.
Note that the embodiments described below are merely examples given to facilitate understanding of the present invention, and do 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.
Furthermore, the screen examples shown in the figures referred to in the following explanations are merely examples, and the screen configuration examples, displayed information, and specific contents of the GUI (Graphical User Interface), etc. It can be designed and changed freely according to specifications and user preferences.

<About the game>
The communication system shown in FIG. 1 (hereinafter referred to as game system S) is a communication system including an information processing device (hereinafter referred to as server 30) according to an embodiment of the present invention, Provide games.

"Game" is an online game provided using Game System S, in which you select various events that occur and play as you progress through the selected events (hereinafter referred to as "play"). It's a game. In this embodiment, as an example of a game, a user U forms a team consisting of a plurality of characters, operates those characters through predetermined actions, fights against enemy characters, and participates in a plurality of events prepared in the game. Here are some games that progress by successively challenging and clearing the game. Furthermore, in the game of this embodiment, the user U can obtain various objects that can be used in the game by logging in, clearing an event, purchasing, drawing, or the like.

The "object" includes, for example, a character that moves in response to the operation of the user U within the game, an item for advantageously advancing the game, and the like. The number of objects held increases according to login, event clearing, purchase, lottery result (winning), etc., and the number of objects held decreases when consumed or discarded within the game.

The "lottery" is one of the mechanisms in the game by which the above-mentioned objects can be obtained, and is implemented in response to a request from the user U during play of the game. In the lottery, a plurality of objects with different winning probabilities are prepared as candidates, one or a predetermined number of objects are won from among the plurality of candidate objects, and the winning objects are given to the user U.

Note that there are various forms of lottery, for example, "single-shot" lottery, which is held only once, and "N" lottery, which is held N times (N is a natural number of 2 or more) consecutively. Includes a consecutive lottery. In addition, there are various conditions for conducting a lottery, such as a lottery that can be conducted by consuming a lottery item that can be obtained for free, a lottery that can be conducted by consuming a lottery item that has been purchased for a fee, and a lottery that can be conducted by consuming a lottery item that has been purchased for a fee. This includes the lottery that can be held.

An "event" is also called a "quest" or the like, and refers to a mission given to the user U in a game, that is, an individual stage that makes up the game. Time ranges and achievement conditions are set for each event, and various events occur as the game progresses. Examples of the event include an event where the user encounters or fights with an enemy character, an event where the goal is to reach a certain point, an event where an object such as an item can be obtained, and the like. Note that completing the event by satisfying the set achievement conditions is called clearing, and when the event is cleared, the user U can obtain a clearing reward.
In the present embodiment, an example of an event in which the enemy character is fought and the enemy character can be obtained as a clear reward, that is, the enemy character can be incorporated into the team in subsequent events as an ally, will be described below.

The "time range" refers to the range of event holding times set for each event, as shown in FIG. The time range is allocated to each event, and is set so that some kind of event is held at all times, in principle. Further, the time ranges may be set to overlap so that a plurality of events are held simultaneously in the same time zone.
For example, as shown in Figure 2, the time range of "Event Title A" is the two-hour period from 0:00 to 2:00 on February 14th, which is the range shown by the solid line in the diagram. If the time is within that time range, user U can play "event title A." In addition, the time range of "Event Title B" (4 hours from 0:00 to 4:00 on February 14th) is set to partially overlap in the same time period, and the current time is set to the overlapped time range. Within the time range, user U can select and play either "event title A" or "event title B."

As a general rule, user U cannot play an end event that ends after the set time range has elapsed. However, in the present embodiment, even if it is an end event, within the recovery period of the end event, if a predetermined condition is satisfied according to the user U's predetermined operation, the user U who performed the predetermined operation will be able to revive and play the ending event. Note that the number of times that an end event can be revived may be limited to a predetermined number of times (for example, once) for each event.

The "recovery period" refers to a period (for example, within 24 hours from the end of the event) during which the user U can perform a predetermined operation on the end event to restore the end event. For example, as shown in Figure 2, the recovery period for "Event Title A" is 24 hours from 2:00 on February 14th to 2:00 on February 15th, which is the range shown by the broken line in the diagram. It's time. At this time, the period during which the end event can be revived and played may be limited to the recovery period, or it may be possible to play beyond the recovery period if a predetermined operation is performed within the recovery period. Note that an end event that is within the recovery period and has not yet been revived is also referred to as a reviveable event.

A "predetermined operation" is an operation that the user U performs in the game to revive the ending event, and specifically, the use of an item to consume the item after the event's time range ends. means. The item used here may be a general-purpose item that can be used for various purposes in the game, such as holding a lottery, or may be a special item for reviving an ending event. Note that if the user U has a dedicated item, the dedicated item may be automatically consumed first, giving priority to the general-purpose item when using the item.

The "predetermined condition" is a condition set in advance for reviving the end event, and can be satisfied by performing the above-described predetermined operation. That is, in the present embodiment, the predetermined condition is that the user U uses and consumes the item within the recovery period of the end event.

"Revival" refers to making the end event playable for a predetermined period of time for the user U who has performed the above predetermined operation.

The "predetermined time" refers to the time (for example, one hour) during which the user U who performed the above-mentioned predetermined operation can play the revived end event. For example, as shown in Figure 2, if the specified operation is performed on "Event Title A" at 21:30 on February 14th within the recovery period, then the up to the predetermined time.

Note that in this embodiment, the number of end events that can be revived and played simultaneously is limited to a predetermined number or less (for example, one).
For example, if the number of end events that can be played at the same time is one, while the already revived end event (first event) is in a playable state (that is, within the predetermined time of the first event), When the other end event (second event) is revived and made playable in response to the above-mentioned predetermined operation by user U, the predetermined time of the already revived first event ends and becomes unplayable. , the end event that can be played is changed from the first event to the second event. Note that the second event may not be revived and the second event may not be played until the first event ends after a predetermined period of time has elapsed.

Furthermore, in this embodiment, after an event once ends, the same event may be held again. For example, as shown in FIG. 2, "Event Title F" is held once at 6:00 on February 14th, but will be held again at 18:00 on February 14th. At this time, the first time range (3 hours from 6:00 to 9:00 on February 14th) corresponds to the first time range, and the second time range (from 18:00 on February 14th) 3 hours until 21:00) corresponds to the second time range. In this case, even if the user U performs a predetermined operation between the first time range and the second time range to revive "event title F" whose first time range has ended, the timing of the predetermined operation (for example, 17:30 on February 14th, etc.), the predetermined time set for the revived "event title F" and the second time range may partially overlap. In this way, if the end event is held again if you wait a little longer and there is an opportunity to play the end event again without consuming items, notify user U of an alert and reconfirm. You can also use it as

Here, with reference to FIGS. 3 to 7, the transition of the screen displayed on the user terminal 10 when the user U revives the finished event will be described. 3 to 7 are examples of screens displayed on the user terminal 10 operated by the user U during game play.

First, as shown in FIG. 3, when an event is selected, an event list screen 50 is displayed on the user terminal 10.
On the event list screen 50, events that the user U can play, that is, events within a time range (for example, "Event Title Z", etc.) are displayed side by side. For each event, explanations such as the event title, difficulty level, enemy character (character obtained as a clear reward), and remaining time range are displayed so that the content of the event can be recognized.
Also displayed on the event list screen 50 is a guide button 52 that transitions to a revivable event list screen 51 for selecting and reviving an end event.

When the user U taps the guidance button 52 on the event list screen 50, a reviveable event list screen 51 is displayed as shown in FIG.
On the reviveable event list screen 51, reviveable events associated with each user U are displayed side by side. For each resurrectable event, explanations such as whether it has been cleared, play conditions, characters obtained as rewards for clearing, difficulty level, and remaining recovery period are displayed so that the content of the event can be recognized. . The reviveable events displayed on the reviveable event list screen 51 are limited to the finished events within the recovery period that have not yet been revived. For finished events that have already been revived, you can select the reviveable event list screen 51. will be deleted. In addition, reviveable events for which the play conditions are not met, such as when user U does not own a character that has reached the level required to play the event, are displayed so that they can be distinguished from other reviveable events ( For example, it is grayed out), so that the user U cannot select it even if he or she taps it. Furthermore, although the reviveable events are, in principle, arranged in order with the oldest ending date and time at the top, they can be sorted or rearranged by tapping the sort button 53 or the like.
Further, the reviveable event list screen 51 displays the number of possessions of exclusive items for reviving the ended event.

When the user U selects and taps an arbitrary revivable event that he/she wishes to restore on the revivable event list screen 51, an end event restoration confirmation screen 54 is displayed as shown in FIG.
The finished event resurrection confirmation screen 54 displays the details of the event to be revived (for example, "Event Title A"), an explanation for reviving the event, an accept button 55, and a reject button 56, allowing the user U to In response, a final confirmation is made as to whether or not to use the item to revive the selected event.

On the other hand, when the user U selects and taps on any reviveable event that he/she wants to revive on the reviveable event list screen 51, an end event that has already been revived (limited to events within a predetermined time) is selected. If there is an end event overwrite confirmation screen 57, as shown in FIG. 6, is displayed.
The finished event overwrite confirmation screen 57 displays the contents of the revived finished event to be deleted (for example, "Event Title B"), the contents of the event to be revived (for example, "Event Title A"), and the information for resurrecting the event. An explanation, an accept button 55, and a reject button 56 are displayed, and the user U is asked whether or not to use the item to revive the selected event after finishing the revived finished event. A confirmation will be made. Note that the remaining predetermined time is also displayed in the content of the revived end event to be deleted.

When the user U taps the accept button 55 on the finished event revival confirmation screen 54 or the finished event overwrite confirmation screen 57, the revived finished event is displayed alongside the events within the time range, as shown in FIG. An event list screen 50 is displayed. At this time, the revived end event is preferentially displayed at the top. Like other events, the revived end event has information such as the event title, difficulty level, enemy character (character obtained as a clear reward), and remaining predetermined time so that the content of the event can be recognized. A description is displayed. Furthermore, the revived end event is labeled with "revived" so that it can be distinguished from other events. Further, the revived end event may be displayed by changing its design or color so that it can be distinguished from other events.

Then, by selecting and tapping the finished event that the user has revived on the event list screen 50, the user U can set the event for a predetermined period of time even though the current time is not within the time range set for that event. can be played.

In this embodiment, it is possible not only for the user U to play alone, but also for so-called multi-play (hereinafter referred to as joint play) in which multiple users U operate their respective user terminals 10 to simultaneously play a common event. be. In this joint play, there is a user U (hereinafter referred to as a host) who hosts a joint play for a specific event and recruits friends, and a user U (hereinafter referred to as a guest) who applies for the recruitment and participates in the joint play. ), a collaborative relationship is formed, and the progress of play is synchronized between users who play together.

The joint play is performed through the communication function of the user terminal 10 of each user U. Specifically, when a certain user U applies to participate in a cooperative play solicited by a host, and the host approves the application, that certain user U applies as a guest to participate in a cooperative play with the host. A communication path is established. Note that the application qualification for joint play is not particularly limited and can be set arbitrarily. For example, another user U who has a friendship with a certain user U, and a friend user who has mutually approved the user U, may be able to apply.

Thereafter, transmission and reception of various data required for joint play is performed according to a known communication method. The data at this time may be a client-server method via the server 30, or may be a P2P (peer-to-peer) method not via the server 30. Further, the style of collaborative play is classified into fully synchronous type and asynchronous type, but either style may be adopted. Note that the fully synchronous type includes a key input synchronous method and a command input method, and the asynchronous type includes a server centralized processing type and a client distributed processing.

Note that the cooperative play compatible game includes a cooperative play game in which a plurality of users U cooperate and a competitive game in which users U compete against each other, but may be of any type. Further, the upper limit of the number of users U (maximum number of players) in one joint play is not particularly limited and may be set to any number, but it is preferably set to about 4 at most, for example.

Even in the case of this joint play, the user U can revive the ending event. However, in order to jointly play the revived end event, all users U, both hosts and guests, who participate in the joint play need to perform the above-mentioned predetermined operations and satisfy the predetermined conditions. In addition, in order to jointly play the revived end event, the host must at least play within the specified time of the end event that the host has revived, and if the predetermined time of the end event that the host has revived has already passed, the guest will play the revived end event alone. Furthermore, if an event similar to the ending event revived by the host is within the time range for the guest and does not fall under the ending event, the guest does not have to go through the trouble of reviving that event and can participate in joint play. I can do it.

<About the configuration of game system S>
Next, the configuration of the game system S for providing the above game to the user U will be described.
As shown in FIG. 1, the game system S is constructed for a user U to play a game, and includes an information terminal (hereinafter referred to as user terminal 10) operated by the user U, and a server 30. It is composed of. The user terminal 10 and the server 30 are connected to be able to communicate with each other via a network N such as the Internet.

The user terminal 10 is equipped with a program stored in the terminal and a processor that executes the program, and is carried by its owner, the user U, who uses the user terminal 10 when playing. operate. As the user terminal 10, a known device used as a game terminal, such as a smartphone, a mobile phone, a notebook PC, a tablet terminal, a wearable terminal, or a game-dedicated device with a communication function, can be used. Note that the number of user terminals 10 constituting the game system S is not particularly limited and may be any number, but in FIG. 1, the number of user terminals 10 is three for convenience of illustration.

The server 30 is a computer that constitutes the information processing apparatus of the present invention. For example, it is constituted by a server computer managed by a game providing company, and is responsible for game progress processing. Specifically, the game account, status, etc. of each user U are managed for each user U, and game progress data is distributed to each user U. Furthermore, the server 30 is not limited to a server device consisting of a single computer that independently performs a specific function, but rather a plurality of computers that exist in a distributed manner but work together to perform a specific function. It may be configured by a server device group consisting of.

The network N may be any network that connects the user terminal 10 and the server 30 in a state where data communication is possible. It includes the Internet, mobile communication networks, LANs (Local Area Networks), WANs (Wide Area Networks), intranets, Ethernet (registered trademark), etc., regardless of whether they are wired or wireless. Further, the user terminals 10 may communicate with each other via the network N, or may communicate directly with each other without going through the network N via Bluetooth (registered trademark), Wifi-Direct, or the like.

In the game system S of this embodiment, with the above configuration, the game progresses as the user terminal 10 and the server 30 cooperate. Specifically, a part of the game progress processing is performed on the server 30 side, and a part of the graphic processing etc. is performed on the user terminal 10 side. For example, a program including certain rules, logic, and algorithms is executed on the server 30 side. On the other hand, on the user terminal 10 side, the game progresses by generating various events in synchronization with the server 30 and using the same rules, logic, and algorithms as the program being executed on the server 30.

<Configuration of user terminal 10>
Next, the configuration of the user terminal 10 according to this embodiment will be described.
As shown in FIG. 8, the user terminal 10 has a hardware configuration including a processor 11, a storage device 12, a communication interface (referred to as communication I/F in FIG. 8) 13, an input device 14, and an output device. 15, and these devices are electrically connected via a bus (not shown).

The processor 11 includes, for example, a central processing unit, a microprocessor, a graphics processor, a digital signal processor, etc., and is stored in the storage device 12. It executes various arithmetic processing based on programs or data, and also controls each part of the user terminal 10. The programs executed by the processor 11 include an OS (Operating System), which is system software for controlling the entire user terminal 10, and application programs for games, and these various programs are read by the processor 11. By being executed, the functions of the user terminal 10 forming the game system S are exhibited.

The storage device 12 includes, for example, a memory or a storage, and stores various programs or data.
The memory is composed of semiconductor memories such as ROM (Read Only Memory) and RAM (Random Access Memory), and provides a work area for the processor 11 by temporarily storing programs and data, and processes executed by the processor 11. Temporarily stores various data generated by.
The storage stores various data related to the game, and includes, for example, flash memory, HDD (Hard Disc Drive), SSD (Solid State Drive), FD (Flexible Disc), MO disk (Magneto-Optical disc), and CD (Compact Disc). , a DVD (Digital Versatile Disc), an SD card (Secure Digital card), and a USB memory (Universal Serial Bus memory).

The communication interface 13 is configured by, for example, a network interface card (NIC), and controls communication processing of the user terminal 10. The communication standard used by the communication interface 13 is not particularly limited, and any communication standard for the public can be applied without restriction. Further, the communication method using the communication interface 13 may be a wireless method or a wired method.

The input device 14 is a device that receives an operation from the user U and generates data indicating the content of the accepted operation. As an example, operation keys, operation buttons, a sound collection microphone, a photographing camera, etc. provided on the user terminal 10 can be used.

The output device 15 is a device that draws a screen to display images, character string information, etc., and reproduces audio. As an example, a liquid crystal display, an organic EL (Electroluminescence) display, a head mounted display, a speaker, etc. provided in the user terminal 10 can be used. Note that in this embodiment, the output device 15 includes at least a display. The display may have the functions of both the input device 14 and the output device 15, such as a touch panel display.

Next, with reference to FIG. 9, the configuration of the user terminal 10 will be explained again from a functional perspective.
As shown in FIG. 9, the user terminal 10 includes a plurality of functional units, specifically, an operation specifying unit 16, a terminal storage unit 17, a terminal generating unit 18, a terminal transmitting and receiving unit 19, and a display processing unit. 20. These functional units are realized by the cooperation of the hardware equipment of the user terminal 10 and a program as software stored in the user terminal 10.

[Operation identification unit 16]
The operation specifying unit 16 is mainly realized by the processor 11 and the input device 14, and specifies the contents of various operations performed by the user U through the input device 14 of the user terminal 10. The operations specified by the operation specifying unit 16 include operations for progressing the game, operations related to joint play (operations related to solicitation of joint play, application for joint play, and permission/disapproval of the application), and the like. Operations for progressing the game include operations for selecting an event to play, operations for selecting an end event to be revived, operations for instructing the use of an item to revive an end event, and the like.

[Terminal side storage unit 17]
The terminal side storage unit 17 is mainly realized by the processor 11 and the storage device 12, and stores various data related to game progress (eg, video data, image data, audio data, etc.).

[Terminal side generation unit 18]
The terminal-side generation unit 18 is mainly realized by the processor 11 and the storage device 12, and generates game operation data and the like according to the operation content of the user U specified by the operation identification unit 16. The game operation data generated here includes event selection data based on event selection operation or end event selection operation, item use instruction data based on item use instruction operation, and operation data related to cooperative play (cooperative play recruitment, cooperative (Includes operation data, etc. regarding applications for play and permission/disapproval of the application.) These generated data are transmitted to the server 30 by the terminal-side transmitting/receiving section 19 .

[Terminal side transmitter/receiver 19]
The terminal-side transmitting/receiving unit 19 is mainly realized by the processor 11, the storage device 12, and the communication interface 13, and transmits and receives data and information between the server 30 and the user terminal 10 of another user U. For example, during game play, the terminal-side transmitting/receiving unit 19 receives game progress data sent from the server 30 and transmits game operation data to the server 30. In addition, when a joint game play is being performed, the terminal-side transmitting/receiving unit 19 transmits joint play data (specifically, game operation data of each user U) with the user terminals 10 of other users U. may be sent and received.

[Display processing unit 20]
The display processing section 20 is mainly realized by the processor 11, the storage device 12, and the output device 15, and executes a display process of displaying the data and information received by the terminal-side transmitting/receiving section 19 on a display using a browsing function. Specifically, the display processing unit 20 draws the game screen at the start of the game, and during game play, develops the game progress data received by the terminal-side transmitting/receiving unit 19 from the server 30, and displays images and images on the game screen. View additional information. Also, during game play, the display processing unit 20 displays an image that changes according to the game operation data generated by the terminal-side generation unit 18 (specifically, an image that moves according to the operation of the user U) on the game screen. indicate.

<Configuration of server 30>
Next, the configuration of the server 30 according to this embodiment will be explained.
As shown in FIG. 8, the server 30 has the same hardware configuration as a general server computer, and includes a processor 31, a storage device 32, and a communication interface (referred to as communication I/F in FIG. 8). ) 33, and these devices are electrically connected via a bus (not shown).

The processor 31 is composed of a CPU, MPU, GPU, DSP, etc., and executes various processes by executing programs installed on the server 30. The programs executed by the processor 31 include an OS, which is system software for controlling the entire server 30, and an application program for causing the server 30 to function as the information processing device of the present invention.

The storage device 32 includes, for example, memory or storage, and stores various programs or data.
The memory is composed of semiconductor memories such as ROM and RAM, and provides a work area for the processor 31 by temporarily storing programs and data, and temporarily stores data generated by various processes executed by the processor 31. Remember.
The storage stores various data related to the user U, the game, etc., and includes, for example, a flash memory, HDD, SSD, FD, MO disk, CD, DVD, SD card, USB memory, and the like. Note that a database server computer connected to the server 30 via the network N may be used as a storage.

The communication interface 33 is configured by, for example, a network interface card or the like, and controls communication processing of the server 30. The communication standard used by the communication interface 33 is not particularly limited, and any communication standard for the public can be applied without restriction. Further, the communication method using the communication interface 33 may be a wireless method or a wired method.

Next, the configuration of the server 30 will be explained again from a functional perspective with reference to FIG. 10. As shown in FIG. It includes a side transmitting/receiving section 35, a server side generating section 36, a control section 37, an information providing section 38, and a notification section 39. These functional units are realized by the cooperation of the hardware equipment of the server 30 and a program as software stored in the server 30. In addition, when the server 30 is comprised of multiple computers, the above-mentioned functions may be distributed so that each of the multiple computers may perform different functions.

[Server side storage unit 34]
The server-side storage unit 34 is mainly realized by the processor 31 and the storage device 32, and stores various data including data related to the user U, data related to game progress processing (game progress data), and the like.
Data regarding user U includes an identifier (user ID or terminal ID) that identifies user U or the user terminal 10 used by user U, and various information associated with the identifier (user U's personal information, user terminal 10 (including device model, access history, payment history, game progress such as status, etc.).
Game progress data includes information on characters owned by user U (name, attributes, abilities, levels, etc.), information on other objects such as items owned by user U, and information on events set for each user U. It includes various information (time range of the event, recovery period of the finished event, recovery status of the finished event, etc.).

[Server side transmitter/receiver 35]
The server-side transmitting/receiving unit 35 is mainly realized by the processor 31, the storage device 32, and the communication interface 33, and transmits and receives data and information to and from the user terminal 10. For example, while playing a game, the server-side transmitting/receiving unit 35 transmits game progress data to the user terminal 10 of the user U, and receives game operation data from the user terminal 10. Further, while the game is being played jointly, the server-side transmitting/receiving unit 35 receives data for joint play from the user terminals 10 of each of the plurality of users U who are playing the joint game, and synchronizes the users U. data (game progress data in a broad sense) is transmitted to each user terminal 10.

[Server side generation unit 36]
The server-side generation unit 36 is mainly realized by the processor 31 and the storage device 32, and generates data to be transmitted by the server-side transmission/reception unit 35. Specifically, the data generated here includes game progress data corresponding to the game operation data received from the user terminal 10. Note that the game progress data includes event list screen display data that causes the event list screen 50 to be displayed on the user terminal 10, reviveable event list screen display data that causes the reviveable event list screen 51 to be displayed on the user terminal 10, and end event resurrection. Confirmation screen data that causes the confirmation screen 54 or end event overwrite confirmation screen 57 to be displayed on the user terminal 10, event data that displays information about the selected event on the user terminal 10 and allows the user U to play the event, collaborative play Collaborative play start screen data that causes a collaborative play start screen to be displayed on the user terminals 10 of a plurality of users U who perform collaborative play, and It also includes data for synchronizing users U.

[Control unit 37]
The control unit 37 is mainly realized by the processor 31 and the storage device 32, and instructs the user U whether or not to play an event based on the relationship between the time range set for each event in the game and the current time. Control. In addition, even if the event ends after the set time range has passed, the control unit 37 controls the control unit 37 if the user U performs a predetermined operation such as using an item within the recovery period after the end of the event and satisfies the predetermined condition. controls the user U who has revived the finished event and performed a predetermined operation to be able to play the revived finished event for a predetermined period of time. In addition, in the case of joint play, if all the hosts and guests participating in the joint play, except for user U whose event for joint play is within the time range, meet the specified conditions, the play of the revived end event will be resumed. control to make it possible.
Note that the control unit 37 limits the number of times that an end event can be revived to a predetermined number of times for each event. Further, the control unit 37 ends the predetermined time of the first event and disables play, and changes the end event that can be played from the first event to the second event, or By disabling the second event from being played until it ends after a predetermined time has elapsed, the number of finished events that can be revived and played at the same time is limited to a predetermined number or less.

[Information provision department 38]
The information providing unit 38 is mainly realized by the processor 31, the storage device 32, and the communication interface 33, and cooperates with the server-side transmitting/receiving unit 35 to provide information that is set for each user U according to the game progress of the user U. , provides the user terminal 10 with information regarding revivable events that can be revived among the terminated events. Note that information regarding revivable events is provided to the user terminal 10 as revivable event list screen display data.

[Notification section 39]
The notification unit 39 is mainly realized by the processor 31, the storage device 32, and the communication interface 33, and cooperates with the server-side transmitting/receiving unit 35 to determine a predetermined time set for an event to be revived in response to a predetermined operation by the user U. , and the second time range of the event, an alert is notified to the user terminal 10.

Although the user terminal 10 and the server 30 generally have various functions other than those described above, only the characteristic functions that have effects in the game system S of the present invention will be explained here. Illustrations and explanations of other known functions and the like will be omitted.

<About the processing flow of game system S>
Next, the flow of processing executed in the game system S having the above configuration will be described with reference to FIGS. 11 to 14.
The information processing method according to the present embodiment is realized by using the game system S functioning as a computer system. In other words, the information processing method according to the present embodiment is applied to the information processing executed by the game system S. There is.

The information processing executed in the game system S according to the present embodiment can be roughly divided into a process of determining whether or not an event can be played based on the relationship between the time range set for each event and the current time. This process is mainly composed of two processes: a process for reviving an end event whose time range has ended and making it playable [end event revival process]. Each process will be explained individually below.

[Event play availability determination process]
First, based on FIG. 11, the event play permission determination process will be described.
The "event play availability determination process" is a process executed by the server 30, which informs the user U whether or not the event can be played based on the relationship between the time range set for each event and the current time. Refers to the process of determining.

As shown in FIG. 11, the server 30 compares the current time with the time range set for the event, and if it determines that the current time is within the time range of the event (S101: YES), the server 30 determines that the current time is within the time range of the event (S101: YES). If there is no event, start the event, and if the event has already started, continue the event as it is to set the event to a playable state for the user U (S102), and make the event playable. The event set in the status is added to the event list screen 50 as shown in FIG. 3 (S103).

On the other hand, if the server 30 determines that the current time is not within the event time range (S101: NO), it ends the event in progress and sets the event to a state where the user U cannot play the event ( S104), the end event set to an unplayable state is deleted from the event list screen 50 (S105). Then, the server 30 compares the current time with the recovery period of the end event, and if it determines that the current time is within the recovery period of the end event (S106: YES), the server 30 selects the end event as shown in FIG. It is added to the list screen 51 of revivable events (S107). Note that if it is determined that the current time is not within the recovery period of the end event (S106: NO), the process of S107 is not performed and the process moves to the next process.

Then, the server 30 transmits event list screen display data for displaying the event list screen 50 and reviveable event list screen display data for displaying the reviveable event list screen 51 to the user terminal 10 (S108), Finish the process.

When the series of steps described above are completed, the event play permission determination process ends. Thereafter, the series of steps described above is repeatedly performed while the user U is playing the game, or as time passes even when the user U is not playing the game.
The above is an example of the event play permission determination process.

[End event restoration process]
Next, the end event restoration process will be explained based on FIGS. 12 and 13.
The "end event revival process" is a process executed by the server 30, and refers to a process that revives an end event whose time range has ended and makes it playable.

As shown in FIG. 12, when the server 30 receives event selection data indicating the end event (revivable event) selected by the user U from the reviveable event list screen 51 from the user terminal 10 (S201) , it is determined whether the user U satisfies the play conditions (S202).

When the server 30 determines that the user U satisfies the play conditions (S202: YES), the server 30 then compares the predetermined time set when the end event is revived with the second time range, As a result of the comparison, if it is determined that the predetermined time does not overlap with the second time range (S203: YES), or if it is determined that the predetermined time overlaps with the second time range (S203: NO), the user terminal 10, if the user U confirms and accepts the alert after sending notification data to display the alert (S204) and accepts the alert (S205: YES), whether or not there are other termination events that have already been revived. That is, it is determined whether the first event is in a playable state (S206). Note that even if the second time range does not exist for the end event, it is determined that the predetermined time and the second time range do not overlap (S203: YES).

If the server 30 determines that there is no other end event that has already been revived (S206: YES), the server 30 sends confirmation screen data that causes the user terminal 10 to display an end event restoration confirmation screen 54 as shown in FIG. Then, the user U is notified of the recovery confirmation (S207). On the other hand, if the server 30 determines that there is another end event that has already been revived (S206: NO), the server 30 causes the user terminal 10 to display an end event overwrite confirmation screen 57 as shown in FIG. The data is transmitted and an overwrite confirmation notification is sent to the user U (S208). When the server 30 determines that the user U has consented by tapping the accept button 55 on the end event revival confirmation screen 54 or the end event overwrite confirmation screen 57 (S209: YES), the server 30 then updates the current time and It is compared with the recovery period of the end event to determine whether the current time is within the recovery period of the end event (S210).

When the server 30 determines that the current time is within the recovery period of the end event (S210: YES), it consumes the items owned by the user U (S211) and sends the selected end event to the user U. It is revived and set to a playable state (S212). Then, the server 30 deletes the selected end event set to a playable state from the revivable event list screen 51 and adds it to the event list screen 50 as shown in FIG. 7 (S213).

Then, the server 30 transmits event list screen display data for displaying the event list screen 50 and reviveable event list screen display data for displaying the reviveable event list screen 51 to the user terminal 10 (S214), Finish the process.

Note that if the server 30 determines that the user U does not satisfy the play conditions (S202: NO) or that the current time is not within the recovery period of the end event (S210: NO), Notification data for displaying that the end event cannot be revived is sent to the user terminal 10, and the user U is notified that the event cannot be revived (S215), and the process ends. In addition, if the user U does not consent to the alert notification (S205: NO), or if the user U does not consent by tapping the reject button 56 on the end event revival confirmation screen 54 or the end event overwrite confirmation screen 57. If it is determined (S209: NO), the process ends immediately.

In addition, in the end event restoration process, if there is another end event that has already been revived, the first event is not overwritten by the second event until the first event ends after a predetermined time has elapsed. may be such that the second event cannot be revived.

Specifically, as shown in FIG. 13, the server 30 receives event selection data indicating the end event (revivable event) selected by the user U from the reviveable event list screen 51 from the user terminal 10. When received (S301), it is determined whether the user U satisfies the play conditions (S302).

When the server 30 determines that the user U satisfies the play conditions (S302: YES), the server 30 then compares the predetermined time set when the end event is revived with the second time range, As a result of the comparison, if it is determined that the predetermined time does not overlap with the second time range (S303: YES), or if it is determined that the predetermined time overlaps with the second time range (S303: NO), the user terminal 10, if the user U confirms and accepts the alert after sending notification data to display the alert (S304) and accepts the alert (S305: YES), whether or not there are other termination events that have already been revived. That is, it is determined whether the first event is in a playable state (S306).

If the server 30 determines that there is no other end event that has already been revived (S306: YES), the server 30 sends confirmation screen data that causes the user terminal 10 to display an end event restoration confirmation screen 54 as shown in FIG. Then, the user U is notified of the recovery confirmation (S307). When the server 30 determines that the user U has consented by tapping the accept button 55 on the end event revival confirmation screen 54 or the end event overwrite confirmation screen 57 (S308: YES), the server 30 then updates the current time and It is compared with the recovery period of the end event to determine whether the current time is within the recovery period of the end event (S309).

When the server 30 determines that the current time is within the recovery period of the end event (S309: YES), it consumes the items owned by the user U (S310) and sends the selected end event to the user U. It is revived and set to a playable state (S311). Then, the server 30 deletes the selected end event set to a playable state from the reviveable event list screen 51 and adds it to the event list screen 50 as shown in FIG. 7 (S312).

Then, the server 30 transmits event list screen display data for displaying the event list screen 50 and reviveable event list screen display data for displaying the reviveable event list screen 51 to the user terminal 10 (S313), Finish the process.

Note that if the server 30 determines that the user U does not meet the play conditions (S302: NO), if it determines that there is another ending event that has already been revived (S306: NO), or if the current time is If it is determined that the end event is not within the recovery period (S309: NO), notification data is sent to the user terminal 10 to display that the end event cannot be revived, and the user U is informed that the end event cannot be revived. A notification is made (S314), and the process ends. Further, if the user U does not consent to the alert notification (S305: NO), or if it is determined that the user U does not consent by tapping the reject button 56 on the end event revival confirmation screen 54 (S308: NO), the process ends.

When the series of steps shown in FIG. 12 or 13 described above is completed, the end event restoration process ends. From then on, while the user U is playing the game, strictly speaking, when the user U selects an end event (revivable event) from the reviveable event list screen 51, the above series of steps is performed. is carried out repeatedly.
The above is an example of the end event recovery process.

[End event revival process in cooperative play]
Next, based on FIG. 14, among the finished event resurrection processes, particularly the finished event resurrection process in joint play will be described.
“End event revival processing in collaborative play” is a process executed by the server 30, and the host When a host and guest are recruiting friends to participate in a joint play, this is a process in which both the host and the guest revive an event whose time range has ended and make it playable.

As shown in FIG. 14, the server 30 first transmits a joint play recruitment list including the end event revived by the host to other users U who can become guests (S401). Then, when the server 30 receives an application for participation from a guest in the joint play of the revived end event from the recruitment list (S402), the server 30 determines whether the guest is also a revived end event with respect to the target event. It is determined whether (S403).

If the server 30 determines that the end event has already been revived by the guest (S403: YES), then it compares the current time with a predetermined time of the end event that the host has revived, and if the current time is the end event that the host has revived. It is determined whether or not it is within a predetermined period of time for the end event that occurred (S404). Then, when the server 30 determines that the current time is within the predetermined time of the end event that the host has revived (S404: YES), the server 30 sets the guest to a state in which co-play of the revived end event is possible. (S405), and transmits joint play start screen data for displaying a joint play start screen notifying that joint play will start for the revived end event to the guest's user terminal 10 (S406), and ends the process. do.

On the other hand, if the server 30 determines that the event is not a revived end event for the guest (S403: NO), or if the server 30 determines that the current time is not within the predetermined time of the end event revived by the host (S404: NO), notification data is sent to the guest's user terminal 10 to display that the guest cannot participate in the joint play, thereby notifying the guest that the guest cannot participate in the joint play (S407), and the process ends.

When the above-mentioned series of steps are completed, the ending event revival process in the joint play ends. From then on, while user U is playing the game, strictly speaking, the above series of steps will be performed when user U, who is the host, recruits friends to participate in joint play for a revived end event. It is carried out repeatedly.
The above is an example of the end event revival process in collaborative play.

<Other embodiments>
The present invention is not limited to the embodiments described above.
In the above embodiment, the server 30 executes the program of the present invention and functions as the information processing device of the present invention, but some or all of the functions of the information processing device of the server 30 are It is also possible to prepare for 10. For example, the user terminal 10 may have a function equivalent to the control unit 37 or the like.

Furthermore, in this embodiment, an online game using data communication performed between the user terminal 10 operated by the user U and the server 30 has been described as an example of the game. However, the type of game is not particularly limited, and may be an offline game that does not require data communication. Furthermore, for example, it may be a social game that can be used only with a web browser and an SNS (Social Networking Service) account.

<Summary>
The main features of the information processing apparatus, information processing method, and program according to the present embodiment described above are as follows.

[1] The information processing device according to the present embodiment includes a control unit that controls whether or not the event can be played based on the relationship between the time range defined for the event in the game and the current time, and the control unit includes: After the time range ends, if a predetermined condition is satisfied according to a predetermined operation by the user, the user who performed the predetermined operation is allowed to play the event for a predetermined time.
According to the above information processing device, even if the time range defined for the event has ended and the user has lost the opportunity to play the event, the user can continue to play the event by performing a predetermined operation and satisfying a predetermined condition. You can play for hours. Therefore, it is possible to improve the user's game satisfaction.

[2] In the information processing device described above, after the time range ends, if the number of times the user is enabled to play the event in response to a predetermined operation by the user reaches a predetermined number, the control unit: It is not possible to play an event according to a user's predetermined operation.
As a result, the user will not be able to play the event for which the time range has ended, even if the user performs a specific operation and satisfies the predetermined conditions, thereby further improving the user's game satisfaction while maintaining the game balance. can be done.

[3] In the above information processing device, the control unit limits the number of events that can be played simultaneously to a predetermined number or less after the time range ends.
As a result, even if a user performs a predetermined operation and satisfies a predetermined condition for an event whose time range has ended, the number of plays that can be played at the same time is limited to a predetermined number or less, so that the game balance is maintained and the user is satisfied with the game. It is possible to further improve the degree of

[4] In the information processing device described above, after the respective time ranges of the first event and the second event have ended, the control unit is configured to control the control unit while the first event is playable according to a predetermined operation by the user. Second, when the second event is made playable in response to a predetermined operation by the user, the first event is made unplayable.
This prevents the user from playing the first event and the second event at the same time even if the user performs a predetermined operation and satisfies the predetermined condition after the respective time ranges of the first event and the second event have ended. Therefore, it is possible to further improve the user's game satisfaction while maintaining the game balance.

[5] In the above information processing device, after the time range of each of the first event and the second event ends, the control unit controls whether the first event that has become playable according to a predetermined operation by the user The play of the second event is not enabled in response to a predetermined operation by the user until the play of the second event ends after a predetermined period of time has elapsed.
This prevents the user from playing the first event and the second event at the same time even if the user performs a predetermined operation and satisfies the predetermined condition after the respective time ranges of the first event and the second event have ended. Therefore, it is possible to further improve the user's game satisfaction while maintaining the game balance.

[6] The information processing device further includes an information providing unit that provides the user with information regarding an event that can be played in response to a predetermined operation by the user, among the events whose time range has ended; The control unit enables play of the event selected by the user based on the information.
This makes it easier for the user to select an event to play from among events whose time range has ended, thereby further improving the user's game satisfaction.

[7] In the above information processing device, an event has a first time range and a second time range, the second time range is after the first time range, and the event has a first time range and a second time range. The apparatus further includes a notification unit that notifies an alert when a playable time range of an event that becomes playable in response to a user's predetermined operation overlaps with the second time range between the ranges.
Thereby, the user is notified that the event for which the first time range has ended can be played in the second time range without performing a predetermined operation and satisfying a predetermined condition. Therefore, the user can easily select an event to play from among the events whose time range (first time range) has ended, and can also reconsider whether or not to perform a predetermined operation on that event. It is possible to further improve the user's game satisfaction.

[8] In the information processing device described above, when the user recruits co-players who play the game together with the user, and other users participate in the game as co-players and play the game together, the control unit controls the time range. After the event ends, if both the user and the other users satisfy a predetermined condition, the user and the other users are allowed to play the event.
As a result, in a joint play between multiple users, in order to play an event whose time range has ended, all the users participating in the joint play must perform the specified operation and satisfy the predetermined conditions, which improves the game balance. It is possible to further improve the user's game satisfaction while maintaining the same level of satisfaction.

[9] Further, according to the information processing method according to the present embodiment, the computer controls whether or not the event can be played based on the relationship between the time range defined for the event in the game and the current time, and After the event is completed, if a predetermined condition is satisfied according to a predetermined operation by the user, the user who performed the predetermined operation is allowed to play the event for a predetermined time.
According to the above information processing method, even if the time range specified for the event has ended and the user has lost the opportunity to play the event, the user can complete the event by performing a specified operation and satisfying a specified condition. You can play for hours. Therefore, it is possible to improve the user's game satisfaction.

[10] Furthermore, the program according to the present embodiment is a program executed by a computer, which causes the computer to play an event based on the relationship between the time range defined for the event in the game and the current time. If a predetermined condition is satisfied according to a predetermined operation by the user after the time range ends, the user who performed the predetermined operation is allowed to play the event for a predetermined time.
According to the above program, even if the user loses the opportunity to play an event because the time range specified for the event has ended, the user can play the event for a predetermined time by performing a predetermined operation and satisfying a predetermined condition. It becomes possible to do so. Therefore, it is possible to improve the user's game satisfaction.

10 User terminal 11 Processor 12 Storage device 13 Communication interface 14 Input device 15 Output device 16 Operation specifying section 17 Terminal side storage section 18 Terminal side generation section 19 Terminal side transmission/reception section 20 Display processing section 30 Server 31 Processor 32 Storage device 33 Communication interface 34 Server-side storage section 35 Server-side transmission/reception section 36 Server-side generation section 37 Control section 38 Information provision section 39 Notification section 50 Event list screen 51 Revivable event list screen 52 Guidance button 53 Sort button 54 Ended event resurrection confirmation screen 55 Accept button 56 Reject button 57 End event overwrite confirmation screen N Network S Game system U User

Claims (4)

Equipped with a processor,
The processor includes:
Controls whether the event can be played based on the relationship between the time range defined for the event in the game and the current time,
a second period in which the user can play the predetermined event if a predetermined condition is satisfied according to the user's first operation within a first period outside the first time range defined for the predetermined event; can be set,
Notifying the user of an alert based on the relationship between a second time range after the first time range defined in the predetermined event and the timing of performing the first operation;
Information processing device. The processor includes:
setting the second period when a consent operation is received from the user after notification of the alert;
causing the user to play the predetermined event if a second operation for the predetermined event is received from the user during the second period;
The information processing device according to claim 1. The processor controls whether or not the event can be played based on the relationship between the time range defined for the event in the game and the current time,
a second period in which the user can play the predetermined event if a predetermined condition is satisfied according to the user's first operation within a first period outside the first time range defined for the predetermined event; is configurable by the processor,
a processor notifies the user of an alert based on a relationship between a second time range after the first time range defined in the predetermined event and the timing of performing the first operation;
Information processing method. to the processor,
A function that controls whether or not an event can be played based on the relationship between the time range defined for the event in the game and the current time;
a second period in which the user can play the predetermined event if a predetermined condition is satisfied according to the user's first operation within a first period outside the first time range defined for the predetermined event; A function that allows you to set
a function of notifying the user of an alert based on a relationship between a second time range after the first time range defined in the predetermined event and the timing of performing the first operation;
A program to run.

Images