JP7302989B2 - Game program, method, and information processing device - Google Patents

Description

Application of Article 30, Paragraph 2 of the Patent Act ・Website address (A) https://twitter. com/colopl_dreaming Posting date March 8, 2018- (B) https://colopl. co. jp/dreaming/ Publication date March 8, 2018- (C) https://colopl. co. jp/news/pressrelease/2018051101. php Posting date May 11, 2018 (D) https://colopl. co. jp/news/pressrelease/June 2018 2501. php Posting date June 25, 2018 (E) https://colopl. co. jp/news/pressrelease/August 2018 901. php Posting date August 9, 2018 (F) https://colopl. co. jp/news/pressrelease/November 2018 1201. php Posting date November 12, 2018 (G) https://www. youtube. com/watch? v=cJth8wp5Z1E Posting date June 21, 2018 (H) https://www. youtube. com/watch? v=wFkCH-_JLLU Posting date June 24, 2018 (I) https://www. youtube. com/watch? v=fTw070kGGC0 Posting date June 24, 2018 (J) https://www. youtube. com/watch? v=SAp7CFZIIKw Posting date June 24, 2018 (K) https://www. youtube. com/watch? v=I3OBLk1rLkg Posting date June 24, 2018 (L) https://www. youtube. com/watch? v=wrFiLqzjrt4 Posting date June 26, 2018 (M) https://www. youtube. com/watch? v=RcJu-U7B1Ss Posting date June 27, 2018 (N) https://www. youtube. com/watch? v=BAADD5pQvZk Publication date July 1, 2018 (O) https://www. youtube. com/watch? v=jM2pPZD4baI Date of publication July 2, 2018

Application of Article 30, Paragraph 2 of the Patent Law (P) https://www. youtube. com/watch? v=lHnJJFzFyx0 Posting date July 3, 2018 (Q) https://www. youtube. com/watch? v=99XUK33ixFw Posting date July 4, 2018 (R) https://www. youtube. com/watch? v=X48UDiWMkZ8 Posting date July 5, 2018 (S) https://www. youtube. com/watch? v=RnLSOd_Bs5I Posting date July 6, 2018 (T) https://www. youtube. com/watch? v=t4HafS4BPHc Posting date July 7, 2018 (U) https://www. youtube. com/watch? v=ruc2FCNgxNI Posting date July 12, 2018 (V) https://www. youtube. com/watch? v=5Q0xEpn2N00 Posting date July 24, 2018 (W) https://www. youtube. com/watch? v=cWgQQ4Ji2qk Posting date July 24, 2018 (X) https://www. youtube. com/watch? v=u_qeJX9vF94 Posting date August 10, 2018 (Y) https://www. youtube. com/watch? v=uszJ5Z4H6Og Posting date October 10, 2018 (Z) https://www. youtube. com/watch? v=KXLkd-eE9-s Posting date October 17, 2018 (AA) https://www. youtube. com/watch? v=CI6AL1ute0g Posting date October 26, 2018 (AB) https://www. youtube. com/watch? v=it6r8QjBSVM Posting date November 11, 2018 (AC) https://live. nico video. jp/watch/lv313939765 Date of publication July 1, 2018

Application of Article 30, Paragraph 2 of the Patent Law (AD) https://live. nico video. jp/watch/lv4219653 Posting date July 24, 2018 (AE) https://live. nico video. jp/watch/lv314923608 Posting date August 22, 2018 (AF) https://live. nico video. jp/gate/lv315377035 Posting date September 19, 2018 (AG) https://live. nico video. jp/gate/lv315994929 Posting date October 19, 2018 (AH) https://live. nico video. jp/gate/lv316637352 Posting date November 28, 2018 (AI) https://live. nico video. jp/gate/lv318022244 Publication date January 29, 2019 ・ Application name: “DREAM! ing” Application version and release/update date: Ver. 1.0.0 August 8, 2018 Ver. 1.0.1 August 13, 2018 Ver. 1.0.2 August 17, 2018 Ver. 1.0.3 August 22, 2018 Ver. 1.0.4 August 31, 2018 Ver. 1.0.5 September 7, 2018 Ver. 1.0.6 September 14, 2018 Ver. 1.0.7 September 28, 2018 Ver. 1.0.8 October 11, 2018 Ver. 1.0.9 October 30, 2018 Ver. 1.0.10 November 15, 2018 Ver. 1.0.11 November 16, 2018 Ver. 1.0.12 November 29, 2018 Ver. 1.0.13 November 30, 2018 Ver. 1.0.14 December 12, 2018 Ver. 1.0.15 December 18, 2018 Ver. 1.0.16 January 18, 2019 Ver. 1.0.17 January 28, 2019 Ver. 1.0.18 February 8, 2019 Ver. 1.0.19 February 22, 2019 Ver. 1.0.20 March 8, 2019

The present disclosure relates to a game program, a method for executing the game program, and an information processing device.

For example, as disclosed in Japanese Unexamined Patent Application Publication No. 2002-200013, after the user instructs the execution of the game, the game automatically progresses, and after a predetermined period of time has passed, the result of the automatic progress is notified to the user. Games have traditionally been widely offered to users.

Japanese Patent Application Laid-Open No. 2013-126462 (published on June 27, 2013)

By the way, in a game in which a character appears, there is room for further improving the enjoyment of the neglected game from the viewpoint of improving attachment to the character.

One aspect of the present disclosure aims to improve the interest of a game.

A game program according to the present disclosure is executed by a computer that includes a processor, memory, and display. The game program causes the processor to change the first character from the first state to the second state in response to a user's first input operation on at least one first character among a plurality of characters appearing in a game based on the game program. a step of returning the first character to the first state when a predetermined time has elapsed since the first character transitioned to the second state; a step of returning the first character to the first state; A step of providing the user with content based on the first character that was in the second state in response to returning to the state, and a step of displaying designated content on the display unit in response to the user's second input operation. and let it run.

According to one aspect of the present disclosure, there is an effect of improving the interest of the game.

It is a figure which shows the hardware constitutions of a game system. FIG. 2 is a diagram illustrating an example of a game cycle of a game executed by the game system; FIG. 3 is a block diagram showing functional configurations of a user terminal and a server; FIG. It is a figure which shows an example of the data structure of a card. FIG. 3 is a diagram showing an example of the data structure of character data defining characters; (A) is a diagram showing an example of the data structure of a pair parameter table, and (B) is a diagram showing an example of the data structure of a pair parameter DB. FIG. 4 is a diagram showing an example of the data structure of a story list; FIG. 10 is a flow chart showing the flow of processing in a practice part executed by a practice part progression section; FIG. FIG. 10 is a diagram showing an example of the data structure of deck information referenced in a practice part; (A) is a diagram showing an example of cards selected by the user and put into play in the previous set, and (B) is a diagram showing the deck information of the secondary deck immediately after the previous set. (C) is a diagram showing candidates for cards to be replenished in vacant positions. (A) and (B) are diagrams showing an example of a stage progress screen displayed on the display unit of the user terminal. 10 is a flow chart showing the flow of processing of an execution part among the neglected parts executed by the neglected part progressing unit; 10 is a flow chart showing the flow of processing of an execution part among the neglected parts executed by the neglected part progressing unit; FIG. 4 is a diagram showing an example of the data structure of abandoned character information; (A) is a diagram showing an example of the data structure of diary data, and (B) is a diagram showing an example of the data structure of diary data with a high rarity level. FIG. 4 is a diagram showing an example of a character selection screen displayed on the display unit; (A) is a diagram showing an example of an introduction screen displayed on a display unit, and (B) is a diagram showing an example of an execution screen displayed on the display unit. 10 is a flow chart showing a flow of processing of a browsing part among the neglected parts executed by the neglected part progressing unit; It is a figure which shows an example of the data structure of a diary database. (A) is a diagram showing an example of a list screen displayed on a display unit, and (B) is a diagram showing an example of a diary screen displayed on the display unit.

[Embodiment 1]
A game system according to the present disclosure is a system for providing a game to multiple users. The game system will be described below with reference to the drawings. The present invention is not limited to these examples, but is indicated by the scope of the claims, and is intended to include all modifications within the meaning and scope of equivalents to the scope of the claims. be. In the following description, the same reference numerals are given to the same elements in the description of the drawings, and redundant description will not be repeated.

<Hardware Configuration of Game System 1>
FIG. 1 is a diagram showing the hardware configuration of the game system 1. As shown in FIG. The game system 1 includes a plurality of user terminals 100 and a server 200 as shown. Each user terminal 100 is connected to the server 200 via the network 2 . The network 2 includes the Internet and various mobile communication systems constructed by wireless base stations (not shown). Examples of mobile communication systems include so-called 3G, 4G mobile communication systems, LTE (Long Term Evolution), and wireless networks (eg, Wi-Fi (registered trademark)) that can be connected to the Internet through a predetermined access point. be done.

The server 200 (computer, information processing device) may be a workstation or a general-purpose computer such as a personal computer. The server 200 includes a processor 20, a memory 21, a storage 22, a communication IF 23, and an input/output IF 24. These components provided in the server 200 are electrically connected to each other by a communication bus.

The user terminal 100 (computer, information processing device) may be a mobile terminal such as a smart phone, a feature phone, a PDA (Personal Digital Assistant), or a tablet computer. The user terminal 100 may be a game device suitable for playing games. As illustrated, the user terminal 100 includes a processor 10, a memory 11, a storage 12, a communication interface (IF) 13, an input/output IF 14, a touch screen 15 (display unit), a camera 17, and a range sensor 18. and These components provided in the user terminal 100 are electrically connected to each other by a communication bus. Note that the user terminal 100 may include an input/output IF 14 to which a display (display unit) configured separately from the user terminal 100 main body can be connected instead of or in addition to the touch screen 15 .

Also, as shown in FIG. 1, user terminal 100 may be configured to communicate with one or more controllers 1020 . The controller 1020 establishes communication with the user terminal 100 according to communication standards such as Bluetooth (registered trademark), for example. The controller 1020 may have one or more buttons or the like, and transmits to the user terminal 100 an output value based on the user's input operation on the buttons or the like. Also, the controller 1020 may have various sensors such as an acceleration sensor and an angular velocity sensor, and transmits output values of the various sensors to the user terminal 100 .

Note that the controller 1020 may have the camera 17 and the ranging sensor 18 instead of or in addition to the user terminal 100 having the camera 17 and the ranging sensor 18 .

The user terminal 100 preferably allows the user using the controller 1020 to input user identification information such as the user's name or login ID via the controller 1020, for example, at the start of the game. As a result, the user terminal 100 can associate the controller 1020 with the user, and identifies which user the output value belongs to based on the transmission source (controller 1020) of the received output value. be able to.

When the user terminal 100 communicates with a plurality of controllers 1020 , each user can hold each controller 1020 to communicate with the one user terminal 100 without communicating with other devices such as the server 200 via the network 2 . You can play multiplayer with. In addition, by connecting each user terminal 100 to each other for communication according to a wireless standard such as a wireless LAN (Local Area Network) standard (connecting for communication without going through the server 200), a plurality of user terminals 100 can realize local multiplay. You can also When the above-described multiplay is locally realized by one user terminal 100, the user terminal 100 may further include at least a part of various functions of the server 200, which will be described later. Also, in the case where multiple user terminals 100 locally implement the above-described multiplay, the multiple user terminals 100 may be provided with various functions of the server 200, which will be described later, in a distributed manner.

Note that the user terminal 100 may communicate with the server 200 even when the multiplay described above is implemented locally. For example, information indicating a play result such as score or win/loss in a certain game may be associated with user identification information and transmitted to the server 200 .

Also, the controller 1020 may be detachable from the user terminal 100 . In this case, at least one surface of the housing of the user terminal 100 may be provided with a coupling portion for the controller 1020 . When the user terminal 100 and the controller 1020 are connected by wire through the connecting unit, the user terminal 100 and the controller 1020 transmit and receive signals via the wire.

As shown in FIG. 1 , the user terminal 100 may accept the attachment of an external storage medium 1030 such as a memory card via the input/output IF 14 . This allows the user terminal 100 to read programs and data recorded on the storage medium 1030 . A program recorded in the storage medium 1030 is, for example, a game program.

User terminal 100 may store a game program acquired by communicating with an external device such as server 200 in memory 11 of user terminal 100, or may store a game program acquired by reading from storage medium 1030 in memory 11. may be stored in

As described above, the user terminal 100 includes the communication IF 13, the input/output IF 14, the touch screen 15, the camera 17, and the ranging sensor 18 as an example of a mechanism for inputting information to the user terminal 100. FIG. Each unit described above as an input mechanism can be regarded as an operation unit configured to receive a user's input operation.

For example, when the operation unit is composed of at least one of the camera 17 and the ranging sensor 18, the operation unit detects an object 1010 near the user terminal 100, and performs an input operation based on the detection result of the object. Identify. As an example, a user's hand as object 1010, a marker of a predetermined shape, or the like is detected, and an input operation is specified based on the color, shape, movement, type, or the like of object 1010 obtained as a detection result. be. More specifically, when the user's hand is detected from the image captured by the camera 17, the user terminal 100 detects a gesture (a series of movements of the user's hand) detected based on the captured image as an input operation of the user. identified and accepted as Note that the captured image may be a still image or a moving image.

Alternatively, when the operation unit is configured by the touch screen 15, the user terminal 100 identifies and accepts the user's operation performed on the input unit 151 of the touch screen 15 as the user's input operation. Alternatively, when the operation unit is configured by the communication IF 13, the user terminal 100 identifies and accepts a signal (for example, an output value) transmitted from the controller 1020 as the user's input operation. Alternatively, when the operation unit is configured by the input/output IF 14, a signal output from an input device (not shown) different from the controller 1020 connected to the input/output IF 14 is specified as the user's input operation and accepted.

<Hardware components of each device>
Processor 10 controls the overall operation of user terminal 100 . The processor 20 controls the operation of the server 200 as a whole. Processors 10 and 20 include a CPU (Central Processing Unit), an MPU (Micro Processing Unit), and a GPU (Graphics Processing Unit).

The processor 10 reads a program from a storage 12, which will be described later, and develops it in a memory 11, which will be described later. The processor 20 reads a program from a storage 22, which will be described later, and develops it in a memory 21, which will be described later. Processor 10 and processor 20 execute the expanded program.

Memories 11 and 21 are main storage devices. The memories 11 and 21 are composed of storage devices such as ROM (Read Only Memory) and RAM (Random Access Memory). The memory 11 provides a work area for the processor 10 by temporarily storing programs and various data read by the processor 10 from a storage 12 described later. The memory 11 also temporarily stores various data generated while the processor 10 is operating according to the program. The memory 21 provides a work area for the processor 20 by temporarily storing various programs and data read by the processor 20 from a storage 22 described later. The memory 21 also temporarily stores various data generated while the processor 20 is operating according to the program.

The program in this embodiment may be a game program for realizing a game by the user terminal 100 . Alternatively, the program may be a game program for realizing the game through cooperation between user terminal 100 and server 200 . Note that the game realized by cooperation between the user terminal 100 and the server 200 may be, for example, a game executed on a browser activated on the user terminal 100 . Alternatively, the program may be a game program for realizing the game by cooperation of a plurality of user terminals 100 . Further, the various types of data include game-related data such as user information and game information, and instructions or notifications transmitted and received between the user terminal 100 and the server 200 or between a plurality of user terminals 100 .

Storages 12 and 22 are auxiliary storage devices. The storages 12 and 22 are composed of storage devices such as flash memories or HDDs (Hard Disk Drives). Various data related to the game are stored in the storage 12 and the storage 22 .

The communication IF 13 controls transmission and reception of various data in the user terminal 100 . The communication IF 23 controls transmission and reception of various data in the server 200 . The communication IFs 13 and 23 control, for example, communication via a wireless LAN (Local Area Network), Internet communication via a wired LAN, wireless LAN, or mobile phone network, and communication using short-range wireless communication.

The input/output IF 14 is an interface for the user terminal 100 to receive data input, and an interface for the user terminal 100 to output data. The input/output IF 14 may input/output data via a USB (Universal Serial Bus) or the like. The input/output IF 14 may include physical buttons, a camera, a microphone, or a speaker of the user terminal 100, for example. The input/output IF 24 of the server 200 is an interface for the server 200 to receive data input and an interface for the server 200 to output data. The input/output IF 24 may include, for example, an input section that is an information input device such as a mouse or a keyboard, and a display section that is a device for displaying and outputting images.

The touch screen 15 of the user terminal 100 is an electronic component in which an input section 151 and a display section 152 are combined. The input unit 151 is, for example, a touch-sensitive device, and is configured by, for example, a touch pad. The display unit 152 is configured by, for example, a liquid crystal display or an organic EL (Electro-Luminescence) display.

The input unit 151 detects the position where the user's operation (mainly physical contact operation such as touch operation, slide operation, swipe operation, and tap operation) is input on the input surface, and inputs information indicating the position. It has a function to transmit as a signal. The input unit 151 may include a touch sensing unit (not shown). The touch sensing unit may employ any type of system, such as a capacitive system or a resistive film system.

Although not shown, the user terminal 100 may include one or more sensors for identifying the holding posture of the user terminal 100 . This sensor may be, for example, an acceleration sensor or an angular velocity sensor. If the user terminal 100 is equipped with a sensor, the processor 10 can identify the holding posture of the user terminal 100 from the output of the sensor and perform processing according to the holding posture. For example, when the user terminal 100 is held vertically, the processor 10 may display a vertically long image on the display unit 152 for vertical screen display. On the other hand, when the user terminal 100 is held horizontally, a horizontal screen display may be used in which a horizontally long image is displayed on the display unit. Thus, the processor 10 may be able to switch between vertical screen display and horizontal screen display according to the holding posture of the user terminal 100 .

The camera 17 includes an image sensor or the like, and generates a captured image by converting incident light from a lens into an electrical signal.

The distance sensor 18 is a sensor that measures the distance to the object to be measured. The ranging sensor 18 includes, for example, a light source that emits pulse-converted light and a light receiving element that receives the light. The distance measuring sensor 18 measures the distance to the measurement object based on the light emission timing from the light source and the light reception timing of the reflected light generated when the light emitted from the light source hits the measurement object and is reflected. The ranging sensor 18 may have a light source that emits directional light.

Here, an example in which the user terminal 100 uses the camera 17 and the ranging sensor 18 to detect the object 1010 near the user terminal 100 and accepts the detection result as the user's input operation will be further described. The camera 17 and the ranging sensor 18 may be provided on the side of the housing of the user terminal 100, for example. A ranging sensor 18 may be provided near the camera 17 . As the camera 17, for example, an infrared camera can be used. In this case, the camera 17 may be provided with an illumination device that emits infrared light, a filter that blocks visible light, and the like. This makes it possible to further improve the object detection accuracy based on the image captured by the camera 17, regardless of whether it is outdoors or indoors.

The processor 10 may perform one or more of the following processes (1) to (5) on the image captured by the camera 17, for example. (1) The processor 10 performs image recognition processing on the captured image of the camera 17 to identify whether or not the captured image includes the user's hand. The processor 10 may use a technique such as pattern matching, for example, as the analysis technique employed in the image recognition processing described above. (2) The processor 10 also detects a user's gesture from the shape of the user's hand. For example, the processor 10 identifies the number of fingers of the user (the number of extended fingers) from the shape of the user's hand detected from the captured image. Processor 10 further identifies the gesture made by the user from the identified number of fingers. For example, when the number of fingers is five, processor 10 determines that the user has performed the "pa" gesture. In addition, when the number of fingers is 0 (no fingers are detected), the processor 10 determines that the user has performed the "goo" gesture. In addition, when the number of fingers is two, the processor 10 determines that the user has made the "Scissors" gesture. (3) The processor 10 performs image recognition processing on the image captured by the camera 17 to detect whether the user's finger is in a state in which only the index finger is raised or whether the user's finger is flicking. . (4) The processor 10 detects an object 1010 (such as a user's hand) near the user terminal 100 based on at least one of the image recognition result of the captured image of the camera 17 and the output value of the distance measuring sensor 18. ) and the user terminal 100 is detected. For example, the processor 10 determines whether the user's hand is close to the user terminal 100 (for example, a distance less than a predetermined value) or far away from the user terminal 100 (for example, a predetermined value or more distance). Note that when the captured image is a moving image, the processor 10 may detect whether the user's hand is approaching or moving away from the user terminal 100 . (5) When it is found that the distance between the user terminal 100 and the user's hand has changed while the user's hand is detected based on the image recognition result of the captured image of the camera 17, the processor 10 recognizes that the user is waving his hand in the photographing direction of the camera 17 . When an object is detected or not detected by the ranging sensor 18, which has a stronger directivity than the imaging range of the camera 17, the processor 10 detects that the user is waving his hand in a direction orthogonal to the imaging direction of the camera. recognize.

In this way, the processor 10 determines whether or not the user is clenching his/her hand (a "goo" gesture or another gesture (for example, "pa") by image recognition of the captured image of the camera 17. or) is detected. The processor 10 also detects how the user is moving the hand together with the shape of the user's hand. The processor 10 also detects whether the user is moving his/her hand closer to or away from the user terminal 100 . Such operations can correspond to operations using a pointing device such as a mouse or a touch panel, for example. For example, the user terminal 100 moves the pointer on the touch screen 15 according to the movement of the user's hand, and detects the user's gesture "goo". In this case, the user terminal 100 recognizes that the user is continuing the selection operation. The continuation of the selection operation corresponds to, for example, maintaining the state in which the mouse is clicked and pushed in, or maintaining the state of being touched after performing a touchdown operation on the touch panel. Further, when the user moves his/her hand while the user's gesture "goo" is detected, the user terminal 100 performs such a series of gestures as an operation corresponding to the swipe operation (or drag operation). can also recognize. Further, when the user terminal 100 detects a gesture such as flicking a finger based on the detection result of the user's hand from the captured image of the camera 17, the user terminal 100 detects the gesture by clicking the mouse or tapping the touch panel. may be recognized as an operation corresponding to

<Game Overview>
A game (hereinafter referred to as "this game") executed by the game system 1 according to the first embodiment based on a game program is, as an example, a breeding simulation game. The breeding simulation game is, for example, an idol breeding simulation game in which a character aiming to become an idol is trained. In this game, the above-mentioned character is, for example, a high school boy aiming to become an idol in a fictional world.

The game system 1 is not limited to a specific genre, and may be a system for executing games of all genres. For example, sports-themed games such as tennis, table tennis, dodgeball, baseball, soccer and hockey, puzzle games, quiz games, RPGs, adventure games, shooting games, simulation games, breeding games, and action games. good too.

Also, the game system 1 may be a system for executing games of any play type, not limited to a specific play type. For example, a single-player game played by a single user, a multiplayer game played by a plurality of users, and among multiplayer games, a competitive game in which a plurality of users compete against each other, and a cooperative play game in which a plurality of users cooperate with each other. may

The game, as an example, may include deck building elements. That is, the game system 1 allows the user to possess game media as digital data that can be used in the game, composes a set of these game media (hereinafter referred to as a deck), and progresses the game based on the deck. .

In this game, the game content influences the progress of the game by subjectively performing some action according to the user's operation. For example, game media are provided to users in the form of cards, which are the minimum units that make up a deck.

In this game, as an example, each card is associated with one of a plurality of characters appearing in this game as a group identifier for classifying the card. A character is expressed as a subject that performs the above-described actions in at least one play part that constitutes the game. In this game, various parameters are set for cards and characters. The user can enhance these parameters through playing the game. In other words, the game may be a game including training elements for training cards or characters.

A game program for executing this game is provided basically free of charge from the server 200 to the user terminal 100 . Some of the in-game services are provided for a fee. As an example, this game is a so-called item-charging game.

In this embodiment, as an example, some of the game media that can be used in this game are provided for a fee. In the present embodiment, as an example, game media provided for a fee are referred to as paid items. Paid items are represented, for example, by simulating diamonds in the game. In this game, diamonds are consumed, for example, to cause the game system 1 to execute a process of selecting cards as game media to be possessed by the user based on a predetermined rule, a so-called "lottery."

In this embodiment, diamonds are granted to the user in conjunction with the user's payment for purchasing diamonds. In addition, diamonds are distributed to the user as a play reward when the user plays the game instead of making a payment and advances the progress of the game so as to meet predetermined conditions. may

In the game system 1, the diamonds granted in accordance with the user's purchase behavior and the diamonds distributed according to the user's play content in place of the user's purchase behavior may be managed separately. Alternatively, only the total number may be managed. Hereinafter, the former diamonds are referred to as purchased diamonds (first paid item), and the latter diamonds are referred to as distributed diamonds (second paid item), and are distinguished as necessary. In the present embodiment, as an example, the game system 1 distinguishes between purchased diamonds given along with a purchase action and distribution diamonds distributed as a play reward in place of a purchase action, and manages the number of each. do.

<Game cycle>
FIG. 2 is a diagram explaining an example of the game cycle of this game. This game consists of multiple play parts. This game is a training simulation game, and includes, as an example, a story part (second part), a practice part (second part), a practice part (second part), a lottery part, an ability management part, and an neglect part ( Part 1) includes 6 play parts.

The story part is a part in which the user advances the game by reading a story about the character, and is the main objective part of the game for the user. The story is provided to the user in the user terminal 100 as story data including at least one of images including still images and moving images, audio, and text.

In this embodiment, as an example, story data is provided as story data including the content of either a common story or an individual story. The common story is developed as the main story of this game, and should be called the main story of this game, in which various characters prepared in this game appear. The common story is assumed to be read by all users in a straight line without branching. An individual story is a side story about individual characters appearing in a common story, such as a side story or a spin-off story. The individual story may have branches or may be read in a different order depending on the user's play situation.

In this way, the user can read through common stories and enjoy individual stories about their favorite characters through video, audio, and text. An individual story may be a story focused on one character, or a story focused on specific characters and their relationships.

In this embodiment, the conditions for reading the story are set, and the user plays the following play parts so as to satisfy the conditions in order to release the locked story. The playfulness of this game as a game is found, for example, in how the user plays the following play parts in order to unlock the story. On the other hand, there may be stories that are automatically released when the time comes or when supplied from the server 200, even if the user does not meet any particular play conditions.

When the user plays the story part, the user obtains some achievements based on the playing of the part to advance the subsequent game progress, especially the practice part and practice part. The result is, for example, the release of quests that can be played in the practice part and practice part. In the following, the quests are referred to as "stages" in which the characters perform as idols in the context of the training simulation game. As other outcomes, distribution diamonds, lottery points, or lottery tickets may be given to the user. For example, when a user finishes reading one piece of story data corresponding to one story, the user may be given a predetermined number of distribution diamonds as a reward for completing the reading. As a result, the user can read the released story data one after another, accumulate distribution diamonds, and enjoy the lottery part described later.

The practice part is a part for training cards and characters corresponding to the cards. As an example, in the practice part, a stage is progressed using a deck in which cards are arranged. When the user selects the stage he/she wants to play and progresses through the stage to the end, it is determined that the user has cleared the stage. Based on the clearing of the stage, the user obtains some kind of result for the subsequent progress of the game, especially the practical part. Examples of achievements include acquisition of rewards, enhancement of card or character parameters, enhancement of user status, and release of individual stories of characters. Rewards are, for example, cards that can be used in each part, enhancement items for enhancing cards or characters, and the like. Cards and characters that have been trained by repeatedly playing the practice part behave more advantageously in the following practice part, for example.

The practice part is a part in which the player clears the tasks imposed on the stage using the deck in which the trained cards are organized. When the user selects a stage that he/she wants to play and clears the stage, the user can obtain a result associated with clearing the stage. Achievements are, for example, rewards for clearing and unlocking common stories. Clear rewards are, for example, cards and enhancement items. Other achievements may be given to the user, such as enhancement of card or character parameters, and improvement of the user's status.

In this embodiment, the practice part may be, for example, a part in which one or more cards (game media) possessed by the user are played against opponent's cards. The opponent may be another user or a computer (COM) that operates according to a game program. Also, one or more cards used in the battle may be usable in the battle by incorporating them into the deck. The deck may have a configuration different from that of the deck organized in the practice part, or may have the same configuration. In the present embodiment, as an example, the practice part is a battle in which each character of the deck organized by the user and each character of the deck organized by the computer based on the game program 131 compete for high performance as idols ( COM battle). In this embodiment, a clear determination is made according to whether the result of the COM game is victory, draw, or defeat, and the result given to the user is determined. As an example, the battle may proceed in such a way that the stronger the parameters of the user's card used in the battle, for example, in the previous practice part, the easier it is for the user to win.

The lottery part is a part in which the user acquires game media as digital data that can be used in the game in exchange for in-game value. In this embodiment, as an example, a lottery is executed in the game system 1 while the lottery part is in progress. Specifically, the server 200 executes a lottery by selecting game media to be owned by the user from a population consisting of a plurality of game media based on a predetermined rule. The in-game value exchanged for the execution of the lottery may be, for example, a valuable medium such as virtual currency obtained by charging the user, or may be points or consumable items provided free of charge as play rewards. . In this embodiment, as an example, when a lottery is executed in the lottery part, the winning card is owned by the user. The winning card can be used in the practice part and practice part.

Valuable media consumed for executing the lottery refers to the above-described paid items in the present embodiment, and more specifically refers to the above-described diamonds. Further, in the present embodiment, the consumable items consumed for executing the lottery are expressed in the form of lottery tickets, as an example. In this game, as an example, the user can cause the game system 1 to execute a lottery by exchanging a predetermined number of diamonds or consuming a predetermined number of lottery tickets.

In this embodiment, as an example, with respect to lottery, purchased diamonds and distributed diamonds are treated as equivalent. Therefore, the number of diamonds required for the lottery is the same regardless of whether the diamonds are purchased or distributed, and the lottery is executed in the same manner regardless of which diamond is consumed. That is, cards to be given to users are selected from the same population according to the same rules.

Further, in the present embodiment, as an example, one lottery is executed once in which one card is won with one lottery ticket. Furthermore, in the present embodiment, lottery points that can be exchanged for lottery tickets can be given to the user. For example, in this game, it is assumed that 100 pt of lottery points given to the user can be exchanged for one lottery ticket. Lottery points are distributed to users as login bonuses, play rewards, and the like.

As described above, in this game, the user has the following three means for causing the game system 1 to execute the lottery. (1) Purchase diamonds and conduct a lottery in exchange for the purchased diamonds. (2) The game is played so that a predetermined condition is satisfied, and a lottery is conducted in exchange for the distributed diamonds obtained. (3) The game is played so that a predetermined condition is satisfied, lottery points are accumulated, and the lottery tickets obtained by exchanging the lottery points are consumed to conduct the lottery.

Here, "allowing the user to obtain/hold/provide (game media, etc.)" means, as an example, changing the status of digital data such as game media managed in association with the user from unusable to usable. It may be to make the transition possible. Alternatively, the digital data may be stored in at least one of memory 11 and memory 21 included in game system 1 in association with user identification information or user terminal ID.

The ability management part is a part that consumes the enhancement items acquired in each of the above parts to release or enhance the abilities of cards or characters. By releasing or enhancing the abilities of cards or characters in this part, the user can advance the practice part and practice part more favorably.

The idle part is a part that includes so-called idle game elements. Specifically, after the user instructs the execution of the neglected part, the game automatically progresses, and after a predetermined period of time has passed, the user is notified of the result of the automatic progress. In this embodiment, as an example, the user terminal 100 executes a sub-part called an execution part and a sub-part called a viewing part in the neglected part. In the execution part, the user terminal 100 causes at least one of a plurality of characters appearing in the game to transition from a first state to a second state in response to a first input operation by the user. After transitioning to the second state, the character is returned to the first state in response to the lapse of a predetermined time, and the character is in the second state in response to the return to the first state. Reward users with character-based content. In the browsing part, the user terminal 100 accepts from the user a second input operation for specifying content to be displayed among the contents given to the user, and in response to accepting the second input operation, specifies The received content is displayed on the display unit 152 . As a result, the user can browse the content based on the character obtained by playing the neglected part separately from the story read in the story part, and enjoy the game while further increasing attachment to the character. can be done.

Furthermore, in the execution part, the user terminal 100 may reward the user with enhancement items, lottery tickets, or the like, in addition to the content. This can further motivate the user to play the idle part.

The game may include elements of a miniscape game, a so-called miniature garden game. For example, the game may include sandplay parts in addition to the five play parts described above. In the sandplay part, the user can arrange various game media such as items and cards obtained by playing the above parts on the map, and enjoy a bird's-eye view of the world of the map. Also, the play result of the sandplay part may be set so that the play result of the sandplay part acts favorably in the other parts described above.

<Functional Configuration of Game System 1>
FIG. 3 is a block diagram showing functional configurations of the server 200 and the user terminal 100 included in the game system 1. As shown in FIG. Each of the server 200 and the user terminal 100 may include a functional configuration required to function as a general computer (not shown) and a functional configuration required to realize known functions in the game.

The user terminal 100 has a function as an input device that receives user input operations and a function as an output device that outputs game images and sounds. The user terminal 100 functions as a control unit 110 and a storage unit 120 through cooperation of the processor 10, memory 11, storage 12, communication IF 13, input/output IF 14, and the like.

The server 200 has a function of communicating with each user terminal 100 and assisting the user terminal 100 in progressing the game. When the game is a multiplayer game, the server 200 may have a function of communicating with each user terminal 100 participating in the game and mediating exchanges between the user terminals 100 . The server 200 functions as a control unit 210 and a storage unit 220 through cooperation of the processor 20, memory 21, storage 22, communication IF 23, input/output IF 24, and the like.

Storage unit 120 and storage unit 220 store a game program, game information 132 and user information 133 . The game program 131 is a game program executed by the user terminal 100 . The game program 231 is a game program executed by the server 200 . Game information 132 is data referred to when control unit 110 and control unit 210 execute a game program. User information 133 is data relating to a user's account. In the storage unit 220, game information 132 and user information 133 are stored for each user terminal 100. FIG.

(Functional Configuration of Server 200)
The control unit 210 controls the server 200 by executing the game program 231 stored in the storage unit 220 . For example, the control unit 210 transmits various data, programs, etc. to the user terminal 100 . The control unit 210 receives part or all of the game information or user information from the user terminal 100 . If the game is a multi-play game, the control unit 210 may receive a multi-play synchronization request from the user terminal 100 and transmit data for synchronization to the user terminal 100 .

The control unit 210 functions as a progress support unit 211 according to the description of the game program 231 . The control unit 210 can also function as other functional blocks (not shown) in order to support the progress of the game on the user terminal 100 according to the nature of the game to be executed.

The progress support unit 211 communicates with the user terminal 100 and supports the user terminal 100 to progress various play parts included in the game. For example, information to be referred to by the user terminal 100 at that time is appropriately provided depending on which of the play parts described above is being executed.

(Functional Configuration of User Terminal 100)
The control unit 110 comprehensively controls the user terminal 100 by executing the game program 131 stored in the storage unit 120 . For example, the control unit 110 progresses the game according to the game program 131 and user's operation. Further, while the game is progressing, the control unit 110 communicates with the server 200 as necessary to transmit and receive information.

Control unit 110 functions as story part progress unit 111 , practice part progress unit 112 , practice part progress unit 113 , lottery part progress unit 114 , and neglect part progress unit 115 according to the description of game program 131 .

Note that the control unit 110 can also function as other functional blocks (not shown) in order to advance the game according to the nature of the game to be executed. For example, the control unit 110 may function as an ability management unit that advances the above-described ability management part, and a sandplay part progression unit that advances the above-described sandplay part.

Furthermore, the control unit 110 also functions as an operation reception unit (not shown), a display control unit, and the like. The operation reception unit detects and receives a user's input operation on the input unit 151 . For example, the operation reception unit detects the coordinates of the input position on the input unit 151 of the above-described input operation, and identifies the type of the input operation. The operation reception unit identifies, for example, a touch operation, a slide operation, a swipe operation, a tap operation, and the like. The display control unit outputs to the display unit 152 of the touch screen 15 a game screen on which the processing results executed by each unit of the control unit 110 are reflected. The display control unit may display a game screen including images generated by each unit of the control unit 110 on the display unit 152 . Further, the display control unit may draw a graphical user interface (hereinafter referred to as GUI) superimposed on the game screen.

The story part progressing unit 111 progresses the story part described above. The story part progression unit 111 reproduces story data corresponding to the story. Story data is data including at least one or more of various data such as moving images, still images, texts, and voices in order to present a story to the user. The story part progression section 111 manages the status of each story, for example, whether it is released or not.

The practice part progression unit 112 advances the above-described practice part. The practice part progressing unit 112 organizes decks used for progressing a quest, which is a stage in this embodiment, and progresses the stage. When the user has played the stage to the end, the practice part progressing section 112 determines a result associated with completing the stage, and reflects the result in the game information 132 .

The practice part progression unit 113 advances the above-described practice part. The practice part progression unit 113 organizes the decks used in the stage, which is the COM game in this embodiment, and advances the COM game. The practice part progression unit 113 determines a result according to the result of the COM game, and reflects the result in the game information 132 .

The lottery part advancing unit 114 advances the above-described lottery part. The lottery part progressing unit 114 transmits a lottery execution request to the server 200 in accordance with the user's input operation for instructing the execution of the lottery. When the winning card is determined by the server 200, the lottery part progressing unit 114 receives notification of the winning card from the server 200 and allows the user to hold the winning card.

The neglected part advancing unit 115 advances the above neglected part. Specifically, the neglected part progression unit 115 transitions the character selected by the user from the first state to the second state, and after a predetermined time has passed since the transition to the second state, The content is given to the user as a play reward for the neglected part.

The second state in which the character falls while the execution part is progressing independently of the user's operation may be expressed to the user, for example, in the form of a sleep state in which the character is sleeping. In this case, the character's first state while the execution part is not progressing may be represented, for example, in the form of an awakened state.

In the present embodiment, as an example, the neglected part progressing unit 115 generates content based on the character at an arbitrary timing after the character transitions to the second state and before content is provided to the user. .

In this embodiment, the content is digital data expressing an event in the form of an event experienced by a character transitioning to the second state while in the second state. Specifically, it is digital data that expresses the content of a dream in the form of a diary report of the content of a dream seen by a character who has transitioned to sleep.

The content is configured to include at least one of moving image data, still image data, audio data, and text data, for example. In the viewing part, idle part progression unit 115 reproduces the content assigned to the user and outputs the content to display unit 152 and a speaker (not shown), thereby allowing the user to view the content.

In the present embodiment, as an example, the content is "diary data" generated in the form of a diary in which a character who has transitioned to sleep describes the details of a dream that he had during his sleep. A method of generating diary data and its data structure will be described in detail later.

Note that the functions of the server 200 and the user terminal 100 shown in FIG. 2 are merely examples. The server 200 may have at least some of the functions that the user terminal 100 has. Also, the user terminal 100 may have at least part of the functions of the server 200 . Furthermore, a device other than the user terminal 100 and the server 200 may be used as a component of the game system 1 and the other device may be caused to perform part of the processing in the game system 1 . That is, the computer that executes the game program in this embodiment may be any of the user terminal 100, the server 200, and other devices, or may be realized by a combination of a plurality of these devices.

<Outline of Invention>
In this embodiment, the user terminal 100 includes a memory 11 that stores a game program 131 , a processor 10 that controls the operation of the user terminal 100 by executing the game program 131 , and a display section 152 . The processor 10 of the user terminal 100 is configured to execute the following steps based on the game program 131 in order to improve the interest of the game. That is, the processor 10 changes the first character from the first state to the second state in response to the user's first input operation on at least one of a plurality of characters appearing in the game based on the game program 131 . a step of transitioning to the state (S107); a step of returning the first character to the first state when a predetermined time has passed after the first character transitioned to the second state (S119); Step (S120) of providing the user with content (diary data) based on the first character that was in the second state in response to the return of the first character to the first state; and a second input operation by the user. and a step (S204) of displaying the specified content on the display unit in response to the request.

Based on the game program 131, the processor 10 provides a second input for designating the content to be displayed among the one or more pieces of content given to the user after step S120 of giving and before step S204 of displaying. A step of receiving an operation from the user (S203) may be executed.

<Data structure>
(card)
FIG. 4 is a diagram showing an example of the data structure of a card. FIG. 4 shows the data structure of data corresponding to one card. Cards having the data structure shown in FIG. 4 are stored in the storage unit 120 as the game information 132 as many as the number of cards held by the user. A card database (DB) is constructed by a collection of cards. The card DB is a database for centrally managing cards held by users. In the card DB, a card having the data structure shown in FIG. 4 is treated as one record.

A card includes, for example, items of card ID, character name, rarity, attribute, card level, charm, practice skill, main skill, sub-skill, and dialogue management information.

The card ID field stores card IDs. A card ID is identification information uniquely assigned to a card in order to uniquely manage the card owned by the user on the game system 1 . In the present embodiment, a plurality of cards with the same content may be acquired in duplicate. Therefore, when there are a plurality of cards with the same contents, each card is given a different card ID to identify each card.

The character name item stores the name of the character associated with the card as a group identifier for classifying the card. In this embodiment, the character linked to the card is one of the characters appearing in the game. A character is an action subject that performs a predetermined action in a practice part and a practice part. It functions as an action subject. Each character that appears as an action subject in this game has a unique name that does not overlap with other characters. That is, the character name can uniquely identify the character associated with the card. A character ID is also uniquely assigned to each character in order to uniquely identify the character. Therefore, the item may store a character ID in place of the character name.

Also, in the present embodiment, the same character may be associated with different cards. Therefore, it is possible that the user has a plurality of cards with which the same character is tied, and in this case, each of the plurality of cards is treated as a separate card.

The item of rarity stores the rarity set for the card. The rarity is a grade representing the rarity value of the card in the game. In general, a high rarity level is set for a card that gives good results in the game, especially in the practice part and practice part. In this embodiment, the rarity level is represented by four levels of SSR, SR, R, and N in descending order of grade. In addition, the rarity is, for example, the difficulty of obtaining a card, more specifically, the probability of winning in a lottery where the card wins, the difficulty of the stage when obtained as a reward for clearing the stage, or the difficulty of obtaining it for a fee. There may be a correlation with price or the like. The higher the difficulty of obtaining the card, the higher the rarity of the card is set.

The attribute item stores information indicating which attribute the card is classified into when the card is classified by attribute. In this game, as an example, three attributes of red, blue, and yellow are provided. Cards are classified into one of red, blue, and yellow attributes. Note that the name of the attribute is appropriately set according to the context of the game. For example, in a game in which an idol appears, the three attributes of passion, intelligence, and grace may be used, and in a game in which a wizard appears, the three attributes of fire, water, and lightning may be used.

Attributes may also be set where the game progresses using cards in the practice part. In this game, the field refers to a place where a card selected as a card used for progressing the game is arranged among the cards arranged in the deck. The user can proceed with the game by using the cards that he/she wants to use in the game by putting them into play. Attributes set in the field are referred to as field attributes. The attributes of the cards incorporated in the deck (hereinafter referred to as card attributes) and the field attributes are referred to by the practice part progression unit 112 during the progress of the practice part, for example, in order to determine the outcome of clearing the stage.

Attributes may also be set to enhancement items for enhancing card parameters. The card attribute of the enhancement target card and the attribute of the enhancement item are referred to, for example, by an ability management section (not shown) during the progress of the ability management part. For example, by using an enhancement item having the same attributes as a card to enhance the card, enhancement efficiency is improved.

The card level item stores a value indicating the level of the card itself. In this embodiment, the higher the card level, the higher the performance that brings about good results in the practice part. The card level can be increased, for example, as a result of clearing the stage of the practice part.

The charm item stores a charm parameter value as one of the card performances. The higher the charm parameter value, the more advantageous the card is in COM battles in the practice part. For example, in a COM game that competes for the number of spectators, the higher the attractiveness, the more spectators can be recruited, and the easier it is to win the COM game. Charm is correlated with card level, and the higher the card level, the higher the charm parameter value.

Detailed information on practice skills is stored in the item of practice skills. A practice skill is tied to a card, and can be activated during a stage of the practice part when the card is incorporated into the deck of the practice part.

The main skill item stores detailed information on the main skill. A main skill is tied to a card, and can be activated during the progress of a stage in the practice part when the card is incorporated into the main deck in the practice part.

The subskill item stores detailed information on the subskill. A sub-skill is tied to a card, and can be activated during the progress of a stage in the practice part when the card is incorporated into the sub-deck in the practice part.

Each of the above-described skills linked to the card may be produced as if the character represented on the card had activated during the progress of the stage. When a skill is activated, it has a favorable effect on the progress of each part. The detailed information of each skill includes, for example, the name of the skill, details of the effect, effect value, activation conditions, and the like.

The item of dialogue management information stores dialogue management information. The line management information is information for managing lines to be spoken by the character, and is supplied from the server 200 . Note that if dialogue between characters is not generated as an event in a practice part or the like, the line management information item may be omitted from the card.

(charactor)
FIG. 5 is a diagram showing an example of the data structure of character data that defines a character. Character data having the data structure shown in FIG. 5 is created for each character in each game part of the game and stored in the storage section 120 as the game information 132 . Character data may be stored in the storage unit 120 for the characters associated with the card owned by the user, or the character data for all characters appearing in the game may be stored before the user obtains the card. Character data may be stored in storage unit 120 .

The character data includes, for example, character ID, character name, affiliation (category), pair parameter table, story list, dialogue database (DB), and card ID list.

A character ID is stored in the character ID item. A character ID is identification information uniquely assigned to a character in order to uniquely manage the character functioning as an action subject in each game part on the game system 1 . Character IDs preferably consist of systematically unique text strings (symbols, alphanumeric characters, etc.).

A character name is stored in the character name item. A character name is identification information uniquely assigned to a character so that the user can identify the character. If the character is a male high school idol, it is preferable that the character string be composed of a character string that can be identified as a person's name or a nickname so that the user can easily identify the character.

The belonging item stores a parameter indicating which group the character belongs to. Each character in the story unfolding in the story part has various settings indicating the category of the character, such as the nature or affiliation of the character. A plurality of affiliation items may be provided. Affiliation items may be defined more specifically according to the context and world view of the game. For example, if the character is a male high school student, the affiliation items include items representing the categories of the character, such as the character's “grade”, “club activities”, “dorm affiliation”, “faction”, and “blood type”. may be provided.

The pair parameter table item stores the pair parameter table or access information indicating the location where the pair parameter table is stored. A pair parameter is a numerical representation of the relationship between the character and other characters. In this embodiment, a pair parameter is set for each combination of all characters appearing in this game. The pair parameter table is a list of pair parameters set with other characters for each of the characters defined by the character data shown in FIG. 5 as a reference.

Instead of managing a pair parameter table for each character, the game system 1 has a pair parameter database (hereinafter referred to as DB) for centrally managing pair parameters set for each combination of all characters appearing in the game. may be stored in the storage unit (storage unit 120 or storage unit 220). In this case, the item of the pair parameter table may store a query for extracting the pair parameter of the character with another character from the pair parameter DB. The pair parameter table and pair parameter DB will be detailed later based on the data structure diagram.

The story list item stores the story list or access information for accessing the story list. The story list is a list of individual stories related to the character. In this embodiment, as an example, an individual story about a character is a story focusing on pairs of the character and other characters. The story list will be detailed later based on the data structure diagram.

The line database item stores the line DB or access information for accessing the line DB. The dialogue DB is a database that centrally manages dialogue packs linked to the character. A dialogue pack is information in which event data necessary for progressing an event in a practice part, its metadata, and the like are packaged together. Specifically, the dialogue pack includes at least a dialogue group consisting of one or more dialogues to be uttered by the character or a partner character paired with the character. In addition, in a practice part or a practice part, if no dialog event occurs, the items of the dialog database may be omitted from the character data.

The card ID list item stores the card ID list or access information for accessing the card ID list. The card ID list is a list of card IDs of cards with which the character is linked among the cards held by the user. By referring to the card ID list, the user terminal 100 can immediately extract the card associated with the character from among the cards held by the user.

In this embodiment, characters and cards are in a one-to-many relationship. In other words, one character is associated with one card, but the same character can be associated with a plurality of different cards. Also, even with the same character, different attributes can be set for each card if the cards that are tied to it are different.

In addition, in the present embodiment, as shown in FIG. 5, each character is associated with the various items described above, and the information for each character is shared by each card associated with the same character. be.

In other words, cards can be grouped by character, characters can be regarded as groups for classifying cards, and character IDs and character names can be regarded as group identifiers for grouping cards. Then, when each card belonging to the same group is used, the information associated with the group is commonly referred to by each card. Specifically, when each card that is tied to the same character is incorporated into a deck and used, the user terminal 100 operates the character that is tied to the card. Browse items.

Cards can also be classified based on rarity or attributes, as described above, in addition to characters. Furthermore, the cards can be classified based on the affiliation set for the character.

(pair parameter table)
(A) of FIG. 6 is a diagram showing an example of the data structure of a pair parameter table. In this game, as an example, five characters appear in the story. The character names of the five characters are, for example, A-ta, B-suke, C-hiko, D-man, and F-ro. In the figure, as an example, a pair parameter table associated with the character "A-fat" is shown. A similar pair parameter table is created for each of the B-suke, C-hiko, D-man, and F-ro characters.

The pair parameter table includes items of partner character and pair parameter. As described above, the pair parameter is a numerical representation of the relationship between the two characters that make up the pair. It is

The item of partner character stores the character name of the partner character paired with the reference character. For example, the first record shown in FIG. 6 is a record for storing a pair parameter between a reference character "A fu" and its partner character "B suke".

The degree of friendship item stores a numerical value indicating the degree of friendship between characters. The degree of friendship is an index for evaluating the degree of friendship between paired characters. In this embodiment, the higher the numerical value, the higher the degree of friendship between the pair, that is, the two people are on good terms. In the example shown in FIG. 6, for example, the degree of friendship between "A-ta" and "B-suke" is "25." Friendship is referred to as a condition for releasing individual stories for each pair.

The degree of harmony item stores a numerical value indicating the degree of harmony between characters. The degree of harmony is an index for evaluating the goodness of cooperation between paired characters. In this embodiment, 100% is taken as the maximum degree of harmony that a pair can have, and the higher the value, the better the pair's coordination, that is, the better the performance output by the pair. .

For example, when playing the stage of the practice part, among the cards used in the stage, according to the numerical value of the degree of harmony between the characters indicated by the two specific cards, the two characters in the stage of the practice part The effects of images, moving images, sounds, and the like related to the characters may be changed. Specifically, when the numerical value of the degree of harmony between the two characters is equal to or greater than a predetermined value, at least one of an image, a video, and a sound indicating that the two characters are intimate is output. good too. Also, the higher the numerical value of the degree of harmony between the two characters, the more gorgeous the presentation may be. Further, the number of times of the effect, that is, the frequency of effect may be increased as the numerical value of the degree of harmony between the two characters is higher.

Also, for example, the higher the numerical value of the degree of harmony between the two characters, the more advantageous the stage progression of the practice part may be. Specifically, the higher the numerical value of the degree of harmony between the two characters, the longer the effect value or the duration of the effect content of the skill that can be exercised in the stage of the practice part. Also, the higher the numerical value of the degree of harmony between the two characters, the greater the number of times the skill of at least one of the two characters can be activated and the opportunity to activate the skill of the two characters in the stage of the practice part. .

Also, for example, the higher the numerical value of the degree of harmony between the two characters, the more advantageous the game is by changing the values of various parameters set for these characters or cards corresponding to the characters. may Specifically, the higher the numerical value of the degree of harmony between the two characters, the higher the charm parameter value of the cards corresponding to these characters. In addition, when the stage of the practice part is a battle-type stage in which the user's own camp and the enemy camp compete, the degree of harmony between the characters indicated by the specific two cards of the own camp and the specification of the enemy camp may be compared with the degree of harmony between the characters indicated by the two cards. Then, as a result of the comparison, the parameter of the particular two cards of the faction with the higher degree of harmony may be increased. Alternatively, the parameters of the particular two cards of the faction with the lower harmony may be reduced as a result of the comparison.

Also, for example, in the case of a game in which the stage of the practice part progresses by executing the turn of the own side and the turn of the enemy side, as a result of the above-mentioned comparison, the turn of the side with the higher degree of harmony is performed first. can be As an example, it is assumed that the faction with the higher degree of harmony increases the probability of taking the first move in the battle. Alternatively, the frequency of performing the turns of the side with the higher degree of harmony as a result of the aforementioned comparison may be increased.

In this embodiment, as an example, the degree of harmony can be increased by the pair practicing in the practice part, and is consumed in order for the pair to output a specific performance in the practice part. That is, the degree of harmony is a numerical value that increases or decreases as the user repeatedly plays the practice part and the practice part.

FIG. 6B is a diagram showing an example of the data structure of the pair parameter DB. In this embodiment, in the pair parameter DB, a combination of characters appearing in the game, that is, a pair is used as a main key, and a record is created for each pair. A pair parameter is stored in the record. Specifically, the degree of friendship and the degree of harmony are stored.

In this embodiment, as described above, five characters appear. In this case, there are 10 possible combinations of 5 characters, so the pair parameter DB has 10 records. The control unit 110 of the user terminal 100 may extract a pair parameter record from the pair parameter DB using one character as a key. For example, if the pair parameter DB is operated based on the query "extract records whose primary key contains A," a pair parameter table for A, as shown in FIG. 6A, is obtained. be done.

(story list)
FIG. 7 is a diagram showing an example of the data structure of a story list. In the same figure, as an example, a story list linked to the character "Ata" is shown. A similar story list is created for each of the B-suke, C-hiko, D-man, and F-ro characters.

The story list includes items of partner character, story ID, and state.

The item of partner character stores the character name of the partner character paired with the reference character ("A-fat" in this case).

The story ID field stores the story ID of the individual story associated with the pair. A story ID is identification information for uniquely identifying story data corresponding to an individual story in the game system 1 . Any information that can uniquely identify an individual story may be used. For example, instead of the story ID, the item may store a story title, a chapter number, or the like set for each individual story. Alternatively, instead of the story ID, the item may store address information indicating the location where the story data corresponding to the individual story is stored.

Individual stories may be provided to multiple users per pair. In the example shown in the figure, for example, individual stories related to the pair of A-ta and B-suke are provided to the user for three episodes with story IDs "AB001" to "AB003".

The status item stores a parameter indicating the status of the individual story. A parameter indicating the state of an individual story may be, for example, a flag indicating whether the individual story has been released or not. In this embodiment, when an individual story is “released”, it means that the user can access the story data of the individual story via the user terminal 100 and the user can read the individual story. It means that it is in a state where

Furthermore, release progress may be stored as a parameter indicating the status of the individual story in the above status item or a separate item. The release progress is information indicating to what extent the user has satisfied the release condition when the individual story has not been released. In this embodiment, the release progress is, for example, a fraction, and is composed of a denominator indicating the degree of friendship required for release and a numerator indicating the current degree of friendship of the pair accumulated by the user playing the game. be done.

The individual stories may be centrally managed on a pair-by-pair basis in a database having pairs as the primary key, similar to the pair parameter DB shown in FIG. 6B.

(story list)
FIG. 7 is a diagram showing an example of the data structure of a story list. In the same figure, as an example, a story list linked to the character "Ata" is shown. A similar story list is created for each of the B-suke, C-hiko, D-man, and F-ro characters.

The story list includes items of partner character, story ID, and state.

The item of partner character stores the character name of the partner character paired with the reference character ("A-fat" in this case).

The story ID field stores the story ID of the individual story associated with the pair. A story ID is identification information for uniquely identifying story data corresponding to an individual story in the game system 1 . Any information that can uniquely identify an individual story may be used. For example, instead of the story ID, the item may store a story title, a chapter number, or the like set for each individual story. Alternatively, instead of the story ID, the item may store address information indicating the location where the story data corresponding to the individual story is stored.

Individual stories may be provided to multiple users per pair. In the example shown in the figure, for example, individual stories related to the pair of A-ta and B-suke are provided to the user for three episodes with story IDs "AB001" to "AB003".

The status item stores a parameter indicating the status of the individual story. A parameter indicating the state of an individual story may be, for example, a flag indicating whether the individual story has been released or not. In this embodiment, when an individual story is “released”, it means that the user owns the story data of the individual story or has the authority to access the story data via the user terminal 100. It means that the user can read the individual story.

Furthermore, release progress may be stored as a parameter indicating the status of the individual story in the above status item or a separate item. The release progress is information indicating to what extent the user has satisfied the release condition when the individual story has not been released. In this embodiment, the release progress is, for example, a fraction, and is composed of a denominator indicating the degree of friendship required for release and a numerator indicating the current degree of friendship of the pair accumulated by the user playing the game. be done.

The individual stories may be centrally managed on a pair-by-pair basis in a database having pairs as the primary key, similar to the pair parameter DB shown in FIG. 6B.

<Practice part>
(processing flow)
FIG. 8 is a flow chart showing the flow of processing in the practice part executed by the practice part progression unit 112. As shown in FIG.

In step S301, the practice part progression unit 112 causes the display unit 152 to display a deck organization screen (not shown). The deck formation screen is a screen for receiving an input operation for selecting cards to be incorporated into the primary deck used in the selected stage from among the cards owned by the user.

In step S302, the practice part progression section 112 determines whether or not the above-described input operation performed on the deck formation screen has been received via the operation reception section. If the input operation has been accepted, the practice part progression unit 112 proceeds from YES in step S302 to step S303, and if not, proceeds from NO in step S302 to step S304.

In step S303, the practice part progression section 112 incorporates the cards selected by the user into the primary deck to organize the primary deck.

Furthermore, in the present embodiment, the practice part progression unit 112 may incorporate cards specified according to a predetermined rule into the primary deck, in addition to the cards selected by the user. The practice part progressing unit 112 may identify cards that are not specified by the user among the cards held by the user, according to a predetermined rule. For example, the practice part progression unit 112 may randomly specify cards held by the user. Alternatively, the practice part progression unit 112 may identify cards that the user does not own according to a predetermined rule. For example, the practice part progression unit 112 may specify a card pre-associated with the stage selected by the user as a card to be incorporated into the primary deck. In this embodiment, the practice part progressing unit 112 organizes, for example, ten cards selected by the user and owned by the user and one card associated with the stage into the primary deck.

In step S304, the practice part progression unit 112 may accept an input operation instructing the start of a stage in the practice part. The input operation for instructing the start of the stage may be input by the user touching a UI component such as a "start button" arranged in the deck organization screen, for example. When the start button is touched, the practice part progression unit 112 advances from YES in step S304 to step S305 to start progressing the stage.

Next, the practice part progression unit 112 advances the stage. In this embodiment, as an example, one stage consists of a set of predetermined times. The practice part progression unit 112 advances the stage by repeating each process from step S305 to step S309, which corresponds to one set, a predetermined number of times, for example, 10 sets. In this embodiment, a field is provided for each set. That is, the practice part progressing unit 112 progresses one stage by repeating the process of progressing one set using the cards selected by the user as cards to be put into play for 10 sets. Therefore, the condition for exiting the loop from step S305 to step S309 is that "all the sets that make up the stage have been processed".

In step S305, the practice part progression section 112 organizes the secondary deck based on the primary deck. More specifically, the practice part progression section 112 extracts cards based on a predetermined rule from among the cards included in the primary deck, and organizes the secondary deck made up of the extracted cards. As an example, the practice part progression unit 112 randomly selects five cards to be included in the secondary deck from the eleven cards in the primary deck.

In step S306, the practice part progression unit 112 displays on the display unit 152 a stage progress screen for disclosing basic information of each set in progress to the user. The stage progress screen includes the secondary deck organized in step S305. Specifically, the practice part progressing unit 112 displays, for example, a list of cards of the secondary deck on the stage progress screen described above, and the user selects a card to be used in the set in progress from the list of cards. Provide a UI that allows That is, the stage progress screen also functions as a screen for accepting an input operation from the user to select a card to be used in the set in progress from among the secondary decks. A specific example of the stage progression screen will be described later in detail with reference to FIG. 11(A).

In step S307, the practice part progression unit 112 determines whether or not an input operation performed on the stage progress screen has been received via the operation reception unit. If the input operation has been accepted, the practice part progression unit 112 proceeds from YES in step S307 to step S308.If the input operation has not been accepted, returns from NO in step S307 to step S306, and accepts the input operation. wait until

In step S308, the practice part progression unit 112 determines a reward to be given to the user based on the user's play for one set, that is, the pair selection. The reward is, for example, an enhancement item that can enhance the parameters set in the card.

In step S309, the practice part progression unit 112 puts the card selected by the user from the secondary deck into play according to the user's input operation, and progresses the set in progress to the end. In this embodiment, the practice part progression unit 112 puts two cards selected by the user into play. Then, the practice part progressing section 112 progresses the set based on the cards put into play. In this embodiment, as an example, "using a card in a set" means putting out a card in a field associated with a set in progress, and depending on the combination of the field and the card put out in the field It refers to progressing the event generated by More specifically, the practice part progression unit 112 identifies pairs of characters tied to each card put into play. Then, the practice part progression unit 112 causes the two characters associated with each of the two cards that have been put out to perform a predetermined action. Specifically, the practice part progressing unit 112 processes the event data for reproducing the event that has occurred, and displays an animation with effects of the characters performing the above-described predetermined action on the display unit 152. Also, voice data corresponding to the character's words are output to a speaker (not shown). Further, the practice part progression unit 112 may also output to the display unit 152 an animation showing how the reward of the amount determined in step S308 is dropped and the user can obtain it.

The practice part progression unit 112 executes each process from step S305 to step S309 for each set, and repeats this for each set. When the practice part progression unit 112 executes the processing from step S305 to step S309 for all the sets that make up the stage, for example, after progressing 10 sets, the practice part progression unit 112 exits the loop and proceeds to step S310.

In step S310, the practice part progression unit 112 displays on the display unit 152 a result screen showing the result of playing the stage. The result screen includes at least information indicating how many enhancement items have been granted in total through ten sets, for example.

In step S311, the practice part progressing unit 112 gives the reward obtained in each set to the user. Specifically, the number of possessed enhancement items stored in association with the user is incremented by the number indicated by the above total.

(Deck organization)
FIG. 9 is a diagram showing an example of the data structure of deck information referenced in the practice part. (A) of FIG. 9 shows the deck information of the primary deck, and (B) of FIG. 9 shows the deck information of the secondary deck.

As shown in FIG. 9, the deck information of each deck includes items of position number and card ID.

The item of position number stores identification information for identifying the place where the card is placed in each deck. For example, the position number "1-1" indicates the first placement location in the primary deck, and the card placed here is identified as the first card in the primary deck. Note that the position number item may be omitted in an embodiment in which the arrangement or placement order on the deck does not affect the progress of the game part using the deck.

The card ID field stores the card IDs of the cards included in each deck. In the figure, single-digit numbers are stored to simplify the explanation, but since the card ID is identification information assigned to uniquely identify all cards, in practice, is assumed to be a complex series of letters and symbols.

In addition, in the figure, an item of character names is provided in order to facilitate understanding of the invention. This is illustrated for explanation, and may not be provided as an item in the actual deck information. The character name item stores the character name of the character linked to the card placed at the position.

As shown in FIG. 9A, the deck information of the primary deck has at least positions for placing cards selected by the user. In the illustrated example, ten positions are provided from "1-1" to "1-10".

It is conceivable that the practice part progression unit 112 may specify a card different from the card selected by the user as a card to be put into the primary deck based on a predetermined rule. In this case, the deck information for the primary deck may have positions for placing the cards so identified. In the illustrated example, one position is provided as "1-11". Hereinafter, the cards selected by the practice part progression unit 112 are referred to as guest cards in addition to the cards selected by the user when special distinction is required. As an example, the primary deck consists of 10 positions for arranging cards selected by the user and 1 position for arranging guest cards determined by the practice part progression unit 112. In this embodiment, the guest card is predetermined for each stage, for example.

In step S103, the practice part progressing unit 112 accepts the first input operation of selecting 10 cards via the deck formation screen, and selects the 10 cards and the 1 card associated with the selected stage. The deck information shown in (A) of FIG. 9 is generated based on the guest card.

Based on a group identifier for classifying cards, such as a character name or a character ID, the practice part progression unit 112 identifies a group to which the card belongs, such as a character associated with the card, and collects game media belonging to the same group. may be incorporated into the primary deck so as not to exceed a predetermined maximum number. For example, as shown in (A) of FIG. 9, the practice part progression unit 112 may control the primary deck so that no more than two cards of the same character are included, excluding guest cards. As a result, it is possible to prompt the user to incorporate cards of various characters into the primary deck and train all characters evenly. As a result, the user can enjoy the breeding game for a long time without getting tired of the game.

As shown in FIG. 9B, the deck information of the secondary deck has positions for arranging cards extracted from the cards incorporated into the primary deck by the practice part progressing section 112 . In the illustrated example, five such positions are provided from "2-1" to "2-5".

Every time a set is started, the practice part progression unit 112 extracts 5 cards (a first predetermined number) from the 11 cards incorporated in the primary deck based on a predetermined rule. , to generate the deck information shown in FIG. 9B.

For example, the practice part progression unit 112 may randomly extract five cards. The practice part progression unit 112 may extract five cards depending on which cards were played in the previous set. As an example, the practice part progression unit 112 extracts five cards based on the following rules and organizes the secondary deck.

(A) to (C) of FIG. 10 show in detail the steps from the progress of the previous set to the rearrangement of the secondary decks used by the practice part progression unit 112 to progress the current set. It is a figure explaining to.

(A) of FIG. 10 is a diagram showing an example of cards selected and put into play by the user in step S109 of the previous set. The upper row shows the card ID of the selected card, and the lower row shows the character name of the character linked to the card. As shown, the user selects cards with card IDs "5" and "7" from the cards in the secondary deck shown in FIG. 9B. The cards with card IDs "5" and "7" are hereinafter referred to as a 5th card and a 7th card.

(B) of FIG. 10 is a diagram showing the deck information of the secondary deck immediately after the end of the previous set. In the example shown in the figure, the description of the position number item is omitted. The upper row shows the card ID of the card incorporated in the secondary deck, and the lower row shows the character name of the character linked to the card.

When the previous set ends, the practice part progression unit 112 temporarily removes from the secondary deck the cards that were selected by the user in the previous set and put into play. In the illustrated example, the practice part progression unit 112 removes the 5th card and the 7th card from the secondary deck. On the other hand, the practice part progressing section 112 maintains the cards that were not selected by the user in the previous set as being included in the secondary deck in the current set.

Next, the practice part progression unit 112 rearranges the secondary decks for the current set. As an example, the practice part progression unit 112 selects cards to replenish the positions vacated by removing the above cards. In another example, the practice part progressing section 112 may reset the secondary decks organized in the previous set and newly select all the positions of the secondary decks.

As an example, the practice part progression unit 112 identifies candidates for cards to be replenished in empty positions as follows, and randomly extracts cards to be replenished from the candidates for the cards.

(C) of FIG. 10 is a diagram showing candidates for cards to be replenished in empty positions. For example, the practice part progression unit 112 selects cards that were not included in the secondary deck in the previous set as candidates. As a result, there is a possibility that each card remaining in the primary deck without being extracted by the practice part progressing unit 112 in the previous set will be incorporated into the secondary deck.

That is, the practice part progression unit 112 has a configuration in which cards that were not selected as cards to be put into play in the previous set remain in the secondary deck, and cards that were not extracted for the secondary deck in the primary deck are candidates. It has a configuration that can be put into With these configurations, as a result, it reflects the intention of the game master side, for example, the management organization that supplies the game program of this game to each user, who wants the user to use various cards and develop various characters widely. can be made

In this embodiment, the practice part progression unit 112 also puts into candidates the cards selected by the user in the previous set. As a result, there is a possibility that the cards selected by the user in the previous set will continue to be incorporated into the secondary deck in this set as well. In addition, if the card is incorporated into the secondary deck, the user can select that card as the card to be finally put into play according to his or her own will. It is assumed that the user would like to select a favorite card over and over again in order to develop the parameters associated with that card.

That is, the practice part progression unit 112 has a configuration in which the cards selected as the cards to be put into play in the previous set are included as candidates, and a configuration in which the user selects a card to be put into play from among the secondary decks. . With these configurations, it is possible to meet the user's desire to intensively strengthen a favorite card.

(Stage progress screen)
(A) and (B) of FIG. 11 are diagrams showing an example of a stage progress screen displayed on the display unit 152 of the user terminal 100. FIG.

The practice part progression unit 112 displays, for example, a stage progress screen 900 shown in FIG. 11A on the display unit 152 when executing step S106. The practice part progression unit 112 displays, for example, a stage progress screen 900 shown in FIG. 11B on the display unit 152 when executing step S109.

The stage progress screen 900 has a first function of disclosing basic information about the stage and each set, a second function of providing UI parts for the user to select cards to be used in the set, an event progress and and a third function of presenting the results to the user.

As shown in FIG. 11A, a stage progression screen 900 includes, for example, set information 901, a concentration gauge 902, and achievement information 903 in order to implement the first function.

The set information 901 includes information indicating the progress of stages. The information indicating the progress status is information indicating how many sets remain, including the set in progress (hereinafter referred to as the current set), for which progress has not been completed. By displaying the set information 901 such as "three more sets", the user understands that there are three uncompleted sets.

The set information 901 may further include information indicating field attributes of the current set, the next set, and the next next set. In each set, the "field" is a place for placing two cards selected by the user, and in the context of this game, Two characters (pair) are a practice stage 905 for performing a performance as practice.

Information indicating field attributes may be presented as color-coded icons, for example, as illustrated. Specifically, in the set information 901, the largest icon on the left indicates the field attributes of the current set, the center icon indicates the field attributes of the next set, and the right icon indicates the field attributes of the next set.

In the present embodiment, the practice part progression unit 112 determines the result that the user will obtain when completing the set according to the relationship between the field attributes in the set and the attributes of the cards placed in the field. good too. For example, the practice part progression unit 112 corrects the results of a set in which cards matching the field attributes are placed on the field so that the user can obtain more favorable results than when cards do not match. good too. Specifically, the practice part progression unit 112 may allow the user to acquire more enhancement items as a reward for completing a set with matching attributes, or increase the pair parameters of the pairs appearing in the set. You can use more values. In addition, in the present embodiment, the practice part progression unit 112 allows the user to acquire more medals in a set in which cards matching the field attributes are placed on the field than in the case where the cards do not match. Furthermore, in the present embodiment, the practice part progressing unit 112, in a set in which a card matching the field attribute and having a recommended pair and a character matching the character is placed on the field, is more likely to be played than when only the attributes are matched. Further, the user is made to acquire more medals.

The user can check the field attributes shown in the set information 901 and compare them with the attributes of the cards in hand to select the most suitable pair in order to obtain better results efficiently. As a result, the playability of the practice part is enhanced.

A concentration gauge 902 is a UI component that indicates the degree of accumulation of parameters accumulated as a result of progressing an event each time an event progresses for each set. In the context of this game, the parameter is expressed as, for example, a degree of concentration indicating the degree to which each character on the field is concentrating on practice. In this embodiment, the practice part progression unit 112 arranges cards on the playing field for each set, and updates the degree of concentration each time an event related to the character pair of each card progresses. When the degree of concentration reaches a predetermined threshold value, the practice part progressing unit 112 progresses the next few sets in a mode (so-called fever mode) in which the stage progresses particularly advantageously for the user. For example, the practice part progression unit 112 may significantly increase the amount of rewards such as enhancement items obtained after completing a set. After ending the fever mode, the practice part progression unit 112 resets the concentration gauge and resumes accumulation from zero. Note that the practice part progression unit 112 may accumulate a greater degree of concentration when the field attribute and the attribute of the card placed on the field match. In this embodiment, the practice part progression unit 112 may carry over the degree of concentration across stages. The practice part progression unit 112 stores the concentration level at the end of the stage in the storage unit 120 as the game information 132, and reads out the stored concentration level when another stage starts.

The achievement information 903 is a UI component for presenting the user with the number or amount of rewards obtained so far in each progressed set in the ongoing stage. In the illustrated example, the rewards are enhancement items and medals for which attributes are set, and for enhancement items, the number of enhancement items acquired as rewards is disclosed for each attribute that is set. As for medals, the total of all types of medals obtained is disclosed regardless of attributes. This allows the user to know in advance the amount of reward to be obtained after completing the stage, even while the stage is in progress.

To implement the second function, the stage progress screen 900 includes a secondary deck 912 as an example.

The secondary deck 912 is a UI component for presenting to the user cards extracted by the practice part progression unit 112 from among the cards incorporated in the primary deck based on a predetermined rule. Also, the secondary deck 912 is a UI component for the user to select two cards to put into play. In the secondary deck 912, five cards, for example, extracted as the secondary deck by the practice part progression unit 112 are arranged.

In the secondary deck 912 , cards may be given attribute icons 914 . The attribute icon 914 indicates card attributes. The user can confirm the card attribute of the card by looking at the attribute icon 914 attached to the card.

In the secondary deck 912 , cards may be marked with health icons 915 . The health icon 915 indicates how good the card is. In this embodiment, the "card condition" is a parameter indicating whether the card is in good condition or not. The condition of the card may be fixed in the stage, changed for each set, or maintained in the same condition until the card is used on the field. A card in good shape means that the card is capable of producing a more favorable or better outcome for the user when the card is put into play than if the card was in normal condition. means.

In this embodiment, the practice part progression unit 112 determines the condition of each card incorporated in the secondary deck based on a predetermined rule, and while each card remains in the secondary deck without being selected, maintain that tone. After the cards have been used, the practice part progression unit 112 resets the condition of the cards based on a predetermined rule when the cards are organized into the secondary deck. As an example, the practice part progression unit 112 randomly determines the condition of each card in three levels of "normal", "good condition", and "excellent condition".

When cards whose condition is higher than a predetermined stage, for example, cards whose condition is good or better are selected as a pair, compared to the case where normal cards are put into play, they are more advantageous. results or better results. As an example, the practice part progressing unit 112 increases the possibility of expressing a line with a high rarity level for an event that progresses for the pair, or expresses more lines as a bonus dialogue, thereby increasing the rarity level of the pair. To make the user enjoy the event more by making the user perform a high action. Alternatively, the practice part progression unit 112 may increase the rate of increase of various parameters obtained after completing the set, or allow the user to obtain more or higher-value rewards to achieve better results. .

In the secondary deck 912, a guest icon 917 may be attached to the guest card. This makes it easier for the user to identify the guest cards incorporated in the deck other than the cards in his or her hand.

As described above, the user confirms various information disclosed on the stage progress screen 900, especially the set information 901 and the secondary deck 912, and selects two cards that are most suitable for the current set. be able to.

An input operation for selecting two cards is realized by, for example, tapping a desired card arranged in the secondary deck 912 .

When the practice part progression unit 112 accepts a tap operation on two cards out of the five cards arranged in the secondary deck 912, the practice part progressing unit 112 puts the selected two cards into play to complete the current set. proceed. Specifically, the practice part progressing unit 112 displays a pair of characters linked to each of the two selected cards on the practice stage 905, and progresses an event related to the pair.

Subsequently, the practice part progression unit 112 may output an effect that visually shows the reward given to the user for the current set. Below, the practice part progression unit 112 internally confirms the reward that the user is to obtain based on a predetermined rule, and visually shows the confirmation to the user as “dropping the reward”. ”, and the fact that the reward is fixed and the fact that the reward is visually presented as such is expressed as “the reward drops”. In addition, the reward itself handled in such a manner is expressed as a "drop reward".

As an example, as shown in FIG. 11(B), the practice part progression unit 112 displays the stage progression screen 900 at the end of the event progress, where the enhancement item 918 as a drop reward is displayed as a character 906 performing a predetermined action. And an animation representing the drop from the character 907 is output. The practice part progression unit 112 preferably matches the number of enhancement items 918 to be dropped in the practice stage 905 as an effect with the number determined in step S108. In this embodiment, the practice part progressing unit 112 may add an animation in which the dropped enhancement item 918 moves to the icon 919 representing the number of enhancement items in the result information 903 .

As a result, the user can intuitively grasp the number of enhancement items acquired in the set, and furthermore, when the number of enhancement items dropped is large, the fact that a large number of enhancement items 918 have been acquired can be recognized. Since it can be visually recognized, it is possible to obtain a greater sense of accomplishment and satisfaction when the set is successfully completed.

(image material database)
The storage unit 220 of the server 200 stores an image material database (hereinafter referred to as material DB). The material data managed in the material DB are images arranged on the game screen during the progress of the story part, the practice part, or the practice part. The material data includes, for example, a background image (first material data) representing a predetermined location where a character is located, and a foreground image (second material data) representing a character performing a predetermined action at the predetermined location. There is.

The background image is, for example, a still image. The background image material DB has a data structure including, for example, items such as an ID, a place name, and a still image. The ID item stores information for uniquely identifying the background image, and the information may be the file name of the still image. The place name item stores the name of the place indicated by the background image. The names are, for example, places appearing in the story progressing in the story part, such as "corridor of the school building", "principal's office", "kitchen of the dormitory", "cafe terrace", "field at dusk", or practice It may be a character string pointing to a location adopted as a background on the part stage progress screen 900 (FIG. 11) or the practice part stage progress screen (not shown). The still image item stores the data body of the background image or an address indicating the location where the data body is stored.

A foreground image is, for example, a set of still images (frames) of a character, that is, a moving image of a character that performs a predetermined action. The foreground image material DB has a data structure including, for example, items such as ID, character name, action, and animation. The ID item stores information that uniquely identifies the foreground image, and the information may be the file name of the moving image. The character name item stores the name of the character represented by the foreground image. A character ID may be stored instead of the character name. The action item stores a character string that describes the action that the character is performing, represented by the foreground image. The character strings are, for example, "eating sweets", "surprised", "jumping", "talking", "folding arms", etc. On the screen 900 ((B) of FIG. 11), words indicating actions to be performed by characters placed on the practice stage 905 are stored. Instead of words, the action item may store identification information that allows the game system 1 to uniquely identify the action. The moving image item stores the data body of the foreground image or an address indicating the location where the data body is stored.

As described above, the background image material DB stores all the background images used in the story part, the practice part, and the practice part. The foreground image material DB stores moving images for all actions for all characters. The progress support unit 211 reads the background image corresponding to the required location based on the background image material DB and reads out the background image corresponding to the necessary location based on the background image material DB and , reads the foreground image corresponding to the desired action of the desired character, and supplies the background image and the foreground image to the user terminal 100 .

In this embodiment, as shown in FIG. 11B, two characters are arranged on the left and right sides of the practice stage 905 of the practice part. The orientation of the character changes depending on whether it is placed on the left or right. Therefore, a foreground image for right placement may be registered in the foreground image material DB, and when the foreground image is placed on the left side of the practice stage 905, the practice part progression unit 112 may horizontally reverse the foreground image. Alternatively, a foreground image for right placement and a foreground image for left placement may be registered for one action of one character in the foreground image material DB.

It is preferable that the above material data managed for the progress of the story part, the practice part and the practice part be diverted to generate diary data as a reward in the idle part described below. As a result, it is possible to introduce the neglected part into the game while utilizing existing resources and reducing labor without newly generating materials for the neglected part.

<Leave part>
(Execution part processing flow)
12 and 13 are flowcharts showing the flow of processing of the execution part of the neglected parts executed by the neglected part progressing unit 115. FIG.

For example, while the top screen (not shown) of the neglected part is displayed, the user performs an input operation to call up a character selection screen for selecting a character to put to sleep. In response to the input operation, the neglected part progression unit 115 displays a character selection screen on the display unit 152, and starts a series of processes from step S101.

In step S101, the neglected part progression unit 115 performs an input operation (third input operation) to select a character to be put to the second state, specifically, a character to be put to sleep (hereinafter referred to as a first character) via a character selection screen. ). In response to the input operation, the neglected part progression unit 115 advances from YES in step S101 to step S102.

In step S102, the neglected part progression unit 115 identifies the first character selected by the above-described input operation. Subsequently, the neglected part progression unit 115 may execute steps S103 and S104 as necessary. Steps S103 and S104 may be omitted.

In step S103, the neglected part progressing unit 115 displays a list of consumable items that can be used in the neglected part, and receives an input operation (fourth input operation) for designating a consumable item to be used.

In step S104, the neglected part progression unit 115 consumes the designated consumable item in response to the input operation described above. The consumable item may be represented by, for example, an aroma or other good sleep goods that help the character sleep soundly. The content of the diary data given after the first character wakes up, that is, the content of the dream that the first character has may change according to the consumed consumable item. For example, if the first character uses an aroma scent that the first character likes, the probability of having a dream with positive content such as a pleasant dream may increase. may increase the probability of appearing in a dream.

In step S105, the neglected part progressing unit 115 displays on the display unit 152 an introductory screen showing how the first character specified in step S102 is introduced to sleep.

In step S106, the neglected part progression unit 115 accepts the user's input operation (first input operation) for the first character displayed on the introduction screen. As this input operation, for example, it is assumed that the area of the input unit 151 where the first character is displayed is repeatedly slid such that the user strokes the area with a finger or the like. When the neglected part progression unit 115 detects the slide operation described above a predetermined number of times, the process proceeds from YES in step S106 to step S107.

In step S107, the neglected part progression unit 115 transitions the first character from the wakeful state to the sleep state in response to the detected slide operation.

In step S108, the neglected part progression unit 115 starts measuring the elapsed time from the sleep state transition. In this way, the neglected part progressing unit 115 automatically progresses the neglected game without requiring user's input operation until a predetermined period of time elapses. Predetermined time is assumed to be, for example, eight hours.

In step S109, the neglected part progressing unit 115 generates content by taking into account the first character that has been put to sleep and the consumable items that have been consumed. It should be noted that the neglected part progressing unit 115 may execute step S109 of generating content at any timing from step S107 to step S120.

In step S110, the neglected part progressing unit 115 displays on the display unit 152 a screen indicating that the first character is sleeping, that is, an execution screen (second screen) indicating that the neglected game is in progress. . The neglected part progression unit 115 may notify the user of the remaining time until the predetermined time elapses on the execution screen.

In step S111, the neglected part progressing unit 115 may receive an instruction to temporarily end the neglected part. Upon receiving an instruction to end the neglected part from the user, the neglected part progressing unit 115 ends the neglected part until receiving an instruction to start the neglected part again in step S112 shown in FIG. Even if the neglected part is ended here, the neglected part progressing unit 115 continues measuring the elapsed time and advances the neglected game in the background. The user may play another part or end the game itself and do something else until the predetermined time has elapsed. Until an instruction to end the neglected part is input, the neglected part progression unit 115 advances from NO in step S111 to step S113 shown in FIG. 13, and waits until a predetermined time elapses.

In step S112, the neglected part progression unit 115 receives an instruction to start the neglected part from the user. Upon receiving an instruction to start the neglected part from the user, the neglected part progressing unit 115 starts the neglected part, and proceeds from YES in step S112 to step S113.

In step S113, the neglected part progression unit 115 determines whether or not the elapsed time measured from when the first character transitioned to sleep has reached a predetermined time, for example, 8 hours. The neglected part progression unit 115 proceeds to step S114 until the predetermined time has elapsed, and proceeds to step S117 after the predetermined time has elapsed.

In step S114, the neglected part progression unit 115 displays an execution screen. The neglected part progressing unit 115 may accept an instruction to cancel progress of the neglected game midway through the execution screen.

In step S115, the neglected part progression unit 115 may accept an input operation (fifth input operation) for canceling the putting to sleep by pressing a cancel button on the execution screen. Upon accepting the input operation, the neglected part progression unit 115 advances from YES in step S115 to step S116. Until the input operation is accepted, the neglected part progressing unit 115 returns to step S111 and waits for an instruction to end the neglected part, or returns to step S113 and waits for the lapse of a predetermined time.

In step S116, the neglected part progression unit 115 restores the first character from the sleep state to the wakeful state without waiting for the expiration of the predetermined time. In this case, the neglected part progression unit 115 may omit giving rewards such as diary data or enhancement items to the user, or may reward the user for returning to an awakened state after a predetermined period of time has elapsed. A reward with a lower in-game value than the user may be given.

In step S117, the neglected part progression unit 115 displays on the display unit 152 a pre-return screen indicating that the predetermined time has expired and the first character can be returned from the sleeping state to the awake state. A first character capable of returning to an awake state may be arranged on the screen immediately before returning.

In step S118, the neglected part progression unit 115 receives an input operation for the first character via the screen immediately before return. As this input operation, for example, it is assumed that the area of the input unit 151 in which the first character is displayed is tapped or double-tapped by the user with a finger or the like. When the left part progression unit 115 detects the tap operation described above a predetermined number of times, the process proceeds from YES in step S118 to step S119.

In step S119, the neglected part progression unit 115 restores the first character from the sleeping state to the awake state in response to the detected tap operation.

In step S120, the neglected part progression unit 115 gives a reward to the user based on the fact that the first character has returned to the awakened state after a predetermined period of time has elapsed. Specifically, neglected part progression unit 115 gives diary data to the user. The neglected part progression unit 115 may store the diary data generated in step S109 in the storage unit 120 of the user terminal 100 so that it can be viewed at any timing. At this time, it is preferable to associate the given date and time with the diary data. Furthermore, the neglected part progression unit 115 may give the user a strengthening item. The neglected part progression unit 115 may display the diary data just added on the display unit 152 .

In another embodiment, step S121 may be performed. In step S121, the neglected part progression unit 115 adds a predetermined increment to the parameter value in the lulling meter. The processing related to the lulling meter will be described in detail in the second embodiment.

(Abandoned character information)
FIG. 14 is a diagram showing an example of the data structure of abandoned character information. The abandoned character information is information about characters used in the abandoned part. For example, the neglected character information is a table containing information about each character to be put to sleep in the neglected part. The neglected character information includes information of each character to be put to sleep in the neglected part among the characters appearing in the game. All characters appearing in this game may be put to sleep.

The abandoned character information may include the items of character ID, character name, and state. A character ID uniquely assigned to a character is stored in the item of character ID. The character name item stores the name of the character. Either one of the character ID and character name may be omitted.

State information (first information) indicating the state of the character is stored in the state item. The state of the character affects the progress of the idle part. The status information includes a "reward" sub-item. The "reward" sub-item stores information indicating the attributes of the reward dropped when the character wakes up after the character has been put to sleep. In the illustrated example, A-thick is associated with the status information of "red". The state information means that if Ata is put to sleep, a red-attribute enhancement item will drop when Ata wakes up. "Random" in the status information means that red, blue, or yellow attribute enhancement items will drop randomly.

The status information may include a "health" sub-item. The "condition" sub-item stores information indicating how easy it is to transition from the first state to the second state, or how well the character is in the second state. The second state may be a sleeping state. In this case, information indicating the ease of falling asleep or the quality of sleep may be stored in the sub-item "Condition". In the illustrated example, the state information "seems to sleep well" indicates that the character has a high probability of having a good dream by maintaining a good sleeping state. When the character has a good dream, diary data containing content that is highly valuable to the user is generated. In other words, the probability of generating diary data with a high rarity value when the character is put to sleep is determined based on the state information of "condition".

The neglected part progression unit 115 may change the sub-items of "reward" and "tone" for each character regularly or at appropriate times based on a predetermined trigger.

The neglected part progressing unit 115 refers to the neglected character information shown in the same figure, generates a list of characters to be put to sleep, and displays the list on the display unit 152 before step S101.

(Diary data)
FIG. 15A is a diagram showing an example of the data structure of diary data. Diary data is generated by neglected part progression unit 115 at an arbitrary timing between steps S108 and S120. The diary data may include items such as author, date and time, text, comment, background image, and foreground image.

The item of author stores the name of the character who was put to sleep in the idle part in the form of a character who wrote a diary.

The date and time item stores the date and time when the character, who is the writer, returned from the sleeping state to the awake state in the idle part in the form of the date and time when the writer had a dream. The time may not be information that accurately indicates the hour and minute, but may be information that indicates an approximate time zone such as morning, noon, and night.

The body text field stores a text generated by the neglected part progressing unit 115 based on the character who is the writer, in the form of a text describing the contents of the dream that the writer had. The comment field stores sentences generated by the neglected part progressing unit 115 based on the author's character in the form of an author's impression of the dream he had. These sentences may be generated by the neglected part progression unit 115 in accordance with the personality set for the character so that the character has a narrative tone in which the character usually speaks in the story part.

The item of background image stores identification information of a still image adopted as a background image among the illustrations representing the dream that the writer had. For example, an ID, a file name, an address indicating a storage destination, or the like is stored.

The foreground image item stores information specifying a frame in the moving image, which is used as the foreground image, from among the illustrations representing the author's dream. A frame is uniquely specified by, for example, a character name, action name or information identifying the action, information specifying the number of the frame in the moving image, and information specifying whether it is for right placement or left placement. be done.

FIG. 15B is a diagram showing an example of the data structure of diary data with a high rarity level. The neglected part progressing unit 115 displays the author having a "rare dream" according to a specific combination of the author and the characters in the dream, a specific combination of the characters in the dream and actions, and the like. Alternatively, diary data with a higher degree of rarity and richer content than ordinary diary data may be generated. For example, in diary data with a high degree of rarity, the content of comments may be more complete than in ordinary diary data. Gorgeous images may be employed.

(Text material database)
The storage unit 220 of the server 200 further stores a material DB of texts for generating texts in the diary data. As the material DB, for example, a character name DB that accumulates names of characters that appear in dreams, a place name DB that accumulates names of places that appear in dreams, and names of actions performed by characters that appear in dreams are accumulated. and an action name DB are stored in the storage unit 220 .

The character name DB accumulates names used when a character points to another character. In the story part, various relationships are set between characters, and one character is called by other characters by various names such as abandonment, nickname, and honorific. In order not to destroy the world view of the game constructed by the story of the story part, it is preferable to use the name set in the story part as the character string indicating the character in the body of the diary data.

In the character name DB, the name is stored in association with the ID of the calling character and the ID of the called character. In this embodiment, it is possible that the writer has a dream in which he himself appears. Therefore, in a record in which the ID of the character on the calling side and the ID of the character on the called side are the same, the first person when the character refers to itself may be stored.

The place name DB stores a plurality of names of places where dreams are assumed to develop. The name of the place may be stored in one-to-one correspondence with the background image.

The action name DB stores a plurality of names of actions assumed to be actions to be performed by the character in a dream. For the sake of convenience, it is called "name", but the character string that indicates the action is constructed so that the fixed part "teitashita" described later in the text follows grammatically correctly. For example, the action name DB stores character strings such as "eat snacks", "dance", "look for a toilet", and "listen to dinner last night". The name of the action is associated with each character for specifying the frame in which the character seems to be performing the action. For example, one frame in the video "Eating sweets" for all characters is associated with the action name "Tsumami-eating". If the action in the dream is determined to be eating snacks, the neglected part progressing unit 115 can use one frame in the moving image of the appearing character "Eating sweets" as the foreground image of the illustration.

The text of the diary data shown in FIG. 15 is, for example, composed of a fixed form part and an unfixed form part. The fixed form portion refers to a portion other than the alphabet portion of, for example, "A and B were C and D." The fixed form part is common in the body of all diary data. Atypical parts are parts of each alphabet described above. Item A corresponds to the first character that appears in the dream, Item B corresponds to the second character that appears in the dream, Item C corresponds to the place where the dream unfolds, Item D corresponds to , correspond to actions performed by two characters appearing in the dream.

The neglected part progression unit 115 may randomly determine two characters appearing in the dream from characters appearing in the game. The neglected part progression unit 115 acquires the names of the two characters appearing in the dream from the character name DB based on the sleeping character (author). The neglected part progression unit 115 may acquire the name associated with the character ID of the writer who is calling and the character ID of the character appearing in the dream who is called from the character name DB. The neglected part progression unit 115 fills in the two acquired names in item A and item B of the text.

The neglected part progression unit 115 randomly acquires the name of the place where the dream develops from the place name DB, and fills in the item C. The neglected part progression unit 115 randomly acquires the name of the action to be performed by the two characters appearing in the dream from the action name DB, and fills in the item D. Thereby, the neglected part progression unit 115 can automatically generate a text based on the sleeping character.

(comment material database)
The storage unit 220 of the server 200 further stores a text material DB (comment DB) for generating comments in the diary data.

The comment DB accumulates sentences in the form of impressions on the content of the dream that the character himself/herself (the author) had. In the comment DB, the text may be prepared for each combination of the author and the action that was performed in the dream seen by the author.

After determining the act of filling item D in the body text as described above, the neglected part progressing unit 115 comments on the text associated with the combination of the character (author) put to sleep and the determined act. Get from DB.

(Procedure for generating diary data)
As described above, the neglected part progression unit 115 determines items A to D in the text based on the author, fills in each character string obtained from each material DB, and completes the text. The neglected part progressing unit 115 may further determine items A to D in consideration of the state information associated when the author was selected. The idle part progression unit 115 is identified based on the background image identified based on the item C, the foreground image of the character positioned on the left identified based on the items A and D, and the items B and D. The foreground image of the character placed on the right side is synthesized to generate an illustration representing the content of the dream. The neglected part progressing unit 115 acquires the text of the comment specified based on the author and the item D from the comment DB. The neglected part progression unit 115 generates diary data including the author, the text generated as described above, the comments obtained as described above, and the illustration synthesized as described above. When the author returns from sleep to wakefulness, the neglected part progression unit 115 completes the diary data by linking the above diary data with the date and time when the author returned to wakefulness.

(Character selection screen)
FIG. 16 is a diagram showing an example of a character selection screen displayed on the display unit 152. As shown in FIG. The neglected part progression unit 115 displays, for example, the illustrated character selection screen 400 after displaying the top screen of the neglected part and before executing step S101.

A character selection screen 400 includes a character list 401 as a UI component. The character list 401 is a UI component for presenting a list of characters that can be put to sleep in the neglected part to the user, and for receiving an input operation for selecting the character to be put to sleep.

The character list 401 includes characters and icons indicating status information of the characters. The icon 402 corresponds to the "reward" sub-item in the status information shown in FIG. The neglected part progression unit 115 attaches an icon 402 indicating any one of red, blue, and yellow attributes to characters for which any one of red, blue, and yellow attributes is set in the "reward" sub-item. . The icon 403 corresponds to the sub-item of "condition". The neglected part progression unit 115 attaches an icon 403 indicating that the character has a high probability of having a good dream to the character for which the tone of "seems to sleep well" is set in the sub-item of "tone".

The neglected part progression unit 115 receives, for example, a tap operation on a character in the character list 401 as an input operation (third input operation) for selecting a character to put to sleep. Thereby, the user can select a character to put to sleep while confirming the state of each character based on the icons 402 and 403 .

(Introduction screen)
(A) of FIG. 17 is a diagram showing an example of an introductory screen displayed on the display unit 152 . The introduction screen is a screen for the user to input an instruction to start the neglected part. The neglected part progression unit 115, for example, displays the illustrated introductory screen 500 between execution of step S102 and execution of step S106.

The introductory screen 500 includes a character 501 and a hand icon 502 as UI components. A character 501 is a UI component representing a character selected by the user. A hand icon 502 is a visualization of an object that acts on the character 501, and is a UI component for prompting the user to perform an input operation. The input operation here is an input operation (first input operation) for transitioning the above-described character selected as a sleep target to a sleeping state. For example, the neglected part progression unit 115 receives, as the first input operation, an operation of repeating a sliding operation in an arbitrary direction while touching the hand icon 502 . Thereby, the user can operate the hand icon 502 to exert an action on the character 501 to cause the character 501 to transition to the sleeping state and instruct to start executing the neglected part.

(Execution screen)
FIG. 17B is a diagram showing an example of an execution screen displayed on the display unit 152. As shown in FIG. The execution screen is a screen for presenting the progress to the user while the neglected part is being executed and progressing without requiring user's operation. The neglected part progression unit 115 displays, for example, the illustrated execution screen 600 when executing steps S110 and S114.

The execution screen 600 includes a character 601, progress 602, browse button 603, and cancel button 604 as UI components. A character 601 is a UI component that indicates a character that is transitioning to the second state. The character 601 is displayed in a display mode different from that of the character 501 so that it can be seen that the character 501 in the first state has transitioned to the second state. A progress status 602 is a UI component for presenting the user with the remaining time until returning from the second state to the first state. A browse button 603 is a UI component for calling a screen for browsing a diary owned by the user. A cancel button 604 is a UI component for canceling the execution of the neglected part without waiting for the expiration of a predetermined period of time. In step S115, the neglected part progressing unit 115 accepts a tap operation on the cancel button 604 as an input operation (fifth input operation) for canceling the putting to sleep.

After the predetermined period of time has elapsed, the neglected part progression unit 115 may switch the execution screen 600 to a screen immediately before return (not shown) in step S117. The pre-return screen is configured, for example, by presenting a notice that the progress status 602 indicates that the character 601 can return to the awakened state at any time instead of the remaining time. In step S118, the idle part progression unit 115 restores the character 601 from the sleeping state to the awakening state in response to receiving a predetermined input operation for the character 601 via the pre-return screen.

(Browse part processing flow)
FIG. 18 is a flow chart showing the processing flow of the viewing part of the neglected parts executed by the neglected part progressing unit 115 .

In step S201, neglected part progression unit 115 receives an input operation for instructing display of a list of contents. For example, a tap operation on the browse button 603 on the execution screen 600 shown in FIG. 17B is accepted as the input operation.

In step S<b>202 , neglected part progression unit 115 displays a list screen (first screen) for displaying a list of contents on display unit 152 .

In step S203, neglected part progression unit 115 receives an input operation (second input operation) for designating content to be viewed via the list screen. Upon receiving the input operation, the neglected part progression unit 115 advances from YES in step S203 to step S204.

In step S<b>204 , neglected part progression unit 115 displays the content designated by the second input operation, specifically, diary data, on display unit 152 .

In step S205, neglected part progress unit 115 may display a share button on the same screen together with the diary data so that the diary data can be shared with another application.

In step S206, the neglected part progressing unit 115 accepts the user's input operation on the share button. Upon receiving the input operation, the neglected part progression unit 115 advances from YES in step S206 to step S207.

In step S207, neglected part progression unit 115 allows other applications to share the diary data displayed on display unit 152 in step S204. As other applications, for example, an SNS (Social Networking Service) application, an e-mail application, a memo pad application, an image storage application, etc. are assumed. Examples of SNS applications include message exchange applications such as LINE (registered trademark), short-text posting applications such as Twitter (registered trademark), and information sharing applications such as Facebook (registered trademark). By allowing these SNS applications to share the diary data, the user can utilize the SNS application to widely disclose the diary data acquired by the user to other users. Furthermore, other applications are assumed to be wireless communication applications using WiFi (registered trademark), Bluetooth (registered trademark), infrared rays, or the like. This allows the user to share diary data with other users with whom short-range communication is possible.

(diary database)
FIG. 19 is a diagram showing an example of the data structure of a diary database (hereinafter referred to as diary DB). The diary DB is for managing diary data owned by the user, and is generated for each user. The diary DB is stored in storage unit 120 of user terminal 100 and storage unit 220 of server 200 and is shared between user terminal 100 and server 200 .

The diary DB may include items such as date and time, author, favorites, current month, last month, and diary data. In the date and time item, the date and time associated with the diary data shown in FIG. 15 is referenced. In the item of author, the author associated with the diary data shown in FIG. 15 is referenced.

The favorite item stores a flag indicating whether or not the diary data is designated as a favorite by the user. In this embodiment, the diary data is stored until the last day of the second month after the month in which the diary data was assigned, and is deleted from the diary DB after the expiration date. However, it is assumed that, for example, up to 30 pieces of diary data designated as favorites by the user can be saved in the diary DB ignoring the viewing deadline. "1" in the item indicates that the user has specified the diary data as a favorite, and "0" indicates that the user has not specified the diary data as a favorite. The neglected part progressing unit 115 deletes the diary data whose item is "0" from the diary DB when the browsing time limit has passed.

The current month item stores a flag indicating whether or not the diary data is given in this month. The last month item stores a flag indicating whether or not the diary data was given in the last month.

For example, if the current month is "March 2019", "1" is stored in the corresponding item of diary data given to the user in March 2019, and diary data given in other months and years. '0' is stored in this item of . When the current time shifts to the next month, for example, "April", the neglected part progression unit 115 updates the current month's item in the diary data given to the user in March 2019 from "1" to "0". and update the last month item from "0" to "1". When the current time shifts to the following month, for example, "May", the neglected part progression unit 115 designates the diary data given to the user in March 2019 as a favorite as the viewing deadline has passed. Remove the diary data from the diary DB.

The data body of diary data (FIG. 15) or an address indicating the location where the data body is stored is stored in the item of diary data.

The neglected part progression unit 115 manages the diary DB as described above, and always generates the list screen based on the latest diary DB when the list screen is called. When diary data is specified from the list screen, the specified diary data is read from the above address and displayed on display unit 152 .

(List screen)
(A) of FIG. 20 is a diagram showing an example of a list screen displayed on the display unit 152 . The neglected part progression unit 115 displays, for example, the illustrated list screen 700 when executing step S202.

A list screen 700 includes tabs 701 to 703 and a diary list 704 as UI components. The diary data are classified into three groups, for example, "favorites", "last month" and "this month". A tab 701 is a UI component for calling a diary list 704 of diary data classified as favorites. A tab 702 is a UI component for calling a diary list 704 of diary data classified into last month's groups. A tab 703 is a UI component for calling a diary list 704 of diary data classified into groups of the current month. In the illustrated example, a list of diary data for the current month is displayed. However, if the user wishes to switch to the diary list of diary data registered in Favorites, the tab 701 should be switched to the diary list of last month's diary data. In this case, each tab 702 should be tapped.

The diary list 704 may include a diary icon 705 and a viewing deadline 706 as UI components. A diary icon 705 is an icon corresponding to one diary data. The diary icon 705 may include an author, date and time, and a favorite icon 707 indicating whether the diary data is registered as a favorite. The viewing deadline 706 is a UI component for notifying the user of the viewing deadline of each diary data in the group. The user confirms the information contained in the diary icon 705, searches for diary data to be viewed, and performs an input operation (second input operation) to instruct the diary icon 705 of the desired diary data to be viewed. can be done. Idle part progression unit 115 accepts the second input operation, and displays diary data corresponding to the operated diary icon 705 on display unit 152 as shown in FIG. 20B, which will be described later.

(Diary screen)
FIG. 20B is a diagram showing an example of a diary screen displayed on display unit 152. As shown in FIG. The neglected part progression unit 115 displays, for example, the illustrated diary screen 800 when executing step S204.

A diary screen 800 includes diary data 801, a share button 802, and a management button 803 as UI components. Diary data 801 is for presenting one piece of diary data to a user, and includes date 804, author 805, text 806, comment 807, and illustration 808 as UI components. These UI components are generated based on the items that make up the diary data shown in FIG.

A share button 802 is a UI component for instructing another application to share the diary data. By tapping the share button 802, the user can cause the SNS application to share the still image data of the diary data 801 displayed on the diary screen 800, for example.

A management button 803 is a UI component for instructing registration and cancellation of favorites of diary data. By tapping the management button 803 while the diary data 801 registered as a favorite is being displayed, the user can cancel the setting of the diary data 801 as a favorite. Conversely, the user can tap the management button 803 while the diary data 801 registered in Favorites is being displayed to register the diary data 801 in Favorites.

As described above, the user can view and enjoy the provided diary data at any time via the list screen 700 and the diary screen 800 .

[Embodiment 2]
In the present embodiment, in the game system 1, a lull meter may be managed for each user. The lull meter is a parameter for managing how long the user has played the idle part, and the parameter value is incremented each time the user puts the character to sleep for a predetermined period of time and obtains diary data. . Every time the character is put to sleep for a predetermined period of time, the neglected part progression unit 115 adds the parameter value of the put-to-sleep meter in step S121. Accumulated parameter values can be exchanged for other game media having in-game value, such as lottery tickets.

There may be several types of lottery tickets that can be exchanged for parameter values according to grades. The higher the parameter value to be exchanged, the higher the grade of the lottery ticket that can be exchanged. A lottery ticket with a higher grade is associated with a population in which a card with a higher rarity value is more likely to be won. When a lottery ticket is drawn based on a lottery ticket with a higher grade, a card with a higher rarity value is more likely to be won than a lottery ticket with a lower grade.

There are, for example, seven types of lottery tickets corresponding to seven stages of grades. A first lottery ticket associated with a population of cards of rarity N, a second lottery ticket associated with a population of cards of rarity N and R, and a population of cards of rarity R. A third lottery ticket with which a group is tied, a fourth lottery ticket with which a population consisting of cards of rarity R and SR is tied, a fifth lottery ticket with which a population consisting of cards of rarity SR is tied There are seven types of lottery tickets: a lottery ticket, a sixth lottery ticket associated with a population of cards of rarity SR and SSR, and a seventh lottery ticket associated with a population of cards of rarity SSR. In other words, when the seventh lottery ticket is used, the card with the rarity level SSR wins 100%, so the seventh lottery ticket is the lottery ticket with the highest in-game value for the user.

For example, the lull meter can accumulate a value of 0 to 700 points, with 100 points for the first lottery ticket, 200 points for the second lottery ticket, and thereafter, every 100 points the value to be exchanged increases by one grade. can be exchanged for a lottery ticket, and the effect can be obtained with the 7th lottery ticket, which has a maximum score of 700 and is the highest grade. When a lottery ticket is granted by exchanging the value, the parameter value of the sleeping meter is reset and counting restarts from zero. Although it is difficult for a user to win a card with a high rarity level, the user may enjoy many lotteries by using low-grade lottery tickets that can be obtained quickly, and it is easy to win a card with a high rarity level. You can enjoy a lottery that aims at a card with a high rarity with a small chance using a lottery ticket with a higher grade that is difficult to obtain.

Further, it is also possible to set a plurality of courses with different increases in the parameter value of the lulling meter, let the user select a desired course, and then play the neglected part. As for the multiple courses, for example, there is a two-month course in which the meter can be put to sleep in about two months and a full score of 700 points, a three-month course in which the meter can be put to bed in about three months and a full score of 700 points, and a sleep in about half a year. A half-year course may be envisioned in which the meter can be fully scored to 700 points.

The neglected part progression unit 115 determines a parameter value to be added for each time of putting the child to sleep according to the course selected in advance by the user. It is preferable that a course with a longer period be exchanged for a reward with a higher in-game value. For example, the reward should be determined so that the reward exchanged for 700 points accumulated in the half-year course has a higher in-game value than the reward exchanged for 700 points accumulated in the 3-month course. .

[Modification]
In step S114, the idle part progressing unit 115 displays a second screen showing the first character in the second state and part of the content to be provided when the first character returns. may Specifically, neglected part progression unit 115 may display a part of the dream that character 601 is seeing on execution screen 600 . For example, the neglected part progression unit 115 may display icons of two characters appearing in the dream that the character 601 is seeing on the execution screen 600 . If the two characters are not the desired characters, the user can operate the cancel button 604 to cancel putting them to sleep and restart the neglected part from the beginning.

As a consumable item that can be used in step S104, there may be a so-called time-saving item that can shorten the predetermined period for maintaining the sleeping state. For example, in step S104, when a time-saving item is used, normally it takes 8 hours to return to the awakened state, but it may be shortened to 3 hours.

The idle part progression unit 115 may allow the user to select a predetermined time for keeping the character in the sleeping state from among a plurality of times. For example, let the user choose from 1 hour, 3 hours, and 8 hours. The idle part progression unit 115 may increase the in-game value of the reward given to the user or increase the probability that a reward with a high in-game value will drop as the selected predetermined time lengthens.

When the character is returned to the awakened state before the predetermined time expires, that is, when the user presses the cancel button 604 to cancel the neglected part, the neglected part progression unit 115 does not give any reward. Alternatively, the reward may be partially awarded according to the progress made until it is stopped. For example, if the part is canceled in the middle, the neglected part progression unit 115 may give only the enhancement items to the user without providing the diary data, or may reduce the number of enhancement items given to the user. good.

[Example of realization by software]
The control block of the control unit 210 (in particular, the progress support unit 211), and the control block of the control unit 110 (in particular, the story part progress unit 111, the practice part progress unit 112, the practice part progress unit 113, the lottery part progress unit 114, The neglected part progression unit 115) may be realized by a logic circuit (hardware) formed in an integrated circuit (IC chip) or the like, or may be realized by software using a CPU (Central Processing Unit). good.

In the latter case, the information processing apparatus having the functions of the control unit 210 or the control unit 110, or both, includes a CPU that executes instructions of a program, which is software for realizing each function, and a computer (or A ROM (Read Only Memory) or storage device (these are referred to as a "recording medium") readable by a CPU), a RAM (Random Access Memory) for developing the above program, and the like are provided. The object of the present invention is achieved by a computer (or CPU) reading and executing the program from the recording medium. As the recording medium, a "non-temporary tangible medium" such as a tape, disk, card, semiconductor memory, programmable logic circuit, or the like can be used. Also, the program may be supplied to the computer via any transmission medium (communication network, broadcast wave, etc.) capable of transmitting the program. Note that one aspect of the present invention can also be implemented in the form of a data signal embedded in a carrier wave in which the program is embodied by electronic transmission.

The present invention is not limited to the above-described embodiments, but can be modified in various ways within the scope of the claims, and can be obtained by appropriately combining technical means disclosed in different embodiments. is also included in the technical scope of the present invention.

[Additional notes]
The contents of one aspect of the present invention are listed below.

(Item 1) The game program (131, 231) has been described. According to one aspect of the present disclosure, a game program is executed by a computer (at least one of user terminal 100 and server 200) comprising processors (10, 20) and memories (11, 21). The game program causes the processor to change the first character from the first state to the second state in response to a user's first input operation on at least one first character among a plurality of characters appearing in a game based on the game program. a step of transitioning to the state (S107); a step of returning the first character to the first state when a predetermined time has passed after the first character transitioned to the second state (S119); a step (S120) of giving the user content (diary data) based on the first character that was in the second state in response to the return of the first character to the first state; to display the designated content on the display unit (S204).

(Item 2) In the step of transitioning in (Item 1), the first part (idle part) in the game progresses in response to the first input operation, and the first character progresses without the user's operation. In the step of transitioning from a first state (awake state) in which the first part is in progress to a second state (sleep state) in which the first part is progressing, and returning, a predetermined time period elapses after the first part progresses. The first part may be terminated depending on what has passed.

(Item 3) In (Item 1) or (Item 2), in the step of providing the content, the first character provides the user with content expressing the event in the form of an event experienced while the first character was in the second state. may be given to

(Item 4) In any one item from (Item 1) to (Item 3), first information (state information) indicating the state of the character is associated with each of the plurality of characters, and the game program specifying a first character to be transitioned to a second state from among a plurality of characters in response to a third input operation by the user; , and first information associated with the first character, generating content to be provided to the user.

(Item 5) In (Item 4), the memory stores a plurality of first material data representing a predetermined location where a character is and a plurality of second material data representing a character performing a predetermined action. The game program causes the processor to proceed with the second part (story part, practice part, practice part) using at least one of the first material data and the second material data. In the step of executing and generating the content, the content may be generated using one or more material data stored in the memory selected based on the first character and the first information.

(Item 6) In (Item 4) or (Item 5), the game program causes the processor to display a UI part (share button) for instructing to publish the content via the SNS application (S205). may be executed.

(Item 7) In any one item from (Item 1) to (Item 6), the game program instructs the processor to switch the first character from the second state to the first state when the predetermined time period expires. When returning, the step of adding the parameter value in the parameter associated with the user (S121), and the step of giving a reward with a higher value in the game as the parameter value to be exchanged is larger, in exchange for the parameter value indicated by the parameter. and may be executed.

(Item 8) In (Item 7), the step of providing a reward provides, as a reward, a lottery item (lottery ticket) necessary for performing a lottery process for selecting a card to which a character is linked to the user. In the step of providing the reward, a lottery item is provided that is associated with a population in which a card with a higher rarity value is more likely to be won as the parameter value to be exchanged increases, and the game program causes the processor to Then, in exchange for the lottery item owned by the user, a step of giving the user a card selected from the population linked to the lottery item may be executed.

(Item 9) In (Item 7) or (Item 8), there are a plurality of types of parameters according to the amount of increase in the parameter value, one of the plurality of types is associated with the user, and in the adding step In the step of adding the parameter value of the parameter associated with the user based on the increase amount set for the parameter and giving a reward, the smaller the increase amount of the parameter associated with the user, the more the parameter The value of the reward given to the user in exchange for the parameter value indicated by may be increased.

(Item 10) In any one item from (Item 1) to (Item 9), in the step of providing the content, the content is associated with the date when the content was provided to the user and stored in a memory. a step of displaying, on the processor, a first screen (list screen 700) listing a plurality of contents stored in the memory by date (S202); and a step of accepting the operation as a second input operation for designating the content (S203).

(Item 11) In (Item 4), the game program, in response to the user's fourth input operation, instructs the processor, among the consumable items owned by the user, the consumable item (good sleep In the step of consuming the goods (S104) and generating the content, based on the first character, the first information associated with the first character, and the consumed consumable item, the user may generate content to be given to

(Item 12) In any one item from (Item 1) to (Item 11), the game program provides the processor with the first character in the second state and, in response to the return of the first character, the processor. a step (S114) of displaying a second screen (execution screen 600) showing a part of the content to be executed; and a step of returning to the first state before the time of elapses.

(Item 13) A method for executing a game program has been described. According to one aspect of the present disclosure, a game program is executed by a computer comprising a processor and memory. The method is a method in which a processor performs each step described in (item 1). The method related to (item 13) has the same effects as the game program related to (item 1).

(Item 14) The information processing apparatus has been described. According to an aspect of the present disclosure, the information processing device includes a memory (memory 11, storage unit 120) that stores the game program according to (item 1), and the information processing device (user and a processor (processor 10, control unit 110) that controls the operation of the terminal 100). The information processing apparatus according to (item 14) has the same effects as the game program according to (item 1).

1 game system, 2 network, 10, 20 processor, 11, 21 memory, 12, 22 storage, 13, 23 communication IF (operation unit), 14, 24 input/output IF (operation unit), 15 touch screen (display unit, operation unit), 17 camera (operation unit), 18 ranging sensor (operation unit), 100 user terminal (information processing device), 110, 210 control unit, 111 story part progress unit, 112 practice part progress unit, 113 practice part progress unit 114 lottery part progress unit 115 neglected part progress unit 120, 220 storage unit 131, 231 game program, 132 game information, 133 user information, 151 input unit (operation unit), 152 display unit, 200 server, 211 progression support unit, 1010 object, 1020 controller (operation unit), 1030 storage medium

Claims (14)

a game program,
The game program is executed by a computer comprising a processor, a memory and a display unit,
The game program causes the processor to:
At least one first character out of a plurality of characters appearing in a game based on the game program is changed from a first state, which is an awake state, to a sleep state in response to a first input operation by a user to the first character. a step of transitioning to a second state of
a step of returning the first character to the first state in response to the lapse of a predetermined time after the first character transitioned to the second state;
giving the user content based on the first character that was in the second state in response to the return of the first character to the first state;
and displaying the designated content on the display unit in response to the user's second input operation. In the step of transitioning, in response to the first input operation, the first character progresses without depending on the user's operation, from the first state in which the first part in the game is not progressing, transition to the second state in which the first part is in progress;
2. The program according to claim 1, wherein, in said returning step, said first part is terminated when said predetermined time has elapsed since said first part progressed. 3. The step of providing the content according to claim 1, wherein the step of providing the content provides the user with content expressing the event in the form of an event experienced by the first character while in the second state. game program. Each of the plurality of characters is associated with first information indicating the state of the character,
The game program causes the processor to:
a step of specifying, from among the plurality of characters, the first character to be transitioned to the second state in response to the user's third input operation;
and generating the content to be given to the user based on the first character specified in response to the third input operation and the first information associated with the first character. 4. The game program according to any one of claims 1 to 3. the memory stores a plurality of first material data representing a predetermined location where the character is located and a plurality of second material data representing the character performing a predetermined action;
The game program causes the processor to:
executing a step of advancing a second part using at least one of the first material data and the second material data;
The step of generating the content uses one or more material data selected from at least one of the first material data and the second material data stored in the memory. , is the one that generates the content, and
The probability that each material data included in the first material data and the second material data is selected as the material data used to generate the content depends on the first character and the first information. determined based on
5. A game program according to claim 4. The game program causes the processor to:
6. The game program according to claim 4 or 5, causing execution of a step of displaying a UI component for instructing disclosure of said content via an SNS application. The game program causes the processor to:
adding a parameter value in a parameter associated with the user when the first character returns from the second state to the first state due to the expiration of the predetermined time;
7. The game according to any one of claims 1 to 6, wherein in exchange for the parameter value indicated by the parameter, the larger the parameter value to be exchanged, the higher the value of the reward in the game. game program. The step of giving the reward is a step of giving the user, as the reward, a lottery item necessary for performing a lottery process for selecting a card to which the character is linked, and giving the reward. In the step, the larger the parameter value to be exchanged, the lottery item associated with a population in which a card with a higher rarity value is more likely to be won,
The game program causes the processor to:
8. The game program according to claim 7, causing execution of a step of giving the user a card selected from the population linked to the lottery item in exchange for the lottery item owned by the user. The parameter has a plurality of types according to the amount of increase in the parameter value, and one parameter among the plurality of types is associated with the user,
In the adding step, the parameter value of the parameter associated with the user is added based on the amount of increase set for the parameter;
9. In the step of providing the reward, the smaller the amount of increase in the parameter associated with the user, the higher the value of the reward given to the user in exchange for the parameter value indicated by the parameter. The game program described in . in the step of providing the content, the content is associated with a date when the content was provided to the user and stored in the memory;
The game program causes the processor to:
displaying a first screen that lists the plurality of contents stored in the memory by date;
10. The method according to any one of claims 1 to 9, further comprising a step of accepting an input operation by the user for the content listed on the first screen as the second input operation for designating the content. game program. The game program causes the processor to:
executing a step of consuming a consumable item designated by the fourth input operation among the consumable items owned by the user in response to the user's fourth input operation;
In the step of generating the content, the content to be given to the user is generated based on the first character, the first information associated with the first character, and the consumed consumable item. 5. The game program according to claim 4. The game program causes the processor to:
displaying a second screen showing the first character in the second state and part of the content to be provided in response to the return of the first character;
and returning the first character to the first state before the predetermined time elapses in response to the user's fifth input operation on the second screen. 12. The game program according to any one of 11. A method for a computer to execute a game program, comprising:
The computer comprises a processor, a memory and a display,
A method in which said processor performs the steps recited in claim 1. An information processing device,
The information processing device is
a memory for storing the game program according to claim 1;
a processor that controls the operation of an information processing device by executing the game program;
An information processing device comprising a display unit.

Images