Patent Application
20170092254
The present invention relates to rhythm-action games, and, more specifically, video games which simulate the experience of playing in a band.
Music making is often a collaborative effort among many musicians who interact with each other. One form of musical interaction may be provided by a video game genre known as “rhythm-action,” which involves a player performing phrases from a pre-recorded musical composition using a video game's input device to simulate a musical performance. If the player performs a sufficient percentage of the notes or cues displayed, he may score well and win the game. If the player fails to perform a sufficient percentage, he may score poorly and lose the game. Two or more players may compete against each other, such as by each one attempting to play back different, parallel musical phrases from the same song simultaneously, by playing alternating musical phrases from a song, or by playing similar phrases simultaneously. The player who plays the highest percentage of notes correctly may achieve the highest score and win. Two or more players may also play with each other cooperatively. In this mode, players may work together to play a song, such as by playing different parts of a song, either on similar or dissimilar instruments. One example of a rhythm-action game is the ROCK BAND™ series of games developed by Harmonix Music Systems, Inc. Another example of a rhythm-action game is the KARAOKE REVOLUTION series of games published by Konami.
Past rhythm-action games that have been released for home consoles have utilized a variety of controller types. For example, GUITAR HERO II, published by Red Octane, could be played with a simulated guitar controller or with a standard game console controller.
A rhythm-action game may require a number of inputs to be manipulated by a player simultaneously and in succession. Past rhythm-action games have utilized lanes divided into sub-lanes to indicate actions. In these games, a lane is divided into a number of distinct sub-lanes, with each sub-lane corresponding to a different input element. For example, a lane for a player might be divided into five sub-lanes, with each sub-lane containing cues corresponding to a different one of five fret buttons on a simulated guitar. As cues appear in each of the sub-lanes, a player must press the appropriate corresponding fret button.
In some cases, the sub-lanes are laid out to correspond to a linear set of input elements. For example, a lane may be divided into five sub-lanes, each sub-lane containing red cues, green cues, yellow cues, blue cues and orange cues, respectively, to correspond to a guitar having a linear arrangement of a red button, green button, yellow button, blue button and orange button. Displaying cues may be more challenging in instances where input elements are not linearly arranged. For example, in the DRUMMANIA series of games published by Konami, players provide input via a number of drum pads and a foot pedal. Foot pedal actions were signified by a sub-lane containing cues shaped like feet.
In some single-player rhythm-action games, such as the GUITAR HERO series, it is possible for a player to “fail” midway through a song. That is, if the player's performance falls below a given threshold, the player may be prevented from completing the song. Such a failure may be accompanied by sounds of the music stopping, the crowd booing, and images of the band stopping the performance. This possibility of failure may enhance a game by providing more serious consequences for poor performance than simply a lower score: if a player wants to complete a song to the end, the player must satisfy a minimum standard of performance. Adapting this failure mechanic to a multiplayer game presents a challenge, as the enhanced incentives for good performance may be desired, but it may be undesirable for one player to remain inactive for long periods of time while others are playing a song.
The techniques described herein are directed at a dynamic fill feature for a rhythm-action game. In some embodiments, this dynamic fill feature can be implemented using a simulated drum controller. It is an object of the presently disclosed fill feature to emulate the fill improvisation exhibited by real drummers. The presently disclosed feature can also present non-drummers with a skill- and style-appropriate set of fills to perform at appropriate sections of songs. Furthermore, the presently disclosed fill feature can vary the play experience of a player even when playing the same song multiple times.
In one aspect, the present disclosure is directed at a computer system for varying a play experience of a player of a rhythm-action game. The system can comprise a game console having a memory that stores a musical track, the musical track having at least one variable fill section. The memory can also store a database having a plurality of fills for the at least one variable fill section, each fill being associated with a different set of cues, wherein each cue directs the player to provide an input. The system can also comprise at least one processor configured to, for each variable fill section of the at least one variable fill section in the musical track: (i) select, for a playthrough of the musical track a fill from the plurality of fills in the database, (ii) transmit display data to a display, the display data comprising at least part of the set of cues associated with the selected fill, and (iii) for each displayed cue: (a) receive player input, (b) evaluate whether the received player input corresponds to the input directed by the displayed cue, and (c) alter an aspect of gameplay based on the evaluation.
In some embodiments, the processor can be configured to mute or distort the soundtrack associated with the corresponding selected fill when the user input does not correspond to the displayed set of cues. For example, each fill of the plurality of fills in the database can be further associated with a different soundtrack. The at least one processor can be further configured to alter an aspect of gameplay based on the evaluation by: (i) when the received user input corresponds to the input directed by the displayed cue, playing at least a portion of the soundtrack associated with the fill that is associated with the set of cues of which the displayed cue is a part, and (ii) when the received user input does not correspond to the input directed by the displayed cue, playing at least one of a muffled, muted, or distorted version of the soundtrack associated with the fill that is associated with the set of cues of which the displayed cue is a part.
In some embodiments, the user input can be received via a simulated drum controller, and the plurality of fills can comprise a plurality of drum fills. For example, each cue can direct the player to provide an input corresponding to a drum pad of a plurality of drum pads on a drum controller. The at least one processor can be further configured to receive player input by receiving input from the drum controller indicating which drum pad on the drum controller has been activated. The at least one processor can be further configured to evaluate whether the received player input corresponds to the input directed by the displayed cue by evaluating whether the activated drum pad corresponds to the drum pad directed by the displayed cue.
In some embodiments, each soundtrack associated with each fill of the plurality of fills can be played according to a plurality of synthesizer settings. The at least one processor can be further configured to play at least a portion of the soundtrack when the received user input corresponds to the input directed by the displayed cue by: selecting a synthesizer setting, and playing the at least a portion of the soundtrack using the selected synthesizer setting.
In some embodiments, the selection of the synthesizer setting is based at least in part on at least one characterizing parameter associated with at least one of the musical track, a variable fill section of the musical track, and a fill section selected by the processor.
In some embodiments, the playthrough is a first playthrough, and the at least one processor can be further configured to: for each variable fill section of the at least one variable fill section in the musical track: select, for a second playthrough of the musical track a fill from the plurality of fills in the database, wherein, for at least some of the at least one variable fill section in the musical track, the fill selected by processor for the first playthrough is different from the fill selected by the processor for the second playthrough.
In some embodiments, the database can store, for each fill of the plurality of fills, a set of characterizing parameters, wherein the processor is configured to select the fill from the plurality of fills based on the sets of characterizing parameters.
In some embodiments, the set of characterizing parameters can include at least one of a fill length, a style, a tempo, a beat type, and a difficulty level.
In some embodiments, for each variable fill section of the at least one variable fill section in the musical track, the selection of the fill from the plurality of fills is further based on one or more characterizing parameters associated with the musical track.
In some embodiments, for a particular variable fill section of the at least one variable fill section in the musical track, the selection of the fill from the plurality of fills is further based on one or more characterizing parameters associated with the particular variable fill section.
In some embodiments, the processor can be configured to select the fill from the plurality of fills for each section in the musical track that can be varied before beginning to play the musical track.
In some embodiments, the processor can be configured to select the fill from the plurality of fills for each section in the musical track that can be varied while playing the musical track.
In another aspect, the present disclosure is directed at a computerized method for varying a play experience of a player of a rhythm-action game. The method can be executed by a computing device comprising at least one processor and at least one memory in communication with the at least one processor. The computerized method can comprise storing in the at least one memory a musical track, the musical track having at least one variable fill section. The method can also comprise storing, in the memory, a database having a plurality of fills for the at least one variable fill section, each fill being associated with a different set of cues, wherein each cue directs the player to provide an input. The method can also comprise, for each variable fill section of the at least one variable fill section in the musical track, selecting, for a playthrough of the musical track, by the at least one processor, a fill from the plurality of fills in the database. The method can also comprise transmitting display data to a display in communication with the at least one processor, the display data comprising at least part of the set of cues associated with the set of cues associated with the selected fill. The method can also comprise, for each displayed cue, receiving user input, evaluating whether the received player input corresponds to the input directed by the displayed cue, and altering an aspect of gameplay based on the evaluation.
In some embodiments, the method can comprise muting or distorting the soundtrack associated with the corresponding selected fill when the user input does not correspond to the displayed set of cues. For example, each fill of the plurality of fills in the database can be further associated with a different soundtrack. Altering an aspect of gameplay based on the evaluation can comprise: when the received user input corresponds to the input directed by the displayed cue, playing at least a portion of the soundtrack associated with the fill that is associated with the set of cues of which the displayed cue is a part, and when the received user input does not correspond to the input directed by the displayed cue, playing at least one of a muffled, muted, or distorted version of the soundtrack associated with the fill that is associated with the set of cues of which the displayed cue is a part.
In some embodiments, the user input can be received via a simulated drum controller, and the plurality of fills can comprise a plurality of drum fills. For example, each cue can direct the player to provide an input corresponding to a drum pad of a plurality of drum pads on a drum controller. Receiving player input can comprise receiving input from the drum controller indicating which drum pad on the drum controller has been activated; and evaluating whether the received player input corresponds to the input directed by the displayed cue comprises evaluating whether the activated drum pad corresponds to the drum pad directed by the displayed cue.
In some embodiments, each soundtrack associated with each fill of the plurality of fills can be played according to a plurality of synthesizer settings; and playing at least a portion of the soundtrack when the received user input corresponds to the input directed by the displayed cue comprises: selecting a synthesizer setting, and playing the at least a portion of the soundtrack using the selected synthesizer setting.
In some embodiments, the selection of the synthesizer setting can be based at least in part on at least one characterizing parameter associated with at least one of the musical track, a variable fill section of the musical track, and a fill section selected by the at least one processor.
In some embodiments, the playthrough is a first playthrough, and the method can further comprise, for each variable fill section of the at least one variable fill section in the musical track: selecting, for a second playthrough of the musical track, by the at least one processor, a fill from the plurality of fills in the database, wherein, for at least some of the at least one variable fill section in the musical track, the fill selected by the at least one processor for the first playthrough is different from the fill selected by the at least one processor for the second playthrough.
In some embodiments, the method can comprise storing, for each fill of the plurality of fills, a set of characterizing parameters, wherein the selection of the fill from the plurality of fills is based on the sets of characterizing parameters.
In some embodiments, the set of characterizing parameters can include at least one of a fill length, a style, a tempo, a beat type, and a difficulty level.
In some embodiments, for each variable fill section of the at least one variable fill section in the musical track, the selection of the fill from the plurality of fills is further based on one or more characterizing parameters associated with the musical track.
In some embodiments, for a particular variable fill section of the at least one variable fill section in the musical track, the selection of the fill from the plurality of fills is further based on one or more characterizing parameters associated with the particular variable fill section.
In some embodiments, the selection of the fill from the plurality of fills for each section in the musical track that can be varied can occur before beginning to play the musical track.
In some embodiments, the selection of the fill from the plurality of fills for each section in a musical track that can be varied can occur while playing the musical track.
In another aspect, the present disclosure is directed at non-transitory computer readable media storing machine-readable instructions that are configured to, when executed by at least one processor, cause the at least one processor to: access from at least one memory: a musical track, the musical track having at least one variable fill section, and a database having a plurality of fills for the at least one variable fill section, each fill being associated with a different set of cues, wherein each cue directs the player to provide an input; and for each variable fill section of the at least one variable fill section in the musical track: (i) select, for a playthrough of the musical track, a fill from the plurality of fills in the database; (ii) transmit display data to a display, the display data comprising at least part of the set of cues associated with the selected fill; and (iii) for each displayed cue: (a) receive player input; (b) evaluate whether the received player input corresponds to the input directed by the displayed cue; and (c) alter an aspect of gameplay based on the evaluation.
For a more complete understanding of the present disclosure, reference is now made to the following descriptions taken in conjunction with the accompanying drawing, in which:
Referring now to
Still referring to
As the gems move along a respective lane, musical data represented by the gems may be substantially simultaneously played as audible music. In some embodiments, audible music represented by a gem is only played (or only played at full or original fidelity) if a player successfully “performs the musical content” by capturing or properly executing the gem. In some embodiments, a musical tone is played to indicate successful execution of a musical event by a player. In other embodiments, a stream of audio is played to indicate successful execution of a musical event by a player. In certain embodiments, successfully performing the musical content triggers or controls the animations of avatars.
In some embodiments, the audible music, tone, or stream of audio represented by a cue is modified, distorted, or otherwise manipulated in response to the player's proficiency in executing cues associated with a lane. For example, various digital filters can operate on the audible music, tone, or stream of audio prior to being played by the game player. Various parameters of the filters can be dynamically and automatically modified in response to the player capturing cues associated with a lane, allowing the audible music to be degraded if the player performs poorly or enhancing the audible music, tone, or stream of audio if the player performs well. For example, if a player fails to execute a game event, the audible music, tone, or stream of audio represented by the failed event may be muted, played at less than full volume, or filtered to alter its sound.
In some embodiments, a “wrong note” sound may be substituted for the music represented by the failed event. Conversely, if a player successfully executes a game event, the audible music, tone, or stream of audio may be played normally. In some embodiments, if the player successfully executes several, successive game events, the audible music, tone, or stream of audio associated with those events may be enhanced, for example, by adding an echo or “reverb” to the audible music. The filters can be implemented as analog or digital filters in hardware, software, or any combination thereof. Further, application of the filter to the audible music output, which in many embodiments corresponds to musical events represented by cues, can be done dynamically, that is, during play. Alternatively, the musical content may be processed before game play begins. In these embodiments, one or more files representing modified audible output may be created and musical events to output may be selected from an appropriate file responsive to the player's performance.
In addition to modification of the audio aspects of game events based on the player's performance, the visual appearance of those events may also be modified based on the player's proficiency with the game. For example, failure to execute a game event properly may cause game interface elements to appear more dimly. Alternatively, successfully executing game events may cause game interface elements to glow more brightly. Similarly, the player's failure to execute game events may cause their associated avatar to appear embarrassed or dejected, while successful performance of game events may cause their associated avatar to appear happy and confident. In other embodiments, successfully executing cues associated with a lane causes the avatar associated with that lane to appear to play an instrument. For example, the drummer avatar will appear to strike the correct drum for producing the audible music. Successful execution of a number of successive cues may cause the corresponding avatar to execute a “flourish,” such as kicking their leg, pumping their fist, performing a guitar “windmill,” spinning around, winking at the “crowd,” or throwing drum sticks.
Player interaction with a cue may be required in a number of different ways. In general, the player is required to provide input when a cue passes under or over a respective one of a set of target markers 140, 141 disposed on the lane. Player interaction with a cue may comprise any manipulation of any simulated instrument and/or game controller.
As shown in
In some embodiments (not shown), instead of a lane extending from a player's avatar, a three-dimensional “tunnel” comprising a number of lanes extends from a player's avatar. The tunnel may have any number of lanes and, therefore, may be triangular, square, pentagonal, sextagonal, septagonal, octagonal, nonagonal, or any other closed shape. In still other embodiments, the lanes do not form a closed shape. The sides may form a road, trough, or some other complex shape that does not have its ends connected. For ease of reference throughout this document, the display element comprising the musical cues for a player is referred to as a “lane.”
Referring back to
Still referring to
Individual player performance levels may be indicated on the meter in any manner. In the embodiment shown in
Still referring to
In some embodiments, if a given amount of bonuses are accumulated, a player may activate the bonus to trigger an in-game effect. An in-game effect may comprise activation of an improvisational of “fill” section indicated to a drummer or any other instrumentalist. An in-game effect may also comprise a graphical display change including, without limitation, an increase or change in crowd animation, avatar animation, performance of a special trick by the avatar, lighting change, setting change, or change to the display of the lane of the player. An in-game effect may also comprise an aural effect, such as a guitar modulation, including feedback, distortion, screech, flange, wah-wah, echo, or reverb, a crowd cheer, an increase in volume, and/or an explosion or other aural signifier that the bonus has been activated. An in-game effect may also comprise a score effect, such as a score multiplier or bonus score addition. In some embodiments, the in-game effect may last a predetermined amount of time for a given bonus activation.
In some embodiments, bonuses may be accumulated and/or deployed in a continuous manner. In other embodiments, bonuses may be accumulated and/or deployed in a discrete manner. For example, instead of the continuous bar shown in
In some embodiments, bonus accumulation and deployment may be different for each simulated instrument. For example, in one embodiment only the bass player may accumulate bonuses, while only the lead guitarist can deploy the bonuses.
In some embodiments, a separate performance meter (not shown) may be displayed under the lane of each player. This separate performance meter may comprise a simplified indication of how well the player is doing. In one embodiment, the separate performance meter may comprise an icon which indicates whether a player is doing great, well, or poorly. For example, the icon for “great” may comprise a hand showing devil horns, “good” may be a thumbs up, and “poor” may be a thumbs down. In other embodiments, a player's lane may flash or change color to indicate good or poor performance.
Each player may use a gaming platform in order to participate in the game. In one embodiment, the gaming platform is a dedicated game console, such as: PLAYSTATION®3, PLAYSTATION®4, or PLAYSTATION®VITA manufactured by Sony Computer Entertainment, Inc.; WII™, WIT U™, NINTENDO 2DS™, or NINTENDO 3DS™ manufactured by Nintendo Co., Ltd.; or XBOX®, XBOX 360®, or XBOX ONE™ manufactured by Microsoft Corp. In other embodiments, the gaming platform comprises a personal computer, personal digital assistant, or cellular telephone.
Referring now to
Still referring to
In some embodiments, the drum pads 202 may be struck with drum sticks used with ordinary drums. In other embodiments, the drum pads 202 may be struck with customized drum sticks designed specially to work with the set 200.
During a game session, each drum pad may be configured to simulate an individual percussion instrument. For example, a user striking a drum pad 202a may cause a snare drum sound to be played, while the user striking drum pad 202b may cause a tom-tom sound to be player, while the user striking drum pad 202d may cause a crash cymbal sound to be played. In some embodiments, the played sound may reflect any of the properties of the user's strike of the drum pad. For example, a game may play a louder snare drum sound in response to a user hitting a drum pad harder. Or for example, a game may alter the sound of a ride cymbal played depending on how close to the center or the rim of the drum pad the user strikes. In some embodiments, the sound played in response to a drum pad strike may be chosen from a prerecorded library of percussion sounds. In other embodiments, in response to a user successfully striking a pad 202 corresponding to an on screen gem, a portion of a pre-recorded drum track corresponding to the current song may be played.
The drum set 200 may also comprise a number of foot pedals 230. In some embodiments, a single foot pedal may be provided. In other embodiments, any number of foot pedals may be provided, including two (such as one to simulate a bass drum and one to simulate a hi-hat), three or four. During a game, the foot pedal may be used to create any percussion sound.
In some embodiments, a drum set 200 may comprise a stand 220 which allows a user to sit or stand while playing the drum pads, and still have access to the foot pedal 230. In one embodiment, the stand may allow a user to adjust the height of the drum pads as a whole. In another embodiment, the stand 220 may allow a user to adjust the height of the drum pads individually. In still another embodiment, the stand 220 may allow a user to adjust the position of one or more pads, such as by swiveling one or more pads closer to the player. In some embodiments, the stand 220 may allow a user to adjust the placement of the foot pedal, including moving the foot pedal forwards, backwards, and side-to-side. In one embodiment, the foot pedal and/or drum pads 202 may be detachable from the stand. In this embodiment, the drum pads 202 may be placed on a table top or held on a player's lap.
In some embodiments, a simulated drum set 200 may include a controller 210. The controller may comprise inputs for configuring the simulated drum set, including, for example, sensitivity, left/right handed switching, and turning the drum set on and off. The controller 210 may also comprise any other game inputs. In some embodiments, the controller 210 may comprise some or all of the functionality of a standard game controller for any of the game systems described herein. In some embodiments, the controller may be used for navigating menus, or inputting configuration or other game data.
A simulated drum set 200 may also comprise any other elements incorporated in game controllers. In some embodiments, a drum set 200 may comprise a speaker which may provide individual feedback to the player about the player's performance. In large multiplayer games, this individual speaker may assist a player in assessing their performance and hearing whether or not they missed a note. In other embodiments, a drum set 200 may comprise a microphone which may be used to chat with other players, provide vocal input, or provide hand claps, microphone taps, or other aural input. In other embodiments, such an individual speaker may be included in any other simulated instrument, including a guitar and/or microphone.
In some embodiments, the drum pads 202 and/or foot pedal 230 may be color coded. For example, drum pad 202a may be green, pad 202b may be red, pad 202c may be yellow, pad 202d may be blue, and the foot pedal 230 may be orange. Color coding may be indicated in any manner, including the color of the pads 202, the color of the rims surround the pads 202, the color of an icon or design on the pads 202 or rims, or one or more labels on the pads, rims, and/or stand. The color code of the foot pedal may also be indicated in any manner, including the color of the foot pedal, the color of a design or icon on the foot pedal, or one or more labels on the foot pedal or stand.
In addition to being used during gameplay, in some embodiments the simulated drum set may be used to navigate one or more menus or produce other game input. For example, a game may display a menu to users in which different menu options are color coded. A user may then strike the drum pad or stomp the foot pedal corresponding to the color of a menu option to activate that menu option. Or for example, a series of menus may be provided in which a user may use two drums 202b 202c to cycle up and down among choices within a menu, and use two drums 202a, 202d to move forward and backward between different menus. In some embodiments, one or more drums may be assigned a designated function throughout a game interface. For example, during the course of navigating a series of menus, startup, and/or configuration screens, a player may always be able to use the foot pedal to return to a main screen. Or for example, the player may always be able to use the leftmost drum 202d to alter a currently selected option. In some embodiments, navigating menus and configuration screens may be done via a combination of the drum pads, foot pedal, and controller.
Referring now to
In some embodiments, lines or other demarcations may be displayed in between sub-lanes. For example, referring back to
In some embodiments, each sub-lane may contain cues corresponding to a different drum pad. For example, a lane may be divided into four sub-lanes, each sub-lane corresponding to one of four drum pads. Referring ahead to
In some embodiments, cues in each sub-lane may always correspond to a given percussion sound during a song. For example, cues in sub-lane 551 may correspond to a snare drum, while cues in sub-lane 552, 553 may correspond to tom-tom sounds while cues in sub-lane 554 may correspond to crash cymbal sounds. In other embodiments, cues in a single sub-lane may correspond to different percussion sounds over the course of a song. For example, during the course of a song, gems in sub-lane 554 may first correspond to cowbell sounds, and then correspond to a crash cymbal sound. In some embodiments, the display of cues within a sub-lane may be changed to indicate to a user that the cues represent a different percussion sound.
Referring back to
A cue may span a plurality of sub-lanes by occupying a portion of visual space corresponding to each of the plurality of sub-lanes. In some embodiments, a cue may span a plurality of sub-lanes by being displayed as covering some or all of each of the plurality of sub-lanes. For example, the cue 603 in
In some embodiments, a cue spanning a plurality of sub-lanes may have one or more cues corresponding to an individual sub-lane overlaid on the cue. For example, the cue 501 in
In some embodiments, a cue spanning a plurality of sub-lanes may comprise a different color than any of the cues corresponding to individual sub-lanes.
Further details regarding visual cues, input methods, scoring methods, and methods for varying a display based on user input for rhythm-action games can be found in application Ser. No. 12/139,819, filed Jun. 16, 2008, titled “SYSTEMS AND METHODS FOR SIMULATING A ROCK BAND EXPERIENCE.” The entire contents of that application are incorporated herein by reference.
The rhythm-action game can be set to play according to any of at least three modes: a “no-fill” mode, a “classic” fill mode, and a “pre-authored” fill mode. In the no-fill mode, the rhythm-action game can treat fill sections 706 like any other part of the song—a set of pre-authored cues can be displayed and scored, wherein the set of pre-authored cues remain the same every time musical-track 701 is played. When the drummer provides input that corresponds to the pre-authored cues, the portion of the musical track that corresponds to the set of pre-authored cues is played. When the drummer provides input that does not correspond to the pre-authored cues, the portion of the musical track that corresponds to the pre-authored cues can be muted or distorted (e.g., played at less than full volume, filtered to alter its sound, replaced with a “wrong note” sound, etc.). In the no-fill mode, the set of pre-authored cues and accompanying soundtrack does not change with each play through of musical-track 701; the player's experience will remain the same every time.
In the “classic” fill mode, the rhythm-action game can display the cues associated with the “classical” drum fill described above in relation to
In the “pre-authored” fill mode, the rhythm-action game can draw from a database 750 of pre-authored drum fills to fill each fill section 706, such that different fills are slotted into each fill section 706 every time musical-track 701 is played. Each pre-authored fill can include a different soundtrack and a different set of visual cues for directing the player to provide different input. The visual cues displayed for a fill in the pre-authored fill mode can be similar to but visually distinguishable from regular cues. For example, the fill cues can glow, be colored a different color, appear brighter, or alter other aspects of their appearance. In some embodiments, scoring will not be suspended for the pre-authored fill mode—instead, the player continues to be evaluated based on how well the player executes the visual cues provided for the selected pre-authored drum fill.
The “pre-authored” fill mode can have several advantages over the “no-fill” and the “classic” fill mode. For example, the “pre-authored” fill mode provides the player with different experiences even when the same musical-track 701 is played, and therefore facilitates greater variety and re-playability for the player. The “pre-authored” fill mode can also mitigate issues with system lag associated with the “classical” drum fill mode. In the “classical” drum fill mode, there can be a noticeable delay between the time when the player strikes an input pad and the time when the sound associated with that input pad strike is played as audible sound. This lag can be caused by delays associated with receiving, digitizing, processing the player's input, as well as in synthesizing and playing the audible sound. In the “pre-authored” fill mode, however, the system can know in advance what a correctly played drum fill should sound like, and can therefore decrease the amount of lag time between when the player strikes an input pad and the time when the sound associated with that input pad strike is played. For example, the system can load the correct audible sound associated with a certain fill, and can choose to simply mute, unmute, or distort the sound track depending on whether the player executes the fill correctly. This can mitigate issues with system lag and provides the user with a more realistic and responsive drum-playing experience.
In some embodiments, e.g., in both the “classical” drum fill mode and the “pre-authored” fill mode, the rhythm-action game can be configured to provide an improvisational fill only if the player's has accumulated a certain amount of stored bonus. A player's stored bonus can be indicated by meter 151. If, for example, the player's stored bonus is below a pre-determined threshold, such as if meter 151 is below 50% full, the rhythm-action game can be configured to display only default notes instead of fill notes, e.g., to operate as if the game is set to “no-fill” mode. If the player's stored bonus is equal to or above the pre-determined threshold (such as if meter 151 is 50% full or more), the rhythm-action game can provide either a “classical” fill or a “pre-authored” fill, depending on which mode the game is configured to implement.
In the “pre-authored” fill mode, the rhythm-action game (e.g., as implemented on game console 300) can select drum fills for each of the fill sections 706 in musical-track 701 when musical-track 701 is first loaded in preparation for play. In these embodiments, each fill section 706 will already have been assigned a pre-authored drum fill by the time the player begins to play. In other embodiments, the rhythm-action game can select drum fills for each of the fill sections 706 dynamically, e.g., as the player is playing through the musical-track 701.
Pre-authored drum fills can be stored in a drum fill database 750, and can be associated with certain characterizing parameters. For example, each drum fill can be identified by a unique identifier (column 752). Drum fill database 750 can also store an indication of each drum fill's length (column 754). While
Drum fill database 750 can also store an indication of each drum fill's style (column 756). As used herein, the term “style” can refer to the musical genre for which each drum fill is most appropriate.
Drum fill database 750 can also store an indication of each drum fill's tempo (column 758). As depicted in
Drum fill database 750 can store the “beat type” associated with each drum fill (column 760). As used herein, the term “beat type” can refer to different ways to describe the rhythm associated with a drum fill. For example, a rhythm associated with a drum fill can be characterized according to how the drum fill predominantly subdivides one note in a measure. Some drum fills can use duplets, e.g., drum fills that subdivide one note into two parts, which can result in a “straight” sounding rhythm. Some drum fills can use triplets, e.g., drum fills that subdivide one note into three parts, which can result in a faster, more complicated rhythm. If the drum fill uses triplets but omits the second note in the triplet, the result can be a rhythm that sounds like a “swing” or a “swung” beat. Other ways of characterizing the rhythm of a drum fill can also be captured by the “beat type” parameter.
Drum fill database 750 can also store the difficulty of a drum fill (column 762). Drum fills can be categorized into discrete difficulty categories, such as “Easy,” “Medium,” “Hard,” and “Expert.” Drum fills can be categorized into one or more of these difficulty categories depending on the number and rate at which notes appear, the number and type of input pads that the player is cued to play, as well as other factors. In some embodiments, drum fills can be categorized into more than one category—for instance, the set of drum fills categorized “medium” difficulty can include every drum fill categorized “easy” difficulty as well as additional drum fills; the set of drum fills categorized “hard” difficulty can include every drum fill categorized “medium” difficulty as well as additional drum fills; and the set of drum fills categorized “expert” difficulty can include every drum fill categorized “hard” difficulty as well as additional drum fills. In other embodiments, drum fills can be categorized into only one difficulty level.
At step 804, process 800 can identify metadata associated with one or more of the fill sections 706 associated with the musical track. The metadata can be embedded in the musical track or can be supplied from a separate file or data source from the data track. The metadata associated with the musical track can include metadata parameters useful for selecting pre-authored drum fills. For example, each musical track can include an indication of the song's style (e.g., Rock, Jazz, Country, or Blues), the song's tempo (e.g., Fast tempo, Medium tempo or Slow tempo), the song's beat type (e.g., triplets, swung, straight), and the song's difficulty level (e.g., Easy, Medium, Hard, Expert). In some embodiments, each musical track can have only one set of metadata parameters that remains constant for the entire track. In other embodiments, musical tracks can switch parameters partway through the song, e.g., a song that starts out as a Fast Rock song with a straight beat and a Hard difficulty can switch midway through into a Slow Blues song with a swung beat and a Medium difficulty. The metadata parameters included in the musical track can also include the number, location in time, and duration of fill sections 706.
At step 806, process 800 can select pre-authored drum fills out of drum fill database 750 to fill each fill section 706. Pre-authored drum fills can be selected according to any of the parameters discussed above in relation to
In some cases, process 800 can determine that there is no suitable drum fill that matches every criteria requested by the metadata associated with a particular fill section 706. In those cases, process 800 can select the next best drum fill according to various policies For example, certain metadata parameters (e.g., tempo) can be prioritized over other parameters (e.g., style) such that drum fills that match only preferred parameters are selected over drum fills that match only non-preferred parameters. Values within parameters can also be prioritized so that process 800 can select the next best drum fill if the ideal drum fill is not available. For example: if a “hard” difficulty drum fill that matches all other criteria is not available, process 800 can select a “medium” difficulty drum fill or an “easy” difficulty drum fill, but can be configured to prefer a “medium” difficulty drum fill if one is available. Alternatively, if a “fast” tempo drum fill that matches all other criteria is not available, process 800 can select a “medium” tempo drum fill or a “slow” tempo drum fill, but can be configured to prefer a “medium” tempo drum fill if one is available. In some embodiments, process 800 can use known optimization algorithms that assign pre-specified weights to different parameters (both across multiple types of parameters, such as style, tempo, beat type, and difficulty level, as well as across parameters within a single type of parameter, such as fast, medium or slow within the parameter type “tempo”) to determine the “best” drum fill for a particular fill section 706.
At step 808, which can be performed only if necessary, process 800 can truncate one or more drum fills to fit within a fill section 706. This can be necessary if the length of fill section 706 is slightly different from the length of available drum fills. For example, fill section 706 can last for 2 beats starting from beat 3 of a 4-beat measure, but the shortest pre-authored drum fill available from drum fill database 750 can last for one 4-beat measure. In these embodiments, process 800 can dynamically truncate a pre-authored drum fill to fit within the required length of the fill section. Continuing with the previous example, process 800 can be configured to select a pre-authored drum fill that lasts for one 4-beat measure, but use only the portion of the fill that correspond to beats 3 and 4 (i.e., the last 2 beats starting from beat 4).
At step 810, the process 800 can start playing the musical track 701. For the sections of the musical track that do not correspond to a fill section, the process 800 can display default drum cues.
At step 812, when process 800 reaches the portions of the musical track 701 that correspond to a fill section 706, process 800 can implement the pre-authored drum fill that was selected for that fill section in step 804. Specifically, process 800 can display the visual cues associated with the selected pre-authored drum fill. These visual cues associated with the selected pre-authored drum fill can appear similar to but visually distinguishable from regular cues, e.g., they can glow, exhibit a different color, appear larger or smaller, appear brighter or dimmer, etc. If the player provides the correct input at substantially the right times according to the displayed visual cues during a pre-authored drum fill, process 800 can play the relevant portions of the soundtrack associated with the selected pre-authored drum fill. If, however, the player does not provide the correct input at substantially the right times, process 800 can mute or distort (e.g., play at half-strength, muffle, or play a “wrong note” sound) the soundtrack associated with the selected pre-authored drum fill.
In some embodiments, the soundtrack associated with each drum fill can comprise data indicating the timing and type of expected input (e.g., input pads 202a, 202b, 202c, 202d, and foot pedal 230) associated with each note in the drum fill. However, the same drum fill can be synthesized into audible sound using different synthesizer settings. Synthesizer settings can include different mappings of input pads 202a, 202b, 202c, and 202d to different types of drums (e.g., snare, tom toms, high hats, bass kick), as well as different ways of synthesizing drum sounds (e.g., a high-pitched tom tom vs. a low-pitched tom tom sound, or snare drums with different types or number of snares). When playing sounds associated with the pre-authored drum fills, synthesizer settings can be varied depending (i) on the musical-track 701 (e.g., use setting 1 for musical-track 701, and setting 2 for another musical-track) or (ii) on the position the current fill section occupies within musical-track 701 (e.g., use setting 1 for the first fill section in musical-track 701, and setting 2 for a second fill section within musical-track 701). In some embodiments, drum fill database 750 can also store one or more preferred synthesizer settings for each drum fill. In these embodiments, synthesizer settings can be another criteria used to associate a drum fill with a fill section 706. For example, metadata associated with a fill section 706 can indicate which types of synthesizer settings are suitable for this fill section, and only drum fills that meet those synthesizer settings in drum fill database 750 can be selected for that fill section 706.
Successful, or partially successful completion of a selected pre-authored drum fill can lead to a bonus activation. In some embodiments, completing at least some of the indicated visual cues correctly can cause a “finale” gem to appear at the end of the selected pre-authored drum fill. Successful execution of the “finale” gem can lead to a bonus activation. Examples of bonus and accompanying in-game effects were discussed previously in relation to
The above figures and discussion has focused on an improvisational or “fill” feature implemented using a drum controller. However, other embodiments featuring improvisational or “fill” features using other types of simulated instrument controllers are also possible. For example, a simulated guitar controller could be substituted for simulated drum controller 200, and cues associated with a simulated guitar controller could be displayed in place of cues for a drum controller. Drum fill database 750 could be substituted or augmented to include “guitar fills” instead of “drum fills” to create a guitar fill database. Such a guitar fill database could also store different guitar fills having different associated soundtracks and sets of visual cues, and each guitar fill could have associated with it similar characterizing parameters to those discussed above, including length, style, tempo, beat type, and difficulty. In addition to these parameters, guitar fills can also be associated with parameters specific to guitars, such as pitch (high-pitched vs. low-pitched), distortion (e.g., wail, feedback, screeching) or guitar-specific playing techniques such as hammer-ons, pull-offs, and tapping. Selections of guitar fills to fit specific fill sections can also be based on any or all of these parameters. Synthesizer settings for synthesizing guitar sounds can also be varied depending on the musical track or current position within a musical track. For example, the rhythm-action game's synthesizer could synthesize different types of electric guitars, and/or different types of acoustic guitars.
Memory 902 can include drum fill database 750, as well as musical track data that comprises pre-authored notes and cues corresponding to a particular song (e.g., musical-track 701). Memory 902 can also include machine-readable instructions for execution on processor 904. Memory can take the form of volatile memory, such as Random Access Memory (RAM) or cache memory. Alternatively, memory can take the form of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks. In some embodiments, memory 902 can be configured to retrieve and store musical track data from portable data storage devices, including magneto-optical disks, and CD-ROM and DVD-ROM disks. In other embodiments, memory 902 can be configured to retrieve and store musical track data over a network via a network interface (not shown).
Processor 904 can take the form of a programmable microprocessor executing machine-readable instructions. Alternatively, processor 904 can be implemented at least in part by special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit) or other specialized circuit. Processor 904 can be configured to execute the steps in process 800, described above in relation to
Processor 904 can be coupled with controller interface 910, which can be any interface configured to be coupled with an external controller. As depicted in
Processor 904 can also be coupled to video rendering module 906 and sound synthesizer 908. While both modules are depicted as separate hardware modules outside of processor 904 (e.g., as stand-alone graphics cards or sound cards), other embodiments are also possible. For example, one or both modules can be implemented as specialized hardware blocks within processor 904. Alternatively, one or both modules can be implemented purely as software running within processor 904. Video rendering module 906 can be configured to generate a video display based on instructions from processor 904, while sound synthesizer 908 can be configured to generate sounds accompanying the video display. Video rendering module 906 and sound synthesizer 908 can be coupled to an audio/video device 320, which can be a TV, monitor, or other type of device capable of displaying video and accompanying audio sounds. While FIG. 9 shows two separate connections into audio/video device 320, other embodiments in which the two connections are combined into a single connection are also possible.
The above-described techniques can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The implementation can be as a computerized method or process, or a computer program product, i.e., a computer program tangibly embodied in a machine-readable storage device, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, a game console, or multiple computers or game consoles. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or game console or on multiple computers or game consoles at one site or distributed across multiple sites and interconnected by a communication network.
Method steps (such as method steps in process 900) can be performed by one or more programmable processors executing a computer or game program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by, and apparatus can be implemented as a game platform such as a dedicated game console, e.g., PLAYSTATION®3, PLAYSTATION®4, or PLAYSTATION®VITA manufactured by Sony Computer Entertainment, Inc.; WII™, WIT U™, NINTENDO 2DS™, or NINTENDO 3DS™ manufactured by Nintendo Co., Ltd.; or XBOX®, XBOX 360®, or XBOX ONE® manufactured by Microsoft Corp.; or special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit) or other specialized circuit. Modules can refer to portions of the computer or game program or gamer console and/or the processor/special circuitry that implements that functionality.
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer or game console. Generally, a processor receives instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer or game console are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer also includes, or is operatively coupled, to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Data transmission and instructions can also occur over a communications network. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.
To provide for interaction with a player, the above described techniques can be implemented on a computer or game console having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, a television, or an integrated display, e.g., the display of a PLAYSTATION®VITA or Nintendo 3DS. The display can in some instances also be an input device such as a touch screen. Other typical inputs include simulated instruments, microphones, or game controllers. Alternatively, input can be provided by a keyboard and a pointing device, e.g., a mouse or a trackball, by which the player can provide input to the computer or game console. Other kinds of devices can be used to provide for interaction with a player as well; for example, feedback provided to the player can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the player can be received in any form, including acoustic, speech, or tactile input.
The above described techniques can be implemented in a distributed computing system that includes a back-end component, e.g., as a data server, and/or a middleware component, e.g., an application server, and/or a front-end component, e.g., a client computer or game console having a graphical player interface through which a player can interact with an example implementation, or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet, and include both wired and wireless networks.
The computing/gaming system can include clients and servers or hosts. A client and server (or host) are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
The invention has been described in terms of particular embodiments. The alternatives described herein are examples for illustration only and not to limit the alternatives in any way. The steps of the invention can be performed in a different order and still achieve desirable results.
This application claims benefit under 35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 62/233,701, filed Sep. 28, 2015, entitled “Dynamic Improvisational Fill Feature,” the content of which is incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62233701 | Sep 2015 | US |
