JP5622916B1 - GAME PROGRAM AND GAME DEVICE - Google Patents

Abstract

A timing game with higher taste is provided. An operation content is presented to a player by the number of appearances of a line, an icon, and the like, and an appropriate range 55 that is a criterion for determining an operation position is changed according to the presented operation content. Thereby, a timing game with higher taste can be provided. [Selection] Figure 10

Description

  The present invention relates to a game program for executing a game for inputting an operation in accordance with a predetermined timing.

  A game for evaluating the operation timing of a player is known. For example, the game described in Patent Document 1 is a game for evaluating a player's operation at the timing when two images overlap. The game described in Patent Document 2 is a game machine that includes a touch panel, and is a game that evaluates touch input for a touch image displayed in accordance with music.

  In recent years, game machines equipped with a touch panel have become widespread, and as in the game described in Patent Document 2, there are an increasing number of games in which an operation is directly input to an image displayed on a game screen.

Japanese Patent No. 3686925 JP 2007-111568 A

  In the case of a timing game in which an operation target object is moved on the game screen and an operation is input to various places on the game screen, the player must determine not only the timing but also the operation input position. Therefore, if the object is moved at high speed, the difficulty of the game will increase. On the other hand, if the moving speed of the object is slow, the sense of speed is lost.

  The present invention has been made in view of the above, and an object of the present invention is to provide a more interesting timing game.

The game program according to the present invention, a computer, operation input means for inputting operation information of the player, to appear a plurality of objects on the game screen, to close a respective said plurality of objects move in different loci Rutotomoni, Object control means for presenting operation contents to the player, the operation information is received from the operation input means, and whether or not the operation information satisfies an evaluation standard regarding a position and an evaluation standard regarding timing for the plurality of objects. A game program that functions as an operation determination unit that determines the operation content according to the operation content , wherein the operation determination unit is configured such that when the operation content is a hold operation that continues a touch operation for a predetermined period, Determine whether the location criteria are met, Rudo during operation, characterized in that the evaluation excluded the evaluation criteria for the position.

  According to the present invention, a more interesting timing game can be provided.

It is a block diagram which shows the internal structure of the game machine with which the game program in this Embodiment is performed. It is a figure which shows an example of a game screen. It is a figure which shows a game screen in time series order. It is a functional block diagram which shows the structure of the game device comprised by the game program in this Embodiment. It is a flowchart which shows the flow of the whole process of the said game device. It is a figure which shows the example from which the line appears from the lower side and the right side of a game screen, and the distance from the appearance position of a line to a virtual intersection differs. It is a figure which shows the example which makes equal the distance to the appearance position of a line, and a virtual intersection. It is a flowchart which shows the flow of a determination process. It is a figure which shows the example of the game screen which displayed the icon etc. which instruct | indicate operation content. It is a figure which shows the appropriate range of the operation input position of a tap, a flick, and a hold | maintenance. It is a figure explaining determination of a flick operation. It is a figure which shows a mode that a flick operation is input continuously. It is a figure which shows the variation of a line and a precursor image. It is a figure which shows the game screen which moved the display position of the line in time series order. It is a figure which shows a mode that the position of a virtual intersection is moved. It is a figure which shows the example of the game screen of a flick and shoot. It is a figure which shows the example of the game screen which displayed the hole in flick and shoot. It is a flowchart which shows the flow of an unlock challenge. It is a sequence diagram which shows the flow of a process when a friend supports an unlock challenge. It is a whole lineblock diagram showing the whole game system composition which realizes a share song function. It is a flowchart which shows the flow in which a player plays a share song. It is a figure which shows the example which displayed the share song on the game screen. It is a figure explaining the time which distributes the reward of an event.

[First Embodiment]
Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a block diagram showing an internal configuration of a game machine 3 on which the game program 1 according to the present embodiment is executed.

  The game machine 3 connects a CPU 31, a RAM 32, a ROM 33, a storage 34, an image processing unit 35, an input interface 36, an audio processing unit 37, a wireless communication unit 38, and a media interface 39 to the bus 30. A touch panel 40 is connected to the image processing unit 35 and the input interface 36. The touch panel 40 displays a game screen generated by the image processing unit 35, inputs the contact coordinates with which the player has touched the touch panel 40, and passes it to the input interface 36. A speaker 41 is connected to the sound processing unit 37. The speaker 41 outputs sound such as sound effects and BGM that are converted into analog signals by the sound processing unit 37 and amplified. For example, a smartphone equipped with a touch panel 40 can be used as the game machine 3.

  The game machine 3 receives the game program 1 from the wireless communication unit 38 or the media interface 39 and stores it in the storage 34. The CPU 31 reads out and executes the game program 1 stored in the storage 34 on the RAM 32, and configures a game device to be described later using the above hardware resources. The game program 1 can be recorded on a recording medium such as a magnetic disk, an optical disk, or a semiconductor memory, or can be provided through a network.

<About the game>
Next, a game provided by the game program in the present embodiment will be described.

  In the case of a timing game in which an operation target object is moved on the game screen and an operation is input to various places on the game screen, the player must determine not only the timing but also the operation input position. Therefore, if the object is moved at high speed, the difficulty of the game will increase. On the other hand, if the moving speed of the object is slow, the sense of speed is lost. In this embodiment, a timing game with a sense of speed is provided.

  Also, when a touch panel is used as the input device, unlike a button operation, in addition to tapping (operation that makes the finger contact the game screen), flick (operation that plays with a finger), hold (operation that keeps pressing for a while) Various operations such as can be input. Therefore, in this embodiment, a determination method more suitable for various input operations is provided.

  This game is a timing game in which a player's operation is evaluated at the timing at which the tips of a plurality of lines appearing from the end of the game screen collide with each other (hereinafter referred to as “just timing”). The score is added when the player performs operations such as tapping, flicking, and holding at the line collision position on the game screen at the collision timing of the plurality of lines.

  FIG. 2 shows an example of the game screen. Lines 51A and 51B and predictive images 52A to 52C are displayed on the game screen shown in FIG. Information such as a score is also displayed on the actual game screen, but it is not shown here. Moreover, you may display the promotion video according to the music reproduced | regenerated as a background of a game screen.

  The lines 51A and 51B appear and extend from the end of the game screen in accordance with the music output from the game machine 3, and the ends collide at a virtual intersection 53 in the game screen. The virtual intersection 53 is not displayed on the game screen.

  The sign images 52A to 52C are images showing signs that the ends of the lines 51A and 51B are close to each other, and are displayed on the game screen before the lines 51A and 51B appear or simultaneously with the appearance of the lines 51A and 51B. The rough collision timing of the lines 51A and 51B and the position of the virtual intersection 53 are shown to the player. In the example illustrated in FIG. 2, as the indication images 52A to 52C, images in which the traveling directions of the lines 51A and 51B are represented by a plurality of broken lines are used, and the position of the virtual intersection 53 is determined in the traveling direction of the folding points of the indication images 52A to 52C. The collision timing of the lines 51A and 51B is shown by the change in the interval between the predictive images 52A to 52C.

  Here, the movement of the lines 51A and 51B and the precursor images 52A to 52C will be described. FIG. 3 is a diagram showing, in chronological order, how the lines 51A and 51B appear in the game screen and approach the virtual intersection 53. FIG.

  As shown in FIGS. 3A to 3C, the lines 51A and 51B appear from the left side of the upper and lower ends of the game screen and extend toward the virtual intersection 53 near the center of the game screen. That is, the line 51A extends in the lower right direction, and the line 51B extends in the upper right direction.

  The sign image 52A appears from the left side of the game screen slightly before the appearance of the lines 51A and 51B and moves to the right side. Another predictor image 52B appears from the left side of the game screen and moves to the right following the predictor image 52A simultaneously with the appearance of the lines 51A and 51B. Further, another sign image 52C appears from the left side of the game screen and moves to the right after the sign images 52A and 52B after the appearance of the lines 51A and 51B.

  The moving speed of each of the predictor images 52A to 52C increases as the appearance speed decreases. Therefore, as shown in FIGS. 3A to 3C, the interval between the predictor images 52A to 52C becomes narrower as the lines 51A and 51B approach the virtual intersection 53, and the predictor images 52A to 52C As the time elapses, the lines 51A and 51B overlap each other at the virtual intersection 53 as the ripples approach the virtual intersection 53. At this time, the break points of the predictor images 52 </ b> A to 52 </ b> C overlap at the virtual intersection 53.

  The player can estimate the rough timing at which the tips of the lines 51A and 51B collide and the position of the virtual intersection 53 by observing the predictive images 52A to 52C.

<Game device>
Next, a game apparatus configured by reading the game program in the present embodiment into the game machine 3 will be described.

  FIG. 4 is a functional block diagram showing a configuration of a game device constituted by the game program in the present embodiment. The game device shown in the figure includes an operation input unit 11, a predictive image control unit 12, a line control unit 13, a timing determination unit 14, a score processing unit 15, an image output unit 16, a background processing unit 17, a voice output unit 18, and A game data storage unit 19 is provided.

  The operation input unit 11 inputs a player's operation. The player inputs an operation by touching the touch panel 40 of the game machine 3 with a finger or the like. The operation input unit 11 acquires operation information such as contact coordinates on the game screen and the type of operation, and transmits the operation information to the timing determination unit 14.

  The sign image control unit 12 causes the sign images 52A to 52C corresponding to the lines 51A and 51B to appear on the game screen, controls the movement of the sign images 52A to 52C, and displays the position information of the sign images 52A to 52C. It transmits to the image output part 16, and the sign image 52A-52C on a game screen is updated. The appearance timing of the predictive images 52A to 52C, the motion data, and the like are read from the game data storage unit 19.

  The line controller 13 causes the lines 51A and 51B to appear on the game screen in accordance with the music output from the audio output unit 17, and controls the movement so that the ends of the lines 51A and 51B collide with each other. , 51B is transmitted to the image output unit 16 to update the lines 51A, 51B on the game screen. In addition, timing determination is performed on proximity information such as the position information of the virtual intersection 53 that is the position where the tips of the lines 51A and 51B collide, the position information of the lines 51A and 51B, and the time until the tips of the lines 51A and 51B collide. To the unit 14. The appearance timing of the lines 51A and 51B, the speed of extension, and the like are read from the game data storage unit 19.

  The timing determination unit 14 receives operation information from the operation input unit 11 and also receives proximity information of the tips of the lines 51A and 51B from the line control unit 13, and whether or not an operation is input at an appropriate position at an appropriate timing. And the success / failure of the operation is transmitted to the score processing unit 15.

  The score processing unit 15 performs score addition processing based on the success or failure of the operation received from the timing determination unit 14. Further, the score processing unit 15 transmits a value of a parameter such as a score to the image output unit 16 and updates the value displayed on the game screen.

  The image output unit 16 receives the position information of the lines 51A and 51B from the line control unit 13 and displays the lines 51A and 51B on the game screen, and also receives the position information of the sign images 52A to 52C from the sign image control unit 12. Then, the predictive images 52A to 52C are displayed on the game screen. In addition, parameter values such as scores and background images are displayed on the game screen.

  The background processing unit 17 reads the background image to be displayed behind the lines 51A and 51B and the predictive images 52A to 52C from the game data storage unit 19 and causes the image output unit 16 to display the background image.

  The audio output unit 18 acquires music data from the game data storage unit 19 and outputs it.

  The game data storage unit 19 stores image data to be displayed on the game screen, audio data such as music and sound effects to be reproduced, line appearance data, and sign appearance data.

  The line appearance data includes information such as the position of the virtual intersection, the number of appearance, the appearance timing of the line, the appearance position, the extending direction / speed, and the like. The position of the virtual intersection represents coordinates on the game screen. The number of appearances represents the number of lines that intersect at a virtual intersection. The appearance timing is data that describes, for each line, how long a time has elapsed since the start of music playback. The appearance position is, for example, data describing coordinates for each line when any corner of the game screen is set as the origin. The extending direction / speed is data describing the extending direction and speed for each line. The speed at which the line extends may vary from line to line.

  The sign appearance data is associated with the line appearance data and includes information such as the appearance timing, appearance position, movement speed, and change information of the sign image. The appearance timing is data describing how much time has elapsed since the start of music reproduction, or the relative time from the appearance timing of the line to the appearance timing of the predictive image. The appearance position is data describing the position where the sign image appears. The moving speed is data describing the moving speed of the precursor image. The change information is data describing how to change, for example, when the color of the predictor image is changed.

<Game flow>
Next, a processing flow of the game device will be described.

  FIG. 5 is a flowchart showing an overall processing flow of the game apparatus.

  When the game is started, an initialization process is performed (step S11). The initialization process includes, for example, initialization of parameters such as clearing of a score, selection of line appearance data to be used with music to be reproduced, and sign appearance data. The music selected by the player and the music set in advance according to the difficulty level are selected as the music to be played.

  When the initialization process ends, the audio output unit 17 starts playing music (step S12).

  The line control unit 13 reads the line appearance data from the game data storage unit 19 and determines whether or not new lines 51A and 51B appear (step S13). Whether or not new lines 51A and 51B appear is determined by, for example, comparing the music playback time with the appearance timing of the line appearance data. When the music playback time is equal to or greater than the appearance timing, it is determined that new lines 51A and 51B appear.

  When it is determined that new lines 51A and 51B are to appear, the predictor images 52A to 52C and the lines 51A and 51B are caused to appear on the game screen (step S14). The line control unit 13 causes the lines 51A and 51B to appear at the appearance positions of the line appearance data read from the game data storage unit 19, and the sign image control unit 12 applies the lines 51A and 51B that the line control unit 13 causes to appear. Corresponding sign appearance data is read from the game data storage unit 19, and the sign images 52A to 52C appear on the game screen. For example, the predictive images 52A to 52C appear on the game screen three beats before the just timing, and the lines 51A and 51B appear on the game screen two beats before the just timing.

  The line control unit 13 moves the lines 51A and 51B on the game screen at a predetermined interval (for example, 60 fps interval) (step S15), and the predictive image control unit 12 updates the predictive images 52A to 52C (step S16). When the distances from the virtual intersection 53 to the appearance positions of the lines 51A and 51B are equal, the moving speeds of the lines 51A and 51B are the same. When the distances from the virtual intersection 53 to the appearance positions of the lines 51A and 51B are different from each other, the moving speeds of the lines 51A and 51B are different.

  For example, as shown in FIG. 6, when the line 51A appears from the bottom of the game screen and the line 51B appears from the right side of the game screen, the distance La from the appearance position of the line 51A to the virtual intersection 53 is from the appearance position of the line 51B. Since the distance Lb is shorter than the distance Lb to the virtual intersection 53, the moving speed Va of the line 51A is slower than the moving speed Vb of the line 51B. As shown in FIG. 6, when the distances from the position of the virtual intersection 53 to the ends of the game screen where the lines 51A and 51B appear are different, when the movement speeds of the lines 51A and 51B are the same, for example, The lines 51A and 51B appear at positions where the distances from the virtual intersection 53 to the tips of the lines 51A and 51B are the same instead of the end of the game screen as the appearance position of one line. Specifically, in the example of FIG. 7A, the distance from the virtual intersection 53 to the tip of the line 51B is La for the line 51B two beats before the just timing, which is the appearance time of the lines 51A and 51B. The line 51A and 51B are moved at the same moving speed Va by appearing at the position with a length of Lb-La. The line 51B may appear with a length of 0 (the same length as the line 51A) at a position where the distance from the virtual intersection 53 is La. That is, the line 51B is a line extending from the game screen, not the end of the game screen. As another example, the timing at which the lines 51A and 51B appear in the game screen is shifted. Specifically, in the example of FIG. 7B, the virtual intersection point outside the game screen is displayed without causing the line 51A to appear in the game screen two beats before the just timing, which is the appearance time of the lines 51A and 51B. The line 51A and the line 51B are moved at the same moving speed Vb by causing the line 51A to appear at a position where the distance from the line 51A to the tip of the line 51A is Lb. When the line 51B extends to some extent and the distance from the tip of the line 51B to the virtual intersection 53 becomes the same as the distance from the virtual intersection 53 to the end of the game screen where the line 51A appears, the line 51A is in the game screen. Appears on. The line 51B appears in the game screen two beats before the just timing as usual, and the line 51A appears in the game screen one beat before the just timing. In the above description, an example in which the appearance position and appearance timing of a line are shifted when the position of the virtual intersection 53 is different from the end of the game screen that is the appearance position has been described, but the distance from the virtual intersection 53 to the appearance position is the same. Even in such a case, the appearance position and the appearance timing of the line may be shifted in order to increase the difficulty level of the game and prevent rubbing.

  And the timing determination part 14 performs the determination process with respect to operation by a player (step S17). Details of the determination process will be described later.

  Further, it is determined whether or not a game end condition is satisfied (step S18). As for the game end condition, for example, it is determined that the game is cleared when the reproduction of music is ended, and it is determined that the game is over when the number of times determined to be a mistake in the determination process exceeds a predetermined value. If the game end condition is not satisfied, the process returns to step S13 to continue the game.

  If the game end condition is satisfied, a message indicating that the game is cleared or the game is over is displayed on the game screen, and the game is ended (step S19). After the game ends, if the game is cleared, the process returns to step S11 to start a new game, and if the game is over, the process returns to the title.

<Judgment process>
Next, the determination process will be described. In the determination process, it is determined whether or not an operation is input to the line collision position on the game screen at the timing at which the line ends collide with each other.

  FIG. 8 is a flowchart showing the flow of the determination process.

  First, it is determined whether or not a tap, flick, and hold operation has been input (step S21).

  When an operation is input (Yes in step S21), operation input coordinates on the game screen are acquired (step S22), and it is determined whether or not the operation input position is within an appropriate range (step S23). Whether or not the operation input position is within an appropriate range is determined by comparing the operation input coordinates with a virtual intersection 53 indicating a position where the ends of the lines collide with each other.

  When the operation input coordinates are within a predetermined range from the virtual intersection 53 (Yes in step S23), it is determined whether or not the input operation content is appropriate (step S24). The player can recognize an operation to be input by displaying the game screen.

  For example, as shown in FIG. 9A, when the icon 54 indicating the flick direction is displayed on the virtual intersection, it indicates that the flick should be performed in the direction of the icon 54. The timing for displaying the icon 54 may be the same as the appearance of the line (2 beats before), the same as the appearance of the predictive image (3 beats before), or just before the operation (for example, 1 beat before). The arrow in the icon 54 indicating the direction of the flick is not fixed, and it may be rotated until the line collides so that the direction of the flick is not known until immediately before the operation. In this case, if the flicking is performed in the direction of the icon 54 at the timing when the lines collide, it is determined to be successful.

  Further, as shown in FIG. 9B, when the four lines 51A to 51D collide, it indicates that the line should be held. The line color or shape may be changed to indicate that the line should be held, or an icon indicating the hold may be displayed at the position of the virtual intersection 53. The hold time is until the lines 51A to 51D disappear. As a method of eliminating the lines 51A to 51D, for example, the lines 51A to 51D may be gradually shortened so as to be gathered at the virtual intersection 53, or the lines 51A to 51D may be thinned to disappear. You may let them. Alternatively, the transparency of the lines 51A to 51D may be gradually increased and disappear, or the lines 51A to 51D may be eliminated at a predetermined timing without changing the length, thickness, color, or the like.

  When the operation content is appropriate (Yes in step S24), the operation timing is determined (step S25). The operation timing is determined by obtaining the time difference between the just timing at which the tips of the lines 51A and 51B collide and the operation timing. For example, the just timing determination width is 2 frames, and an appropriate range is from several frames to several tens of frames before and after the just timing. The width of the appropriate range depends on the difficulty level of the game. When the difficulty level is lowered, the appropriate range is widened, and when the difficulty level is increased, the appropriate range is narrowed. Also, the appropriate range may be changed according to the tempo of the song being played. For example, a song with a fast tempo narrows the appropriate range, and a song with a slow tempo widens the proper range. In any case, the just timing judgment width is kept at 2 frames.

  If all of the operation position, operation content, and operation timing are appropriate, the score is added (step S26), and the lines 51A and 51B are deleted from the game screen (step S27). If the operation timing is just timing, the maximum score is added, and if not, a smaller score is added. Further, the closer the operation position is to the collision position, the greater the score to be added.

  On the other hand, when the operation is not input (No in Step S21), the operation input position is outside the appropriate range (No in Step S23), and the operation content is not appropriate (No in Step S24), the operation timing It is determined whether or not missed (step S28). If a predetermined time has elapsed after the leading ends of the lines 51A and 51B, that is, if the appropriate timing of operation is exceeded, a mistake is determined (Yes in step S28), and a mistake is processed (step S29). ), The lines 51A and 51B that missed the operation input are deleted from the game screen (step S26).

  Here, the determination of the operation input position will be described in more detail. 10A to 10C show the appropriate ranges 55 of the operation input positions for tap, flick, and hold. The appropriate tap and hold range 55 is a circle centered on the virtual intersection 53 (FIGS. 10A and 10C). The appropriate flick range 55 is an ellipse centered on the icon 54 indicating flick and extending in the flick direction (FIG. 10B). The length of the major axis of the ellipse is longer than the diameter of the circle in the appropriate tap / hold range 55. The length of the minor axis of the ellipse is the same as or shorter than the diameter of the circle in the appropriate tap and hold range 55. Note that the appropriate range 55 may be shaped like a rectangle that is long in the flick direction.

  In the determination of the tap operation, it is determined whether or not the tapped position is within the appropriate range 55.

  In the determination of the hold operation, first, it is determined whether or not the hold start position is within the appropriate range 55, and it is determined whether or not the hold position is within the appropriate range 55 during the hold. If the hold position is outside the appropriate range 55, it is considered a mistake. If the hold ends (the finger is released) within the hold operation time (the time during which the game screen is kept pressed), a mistake is made. In addition, regarding the determination of the hold operation, it is determined whether or not the hold start position is within the appropriate range 55 and only the hold operation time, and unless the finger is released from the game screen, that is, even if the hold position is moved, it is considered a mistake. It does not have to be. In this case, even when the line that the player should input next appears on the game screen during the hold, and the player's own finger is in the way, it is difficult to see the movement of the line. it can. Alternatively, regarding the determination of the hold position, if the hold position is within the appropriate range 55 at the start of the hold and at the end of the hold, the hold operation may be determined to be successful even if the outside of the appropriate range 55 is held during the hold operation time.

  As another example, the appropriate range 55 of the hold operation may be widened or narrowed after the start of holding, or the shape of the appropriate range 55 may be changed from a circle to another shape. Further, the appropriate range 55 may be moved. If the hold position cannot be made to follow the moving proper range 55, it is determined as a mistake. Specifically, after the hold is started, a predetermined mark object is displayed on the game screen and moved, and the appropriate range 55 is moved in accordance with the movement of the mark object. The player moves the held finger so as to follow the mark object (to keep the finger within the appropriate range 55) without releasing the finger from the game screen.

  In the determination of the flick operation, first, it is determined whether or not the start point of the flick is within the appropriate range 55, then the end point of the flick is obtained, and whether or not the direction from the start point of the flick is the direction indicated by the flick is determined. Determine. In this embodiment, as shown in FIG. 11, when the appropriate flick range 55 is divided into a rear portion 55A and a front portion 55B, and the starting point of the flick is the rear portion 55A, the center line 55C of the proper range 55 is indicated by the pressing position. If the position exceeds the end point of the flick and the start point of the flick is the front portion 55B, the position where the pressed position exceeds the appropriate range 55 is set as the end point of the flick. Further, when the finger leaves the game screen without exceeding the center line 55C or the appropriate range 55, the position where the finger is removed is set as the end point of the flick. When the end point is determined, the direction of the flick is determined to be correct if the direction from the start point to the end point of the flick and the direction indicated by the flick are within a predetermined angle (for example, within 30 degrees). By setting the position where the pressed position exceeds the center line 55C or the appropriate range 55 as the end point of the flick, it is determined that the flick operation is performed without releasing the finger from the game screen. As a result, as shown in FIG. 12, when flick operations in the same direction appear continuously, the correct operation is input by sliding the finger in the flick direction instead of inputting the flick operations one by one. It is determined that In the example of FIG. 12, the determination of the flick operation is sequentially performed from the lower icon. When the pressed position exceeds the center line or the appropriate range and the flick is determined, the appropriate range of the next icon is pressed. Therefore, even if the finger is slid, the flick determination is continuously performed.

  Note that the appropriate range 55 of the flick operation may be widened or narrowed after the flick is started (after the start point of the flick is recognized), or the shape may be changed. As an example of changing the shape of the appropriate range 55, first, the circular appropriate range 55 is set in the same manner as tap and hold, and the shape is changed to an ellipse, a fan shape, a triangle, or the like spreading in the flick direction after the flick is started. When the appropriate range 55 is changed to a fan shape or a triangle, the fan shape or the triangle is set so that the corner of the fan shape or the triangle is aligned with the start point of the flick and spread in the flick direction. For example, the angle of the starting point of the flick is set to 60 degrees, and the appropriate range 55 of the sector shape or the triangle is set so that the line passing through the center of the corner is the flick direction. If the finger is slid beyond the arc or side facing the corner placed at the starting point of the flick, it is determined that the flick is successful. If the finger is slid beyond two sides across the corner placed at the start point of the flick, the flick direction is determined to be incorrect.

<Modification>
Next, variations of lines and predictive images will be described.

  FIG. 13 is a diagram showing variations of lines and predictive images. Hereinafter, each variation shown in FIG. 13 will be described.

  FIG. 13A is a diagram illustrating an example in which a plurality of sets of lines appear simultaneously. In the example shown in FIG. 13A, a plurality of sets of lines 51A to 51D colliding at different virtual intersections 53A and 53B respectively appear on the game screen at the same time. In the example shown in FIG. 13A, the player taps in the order of the virtual intersections 53A and 53B. If a plurality of sets of lines exist in the game screen at the same time, it becomes difficult to understand the order of inputting operations and the sets of lines that collide with each other. Therefore, just before the line collides (for example, one beat before), you can display the effects such as enlarging the tip of the line, changing the color, changing the shape, rotating it, and adding movement. The order of inputting operations and the set of lines that collide with each other may be easily understood. In addition, in order to make it easy to understand the lines that collide, the colors may be changed or the shapes may be changed for each set of colliding lines. Furthermore, the shape of the tip of the line may be different, or the predictive image may be changed for each group that collides.

  FIG. 13B is a diagram illustrating an example in which the lines 51A and 51B disappear or appear. In the example shown in FIG. 13B, when the lines 51A and 51B extend, the lines 51A and 51B are temporarily hidden until just before the virtual intersection 53. Alternatively, a part of the lines 51A and 51B is not displayed. When the lines 51A and 51B are not displayed, the sign image may be not displayed or only the sign image may be displayed.

  FIG. 13C is a diagram illustrating an example in which a line collision is predicted by a color change. In the example shown in the figure, a predictive image 52 (pentagon in FIG. 13C) in which the color changes is arranged at a portion delimited by the lines 51A and 51B when the lines 51A and 51B collide. The sign image 52 changes color according to the growth of the lines 51A and 51B. For example, the color of the predictive image 52 is black or transparent so that it is not distinguished from other parts when it appears, and gradually becomes red or decreases in transparency. The player can know the rough timing when the lines 51A and 51B collide with each other based on the color density and transparency of the sign image 52, and can know the direction in which the lines 51A and 51B extend and the position of the virtual intersection 53 based on the shape of the sign image 52. it can.

  FIG. 13D is a diagram illustrating an example in which a line collision is predicted by a change in line thickness. In the example shown in the figure, the thick line including the lines 51 </ b> A and 51 </ b> B and the virtual intersection 53 is used as the sign image 52. The predictor image 52 becomes thinner as the lines 51A and 51B approach. The player knows the rough timing at which the lines 51A and 51B collide with the change in the thickness of the predictor image 52, and knows the direction in which the lines 51A and 51B extend and the rough position of the virtual intersection 53 at the position of the predictor image 52. it can.

  Note that the user may be able to arbitrarily specify the color, transparency, thickness, and the like of the sign image using a configuration menu or the like.

  Although not shown, a virtual intersection may automatically occur somewhere within a certain range from the touched location, and a line toward the virtual intersection may appear. This can also be applied to a case where a plurality of people perform the game, and the game progresses separately on the side giving the task (line) and the side playing the task. When the first player taps a predetermined position on the screen of his / her first game device, the task information is transmitted to the second game device operated by the second player, and the display screen of the second game device receiving the information is displayed. A line having a virtual intersection at or near the position tapped by the first player is displayed. A 2nd player advances a game by operating with respect to the line.

<Movement in the depth direction of the line>
In the embodiments described so far, the line moves only in the direction in which the line extends, and does not move in any direction other than the direction in which the line extends. Here, an embodiment will be described in which a line is moved in a direction other than the direction in which the line extends to make the line appear to move in the depth direction.

  FIG. 14 is a diagram showing the game screen with the line display position moved in chronological order in the order of (a) to (c). In the embodiment shown in FIG. 14, the lines 51A and 51B and the predictive images 52A and 52B are displayed on the background with a sense of depth using the perspective method, and the lines 51A and 51B move from the back to the front (depth direction). As shown, the display positions of the lines 51A and 51B are moved.

  As the background of the game screen, the floor 58A and the ceiling 58B are expressed by lines radiating from the vanishing point 56 set at the center of the game screen, giving a sense of depth. Level meters 58C indicating the volume of music to be reproduced are arranged on both sides of the floor 58A. The display positions on the game screen of the floor 58A, the ceiling 58B, and the level meter 58C are moved toward each other for each frame, and the player feels that the player is moving toward the vanishing point 56. Specifically, the horizontal line of the floor 58A is moved downward, the horizontal line of the ceiling 58B is moved upward, and the left and right level meters 58C are moved downward in the horizontal direction so as to be away from the vanishing point 56 on the game screen. The moving speed of the background images such as the floor 58A, the ceiling 58B, and the level meter 58C is adjusted to the tempo (BPM) of the music to be reproduced. The floor 58A, the ceiling 58B, and the level meter 58C are backgrounds for giving a sense of depth and speed, and are not related to the operation of the player. By moving and displaying the floor 58A, the ceiling 58B, and the level meter 58C away from the vanishing point 56, the background is displayed so as to move in the depth direction, thereby creating a sense of speed.

  The lines 51 </ b> A and 51 </ b> B are displayed so as to overlap the background with a sense of depth, and are moved so that the display positions of the lines 51 </ b> A and 51 </ b> B are separated from the vanishing point 56. Specifically, as shown in FIGS. 14A to 14C, the line 51A extending in the horizontal direction displayed above the vanishing point 56 on the game screen is moved upward in accordance with the elapsed time. The line 51B extending in the vertical direction displayed to the right of the vanishing point 56 is moved to the right according to the elapsed time. The size (thickness) of the lines 51A and 51B is also increased (thickened) according to the elapsed time.

  The predictive images 52A and 52B are displayed so as to indicate the virtual intersection 53 that extends the lines 51A and 51B at the current display position, not the expected collision position 57 that is the final collision position of the lines 51A and 51B. . In the example illustrated in FIG. 14, strip-shaped sign images 52A and 52B extending in the longitudinal direction of the lines 51A and 51B are displayed. The intersection of the two strip-shaped sign images 52A and 52B corresponds to the virtual intersection 53.

  Next, processing for calculating the display positions of the lines 51A and 51B and the sign images 52A and 52B will be described.

  The display positions of the lines 51A and 51B are determined based on the position of the virtual intersection 53 that moves from the vanishing point 56 to the final collision position 57 that is the final collision position with the passage of time. The position of the virtual intersection 53 is determined by interpolation on the line connecting the vanishing point 56 and the expected collision position 57 according to the elapsed time.

  FIG. 15 shows how the position of the virtual intersection 53 is moved. In the example shown in the figure, it is assumed that the virtual intersection 53 moves from the vanishing point 56 to the expected collision position 57 in one bar, the predictive images 52A and 52B are 3 beats before the just timing, and the lines 51A and 51B are 2 of the just timing. It is supposed to appear before the beat.

  When three beats before the just timing, that is, when the indication images 52A and 52B appear, the virtual intersection 53 is located at a position P of 3/4 from the expected collision position 57 to the vanishing point 56, as shown in FIG. And the sign images 52A and 52B are displayed with the virtual intersection 53 as a reference. Specifically, the band-like predictive images 52A and 52B are displayed from the virtual intersection 53 to the sides where the lines 51A and 51B appear.

  As time passes, the virtual intersection 53 is moved on the line segment toward the expected collision position 57, and the display positions of the predictive images 52A and 52B are corrected and moved in accordance with the position of the virtual intersection 53.

  Then, two beats before the just timing, that is, when the lines 51 </ b> A and 51 </ b> B appear, the virtual intersection 53 reaches the half position Q from the expected collision position 57 to the vanishing point 56 as shown in FIG. The sign images 52A and 52B are displayed with reference to the virtual intersection 53, and lines 51A and 51B appear with the virtual intersection 53 as a reference. Specifically, the line 51A appears at the left end of the game screen according to the vertical position of the virtual intersection 53, and the line 51B appears at the lower side of the game screen according to the horizontal position of the virtual intersection 53.

  Thereafter, the lines 51A and 51B are extended, the virtual intersection 53 is moved toward the expected collision position 57, and the display positions of the lines 51A and 51B and the predictive images 52A and 52B are corrected and moved according to the position of the virtual intersection 53. Let At the just timing, the virtual intersection 53 reaches the expected collision position 57, and the ends of the lines 51A and 51B collide with each other at the expected collision position 57. The score is added by tapping the collision position of the lines 51A and 51B on the game screen at the just timing. Compare the tapped position and the collision position on the game screen, the tapping timing and the just timing, and if the tapping position and the collision position are in the specified range, the tapping timing and the just timing are within the predetermined range. If it is out of the predetermined range, it is determined as failure.

  Note that when the moving speed of the lines 51A and 51B is increased in the game setting, for example, the appearance timing of the predictive images 52A and 52B is 2 beats before the just timing, and the appearance timing of the lines 51A and 51B is 1 beat from the just timing. Before. When the moving speed of the lines 51A and 51B is slowed, the appearance timing of the predictive images 52A and 52B is set to 4 beats before the just timing, and the appearance timing of the lines 51A and 51B is set to 3 beats before the just timing.

  Moreover, you may add the setting which does not display the precursor images 52A and 52B. When the display positions of the lines 51A and 51B move without displaying the predictive images 52A and 52B, it becomes difficult for the player to grasp the collision positions of the lines 51A and 51B, and the difficulty of the game can be increased.

<Flick and shoot>
Next, flick and shoot will be described. In a conventional timing game, the game may become monotonous only by inputting an operation at a designated timing. In the present embodiment, a game program with higher entertainment is provided by adding effects after an operation input.

  As shown in FIG. 16A, the flick and shoot appears as a light object 61 that moves in the flicked direction from the operation position when the player makes a successful flick operation when the flick operation is requested. It is a function to let you.

  As an example of using the light object 61, as shown in FIG. 16 (b), the light object 61 bounces off at the end of the game screen and changes to the line 51D, and the line 51C appears to create a new line 51C. , 51D request an operation for a collision. If the player fails in the flick operation in FIG. 16 (a), the light object 61 does not appear, so in FIG. 16 (b), the line 51D does not appear but only the line 51C appears, and the line 51C , 51D operation cannot be input, resulting in a mistake. When the operation with respect to the collision between the line 51C and the line 51D in which the light object 61 has changed is successful, a privilege that is more advantageous to the player than the normal time may be given. For example, there are an effect that a high score is given, a predetermined item is given, an appropriate range 55 is widened for a certain time, a game progress speed is slowed for a certain time, and the like. On the contrary, when the operation for the collision between the line 51C and the line 51D where the light object 61 has changed (including the flick operation failure), an effect that is disadvantageous to the player may be generated. For example, the score is deducted, the appropriate range 55 is narrowed for a certain time, or the game progress speed is increased for a certain time. Further, when the light object 61 appears, the light object 61 may be flicked in any direction. In this case, the direction in which the light object 61 bounces at the end of the game screen is calculated, and a set of a line 51C where the light object 61 changes and a line 51D that collides with the line 51C appears. Specifically, the moving direction of the line 51C is determined so that the incident angle and the reflection angle of the light object 61 with respect to the edge of the game screen are equal, and the appearance position and moving direction of the line 51D are set so as to collide with the line 51C. Decide.

  As another example of use, as shown in FIG. 17, when a hole 62 appears on the game screen and a light object 61 that appears by a flick operation enters the hole 62, a bonus score is added to the player. Give benefits that will be advantageous. The light object 61 is reflected at the edge of the game screen and disappears after a predetermined time has elapsed since the appearance. The moving speed of the light object 61 may be constant, or may be a speed according to the flick operation. The appearance timing of the hole 62 includes when a line appears in the game screen, before the just timing, at the just timing, and after the flick operation. Note that the player may be requested to perform the flick operation by causing the hole 62 to appear on the game screen instead of displaying the icon 54 indicating the flick at the line collision position. That is, when the hole 62 appears on the game screen, the player must perform a flick operation to put the light object 61 into the hole 62. When the icon 54 is not displayed, no mistake is determined for the flicking direction. Alternatively, the hole 62 may appear during the hold operation, a flick operation may be requested after the hold operation, and the light object 61 may appear according to the flick operation.

  As described above, according to the present embodiment, in the timing game of tapping the position where the leading ends of the lines 51A and 51B collide, the lines 51A and 51B displayed corresponding to the lines 51A and 51B are displayed. By displaying the sign images 52A to 52C indicating signs that the tips of 51B are close to each other, the player can estimate the collision position and timing of the tips of the lines 51A and 51B from the sign images 52A to 52C. 51B can be moved at high speed to give a sense of speed to the game. Further, the game screen can be dynamically changed by the predictive images 52A to 52C.

  According to the present embodiment, the moving speeds of the lines 51A and 51B are made different according to the distance between the appearance positions of the lines 51A and 51B and the virtual intersection 53, and the appearance timings of the lines 51A and 51B are made different. By making the movement speed the same, a more interesting timing game can be provided.

  According to the present embodiment, the operation content is presented to the player by the number of appearance of the line, the icon, and the like, and the appropriate range 55 that is the determination criterion of the operation position is changed according to the presented operation content, thereby making it more desirable. A highly timing game can be provided.

  According to the present embodiment, the light object 61 appears after the flick operation, and further, the line 51D and the hole 62 that generate a predetermined effect when the light object 61 comes close to each other appear. A game can be offered.

[Second Embodiment]
2. Description of the Related Art In recent years, a basic free to play (Free to Play) system in which game programs are charged for items used in the game for free has become widespread. For example, in a rhythm action game, a new music can be played by charging for the music.

  However, there are many players who are reluctant to charge for in-game items. The player who does not charge does not increase the number of songs that can be newly played, and may stop playing the game itself. In social games that compete with or cooperate with other players over the network, the total number of players who continue to play the game is important.

  Therefore, in the present embodiment, a music (game data) can be obtained without charging, but a method in which a charged player can obtain music more advantageously will be described.

<Unlock Challenge>
The unlock challenge is one of the game modes in which the player obtains new music.

  The music played in this game has three states of “unlocked”, “locked state”, and “not appeared”. Players can freely select and play “unbanned” music. The music in the “lock state” is music that the player knows about existence (game data is stored in the game machine) but cannot be freely played. Music that has not yet appeared is music that the player does not know about (there is no game data in the game machine). Players can freely play the banned music by consuming tickets described later. Music in the “locked state” cannot be played under the same conditions (for example, ticket consumption) as the music in “unlocked”. As a method for obtaining the music in the “lock state”, for example, the music is distributed in the “lock state” at an event or the like. The player can perform an unlock challenge on the music in the “locked state”, and put the music in the “unlocked” state according to the result of the unlock challenge.

  The unlock challenge can be activated when the unlock challenge gauge exceeds a predetermined value. The unlock challenge gauge is accumulated when a player plays a song (such as a “banned” song) or obtains it according to a predetermined condition (for example, continuous login days). In the present embodiment, a ticket is necessary to play music. Each time a predetermined time (for example, several minutes) elapses, the ticket increases one by one up to a predetermined number. Since the ticket increases according to the elapsed time, it is possible to play the music without charge. However, when all the tickets are consumed, the music cannot be played until the tickets are accumulated. By purchasing a ticket by charging, there is no need to wait for the ticket to increase to the number required for play. A player who purchases a ticket by charging can play more times than a player who does not charge, so it is easier to accumulate unlock challenge gauges. The ticket consumption may be changed according to the music to be played or the difficulty level. Also, when retrying a song from the middle, it can be played with a smaller number than the normal consumption. Ticket consumption is changed according to the degree of progress of the music. In the course mode in which a plurality of determined songs are played continuously, if a failure occurs during the course, it is possible to retry by further consuming the ticket.

  FIG. 18 is a flowchart showing the flow of the unlock challenge.

  When the player designates a song to be unlocked, the unlock challenge gauge is consumed, the unlock point is cleared, an unlock challenge timer is set, and an unlock challenge is started (step S31). The game machine acquires the state of each song, selects a song that can be unlocked, and presents it to the player as an unlock challenge candidate. The state of each piece of music is acquired from the game data storage unit 19 or acquired from a server via a network. The server holds the state of each song for each player. The game machine sets the music in the “locked state” as a candidate for an unlock challenge. The unlock challenge timer is a time limit (for example, 20 minutes) of the unlock challenge, and if a predetermined unlock point is acquired before the unlock challenge timer expires, the music is “unlocked”. The unlock challenge gauge, unlock point, and unlock challenge timer are managed at the server.

  When the unlock challenge is started, the player selects a clear condition (step S32), and starts playing the music for the unlock challenge (step S33). The clear condition is a condition for determining success or failure of the play. The clear condition is associated with an unlock point and managed by the server. Many unlock points are set for clear conditions with high difficulty. The clear condition is, for example, a condition that ranks S, A, B,... (S is the highest) as a result of play are achieved. The player chooses clear conditions according to his skill and plays the game.

  When the game ends, it is determined whether or not the clear condition is satisfied (step S34). The game machine transmits the play result of the music for the unlock challenge to the server, and the server compares the play result with the clear condition selected by the player to determine success or failure. For example, when the player selects rank S as the clear condition, if the result of play is rank S, it is determined that the clear condition is satisfied.

  If the clear condition is satisfied (YES in step S34), the unlock point set in the clear condition is acquired (step S35). The server manages the unlock points for each player, and adds the acquired unlock points to the unlock points acquired by the player so far.

  Then, it is determined whether or not the total of unlock points has reached the standard (step S36).

  If the total of unlock points has reached the standard (YES in step S36), the state of the music for the unlock challenge is set to “unlocked” (step S37). If the server manages the music state, the server data is changed and the game machine is notified that the music state has been changed.

  On the other hand, if the clear condition is not satisfied (NO in step S34), and if the total of unlock points has not reached the standard (YES in step S36), it is determined whether or not the unlock challenge timer has expired ( If the unlock challenge timer has expired (step S38) (YES in step S38), the unlock challenge fails (step S39). If the unlock challenge fails, the accumulated unlock points are cleared to zero.

  If the unlock challenge timer has not expired (NO in step S38), the process returns to step S32 to allow the player to select the clear condition again and continue the unlock challenge. When letting the player continue the unlock challenge, the player's motivation is kept high by displaying the jacket image of the music in which the displayed range is changed according to the total unlock points. For example, the jacket image is divided into 16, and the number of pieces of the jacket image to be displayed is determined according to the ratio of the total number of unlock points acquired with respect to the unlock point reference.

  When an unlock challenge is applied to a social game related to another player, a function is provided for allowing the other player to support the unlock challenge. Specifically, when the player starts an unlock challenge in step S31 of FIG. 18, the server notifies other players (a friend player set and registered in advance by the player, hereinafter referred to as “friend”) to that effect. The player who receives the notification supports the unlock challenge. Support for the unlock challenge is also provided by other players playing the music for the unlock challenge. This support does not play the music for the unlock challenge at the same time, but only needs to be played within the time limit of the unlock challenge. When receiving support from another player, the unlock points that can be obtained in step S35 are increased. For example, an unlock point that is increased according to the number of the support is determined, such as an increase of 10% when receiving support by one person and an increase of 20% when receiving support by two persons. Or you may determine the unlock point increased according to the play result (a rank, a score, etc.) of the other player to support. Supporting points will be awarded to the supporting player. Players can exchange for various items by accumulating support points.

  FIG. 19 is a sequence diagram showing a processing flow when a friend supports a player unlock challenge.

  First, when the player starts an unlock challenge on his game machine, the server is notified that the unlock challenge has started (step S301). The player selects clear conditions (step S302) and plays the game (step S303).

  When the server receives the unlock challenge start notification from the player's game machine (step S304), the server searches the server database for the player's friend and notifies the friend that the player has started the unlock challenge ( Step S305). In FIG. 19, only one friend is notified, but in fact, all the friends of the player are notified.

  When the friend's game machine receives an unlock challenge start notification from the server, the friend's game machine notifies the friend (step S306). It is notified to the friend that the player has started the unlock challenge using a push notification or an in-game mail function. Upon receiving the notification, the friend starts support in his game machine (step and 307).

  When the support is successful, the server is notified that the support is successful (step S308), the server receives a notification of the support success (step S309), and calculates a support point to be given to the friend (step S310). The provided support points are notified to the friend's game machine and added (step S311). In this embodiment, the support points to be given are calculated by the server and the support points are managed by the game machine. However, the support points may be managed by the server. In this case, you may obtain | require the support point provided with a game machine.

  On the other hand, when the player plays the game and satisfies the clear condition, the server is notified that the clear condition is satisfied (steps S312 and S313), and an unlock point to be given to the player is calculated (step S314). The unlock points to be given are notified to the game machine of the player and added (step S315). In the process of calculating the unlock point, since the support success notification is received from the friend, the unlock point that is 10% higher than usual is given. In this embodiment, the unlock point is calculated by the server, but may be performed by a game machine. In this case, a notification of successful support is also sent to the player's game machine, and the player's game machine performs 10% up processing. Moreover, you may manage an unlock point with a server.

  As described above, according to the present embodiment, an unlock challenge is started with respect to a music in a locked state, the music is played, and the unlock point is set when the play result satisfies a predetermined clear condition. When the total number of unlock points acquired and reached the standard, the player can set the state of the song to the release state, so that the player can set the release state of the song at his own timing.

  According to the present embodiment, the unlock challenge can be activated when the unlock challenge gauge accumulated by playing the music is accumulated more than a certain value, and consumes a ticket to play the music, By making the ticket available by charging, the charging player can obtain music more advantageously than the non-charging player.

  In the above description, the unlock challenge process is performed by the server. However, information necessary for the game machine may be managed, and all processes (including notifications to friends) may be performed by the game machine side. However, the unlock challenge process may be distributed to the server and the game machine. For example, the state of music is managed by a game machine, and processing closely related to charging such as ticket management is performed by a server. In the present embodiment, the game data of music is described as an example, but the present invention can be similarly applied to other digital data used in the game.

[Third Embodiment]
In a conventional rhythm action game, a mechanism for sharing music obtained by each player has not been provided.

  Therefore, in the present embodiment, a mechanism for sharing music ("unbanned") that he has with other players and a mechanism for providing an incentive to share music will be described.

<Share song>
FIG. 20 is an overall configuration diagram showing an overall configuration of the game system in the present embodiment.

  Each game machine 3, 3A, 3B is connected to the server 7 via a network. The game machines 3A and 3B are game machines owned by friends. The server 7 manages information of each player including friend information, share song information, and login date / time information.

  The friend information is information of a player registered as a friend by the player. In order to register a player as a friend, identification information (for example, ID123456) of the player to be registered as a friend is notified to the server 7, and each other is registered as a friend when authentication is obtained from the opponent player. As an example of a method for searching for a friend, the server 7 determines a musical preference of the user from a player who is geographically close based on the player's position information or a play history such as the number of songs played and the number of times played. There is a method to recommend a player as a friend candidate. The player notifies the server 7 that the recommended friend candidate has been registered as a friend, and registers each other as a friend when authentication is obtained from the opponent friend candidate player.

  The shared song information is information on a song registered by the player as a shared song. The player registers the music to be shared as a shared song from the banned music possessed by the player in the server 7. When registering a share song in the server 7, the identification information of the song to be registered as a share song, the high score (rank) when the share song is played, and the difficulty level (standard, hardware, master) when the share song is played are stored. Information is transmitted to the server 7.

  The login date and time is the date and time when the player starts the game machine 3 and accesses the server 7. When the player activates the game machine 3 and operates the game, the server 7 is automatically accessed and the login date and time is recorded.

  When a player desires to play a shared song of another player, the game machine 3 requests a shared song list from the server 7. When the server 7 receives the request, it searches for the friend of the player who requested the shared song list, and among the searched friends, the share song registered by the friend whose login date and time is within a predetermined time (for example, within 12 hours) is shared song. List it. Then, the server 7 returns a shared song list to the game machine 3. The player selects a shared song to be played from the shared song list and plays it on the game machine 3. The following describes the flow when playing a share song.

  FIG. 21 is a flowchart showing a flow in which a player plays a share song.

  When the player plays a friend's shared song, the game machine 3 acquires a shared song list describing a list of the friend's shared songs from the server 7 (step S41), and displays the shared song list on the game screen (step S41). Step S42). FIG. 22 shows an example in which a shared song is displayed on the game screen. In the example shown in the figure, a shared song jacket 61 is displayed, and a rank 62 when the player who provides the shared song over the jacket 61 plays the shared song is displayed. A frame 63 is displayed around the jacket 61. The color of the frame 63 is changed according to the difficulty level played by the player who provides the share song. By displaying the rank, score, difficulty level, etc. of the player who provides the shared song, it is possible to satisfy the desire to show off his skill to his friends.

  When the player selects a share song to be played (step S43), it is determined whether or not game data of the selected share song exists in the game machine 3 (step S44). If no game data exists (step S44). NO), the game data of the share song is downloaded from the server 7 (step S45).

  When the game data is downloaded to the game machine 3, game play is started (step S46). The share song selected by the player is usually not a song that has been banned by the player. Therefore, after the game machine 3 obtains permission to play the share song from the server 7, the game machine 3 starts playing the game. Alternatively, when the game machine 3 receives the shared song list from the server 7, the game machine 3 may start playing the game on the assumption that permission to play the music described in the shared song list is obtained.

  In order to play a shared song, points called link energy are consumed instead of tickets. Link energy can be obtained through login bonuses, mission clears, billing, etc., when other players play their share songs. By increasing the link energy required to play a shared song according to the number of times each shared song is played, it is possible to expect the player to play shared songs of various friends.

  As described above, according to the present embodiment, the player registers a shared song that can be played by a friend from the music pieces held by the player in the server 7, and the player who wants to play the shared song requests the server. You can share a song between friends by acquiring a list of the shared songs of the friend and obtaining the game data of the shared song selected by the player from the shared song list and permission to play the shared song from the server. It becomes.

  In this embodiment, the share song is registered in the server 7 and the share song list and play permission are acquired from the server 7. However, the server process described above is a friend game that provides a share song. It may be performed by the machine itself, and share song information transmission and play permission may be given. In the present embodiment, the game data of music is described as an example, but the present invention can be similarly applied to other digital data used in the game.

[Fourth Embodiment]
In social games in which a player is related to another player via a network, a limited-time event is often held repeatedly. The player can obtain items used in the game by participating in the event. By holding an attractive event, it will be an opportunity to continue playing the game.

  In the present embodiment, a mechanism is introduced in which players actively participate in the event by shifting the time for distributing the reward according to the ranking of the result of the event.

  First, event participation will be described. As an event, for example, a player competes for a score of a designated music piece. In event A, the score of song A competes between players, and in event B, the score of song B competes between players. When the player participates in event A, the game machine notifies the server that he / she will participate in event A, and downloads music A used in event A. If the game machine already holds music A, there is no need to download it again. The server manages the players who participated in the event. For example, when the server receives a notification to participate in event A from the game machine, the player identification information is written in the event participant list held by the server. The server may manage the identification information of the game machine that has transmitted the notification.

  A player who participates in the event consumes a ticket (for example, two) and plays the music A, and the game machine transmits a play result to the server. When the player's ticket is managed on the server side, the game machine notifies the server that the song A will be played, and the server reduces the number (for example, two) of the corresponding player's ticket and plays the song A. The game machine is notified that permission is granted. When the game machine receives a notification from the server, the game machine starts to play the music piece A. When the play of the music piece A is finished and the play result of the music piece A is obtained, the game machine transmits the play result such as the score together with the identification information of the player and the game machine to the server. The server records the received play result in association with the player described in the event participant list.

  When the period of event A ends, the server arranges the play results of each player who participated in event A in order of results, and determines the ranking of the players. Then, rewards are distributed by shifting the distribution period in order from the player with the highest play result. The reward to be distributed is digital data such as tickets and music (game data) that can be used in the game. The reward contents may be different depending on the rank, or the same. In the present embodiment, the music B used at the event B to be held next is distributed as a reward.

  Next, the reward distribution period will be described. FIG. 23 is a diagram for explaining the timing of distributing event rewards. In the figure, the time when the reward for event A is distributed after the end of event A is shown. As shown in FIG. 23, after the end of the event A, rewards are first distributed to the top players (for example, 1st to 100th) of the event A, and then the middle player of the event B (for example, 101st to 500th) ) To distribute rewards. Finally, rewards are distributed to the remaining lower players who participated in the event (for example, 501st or lower). As a result, a player with a higher grade can obtain a reward earlier than a player with a lower grade, and thus receives the benefit of the reward earlier.

  When the same music is distributed as a reward regardless of the rank, the state of the music is distributed as “unlocked” to each player as a process of distributing the reward. For a player who already owns the song as “locked”, the “locked” is changed to “unlocked”. When managing the player's music state on the server, the player's music state in the server is changed. When managing the state of a music piece with a game machine, the music information received as a reward from the server is received and stored in the game machine, or the music state is changed.

  In this embodiment, since the reward is the music B used in the next event B, the player who received the music B earlier can play the music B earlier and can practice before the event B starts. This is advantageous because the period becomes longer. In the example of FIG. 23, the music B as a reward is given to the upper and middle players of the event A before the start of the event B, and the music B is given to the lower players after the start of the event B. The upper and middle players who participated in event A have received the reward before the start of event B, so when event B starts, they hold song B used in event B. Since the reward is received after starting, the music B is not held when the event B starts.

  Here, an example of making a difference in tickets consumed when participating in the event B will be described. Since it is necessary to play the music B in order to participate in the event B, a difference is made in the tickets consumed when the music B is played depending on whether or not the music B is held. Players who receive song B as a reward for event A have fewer ticket numbers than lower players or players who participated from event B without participating in event A (players who downloaded song B to participate in event B) For example, the music B can be played with one). When a lower player participates in event B, it is necessary to consume more tickets (for example, two) than the upper and middle players of event A and participate in the event until music B is acquired as a reward for event A. There is. After receiving the music B as the reward, the lower player can participate in the event with a small number of tickets (for example, one). For lower players who have consumed a lot of tickets in order to participate in event B during the period until song B is given as a reward, the player plays before acquiring the reward song B according to the result at the end of event B. A part of the ticket used for the song B may be returned, or may be returned at another point instead of the ticket.

  In addition, you may vary the reward content of an event according to a ranking. For example, the upper player of the event may be given a predetermined song in the “unlocked” state, may be given to the middle and lower players as “locked”, or the upper player may play the predetermined song to the end. It may be given in a state where it can be played, and may be given to the middle and lower players in a state where only halfway (50% of all songs) can be played (restricted songs). A player who has been given a song in the “locked state” cannot complete the “unlocked” state in which the song can be freely played unless the unlock challenge described above is successful. The period for practicing is shortened. In the case where the reward is a restricted music, the assigned player may clear a predetermined task or increase the range of music that can be played in stages as the period elapses. Since this player needs time or effort to play to the end of the music, the period for practicing before the next event is shortened.

  As described above, according to the present embodiment, the player who receives the reward early by shifting the distribution time of the reward (song B) of event A used in the next event B according to the play result is next time. Since it becomes advantageous in the event B, it can be expected that the player actively participates in the event.

  In the above, rewards are distributed early to the player with the highest grade, but the reward may be distributed in order from the player with the lowest grade. In addition, although the music has been described as an example of the reward for the event, the reward to be distributed may be other digital data that is advantageous for the player who participates in the next event.

[Fifth Embodiment]
5th Embodiment demonstrates the Example which cooperates or fights with a friend.

<Raid Boss>
A raid boss is a kind of boss that is encountered while the game is in progress, and can give damage according to the play result (music score) of the game. A raid boss event can ask friends for help. Friends who are requested to cooperate can consume tickets and participate in raid boss events. In order to request cooperation from friends, Link Energy is required.

  In the raid boss event, the raid boss's health value is displayed on the game screen, and the raid boss's health value is decreased and reflected in real time each time a score is entered during game play. In addition, the effect of the entire screen is changed according to the physical strength value of the raid boss. For example, the moving speed of the background of the game is changed according to the strength value of the raid boss, or the color of the entire game screen is changed. In addition, the change in the production of the entire game screen is the same depending on the point difference with the opponent, even when playing against other players via the network, or against ghost data when you give a high score. You may apply as follows.

  When a raid boss event occurs, the rate of damage dealt by the player consuming more tickets increases. More specifically, when 5 tickets are consumed instead of normally 3 tickets, the damage to the raid boss is 1.5 times the normal.

<Arcade housing>
The game program may be operated in an arcade case installed in a game center or the like. When the player plays in the arcade case, by logging into the server through the arcade case, an item such as a ticket acquired by the game machine held by the player can be used for playing in the arcade case. When an unlock challenge is started or a raid boss is found when playing in an arcade case, a notification is sent to registered friends. Further, when the player has set his / her store in the server and there is a play history within 30 minutes in the store, a notification is transmitted to the registered friend. In addition, based on the position information of the game machine, a notification is transmitted to a friend near the store where the game was played. Furthermore, a special play ticket that can be used in the arcade housing may be distributed when a specific condition is satisfied with the game machine held by the player.

DESCRIPTION OF SYMBOLS 1 ... Game program 11 ... Operation input part 12 ... Predictive image control part 13 ... Line control part 14 ... Timing determination part 15 ... Score processing part 16 ... Image output part 17 ... Background processing part 18 ... Audio | voice output part 19 ... Game data accumulation | storage Part 3, 3A, 3B ... Game machine 51A-51D ... Line 52, 52A-52C ... Predictive image 53, 53A, 53B ... Virtual intersection 54 ... Icon 55 ... Appropriate range 56 ... Vanishing point 57 ... Expected collision position 61 ... Light Object 62 ... hole 63 ... jacket 64 ... rank 65 ... frame 7 ... server

Claims (5)

Computer
Operation input means for inputting operation information of the player;
A plurality of objects to appear on the game screen, each the plurality of objects in proximity to move at different trajectories Rutotomoni, object control means for presenting the operation content to the player,
An operation determination unit that receives the operation information from the operation input unit, and determines whether the operation information satisfies an evaluation criterion regarding a position and an evaluation criterion regarding timing of the plurality of objects according to the operation content ;
A game program that functions as
The operation determination means determines whether or not an evaluation criterion related to the position is satisfied at the start of the hold operation when the operation content is a hold operation that continues the touch operation for a predetermined period. A game program characterized by excluding evaluation criteria . The game program according to claim 1, wherein the operation determination unit determines whether or not the evaluation criterion regarding the position is satisfied even at the end of the hold operation. Computer
Operation input means for inputting operation information of the player;
A plurality of objects to appear on the game screen, each the plurality of objects in proximity to move at different trajectories Rutotomoni, object control means for presenting the operation content to the player,
An operation determination unit that receives the operation information from the operation input unit, and determines whether the operation information satisfies an evaluation criterion regarding a position and an evaluation criterion regarding timing of the plurality of objects according to the operation content ;
A game program that functions as
In the case of a flick operation in which the operation content is a flick operation in which a touch position is moved and a direction is input after the touch operation, after determining whether or not the evaluation criterion related to the position is satisfied at the start of the flick operation, A game program characterized by changing an evaluation standard concerning the position . Evaluation criteria for the position, the shape of the range to evaluate the position, size, according to any one of claims 1 to 3, characterized in that it comprises at least one of a position in the game screen Game program. A program storage unit storing the game program according to any one of claims 1 to 4 ,
A computer for executing the game program stored in the program storage unit;
A game device comprising:

Images