Analog stick input replacement for lengthy button push sequences and intuitive input for effecting character actions
An interactive game programmed according to game rules including at least some game rules for mapping analog input movement to character actions for a character controlled by a player, the interactive game including program code to effect game state changes corresponding to moves made by a character controlled by the user, database or tables of operations wherein an operation represents a series of actions taken by a character in response to a particular user input using the analog input control, program code for processing the particular user input from the analog input control including representing input movement as a sequence of one or more sector visits, comparing the particular sector visit sequence with the database of operations to find matching character actions for the particular sector visit sequence or defined variation thereof, program code for effecting, where a match or defined variation thereof is found in the database of operations, the operations in sequence according to an associated series of actions of the found match and the like.
Latest Electronic Arts Inc. Patents:
The present disclosure may be related to the following commonly assigned applications/patents:
U.S. Pat. No. ______ (U.S. patent application Ser. No. 10/441,368, filed on May 20, 2003 and entitled “Sequencing Input Control Stick”) to Bollo et al. (hereinafter “Bollo”);
The respective disclosures of these applications/patents are incorporated herein by reference in their entirety for all purposes.
FIELD OF THE INVENTIONThe present invention relates to interactive computer games in general and in particular to user interface techniques for accepting user input representing user actions to be input to the play of an interactive computer game.
BACKGROUND OF THE INVENTIONInteractive computer games might be implemented as computers, consoles, or other computing device coupled to a display (and possibly other output devices, such as an audio output or sensory output) in user input devices such as console controllers, keyboards, and the like. It is known to use complex user input devices with several buttons to allow for a wide range of possible user inputs. For example, an interactive computer game might be programmed such that a particular one of a dozen buttons controls whether a character in the game jumps or runs.
In a typical game, a game designer programs the game so that it operates according to certain game rules that may be known to the player of the game (the user of the game providing input) or not. For example, the player might know that causing his or her character to perform a particular action obtains points or other benefits for the player such as gaining 100 health points for causing the player's character to pass by a medical kit object displayed in a playing field. In other cases, there might be game rules that are imposed but possibly not known by the player, or maybe inferred by more skilled players.
As used herein, a player is a person that operates a game system by interacting with the game system. Typically, the game system is programmed such that player input directs a simulated character within the game in interactions with its environment and other characters in the game space and game rules determine what happens when the character performs a directed action. In some terminology, the controlled character is termed an “avatar”, with each player controlling one or more avatar and characters, and computer-controlled characters are termed “NPC” (non-player characters). In some games, the avatars and NPC can have indistinguishable appearances, with the difference being that a player does not control the movement or actions of the NPCs. As used herein, “characters” are animate objects or assumed animate objects. They need not be human, but can be animals, robots, monsters, mythical beings, or things commonly thought of as inanimate objects (e.g., a walking, talking rock). In some games, game play might be such that it is not important to distinguish between NPCs and inanimate objects, as both might be movable by the game according to game rules without input from a player.
The game space might be represented by a simulated world coordinate space into which characters and objects are positioned, with a game display showing one or more views into that space, possibly also including status displays (such as current score, current contexts, current tool(s)/weapon(s) in use, etc.). It should be understood that player manipulation of a character in the game involves the game system accepting user input, interpretation of that user input as actions taken by the player per predetermined game rules (e.g., pressing a button labeled “B” in particular contexts causes the character to use its current weapon, pressing a track control causes the character to move about the game space, etc.), updating the game state to take into account the actions taken and displaying the updated game space. The other characters in the game with which the player's character “interacts” might be controlled by other human players or computer-controlled according to game rules. The game rules can be embodied in program code loaded into a processor memory when the game is being played.
Input devices may include keyboards, computer mice, track balls, joysticks and/or special purpose controllers having a variety of input (and possibly some output) mechanisms. With these input devices, characters may be controlled in a variety of ways. With joysticks, the character or characters may be moved by moving the joystick in various directions and positions. By pressing a single button, or possibly a combination of buttons, an animation sequence may be triggered. Analog inputs have also been introduced to game play, wherein a player is able to specify more than just whether a button is pressed or not and how long the press lasts, but can provide an input that varies as the trigger for an analog input. In many cases, the analog input is digitized.
Some buttons might be multiple input buttons, such as a rocking four-way button that, when pressed in particular direction, would send a signal to the device executing the computer game indicating that the user, for example, pressed the “up”, “down”, “left” or “right” portion of the four-way button. For some hardware and games, multiple presses of a button might indicate something different than a single press. Often, multiple presses of a button cause multiple instances of the movement that a character would take for a single button press. For example, if the interactive computer game interpreted a single button press as a user instruction to cause a character to take a step forward, multiple presses of that button might be interpreted by the interactive computer game as instructions to have the character take one step forward for each of the presses, resulting in multiple steps forward.
In some games, because of the speed of the action, the user might have to press many different buttons once or more in a particular order in quick succession to have the character behave in a desirable manner. This is often referred to as “button mashing” and is often a disfavored characteristic of an interactive computer game and may lead to premature hardware failure for the user input devices. Nonetheless, with many games, the enjoyment of playing the game is in the interaction which might be complex enough that ordinarily many buttons would have to be pressed to get the desired action. Another difficulty with complex games, such as where the player has the option to make their avatar(s) take one or more of a large number of possibilities, it is hard for a player to remember the correspondence between each available avatar action and the corresponding input sequence that would be interpreted as a player desire for that particular avatar action.
BRIEF SUMMARY OF THE INVENTIONAn interactive game programmed according to game rules including at least some game rules for mapping analog input movement to character actions for a character controlled by a player, the interactive game including program code to effect game state changes corresponding to moves made by a character controlled by the user, database or tables of operations wherein an operation represents a series of actions taken by a character in response to a particular user input using the analog input control, program code for processing the particular user input from the analog input control including representing input movement as a sequence of one or more sector visits, comparing the particular sector visit sequence with the database of operations to find matching character actions for the particular sector visit sequence or defined variation thereof, program code for effecting, where a match or defined variation thereof is found in the database of operations, the operations in sequence according to an associated series of actions of the found match and the like. The following detailed description together with the accompanying drawings will provide a better understanding of the nature and advantages of the present invention.
BRIEF DESCRIPTION OF THE DRAWINGS
An improved game system wherein user inputs are used to improve the game flow is described herein. In one aspect, a set of user input devices include an analog input and the use of the analog input in particular sequences is used to represent corresponding character actions, including complex character hand movements, the ability to convey intensity of the movement and with an intuitive mapping from input device movement to avatar movement.
One or more game media 12 can include any game applications that may be used by game device 14 to involve a user in a game. Each game medium 12 includes logic to provide a game, denoted as game A, game B, and game C. In one embodiment, the game provided by game device 14 is an electronic video game. Games are each individually stored on media, such as compact disk read-only memories (CDROMs), digital versatile disks (DVDs), game cartridges, or other storage media. A game, such as game A, is inserted in, coupled to, or in communication with game device 14 so that game device 14 may read all or part of a game application and/or related game data found on game media 12. Some games might also be included integrated in with game device 14.
Game device 14 is a computing device that includes a processor, such as a CPU, and data storage combined or in separate elements. Game device 14 may be connected to a network that allows game device 14 to provide games that are not included on one or more game media 12. Thus, game A, game B, and game C may be accessed through the network and not be individually stored on game media 12. To allow a user to select from a plurality of available games, a display 16 might present a list of the games provided by game applications on game media 12.
A game application may be also referred to as a game code and/or a game program. A game application should be understood to include software code that game device 14 uses to provide a game for a user to play. A game application might comprise software code that informs game device 14 of processor instructions to execute, but might also include data used in the playing of the game, such as data relating to constants, images and other data structures created by the game developer including predefined input sequences and their corresponding game actions. A user interacts with the game application and game device 14 through user input/output (I/O) devices, some of which are described in more detail below.
Game device 14 might include a separate graphics processor 24. Game device 14 might be a handheld video game device, a console (special purpose) computing system for operating computer games such as video games, a general-purpose laptop or desktop computer, or other suitable system.
Game device 14 also includes various components for enabling input/output, such as an I/O 32, a user I/O 34, a display I/O 36, and a network I/O 38. I/O 32 interacts with storage element 40 and, through a device 42, removable storage media 44 in order to provide storage for game device 14. Processing unit 20 communicates through I/O 32 to store data, such as game state data and any shared data files. In addition to storage 40 and removable storage media 26, game device 14 is also shown including ROM (read-only memory) 46 and RAM (random access memory) 48. RAM 48 may be used for data that is accessed frequently, such as when a game is being played.
User I/O 34 is used to send and receive commands between processing unit 20 and user devices, such as game controllers. Display I/O 36 provides input/output functions that are used to display images from the game being played. Network I/O 38 is used for input/output functions for a network. Network I/O 38 may be used if a game is being played on-line or being accessed on-line.
Game device 14 also includes other features that may be used with a game, such as a clock 50, flash memory 52, and other components. An audio/video player 56 might also be used to play a video sequence such as a movie. It should be understood that other components may be provided in game device 14 and that a person skilled in the art will appreciate other variations of game device 14.
Program code might be stored in ROM 46, RAM 48 or storage 40 (which might comprise hard disk, other magnetic storage, optical storage, other storage or a combination or variation of these. In a common arrangement, part of the program code is stored in ROM that is programmable (ROM, PROM, EPROM, EEPROM, etc.) and part of the program code is stored on removable media such as game media 12 (which can be a CD-ROM, cartridge, memory chip or the like, or obtained over a network or other electronic channel as needed). In general, program code can be found embodied in a tangible signal-bearing medium.
RAM 48 (and possibly other storage) is usable to store variables and other game and processor data as needed. Typically, RAM is used and holds data that is generated during the play of the game and portions thereof might also be reserved for frame buffers, game state and/or other data needed or usable for interpreting user input and generating game displays.
As game device 14 reads game media 12 and provides a game, information may be read from game media 12 and stored in a memory device, such as RAM 48. Additionally, data from storage 40, ROM 46, servers through a network (not shown), or removable storage media 26 may be read and loaded into RAM 48. Although data is described as being found in RAM 48, it will be understood that data does not have to be stored in RAM 48 and may be stored in other memory accessible to processing unit 20 or distributed among several media, such as game media 12 and storage 40.
User I/O can come in many forms and is not limited to the examples described here. A typically example that will be used for many examples herein is a handheld controller such as that shown in
As shown in the specific example of the figure, controller 70 includes a number of digital inputs, such as momentary switches 74 (A, B, C), two-position momentary rocker switches 76, a two-position switch 78 (with positions X and Y) and a track control 79 which the user can press to indicate one of four directions or combinations thereof (e.g., “north”, “south”, “east” and “west”, or “up”, “down”, “right” and “left”). Controller 70 is also shown including two analog inputs 80. When used, controller 70 might convey to a game system, via cable 72 or otherwise, user movement of the analog inputs. One way to convey the movement is to send (periodically or as the position changes) the two-dimensional position of the analog inputs. It should be understood that this is just one specific example of a controller and other variations could be used without departing from the scope of the invention. For example, the analog inputs described have two degrees of freedom, but the inputs can have one or more than two degrees of freedom. For example, if analog inputs 80 can be pushed in and pulled out, as well as being bent in two directions, it would have an additional degree of freedom. Other degrees of freedom might be implemented with an ability to rotate the input sticks.
In at least one example, one of the inputs is an analog input that can move through at least two degrees of freedom. The analog input has a number of embodiments, such as a stick, a stick with a button on its free end, or other arrangement allowing for character movement through a movement space defined by the range of movement and degrees of freedom of the analog input. Unless otherwise indicated, it should be understood that examples using an analog stick also apply to other analog inputs of similar degrees of freedom.
Sector visits provide a way for a game to reduce the granularity of analog stick movement. For example, instead of having to deal with mapping an analog stick position in a grid of 256 by 256 position values, the “movement space” through which the analog stick can move might be segmented into a small number of segments. In one example, the number of segments is nine, and in another example the number of segments is 17.
In some controllers, the internal signal processor samples the position of the analog stick and outputs the result of the sampling, which game device 14 can process to arrive at sequences of sector visits, which can in turn be mapped to avatar actions. In other controllers, the controller outputs higher-level constructs such as mapping movements to sector identifiers and outputting sector identifiers or even mapping sector identifiers to a sequences and outputting sequence identifiers. In sampling the movement of the analog stick, the internal signal processor might use different sample rates under different conditions. For example, the internal signal processor might sample more frequently when the analog stick is being moved quickly to catch all the motion or the internal signal processor might sample less frequently when the analog stick is being moved quickly so as to be able to more easily ignore quick and possibly unintended visits to some sectors.
Game device 14 provides for user input to control aspects of the game according to game rules. Game rules might be specified in instruction form on game media 12. Examples of game rules include rules for scoring, possible inputs, actions/events, movement in response to inputs and the like.
Responses to Input Sequences
The analog stick can be used to convey sequences of operations such as button push sequences representing character hand movement. Hand movements might include simulation of a character picking things up, including other characters, and making hand movements. Hand movements might be used to signal aggression or otherwise simulate inter-character interaction and hand movements might correspond to combat moves, such as sticking another character with a hand or an object held in the hand.
In some embodiments, users can specify the button push sequences that correspond to particular analog stick motions. In advanced modes, the occurrence of certain pre-specified sequences of analog stick movements might cause predefined combination sequences of character actions to be performed. For example, an input representing the signaling of aggression followed by a move signaling an advancement towards an attack might be immediately (without further user input) followed by an attack sequence, thereby allowing the player to react more quickly to game events than if the player were required to press a button for each step of the sequence. Another advantage of such sequencing is that many more variations of actions can be input than would normally be permitted for a given number of input buttons on a controller. With other advanced game design techniques, such as the use of a physics engine to animate characters in other than pre-scripted animations, dynamic situations can be handled by the game, thereby allowing for much more refined user inputs and thus needing input devices and methods that allow for complex and/or refined user inputs to be timely input and processed.
With the wide range of possible avatar actions, it is often helpful to map analog stick movements to avatar actions such that the movements correspond to the action. For example, in an attack mode, the avatar action of a light hit might be conveyed by the player pushing the analog stick forward while the avatar action of a heavy hit might be conveyed by the player pulling back on the analog stick (to convey a wind-up) and slapping the analog stick forward.
Some variations allow for some inputs or events to interrupt the combination sequence, such as another character doing something inconsistent with continuing the sequence, such as escaping, moving or counterattacking. Sequences can convey differences such as degrees of intensity. In some cases, context is taken into account, wherein some player moves are allowed only within certain areas.
Input Sequences
Input sequences can cover complex operations that are actually simple moves in the real world. For example, the use of finesse, intimidation through hand gestures, attacking, grabbing, moving objects and characters by moving while grabbing (e.g., causing another character to move from a kneeling posture to a standing posture by grabbing their shoulders and raising arms), are possible using relatively simple actions on the part of the player.
Game play might use two analog sticks with one analog stick controlling movement around the game space (and therefore the display screen) while the other analog stick controls attacks—allowing the player to execute directional quick attacks with a flip of analog sticks. By considering timing the flicks of the stick(s), combination moves are played out and several flicks might result in multi-hit combination moves. Pulling back on the attack stick might be interpreted as an intimidation of the opponent and quickly slapping the stick forward might be interpreted as unleashing heavier charged attacks.
Analog stick actions in combination with digital inputs might also be handled. For example, an analog stick action with a press of a button associated with a block (a.k.a., the “block button”) might result in character movement with a blocking action.
This might mimic real life motions in hand-to-hand combat, so the player manhandles their opponent by “manhandling” their controller and a game rule might specify in a mobster game that a player's “respect” rating increases when the player's character successfully “intimidates” another character. Intimidation might be successful as the other character takes on an intimidated posture.
Sector Mapping
In a process described herein, analog stick movements throughout a movement space are sampled, at fixed or variable rates, to obtain a stream of movement. The movement space is divided up into sectors such that the movements through the movement space are representable by “visits” of the analog stick to particular sectors. As the visits are sampled, they can be timed, such that game or controller logic has available to it the sectors visited and the duration of the visit. The duration might be useful for determining which sector visits to ignore (a form of hysteresis that may serve to smooth out movements) and/or for interpreting different avatar actions. An example of the latter might be that the game causes one avatar action if the movement through a particular sector lasts less than a threshold time and causes another avatar action if the movement through the sector lasts more than the threshold time.
In the example shown, there is a center sector (the sector typically occupied by the analog stick in a rest position when the player is not actuating the stick), eight sectors representing moderate displacement of the analog stick (N, NE, E, SE, S, SW, W and NW), and eight sectors representing larger displacement of the analog stick (N*, NE*, E*, SE*, S*, SW*, W* and NW*).
The analog stick is thus mapped into 17 individual sectors as projected onto a unit circle in two-dimensional space. Sectors can be grouped together to form new sectors giving us hundreds of possible combinations. The mapping can change, possibly in real-time, to make certain sectors larger or smaller. The sample rate can be varied, possibly in real-time, thereby negating the effects of briefly landing in an erroneous sector, leading to more forgiving results and lending itself to a more fluid intuitive feel.
Individual avatar motions can be mapped to specific to a sequence of order important sequence of sectors being hit, and the time spent within each defined sector. In this manner, the analog stick movement is mapped onto the avatars according to real world physical movement in an intuitive fashion.
-
- (C, S*, {NW*|N*|NE*})=> “power punch”
According to the above expression, movement from the center sector (C) to the extreme south sector (S*) to any one of the extreme northerly sectors (NW*, N* or NE*) would be interpreted as a player requesting his or her avatar perform a “power punch” move. Note that, technically, the first sequence is (C, S, S*, S, C, N, N*) and the second sequence is (C, SW, S, S*, S, SW, W, NW, NW*) and so on. With suitable thresholds, the transient sectors can be ignored or missed through the use of the appropriate sampling rate. With this approach, the player's avatar achieves the desired motion with stick movement that feels fluid and natural and small variations that typically do not signify variations in player intent, are ignored.
The sector map that maps stick position to sector might be as shown in
A possible sequence of operations will now be described with reference to the step numbers indicated in circles in
Processor 120, or other processor, reads the next avatar action value (step 7) as well as instructions 116 (step 8) and outputs signals as needed to update the game for the new avatar action.
Examples of Sequences
Engaging in a Fight: In order to engage, the target must be locked. Once locked, the analog stick controls attacks/grabs. When not target locked, the analog stick might perform other roles; such as controlling a free roaming camera. The effects of an attack, such as the damage done, might be set in the game rules for particular actions and that table might be tunable.
Quick Attacks: Quick attacks are relatively weak, but very fast. Quick attacks can be executed by hitting a single face button on the controller, OR by pushing the right analog stick quickly towards a target. These attacks have little or no “wind up” period and connect quickly. The damage from a quick attack can be tunable from a table.
Power Attacks: Power attacks are stronger, and slightly longer than quick attacks. They can be executed by hitting a single face button on the controller, OR by pulling away and then pushing the right analog stick quickly towards a target. These attacks have a brief “wind up” period before connecting with an opponent. The damage from a power attack can be tunable from a table. The animation for power attacks could easily transition to the hold state for a charge attack, since they both begin with the same controller input.
Charge Attacks: Charge attacks are the most powerful and longest attacks. They can be executed by holding down the power attack button for a brief time, then releasing it, or by holding the right analog stick back for a brief time, then pushing it forward in the direction of a target. These attacks have a substantial “wind up” period that can loop, before the player follows through and connects with an opponent. Charge attacks can be “released” during the wind up period, which puts the attacker into his regular posture without following through with the attack. This can be done by settling the right analog stick to neutral.) The damage from a power attack can be tunable from a table.
Combination Attacks: Combination attacks occur when the player has executed multiple quick attacks or power attacks in rapid succession. Combination attacks can chain two, three, four or more attacks or sequences together, eventually unlocking a “finishing” move. The player should be able to change an attack at any point; however, this breaks out of the combination cycle. Each move should flow smoothly from the last.
Directional Input: If the analog stick is pressed left or right of center during the forward push the stick, this might be interpreted as combination movement toward front left or front right. For example, if the analog stick is pressed left or right of center during the forward push of an attack, then the animation changes according to the user's input such that the hit strikes the target a little to the left or right, respectively. Similarly, if the player initiates the charge loop of a charge attack by holding back on the stick, then the animation switches depending on whether the player is holding back left or right of center.
Two handed grab: When the player has an opponent target locked and presses another particular button, they will execute a two handed grab. This grabs the opponent with both hands. Other follow-on moves, such as a drop, push, move, etc. can be done in this state.
Strangle: When the player has an opponent in a two-handed grab, he can strangle the target by clicking the two analog sticks inward. If no strangle weapon exists in the player's inventory, then the strangle will be performed with the hands. Otherwise, this will automatically equip the player's current strangle weapon (garrote, nylon rope, etc.) and engage the target with it. During the strangle, the player's controller might include vibration for a “heartbeat” that slowly fades over the course of the strangle indicating player's health.
Push: When the player has an opponent in a two-handed grab, he can push the target by releasing both shoulder buttons simultaneously. This move releases the two handed grab, and pushes the opponent forward.
Posture sensitive melee attacks: When a target is in a posture such as stunned, kneeling or grabbed, the character can perform a posture sensitive attack instead of the normal ones.
Ability to attack with an inventory melee weapon: The player can carry several weapons in his or her inventory, including melee weapons such as bats, knives, and blackjacks. When a weapon is equipped, the player will be able to attack with this weapon. The types of melee attacks can be similar to unarmed combat (quick, power, and charge).
Ability to grab, use, and drop environmental melee items: The player should be able to grab “environmental melee” items. These behave just like other types of melee weapons, except that they do more damage, only use quick attacks and cannot be saved to the inventory. Objects are grabbed with a press of a button designated for that purpose. The player will carry the item until it is dropped (with the action button), displaced by selecting an existing inventory item, or dropped by concealing all weapons. Environmental melee items can also be thrown. These items might “break” after a period of time and “shatter” once they are thrown. The damage from a thrown object might be tunable from a table. Thrown objects will rotate as they are thrown. These items are often items not worth carrying around, but happen to be available at the time, such as broken bottles, a broom handle, a wrench, a trash can, a trash can lid, etc.
Defensive Blocks: The player should be able to perform a block by pressing a face button. The block will be held for as long as the block button is held down. Blocks can prevent the player from being hit by most quick attacks, and can reduce damage from most power and charge attacks.
AI Patterns/Behaviors: In some “boss” fights, the player will need to learn and react to specific Al behaviors by observing patterns in the computer controlled character's brawling style. Each “boss” will have predictable attack patterns that they will follow as well as defensive tactics (or immunities) to specific attacks.
Context Sensitive Attacks—Opponent Postures
Attacks might be context sensitive in that the result might depend on postures of opponents, locations in the game space, and the like. For example, the player might be able to control his or her character to grab an opponent, execute grab attacks and pull the opponent up to the next posture (e.g., lying to kneeling, kneeling to standing). The grip of individual hands might be controlled by other buttons, such that one button toggles whether the character's right hand is open or gripping and another button controls the same for the character's left hand. When gripping an opponent and moving, the character might have the ability to move their opponents around, push them into objects or onto the ground.
Grab Attacks
Sneaking up on an opponent from the back might permit more advanced grab attacks. Some sneak grab attacks might only be permitted in certain areas of the game space (e.g., dark alleys or other “hot spot”). A “hot spot” signifies a context sensitive area where extra moves can be made and where opponents leave themselves very vulnerable when near these hot spots. When near a hotspot, the user display might indicate a character being in a hot spot.
Combination Attacks
The examples shown in
Customizing Sequences
The game system might provide an interface accessible to players allowing them to customize their sequences (such as an attack and a multi-hit combination sequence). In one approach, a user selects a combination they would like to customize, followed by the sequence order and finally the actions set in each slot. Users can select from a list of attacks via name and icon and select an attack in each slot to set for their character's animation string. Each link on the chain is revealed as the player progresses and each attack can be set in order of importance. Some sequences might require more accomplishments that currently had by the player. For example, the game system might maintain locked animations and combination strings and those might appear “ghosted out” with a hint indication on what accomplishments are needed to access them. For example, a certain number of intimidation points might be required to use some sequence.
Types of Attacks
In a specific embodiment, attacks are categorized as quick, charged or intimidate attacks. Attacks might also be characterized by tool (e.g., hands only, weapon and hands, etc.). The game program might include a “combat system” that handles rules and operations related to combat between the character controlled by the player and opponents (either human-controlled or computer-controlled).
Each type of attack has a wind-up and a follow-through. The quick attack has the shortest wind-up and the charge has the longest wind-up. If an attacker is struck during a wind-up phase, the attacker's attack is “broken” and a hit reaction is played. Otherwise, the follow-through will occur uninterrupted. When it connects, it will do damage to the target. If two characters attack each other and both are in their follow-through phase, then there is a chance that one attack will “win” depending on attack type. The “winning” attacker receives less damage and does not play a hit reaction. There is also a chance that the attacks will result in a “push”, wherein both attackers receive equal damage and both play a hit reaction.
Positioning
The game rules might automatically determine whether a player is “in range” for a particular action. For example, a player might be required to be within a specified distance of another character before being allowed to engage that other character in threats, attacks or other interactions. This is referred to sometimes as “target lock”.
The view point of a display (i.e., the simulated position of the camera in a game space) might depend on whether there is a target lock. For example, the camera might attempt to get behind the player when he is targeting/attacking an opponent. This allows for more natural game play and in some instances it simplifies animation as the view angles are more likely to me the same from event to event.
Other Variations
Other features might be added to the control sequences. For example, hot spots might be defined as such that the player is shown an indication of when the player's character is within a hot spot that allows certain actions not allowed outside the hotspot. Another feature might use one of the analog sticks to convey character movement in a game space while another analog stick conveys a control sequence.
As has been described, particular user input devices can be used to allow a player to use complex game operations, such as hand-to-hand combat, by specifying movements with an analog input. Using these inputs, the player can control engagement in combat or preparing for combat. Combat can be armed or unarmed and can take into account postures of the player's character and opponents, such as postures for standing, being stunned, kneeling, crawling, being knocked-out, dead, etc. Armed combat can include inventory weapons (that a player can store in an inventory) and environmental weapons (that a player must use as picked up and cannot store for later). The user can input sequences for defensive moves such as blocks and crouches. Various grabs and grapples can be used. A round-robin approach to timing attacks between two opponents might be used.
Embodiments of a user interface process and apparatus, as well as a game programmed according to the use of such user interfaces, according to aspects of the present invention are described herein. It should be understood that many variations from what is described can be easily derived from reading this detailed description. Thus, while embodiments are described with reference to particular examples, it should be understood that, while specific details are described by example, the invention is not limited to specific examples. For example, while user interface devices and methods are described with reference to interactive computer games programmed to accept complex sequences, the invention might be used in other applications wherein efficient user interfaces are required or useful.
While the analog control is often described herein with reference to an analog stick, other analog controls might also be provided, such as dials, balls, sliders, touch- or optical-sensitive controls, or the like.
While the invention has been described with respect to exemplary embodiments, one skilled in the art will recognize that numerous modifications are possible. For example, the processes described herein may be implemented using hardware components, software components, and/or any combination thereof. Thus, although the invention has been described with respect to exemplary embodiments, it will be appreciated that the invention is intended to cover all modifications and equivalents within the scope of the following claims.
Claims
1. A computerized interactive game programmed according to game rules such that game state changes according to user input and the game rules and appropriate displays by a computer system operating the game are presented to a user representing the game state changes, wherein the user input includes input from digital switches and at least one analog input control for accepting analog input, the computerized interactive game comprising:
- program code to effect game state changes corresponding to moves made by a character controlled by the user;
- a database of operations wherein an operation represents a series of actions taken by a character in response to a particular user input using the analog input control and associated with the operation;
- program code for processing the particular user input from the analog input control including representing input movement as a sequence of one or more sector visits, comparing the particular sector visit sequence with the database of operations to find matching character actions for the particular sector visit sequence or defined variation thereof, and
- program code for effecting, where a match or defined variation thereof is found in the database of operations, the operations in sequence according to an associated series of actions of the found match.
2. The computerized interactive game of claim 1, wherein the database of operations stores each is series of actions as a sequence of a plurality of button presses, thereby allowing manipulation of the analog input control to substitute for a plurality of button presses to effect a sequence.
3. The computerized interactive game of claim 2, wherein button push sequences that correspond to particular analog stick motions are user-specified.
4. The computerized interactive game of claim 1, wherein hand movements of the character include picking objects up using an animated gripped hand of the character.
5. The computerized interactive game of claim 1, wherein hand movements of the character include picking up other characters using an animated gripped hand of the character.
6. The computerized interactive game of claim 1, wherein hand movements of the character include making gestures.
7. The computerized interactive game of claim 6, wherein the gestures include signaling aggression or intimidation.
8. The computerized interactive game of claim 1, wherein hand movements of the character include combat moves.
9. The computerized interactive game of claim 1, further comprising program code to effect operations corresponding to predefined combination sequences of character actions following a sequence of analog stick movements.
10. The computerized interactive game of claim 9, further comprising program code to interrupt an ongoing predefined combination sequence when an intervening event occurs.
11. The computerized interactive game of claim 10, wherein the intervening event is a counterattack by an engaged opponent.
12. The computerized interactive game of claim 1, further comprising program code to output touch feedback to the user.
13. The computerized interactive game of claim 1, wherein the program code for processing is adapted to process inputs according to a speed of engagement of the analog control device.
14. The computerized interactive game of claim 13, wherein the speed of engagement determines whether an attack move is a quick attack, a normal power attack, or a charging attack.
15. The computerized interactive game of claim 13, wherein a sequence of speeds of engagement is interpreted as the start of a pre-selected attack sequence and the attack sequence follows.
16. The computerized interactive game of claim 1, wherein the program code for processing is adapted to take into account whether a target is identified and locked, thereby interpreting a particular input in a first manner when a target is identified and locked and interpreting the particular input in a second manner distinct from the first manner when a target is either not identified or not locked.
Type: Application
Filed: May 5, 2005
Publication Date: Nov 9, 2006
Applicant: Electronic Arts Inc. (Redwood City, CA)
Inventors: Michael Olsen (Redwood City, CA), Niall Hayes (San Francisco, CA), Casey Weaver (San Francisco, CA)
Application Number: 11/124,419
International Classification: A63F 9/24 (20060101);
