Information processing device, information processing method and program

Abstract

To provide an information processing device, information processing method and program enhancing a player's satisfaction by allowing the player to play even such an event that the player has lost an opportunity to play by termination of a time range set for the event.SOLUTION: An information processing device includes a control unit 37 controlling playability of an event based on a relation between a time range set for the event in a game and a current time. After the time range has been terminated, when a prescribed condition is satisfied depending on a prescribed operation of a user, the control unit 37 allows the user having executed the prescribed operation to play the event for a prescribed time.SELECTED DRAWING: Figure 10

Description

[Technical field]

[0001] The present invention relates to an information processing device, an information processing method, and a program. [Background technology]

[0002] 2. Description of the Related Art Conventionally, there have been known games, such as online games, in which a player selects various events that occur and progresses through the game by completing the selected events.

[0003] For example, Patent Document 1 discloses an information processing device that can easily select a time-limited event (referred to as a "quest" in Patent Document 1), which is a unit of play in a game. [Prior art documents] [Non-patent literature]

[0004] [Patent Document 1] JP 2019-188132 A Summary of the Invention [Problem to be solved by the invention]

[0005] However, since the event described in Patent Document 1 has a limited period during which it can be played, users often lose the opportunity to play when the period set for the event ends, which causes dissatisfaction among users.

[0006] Therefore, an objective of the present invention is to provide an information processing device, an information processing method, and a program that enable a user to play an event even when the time range set for the event has ended and the opportunity to play has been lost, thereby improving the user's level of game satisfaction. [Means for solving the problem]

[0007] An information processing device according to one embodiment of the present invention has a control unit that controls whether or not an event can be played based on the relationship between a time range set for an in-game event and the current time, and when a predetermined condition is satisfied in response to a predetermined operation by the user after the time range has ended, the control unit enables the user who performed the predetermined operation to play the event for a predetermined period of time. Effect of the Invention

[0008] According to one aspect of the present invention, it is possible to play an event even when the time range set for the event has ended and the opportunity to play has been lost, thereby improving the user's level of satisfaction with the game. [Brief description of the drawings]

[0009] [Figure 1] 1 is a conceptual diagram of a game system including an information processing device according to an embodiment of the present invention. [Diagram 2] FIG. 2 is an explanatory diagram showing an example of a time range during which an event is carried out. [Diagram 3] FIG. 13 illustrates an example of an event list screen. [Figure 4] FIG. 13 is a diagram showing an example of a list screen of ended events that can be revived. [Diagram 5] FIG. 13 is a diagram showing an example of a completed event revival confirmation screen. [Figure 6] FIG. 13 is a diagram showing an example of an end event overwrite confirmation screen. [Figure 7] FIG. 13 illustrates an example of an event list screen. [Figure 8] 1 is a diagram illustrating the hardware configuration of an information processing device and a terminal according to an embodiment of the present invention. [Figure 9] FIG. 2 is an explanatory diagram of functions of a terminal according to an embodiment of the present invention. [Figure 10] FIG. 2 is an explanatory diagram of functions of a server constituting an information processing device according to an embodiment of the present invention. [Figure 11] 13 is a flowchart showing the flow of an event play possibility determination process. [Figure 12]13 is a flowchart showing the flow of an ended event revival process. [Figure 13] 13 is a flowchart showing another flow of the ended event revival processing. [Figure 14] 13 is a flowchart showing the flow of an ended event revival process in cooperative play. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An information processing device, an information processing method, and a program according to the present invention will be described in detail below with reference to preferred embodiments shown in the accompanying drawings. The embodiment described below is merely an example given to facilitate understanding of the present invention, and is not intended to limit the present invention. In other words, the present invention may be modified or improved from the embodiment described below without departing from the spirit of the present invention. Naturally, the present invention also includes equivalents thereof. Furthermore, the screen examples shown in each of the figures referenced in the following description are merely examples, and examples of screen configurations, displayed information, and specific contents of the GUI (Graphical User Interface), etc., can be freely designed and changed according to design specifications and user preferences.

[0011] <About the game> The communication system (hereinafter referred to as game system S) shown in FIG. 1 is a communication system including an information processing device (hereinafter referred to as server 30) according to one embodiment of the present invention, and provides a user U with a game.

[0012] A "game" is an online game provided using the game system S, and is an electronic game in which the player selects various events that occur and progresses while completing the selected events (hereinafter, "play"). In this embodiment, an example of a game is a game in which the user U forms a team of multiple characters, controls the characters through predetermined actions to fight enemy characters, and progresses by sequentially challenging and clearing multiple events prepared in the game. In the game of this embodiment, the user U can obtain various objects that can be used in the game by logging in, clearing events, purchasing, drawing lots, etc.

[0013] An "object" includes, for example, a character that moves in response to the operation of the user U in the game, and an item for progressing through the game advantageously. The number of objects possessed increases in response to logging in, clearing an event, purchasing, winning a lottery, etc., and decreases by consuming or discarding the object in the game.

[0014] The "lottery" is one of the mechanisms in the game by which the above objects can be obtained, and is implemented at the request of the user U while playing the game. In the lottery, multiple objects with different winning probabilities are prepared as candidates, and one or a predetermined number of objects are selected from the multiple candidate objects, and the selected objects are given to the user U.

[0015] There are various types of lotteries, including, for example, a "single-shot" lottery that is held only once, and an "N-consecutive" lottery that is held N times in succession (N is a natural number equal to or greater than 2). There are also various conditions for holding a lottery, including a lottery that can be held by consuming a lottery item that can be obtained for free, a lottery that can be held by consuming a lottery item that has been purchased for a fee, and a lottery that can be held as a reward for clearing an event.

[0016] An "event" is also known as a "quest" and refers to a task given to the user U in the game, i.e., an individual stage that constitutes the game. A time range and achievement conditions are set for each event, and various events occur as the game progresses. Events include, for example, events in which the player encounters or fights an enemy character, events in which the objective is to reach a certain point, and events in which objects such as items can be obtained. Completing an event by satisfying the set achievement conditions is referred to as clearing the event, and when the user U clears the event, he or she can receive a clear reward. In this embodiment, an event in which you fight an enemy character and can obtain that enemy character as a reward for clearing the event, i.e., an event in which you can incorporate the enemy character as an ally into your team in the next or subsequent events, will be taken as an example and will be described below.

[0017] "Time range" refers to the range of event times set for each event, as shown in Figure 2. A time range is assigned to each event, and is set so that, in principle, some event is always held. Time ranges may also be set to overlap so that multiple events are held simultaneously in the same time period. For example, as shown in Fig. 2, the time range of "Event Title A" is the two-hour range from 0:00 to 2:00 on February 14th, which is the range indicated by the solid line in the figure, and if the current time is within that time range, user U can play "Event Title A." In addition, the time range of "Event Title B" (four hours from 0:00 to 4:00 on February 14th) is also set to overlap with the same time period, and user U can select and play either "Event Title A" or "Event Title B" if the current time is within that overlapping time range.

[0018] In principle, the user U cannot play an ended event that has ended after the set time range has elapsed. However, in this embodiment, even if the event is an ended event, if a predetermined condition is satisfied in response to a predetermined operation by the user U, the user U who performed the predetermined operation can revive the ended event and play it, so long as the event is within the recovery period of the ended event. Note that the number of times that an ended event can be revived may be limited to a predetermined number of times (for example, once) for each event.

[0019] The "recovery period" refers to a period during which a user U can perform a predetermined operation to revive a finished event (for example, within 24 hours after the end of the event). For example, as shown in FIG. 2, the recovery period for "Event Title A" is the 24 hours from 2:00 on February 14th to 2:00 on February 15th, which is the range indicated by the dashed line in the figure. In this case, the period during which the finished event can be revived and played may be limited to within the recovery period, or it may be possible to play the finished event beyond the recovery period by performing a predetermined operation within the recovery period. Note that a finished event that is within the recovery period and has not been revived is also called a reviveable event.

[0020] The "predetermined operation" refers to an operation that the user U performs in the game to revive a ended event, and specifically refers to using an item and consuming the item after the time range of the event has ended. The item used here may be, for example, a general-purpose item that can be used for various purposes in the game, such as a lottery, or a dedicated item for reviving a ended event. If the user U has a dedicated item, the dedicated item may be automatically consumed before the general-purpose item when using the item.

[0021] The "predetermined condition" is a condition that is set in advance to revive the ended event, and can be satisfied by performing the above-mentioned predetermined operation. That is, in this embodiment, the predetermined condition corresponds to the user U using and consuming an item within the recovery period of the ended event.

[0022] "Resurrecting" refers to making the ended event playable for a predetermined period of time for the user U who performed the above-mentioned predetermined operation.

[0023] The "predetermined time" refers to the time (e.g., 1 hour) during which the user U who performed the above-mentioned predetermined operation can play the revived ended event. For example, as shown in Fig. 2, for "Event Title A", if the predetermined operation is performed at 21:30 on February 14th within the recovery period, the predetermined time is set to be from 21:30 to 22:30 on February 14th.

[0024] In this embodiment, the number of ended events that can be revived and played simultaneously is limited to a predetermined number or less (for example, one, etc.). For example, if the number of ended events that can be played simultaneously is one, and another ended event (second event) is revived and made playable in response to the above-mentioned predetermined operation by user U while an already revived ended event (first event) is in a playable state (i.e., within the predetermined time of the first event), the predetermined time of the already revived first event is ended and it becomes unplayable, and the playable ended event is changed from the first event to the second event. Note that the second event may not be revived and cannot be played until the first event has ended after the predetermined time has elapsed.

[0025] In addition, in this embodiment, after an event has ended, 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, and is held again at 18:00 on February 14th. In this case, the first time range (three hours from 6:00 to 9:00 on February 14th) corresponds to the first time range, and the second time range (three hours from 18:00 to 21:00 on February 14th) 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, depending on the timing of the predetermined operation (for example, 17:30 on February 14th), the predetermined time set for the revived "event title F" may partially overlap with the second time range. In this way, if the ended event will be held again if the user waits a little longer, and an opportunity to play the ended event again without having to take the trouble of consuming an item occurs, an alert may be notified to the user U to reconfirm.

[0026] Here, transition of screens displayed on the user terminal 10 when the user U revives an ended event will be described with reference to Figures 3 to 7. Figures 3 to 7 are examples of screens displayed on the user terminal 10 operated by the user U during game play.

[0027] First, as shown in FIG. 3, an event list screen 50 is displayed on the user terminal 10 when an event is selected. Events that the user U can play, i.e., events within a time range (e.g., "Event Title Z"), are displayed in a line on the event list screen 50. For each event, an explanation such as the event title, difficulty level, enemy character (character obtained as a clear reward), and remaining time range is displayed so that the contents of the event can be recognized. Also displayed on the event list screen 50 is a navigation button 52 for transitioning to a reviveable event list screen 51 for selecting an ended event and reviving it.

[0028] When the user U taps or otherwise operates the guidance button 52 on the event list screen 50, a reviveable event list screen 51 is displayed as shown in FIG. The reviveable event list screen 51 displays reviveable events associated with each user U in a line. For each reviveable event, an explanation such as whether or not it has been cleared, the play conditions, the character obtained as a reward for clearing it, the difficulty level, and the remaining recovery period is 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 finished events that are within the recovery period and have not been revived, and finished events that have already been revived are deleted from the reviveable event list screen 51. In addition, a reviveable event that does not satisfy the play conditions, such as when the user U does not have a character that has reached the level to play the event, is displayed in a manner that is distinguishable from other reviveable events (for example, grayed out) and cannot be selected even if the user U taps or the like. In addition, the reviveable events are, in principle, arranged in order from the oldest end date and time at the top, but it is also possible to select or rearrange them by tapping the sort button 53 or the like. Furthermore, the reviveable event list screen 51 displays the number of special items possessed for reviving ended events.

[0029] When the user U selects an arbitrary revivable event that he / she wishes to revive on the revivable event list screen 51 and taps or the like, a ended event revival confirmation screen 54 is displayed as shown in FIG. The ended event revival confirmation screen 54 displays the details of the event to be revived (e.g., "Event Title A"), an explanation for reviving the event, an accept button 55 and a reject button 56, and provides a final confirmation to the user U as to whether or not to revive the selected event using the item.

[0030] On the other hand, when user U selects and taps any revivable event that he or she wishes to revive on the revivable event list screen 51, if there is a terminated event that has already been revived (limited to events within a specified time period), a terminated event overwrite confirmation screen 57 is displayed, as shown in FIG. 6. The ended event overwrite confirmation screen 57 displays the details of the revived ended event to be deleted (e.g., "Event Title B"), the details of the event to be revived (e.g., "Event Title A"), an explanation for reviving the event, an accept button 55, and a reject button 56, and provides a final confirmation to the user U as to whether or not to revive the selected event using an item after ending the revived ended event. The details of the revived ended event to be deleted also display the remaining specified time.

[0031] 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, an event list screen 50 is displayed in which the revived finished event is displayed alongside the events within the time range, as shown in FIG. 7. At this time, the revived finished event is preferentially displayed at the top. For the revived finished event, as with other events, an explanation such as the event title, difficulty level, enemy character (character obtained as a clear reward), and remaining time is displayed so that the contents of the event can be recognized. In addition, the revived finished event is labeled "revived" so that it can be distinguished from other events. In addition, the revived finished event may be displayed by changing the design or color, etc., so that it can be distinguished from other events.

[0032] Then, user U can select the ended event that he or she has revived on the event list screen 50 and tap or the like to play for a specified period of time even though the current time is not within the time range set for that event.

[0033] In this embodiment, not only can a user U play alone, but also a so-called multiplay (hereinafter referred to as cooperative play) is possible in which a plurality of users U simultaneously play a common event by operating their respective user terminals 10. In this cooperative play, a cooperative relationship is formed between a user U (hereinafter referred to as a host) who hosts a cooperative play for a specific event and invites companions, and a user U (hereinafter referred to as a guest) who applies for the invitation and participates in the cooperative play, and the progress of the play is synchronized between the users playing cooperatively.

[0034] Cooperative play is carried out through the communication function of the user terminal 10 of each user U. Specifically, when a user U applies to participate in a cooperative play invited by a host and the host accepts the application, a communication path for cooperative play is established between the user U as a guest and the host. The qualifications for applying for cooperative play are not particularly limited and can be set arbitrarily. For example, a friend user who is another user U who has a friendship relationship with a certain user U and who has been mutually approved by the users U may apply.

[0035] After that, various data required for the cooperative play is transmitted and received according to a known communication method. The data at this time may be transmitted in a client-server manner via the server 30, or in a peer-to-peer (P2P) manner without the server 30. The cooperative play style is classified into a fully synchronous type and an asynchronous type, and either style may be adopted. The fully synchronous type includes a key input synchronous type and a command input type, and the asynchronous type includes a server-centralized processing type and a client-distributed processing type.

[0036] The cooperative play-compatible game includes a cooperative play game in which multiple users U cooperate, and a competitive game in which users U compete against each other, but either type may be used. The upper limit (maximum number of players) of the number of users U in one cooperative play is not particularly limited and may be set to any number, but is preferably set to a maximum of about four people, for example.

[0037] Even in this case of joint play, user U can revive the ended event. However, in order to jointly play the revived ended event, all users U, both the host and the guest participating in the joint play, must perform the above-mentioned predetermined operation and satisfy the predetermined condition. In addition, in order to jointly play the revived ended event, it must be at least within the predetermined time of the ended event revived by the host, and if the predetermined time of the ended event revived by the host has already passed, the guest will play the revived ended event alone. Note that if an event similar to the ended event revived by the host is within the time range for the guest and does not fall under the ended event, the guest can participate in the joint play without having to go to the trouble of reviving that event.

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

[0039] The user terminal 10 is equipped with a program stored therein and a processor that executes the program, and is carried by its owner, a user U, who operates the user terminal 10 when playing. The user terminal 10 may be any 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 dedicated game device equipped with a communication function. The number of user terminals 10 constituting the game system S is not particularly limited and may be any number, but in FIG. 1, for convenience of illustration, the number of user terminals 10 is three.

[0040] The server 30 is a computer constituting the information processing device of the present invention. For example, it is constituted by a server computer managed by a game provider, and is responsible for game progress processing. Specifically, it manages the game account and status of each user U for each user U, and distributes game progress data to each user U. In addition, the server 30 is not limited to a server device consisting of a single computer that independently performs a specific function, but may be constituted by a group of server devices consisting of multiple computers that are distributed and work together to perform a specific function.

[0041] The network N may be any network that connects the user terminal 10 and the server 30 in a state that enables data communication. It may be wired or wireless, and includes the Internet, a mobile communication network, a LAN (Local Area Network), a WAN (Wide Area Network), an intranet, Ethernet (registered trademark), and the like. The user terminals 10 may communicate with each other via the network N, or may communicate directly via Bluetooth (registered trademark), Wifi-Direct, or the like without going through the network N.

[0042] In the game system S of this embodiment, the user terminal 10 and the server 30 cooperate with each other in the above configuration to progress the game. Specifically, part of the game progress processing is performed on the server 30 side, and part of the graphic processing, etc. is executed on the user terminal 10 side. For example, the server 30 side executes a program including certain rules, logic, and algorithms. Meanwhile, the user terminal 10 side synchronizes with the server 30 and generates various events to progress the game according to the same rules, logic, and algorithms as the program executed on the server 30.

[0043] <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, as its hardware configuration, a processor 11, a memory device 12, a communication interface (represented 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.

[0044] The processor 11 includes, for example, a central processing unit, a microprocessor, a graphics processing unit, or a digital signal processor, and executes various types of arithmetic processing based on programs or data stored in the storage device 12, and 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 the functions of the user terminal 10 constituting the game system S are fulfilled by reading and executing these various programs by the processor 11.

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

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

[0047] The input device 14 is a device that receives an operation by the user U and generates data indicating the content of the received operation. As an example, an operation key, an operation button, a microphone for collecting sound, a camera for taking pictures, and the like provided on the user terminal 10 can be used.

[0048] The output device 15 is a device that draws a screen to display images and character string information, and plays back audio. As an example, a liquid crystal display or an organic EL (Electroluminescence) display provided in the user terminal 10, a head-mounted display, a speaker, and the like can be used. In this embodiment, the output device 15 has 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.

[0049] Next, the configuration of the user terminal 10 will be described again from a functional perspective with reference to FIG. 9, the user terminal 10 includes a plurality of functional units, specifically, an operation identification unit 16, a terminal-side storage unit 17, a terminal-side generation unit 18, a terminal-side transmission / reception unit 19, and a display processing unit 20. These functional units are realized by cooperation between the hardware devices of the user terminal 10 and programs stored in the user terminal 10 as software.

[0050] [Operation specification part 16] The operation identification unit 16 is mainly realized by the processor 11 and the input device 14, and identifies the contents of various operations performed by the user U through the input device 14 of the user terminal 10. The operations identified by the operation identification unit 16 include operations for progressing the game and operations related to joint play (operations related to soliciting participation in joint play, applying for joint play, and accepting or rejecting the application), etc. The operations for progressing the game also include an operation for selecting an event to be played, an operation for selecting an end event to be revived, and an operation for instructing the use of an item to revive an end event, etc.

[0051] [Terminal side memory 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 the progress of the game (for example, video data, image data, audio data, etc.).

[0052] [Terminal side generation unit 18] The terminal-side generating 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 identified by the operation identifying unit 16. The game operation data generated here includes event selection data based on an event selection operation or an end event selection operation, item use instruction data based on an item use instruction operation, and operation data related to joint play (including operation data related to soliciting joint play, applying for joint play, and whether or not the application is accepted). These generated data are transmitted to the server 30 by the terminal-side transmitting / receiving unit 19.

[0053] [Terminal side transceiver unit 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 terminals 10 of other users U. For example, while playing a game, 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. Furthermore, when a game is being played jointly, the terminal-side transmitting / receiving unit 19 may transmit and receive joint play data (specifically, game operation data of each user U) between the user terminals 10 of other users U.

[0054] [Display processing unit 20] The display processing unit 20 is mainly realized by the processor 11, the storage device 12, and the output device 15, and executes a display process to display data and information received by the terminal side transmitting / receiving unit 19 on the display by a browsing function. Specifically, the display processing unit 20 draws a game screen when the game starts, and during game play, expands game progress data received by the terminal side transmitting / receiving unit 19 from the server 30, and displays images and other information on the game screen. During game play, the display processing unit 20 also displays images that change according to game operation data generated by the terminal side generating unit 18 (specifically, images that move according to the operation of the user U) on the game screen.

[0055] <Server 30 Configuration> Next, the configuration of the server 30 according to the present embodiment will be described. As shown in FIG. 8, server 30 has the same hardware configuration as a typical 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.

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

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

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

[0059] Next, the configuration of the server 30 will be described again from a functional perspective with reference to FIG. 10, the server 30 includes a plurality of functional units, specifically, a server-side storage unit 34, a server-side transmission / reception unit 35, a server-side generation unit 36, a control unit 37, an information provision unit 38, and a notification unit 39. These functional units are realized by cooperation between the hardware devices of the server 30 and programs as software stored in the server 30. When the server 30 is configured by a plurality of computers, the above functions may be distributed so that each of the plurality of computers performs a different function.

[0060] [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 on the user U and data on the game progress process (game progress data). Data relating to 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 that identifier (personal information of user U, model of user terminal 10, access history, payment history, and game progress such as status, etc.). The game progression data includes information about characters owned by user U (such as name, attributes, abilities, and level), information about other objects such as items owned by user U, and various information about events set for each user U (such as the time range of an event, the recovery period for a completed event, and the revival status of a completed event).

[0061] [Server side transmission / reception unit 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 a game is being played, 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. Also, while a game is being played jointly, the server-side transmitting / receiving unit 35 receives joint play data from each of the user terminals 10 of the multiple users U playing jointly, and transmits data for synchronizing between the users U (game progress data in a broad sense) to each user terminal 10.

[0062] [Server-side generation part 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. The data generated here specifically includes game progress data corresponding to the game operation data received from the user terminal 10. The game progress data also includes event list screen display data for displaying the event list screen 50 on the user terminal 10, resurrectable event list screen display data for displaying the resurrectable event list screen 51 on the user terminal 10, confirmation screen data for displaying the ended event resurrection confirmation screen 54 or the ended event overwrite confirmation screen 57 on the user terminal 10, event data for displaying information about a selected event on the user terminal 10 to allow the user U to play the event, joint play start screen data for displaying a joint play start screen notifying the user that joint play will start on the user terminals 10 of the multiple users U who will play jointly, and data for synchronizing the multiple users U who will play jointly while the joint play is being performed.

[0063] [Control Unit 37] The control unit 37 is mainly realized by the processor 31 and the storage device 32, and controls whether or not the user U can play an event based on the relationship between the time range set for each event in the game and the current time. Furthermore, the control unit 37 controls so that even if the event has ended beyond the set time range, the user U performs a predetermined operation such as using an item within a recovery period after the end of the event to satisfy a predetermined condition, thereby reviving the ended event and allowing the user U who performed the predetermined operation to play the revived ended event for a predetermined time. Furthermore, in the case of cooperative play, the control unit 37 controls so that the revived ended event can be played when all of the host and guests participating in the cooperative play, except for the user U whose cooperative play event is within the time range, satisfy a predetermined condition. The control unit 37 limits the number of times that a finished event can be revived to a predetermined number for each event. The control unit 37 also limits the number of finished events that can be revived and played simultaneously to a predetermined number or less by ending a first event for a predetermined time and making it unplayable, and changing the playable finished event from the first event to the second event, or by making it impossible to play the second event until the first event has ended after a predetermined time has elapsed.

[0064] [Information 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 the user terminal 10 with information on reviveable events that can be revived among ended events, which is set for each user U according to the game progress status of the user U, etc. Note that the information on the reviveable events is provided to the user terminal 10 as reviveable event list screen display data.

[0065] [Notification section 39] The notification unit 39 is mainly realized by the processor 31, the storage device 32, and the communication interface 33, and in cooperation with the server-side transceiver unit 35, notifies the user terminal 10 of an alert when a specified time set for an event that is revived in response to a specified operation by the user U overlaps with the second time range of the event.

[0066] In general, the user terminal 10 and the server 30 have various functions other than those described above, but here we will only explain the characteristic functions that provide an effective effect in the game system S of the present invention, and will not illustrate or explain other known functions, etc.

[0067] <Processing flow of game system S> Next, the flow of processing executed in the game system S configured as above will be described with reference to FIGS. The information processing method of this embodiment is realized by using a game system S that functions as a computer system; in other words, the information processing method of this embodiment is applied to the information processing performed by the game system S.

[0068] The information processing executed in the game system S in this embodiment is mainly composed of two processes: a process [event playability determination process] that determines whether or not an event can be played based on the relationship between the time range set for each event and the current time, and a process [ended event revival process] that revives an ended event whose time range has ended and makes it playable. Each process will be explained individually below.

[0069] [Event play availability decision process] First, the event play availability determination process will be described with reference to FIG. The "event play permission determination process" refers to a process executed by the server 30, which determines whether the user U can play the event based on the relationship between the time range set for each event and the current time.

[0070] 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 for the event (S101: YES), it starts the event if it has not yet started, or continues the event if it has already started, thereby setting the event to a playable state for the user U (S102), and adds the event that has been set to a playable state to the event list screen 50 as shown in FIG. 3 (S103).

[0071] On the other hand, if the server 30 determines that the current time is not within the time range of the event (S101: NO), it ends the ongoing event, sets the event to an unplayable state for the user U (S104), and deletes the ended event that has been set to an unplayable state from the event list screen 50 (S105). Then, the server 30 compares the current time with the recovery period of the ended event, and if it determines that the current time is within the recovery period of the ended event (S106: YES), it adds the ended event to the reviveable event list screen 51 as shown in Fig. 4 (S107). Note that if it is determined that the current time is not within the recovery period of the ended event (S106: NO), the process of S107 is not performed and the process moves to the next step.

[0072] Then, the server 30 transmits event list screen display data for displaying the event list screen 50 and revivable event list screen display data for displaying the revivable event list screen 51 to the user terminal 10 (S108), and terminates the processing.

[0073] When the above series of steps is completed, the event play possibility determination process is completed. After that, the above series of steps are repeatedly performed while the user U is playing the game, or as time passes even if the user U is not playing the game. The above is an example of the event play possibility determination process.

[0074] [End event revival process] Next, the ended event revival process will be described with reference to FIG. 12 and FIG. The "ended event revival process" is a process executed on the server 30, and refers to a process of reviving an ended event whose time range has ended, making it playable.

[0075] As shown in FIG. 12, when the server 30 receives event selection data from the user terminal 10 indicating an ended event (revivable event) selected by the user U from the reviveable event list screen 51 (S201), the server 30 determines whether the user U satisfies the play conditions (S202).

[0076] If the server 30 determines that the user U meets the play conditions (S202: YES), it then compares the predetermined time set when the ended event is revived with the second time range, and if it determines that the predetermined time does not overlap with the second time range as a result of the comparison (S203: YES), or if it determines that the predetermined time overlaps with the second time range (S203: NO), it transmits notification data for displaying an alert to the user terminal 10 to notify the alert (S204), and if the user U confirms and accepts the alert (S205: YES), it determines whether there is another ended event that has already been revived, that is, whether the first event is in a playable state (S206). Note that if there is no second time range for the ended event, it is also determined that the predetermined time does not overlap with the second time range (S203: YES).

[0077] When the server 30 determines that there is no other ended event that has already been revived (S206: YES), the server 30 transmits confirmation screen data to the user terminal 10 to display a finished event revival confirmation screen 54 as shown in FIG. 5, and notifies the user U of the revival confirmation (S207). On the other hand, when the server 30 determines that there is another ended event that has already been revived (S206: NO), the server 30 transmits confirmation screen data to the user terminal 10 to display a finished event overwrite confirmation screen 57 as shown in FIG. 6, and notifies the user U of the overwrite confirmation (S208). Then, when the server 30 determines that the user U has accepted the end by tapping the accept button 55 on the finished event revival confirmation screen 54 or the finished event overwrite confirmation screen 57 (S209: YES), the server 30 subsequently compares the current time with the recovery period of the ended event and determines whether the current time is within the recovery period of the ended event (S210).

[0078] When the server 30 determines that the current time is within the recovery period of the ended event (S210: YES), it consumes an item possessed by the user U (S211) and revives the selected ended event and sets it to a playable state for the user U (S212). Then, the server 30 deletes the selected ended event that has been 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 (S213).

[0079] Then, the server 30 transmits event list screen display data for displaying the event list screen 50 and revivable event list screen display data for displaying the revivable event list screen 51 to the user terminal 10 (S214), and terminates the processing.

[0080] 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 ended event (S210: NO), the server 30 transmits notification data to the user terminal 10 indicating that the ended event cannot be revived, notifies the user U that revival is not possible (S215), and ends the process. If the user U does not accept the alert notification (S205: NO), or if the server 30 determines that the user U has not accepted the notification by tapping the reject button 56 on the ended event revival confirmation screen 54 or the ended event overwrite confirmation screen 57 (S209: NO), the process ends.

[0081] In addition, in the ended event revival process, if there is another ended event that has already been revived, the first event may not be overwritten by the second event, and the second event may not be revived until the first event has ended after a predetermined time has elapsed.

[0082] Specifically, as shown in FIG. 13, when the server 30 receives event selection data from the user terminal 10 indicating an ended event (revivable event) selected by the user U from the reviveable event list screen 51 (S301), the server 30 determines whether the user U satisfies the play conditions (S302).

[0083] If the server 30 determines that the user U meets the play conditions (S302: YES), it then compares the specified time that would be set if the ended event were revived with the second time range, and if, as a result of the comparison, it determines that the specified time does not overlap with the second time range (S303: YES), or if it determines that the specified time overlaps with the second time range (S303: NO), it sends notification data to the user terminal 10 to display an alert (S304), and if the user U confirms and accepts the alert (S305: YES), it determines whether there are any other ended events that have already been revived, i.e., whether the first event is in a playable state or not (S306).

[0084] When the server 30 determines that there are no other ended events that have already been revived (S306: YES), it transmits confirmation screen data for displaying a ended event revival confirmation screen 54 as shown in Fig. 5 to the user terminal 10, and notifies the user U of the revival confirmation (S307). Then, when the server 30 determines that the user U has accepted the request by tapping the accept button 55 on the ended event revival confirmation screen 54 or the ended event overwrite confirmation screen 57 (S308: YES), it then compares the current time with the recovery period of the ended event and determines whether the current time is within the recovery period of the ended event (S309).

[0085] When the server 30 determines that the current time is within the recovery period of the ended event (S309: YES), it consumes an item possessed by the user U (S310) and revives the selected ended event and sets it to a playable state for the user U (S311). Then, the server 30 deletes the selected ended event that has been 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).

[0086] Then, the server 30 transmits event list screen display data for displaying the event list screen 50 and revivable event list screen display data for displaying the revivable event list screen 51 to the user terminal 10 (S313), and terminates the processing.

[0087] If the server 30 determines that the user U does not satisfy the play conditions (S302: NO), if it determines that there is another ended event that has already been revived (S306: NO), or if it determines that the current time is not within the recovery period of the ended event (S309: NO), it transmits notification data to the user terminal 10 indicating that the ended event cannot be revived, notifies the user U that revival is not possible (S314), and ends the process. If the user U does not accept the alert notification (S305: NO), or if it determines that the user U has not accepted the notification by tapping the reject button 56 on the ended event revival confirmation screen 54, for example (S308: NO), the process ends.

[0088] The ended event revival process ends when the series of steps shown in Fig. 12 or 13 above is completed. Thereafter, while the user U is playing the game, strictly speaking, when the user U selects an ended event (revivable event) from the reviveable event list screen 51, the series of steps described above is repeatedly performed. The above is an example of the ended event revival process.

[0089] [End event revival processing in cooperative play] Next, the ended event revival process, particularly the ended event revival process in cooperative play, will be described with reference to FIG. "Ended event revival processing in cooperative play" refers to processing executed on the server 30, which revives an ended event whose time range has ended and makes it playable for both the host and guest when the host recruits friends to join in cooperative play for an ended event that the host revived via the ended event revival processing shown in Figure 12 or Figure 13 above.

[0090] 14, the server 30 first transmits a joint play invitation list including the ended event revived by the host to other users U who may become guests (S401). Then, when the server 30 accepts an application to participate in a joint play of the revived ended event from the invitation list from a guest (S402), the server 30 determines whether the event in question is also an ended event that has been revived by the guest (S403).

[0091] When the server 30 determines that the event has also been revived by the guest (S403: YES), it then compares the current time with the predetermined time of the ended event revived by the host and determines whether the current time is within the predetermined time of the ended event revived by the host (S404). When the server 30 determines that the current time is within the predetermined time of the ended event revived by the host (S404: YES), it sets the guest to a state in which cooperative play of the revived ended event is possible (S405), and transmits cooperative play start screen data to the guest's user terminal 10 to display a cooperative play start screen notifying the guest that cooperative play will begin for the revived ended event (S406), and ends the process.

[0092] On the other hand, if the server 30 determines that the event is not a revived ended event for the guest (S403: NO), or if it determines that the current time is not within the specified time period of the ended event revived by the host (S404: NO), it sends notification data to the guest's user terminal 10 indicating that the guest cannot participate in cooperative play, notifying the guest that he or she cannot participate in cooperative play (S407), and terminates the processing.

[0093] When the above series of steps is completed, the process of reviving the ended event in the cooperative play is completed. After that, while the user U is playing the game, or more precisely, when the host user U recruits friends to participate in the cooperative play for the revived ended event, the above series of steps is repeatedly performed. The above is an example of the process of reviving an ended event in cooperative play.

[0094] <Other embodiments> The present invention is not limited to the above-described embodiments. 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 server 30 as the information processing device may be provided in the user terminal 10. For example, the user terminal 10 may be provided with a function equivalent to the control unit 37, etc.

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

[0096] <Summary> The main features of the information processing device, information processing method, and program according to the above-described embodiment are as follows.

[0097] [1] The information processing device according to this embodiment has a control unit that controls whether or not an event can be played based on the relationship between a time range set for an in-game event and the current time. When a predetermined condition is satisfied in response to a predetermined operation by the user after the time range ends, the control unit enables the user who performed the predetermined operation to play the event for a predetermined time. According to the information processing device, even if the time period set for an event has ended and the opportunity to play the event has been lost, the user can still play the event for a predetermined period of time by performing a predetermined operation to satisfy a predetermined condition, thereby improving the user's level of satisfaction with the game.

[0098] [2] In the above-mentioned information processing device, after the time range ends, if the number of times that the control unit has enabled the user to play an event in response to the user's specified operation has reached a specified number, the control unit does not enable the user to play the event in response to the user's specified operation. This prevents the user from playing an event whose time range has ended indefinitely, even if the user performs a specified operation and fulfills a specified condition, thereby further improving the user's game satisfaction while maintaining game balance.

[0099] [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 specified operation to satisfy a specified condition for an event whose time range has ended, the number of times that the user can play simultaneously is limited to a specified number or less, thereby further improving the user's game satisfaction while maintaining game balance.

[0100] [4] In the above-mentioned information processing device, the control unit makes the first event unplayable when, after the time ranges of the first event and the second event have ended, the second event is made playable in response to a specified user operation while the first event is playable in response to a specified user operation. This prevents the user from playing the first and second events simultaneously, even if the user performs a specified operation to satisfy a specified condition after the time ranges of the first and second events have ended, thereby further improving the user's game satisfaction while maintaining game balance.

[0101] [5] In the above-mentioned information processing device, the control unit does not enable play of the second event in response to a specified operation by the user until the first event, which has become playable in response to a specified operation by the user, has ended after a specified time has elapsed after the end of the time ranges of the first event and the second event. This prevents the user from playing the first and second events simultaneously, even if the user performs a specified operation to satisfy a specified condition after the time ranges of the first and second events have ended, thereby further improving the user's game satisfaction while maintaining game balance.

[0102] [6] The above-mentioned information processing device further includes an information providing unit that provides the user with information regarding events that can be played in response to a specified operation by the user, among the events whose time range has ended, and the control unit enables the 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 ranges have ended, further improving the user's level of satisfaction with the game.

[0103] [7] In the above information processing device, a first time range and a second time range are defined for the event, the second time range is after the first time range, and the information processing device further has a notification unit that notifies an alert when a playable time range of an event that becomes playable in response to a specified user operation between the first time range and the second time range overlaps with the second time range. This notifies the user that an event for which the first time range has ended can be played in the second time range even if the user does not perform a predetermined operation to satisfy a predetermined condition. This makes it easier for the user to select an event to play from among the events for which the time range (first time range) has ended, and also allows the user to reconsider whether or not to perform a predetermined operation for that event, thereby further improving the user's game satisfaction.

[0104] [8] In the above-mentioned information processing device, when a user recruits co-players to play a game together with the user and other users join the game as co-players to play together, the control unit enables the user and the other users to play the event after the time range ends if both the user and the other users satisfy a predetermined condition. As a result, in cooperative play by multiple users, in order to play an event whose time range has ended, all users participating in the cooperative play must perform specified operations and satisfy specified conditions, thereby further improving users' game satisfaction while maintaining game balance.

[0105] [9] Furthermore, according to the information processing method of this embodiment, the computer controls whether or not an event can be played based on the relationship between a time range set for an in-game event and the current time, and after the time range ends, if a predetermined condition is satisfied in response to a predetermined operation by the user, the computer enables the user who performed the predetermined operation to play the event for a predetermined period of time. According to the above information processing method, even if the time period set for an event has ended and the opportunity to play the event has been lost, the user can still play the event for a predetermined period of time by performing a predetermined operation to satisfy a predetermined condition, thereby improving the user's level of satisfaction with the game.

[0106]

[10] Furthermore, according to the program of this embodiment, the program is executed by a computer, and causes the computer to control whether or not an event can be played based on the relationship between a time range set for an in-game event and the current time, and after the time range ends, if a predetermined condition is satisfied in response to a predetermined operation by the user, allows the user who performed the predetermined operation to play the event for a predetermined period of time. According to the above program, even if the user misses an opportunity to play an event because the time period set for the event has ended, the user can still play the event for a predetermined period of time by performing a predetermined operation to satisfy a predetermined condition, thereby improving the user's level of satisfaction with the game. [Explanation of symbols]

[0107] 10 User terminal 11 Processors 12 Storage device 13 Communication Interface 14 Input Devices 15 Output Devices 16 Operation specific part 17 Terminal side memory unit 18 Terminal side generation unit 19 Terminal side transmission / reception unit 20 Display processing section 30 Servers 31 Processors 32 Storage device 33 Communication Interface 34 Server side storage unit 35 Server side transmission / reception unit 36 Server-side generation unit 37 Control Unit 38 Information provision department 39 Notification Department 50 Event list screen 51 List of events that can be revived 52 Guidance button 53 Sort button 54 Ended event revival confirmation screen 55 Accept button 56 Reject button 57 Confirmation screen for overwriting the finished event N Network S Game System U User

Claims

[Claim 1] a control unit that controls whether or not an event can be played in a game based on a relationship between a time range defined for the event and a current time; The control unit is after the time range ends, when a predetermined condition is satisfied in response to a predetermined operation by a user, allowing the user who performed the predetermined operation to play the event for a predetermined period of time; 23. An information processing apparatus comprising:

Images