U.S. Pat. No. 11,465,040

DETAILED DESCRIPTION

The present invention relates to systems and methods for controlling a weapons-related video game on a touchscreen-based device. Aspects of the invention simplify the act of aiming at a target on a touchscreen-based device by: presenting a virtual environment from a first viewpoint; presenting a user interface to a player, the user interface including at least a plurality of graphical user input elements representative of different directions in the virtual environment; instantiating a plurality of targets in the virtual environment; assigning priorities to at least some of the plurality of targets; receiving an indication that one of the graphical user input elements representative of different directions in the virtual environment has been selected by a user; and in response to receiving the indication that the one of the graphical user input element has been selected by a user, determining a second viewpoint for viewing the virtual environment that is different from the first viewpoint for viewing the virtual environment, wherein the second viewpoint for viewing the virtual environment is determined relative to a highest-priority target in a direction corresponding to a direction of the selected graphical user input element.

FIG. 1illustrates an exemplary screen of a user interface100for a weapons-related video game in accordance with aspects of the invention. User interface100is depicted in the context of a first-person shooter combat simulation, but the inventive aspects of user interface100may be applied in various embodiments to other video games that involve aiming at a target on a touchscreen-based device, including without limitation, first- and third-person weapons-related video games such as combat simulations and flight/vehicle simulators.

During gameplay, the weapons-related video game presents a virtual environment of gameplay, and may instantiate one or more targets, for example targets150-170, in the virtual environment for the player to attack. InFIG. 1, targets150-170are visible to the player, however, in many cases, one or more of targets150-170may not be visible to the player (e.g., they are behind, to the side of, or otherwise blocked from the player's view). InFIG. 1, a z-axis extends away from the facing direction of the player's avatar (not shown inFIG. 1) or viewpoint towards the horizon, and the z-axis may be considered to vertically bisect the user interface100. (Note that Cartesian axis190is included for reference only and in most embodiments would not be displayed in user interface100.) Target150is the closest along the z-axis to the player's avatar (or viewpoint), followed by target160and target170in the distance. Targets whose center is to the right of the z-axis are considered to the right of the player's avatar (or viewpoint) (e.g., targets150and170inFIG. 1), and targets whose center is to the left of the z-axis are considered to the left of the player's avatar (or viewpoint) (e.g., target160inFIG. 1).

User interface100comprises a crosshair110that the player may use to aim his weapon at targets150-170. Generally, the position of crosshair110relative to the targets when the player fires his weapon determines whether the player hits or misses any given target150-170. In some embodiments, rays representing the trajectory of the fired shots are cast from the center of the screen, or in various embodiments some other point on the screen, for example a bottom center position, towards crosshair110. If a ray intersects with a target150-170, the target150-170is hit; otherwise, the target150-170is missed. In some embodiments, crosshair110is locked to the center of the screen. In other embodiments, crosshair110may be freely moved about the screen by the player. Although crosshair110is depicted in an “x” configuration, crosshair110may be of any configuration, including for example, a cross, a circle, a cross within a circle, etc. In some embodiments, there is no visible crosshair, and shots are simply fired to a predetermined location relative to the player's viewpoint (e.g., the center of the screen).

User interface100comprises two graphical user input elements herein referred to as snap-to-target buttons120and130. As illustrated inFIG. 1, a left snap-to-target button120is about a left side of the screen, and may be considered pointing to the left, and a right snap-to-target button130is about a right side of the screen, and may be considered pointing to the right. The left snap-to-target button may be considered representative of a left direction and the right snap-to-target may be considered representative of a right direction. In various embodiments additional (or fewer) snap-to-target buttons representative of different directions may be available. In addition, in various embodiments the snap-to-target buttons may be variously positioned on the screen, and may be representative of different directions solely by their placement on the screen, solely by use of graphical or textual symbols indicating directions, or by other means. Snap-to-target buttons120and130assist the player in taking aim at the highest-priority target to the left and to the right of the player's avatar (or viewpoint). For example, when the player selects left snap-to-target button120, the viewpoint pans to center crosshair110on the highest-priority target on the left of the player's avatar (or viewpoint). Similarly, when the player selects right snap-to-target button130, the viewpoint pans to center crosshair110on the highest-priority target on the right of the player's avatar (or viewpoint).

In some embodiments, snap-to-target buttons120and130are configured to pan the viewpoint such that crosshair110is centered on the highest-priority target, in a direction indicated by or associated with the particular snap-to-target button, such that a shot fired by the player would hit that target. Alternatively or additionally, snap-to-buttons120and130may be configured to pan the viewpoint such that crosshair110is within a predetermined distance from the highest-priority target, but still require the player to take additional aim to hit the target. Such a configuration may be useful as it provides assistance to the player while still challenging the player to take aim at the target. In some embodiments, when the player selects a snap-to-target button120or130, the gameplay may temporarily enter a slow-motion mode as the viewpoint pans to highest-priority target, with the virtual environment displayed on the screen panning in slow motion.

A target's priority may be based on a number of factors approximating the target's threat to the player or the target's danger level. For example, priority may be based on the one or more of: the target's proximity to the player's avatar (or viewpoint); the target's proximity to a line extending along the player's avatar's facing direction representing the avatar's line of sight (i.e., the z-axis); the total amount of damage inflicted by the target on the player; the amount of damage inflicted by the target on the player in a given amount of time (e.g., the last 3, 5, or 10 seconds); the amount of damage the target is capable of inflicting in a given shot and/or amount of time (e.g., the damage rate of the target's weapon); the target's health; etc.

FIG. 2depicts an exemplary target prioritization scheme in accordance with aspects of the invention. In the embodiment ofFIG. 2, the target's priority is based on a combination of the target's proximity to the player's avatar210(or viewpoint) and the target's proximity to the player's line of sight220.FIG. 2shows a high-priority region as an area within a predefined radius of a player's unit, for example the player's avatar, an area within 22.5 degrees of an axis defined by the avatar's line of sight (z-axis) and between the predefined radius and a more distant predefined point on the z-axis, and an area within approximately 10 degrees of the z-axis between the predefined point on the z-axis and an even more distant point on the z-axis.FIG. 2also shows mid-priority regions240and250as areas outside the high-priority region between the more distant point and the even more distant point on the z-axis, but within 22.5 degrees of the z-axis. Generally, targets falling within high-priority region230have the highest-priority, targets within mid-priority regions240and250have the second highest priority, and targets outside regions230,240, and250are the lowest priority. Within each region, targets may be further prioritized based on their proximity to the player's avatar210and/or the avatar's facing direction220.

Referring back toFIG. 1, in some embodiments, snap-to-target buttons120and130are configured to visually alert the player (for example, by flashing, changing color, made bold, etc.) when a target is within a predetermined range of the player's avatar (or viewpoint) or when a target exceeds a certain priority level. In some embodiments the visual alert provided by the snap-to-target buttons are on a directional basis, with only buttons for a particular direction providing visual alerts when there are targets in those directions fulfilling the criteria. In some embodiments, snap-to-target buttons120and130may be visually de-emphasized (for example, greyed out, made to appear translucent, removed altogether, etc.) if there are no targets within a predetermined range of the player's avatar (or viewpoint) or if there are no targets of a certain priority level.

In some embodiments, user interface100may further comprise a soft-lock area140centered around crosshair100. Soft-lock area140further assists the player to take aim by automatically moving crosshair100onto targets within soft-lock area140. For example, inFIG. 1, a portion of target150is within soft-lock area140. If soft-lock is enabled, crosshair110would automatically center over some portion of target150that is within soft-lock area140. In many embodiments, crosshair110would move independently of the player's viewpoint. Alternatively, movement of crosshair110may cause the player's viewpoint to move correspondingly.

Although soft-lock area140is depicted as a circular area inFIG. 1, the area may be of any shape or size depending on the degree of assistance desired. In addition, whileFIG. 1depicts a circle demarcating soft-lock area140, in some embodiments, soft-lock area140is an “invisible,” non-demarcated area.

FIG. 3is a flow chart of a process in accordance with aspects of the invention. The process may be performed, for example, by a video game system such as described in connection withFIG. 5, below.

In block310, the process presents a virtual environment on a touchscreen-based device. In many embodiments, the virtual environment will be a level or world in which the weapons-related video game is played.

In block320, the process presents a user interface to the user, the user interface comprising one or more graphical user input elements representing one or more snap-to-target buttons as discussed inFIGS. 1 and 2. In many embodiments, the user interface will comprise two snap-to-target buttons, which assist the player in taking aim at the highest-priority targets to the right and left of the player's avatar (or viewpoint). However, any number of snap-to-target buttons may be used. For example, a single snap-to-target button may be used to assist the player in taking aim at the highest-priority target to the player on any side of the player. Alternatively, additional snap-to-target buttons may be used to assist the player in taking aim at targets above and below the player.

In block330, the process instantiates one or more targets in the virtual environment. In many embodiments, the targets may be enemy combatants in the weapons-related video game.

In block340, the process determines a first viewpoint for viewing the virtual environment. The process then renders the virtual environment from the determined viewpoint. Depending on the type of game (e.g., first-person game, third-person game, side-scrolling game, etc.), the viewpoint may be determined relative to the player's avatar, the player's viewpoint, or some other virtual camera location.

In block350, the process assigns a priority to at least one of the instantiated targets. As discussed above, a target's priority may be based on a number of factors approximating the target's threat to the player or the target's danger level. For example, a target's priority may be based on the one or more of: the target's proximity to the player's avatar (or viewpoint); the target's proximity to the player's avatar's facing direction (i.e., the z-axis); the total amount of damage inflicted by the target on the player; the amount of damage inflicted by the target on the player in a given amount of time (e.g., the last 3, 5, or 10 seconds); the amount of damage the target is capable of inflicting in a given shot and/or amount of time (e.g., the damage rate of the target's weapon); the target's health; etc. In some embodiments, the process may only assign priorities to a subset of the instantiated targets, for example, only those targets to the left or right of the player's avatar (or viewpoint), only those targets currently attacking the player, or only those targets currently visible to the player.

In block360, the process determines a highest-priority target out of the targets that have been assigned a priority.

In block370, the process receives an indication that the player has selected a snap-to-target button.

In block380, in response to receiving the indication, the process determines a second viewpoint for viewing the virtual environment, the second viewpoint being determined relative to the highest-priority target, which in some embodiments is a highest priority target in a direction corresponding to a direction indicated by or corresponding to a direction associated with the selected snap-to-target button. For example, the viewpoint may pan to center the player's crosshair on the highest-priority target. In some embodiments, the second viewpoint may position the crosshair such that a shot fired would hit the highest-priority target. In some embodiments, the second viewpoint may position the crosshair within a predefined distance from the highest-priority target but such that a shot fired would still miss the highest-priority target. In some embodiments, gameplay may temporarily enter a slow-motion mode, which further assists the player in taking aim at the highest-priority target.

The process then returns.

FIG. 4is a flow chart of a process in accordance with aspects of the invention. The process may be performed, for example, by a video game system as described in connection withFIG. 5, below.

In block410, the process presents a virtual environment on a touchscreen-based device. In many embodiments, the virtual environment will be a level or world in which the weapons-related video game is played.

In block420, the process presents a user interface comprising a crosshair. The user interface further comprising a predefined area around the crosshair (i.e., the soft-lock area) that may or may not be visible to the user. As discussed above in connection withFIG. 1, when a target is within soft-lock area, the crosshair is automatically moved onto a portion of the target within the soft-lock area. In some embodiments, the soft-lock area may be a circular area around the crosshair, but the soft-lock area may be of any shape or size depending on the degree of assistance desired.

In block430, the process instantiates one or more targets in the virtual environment. In many embodiments, the targets may be enemy combatants in the weapons-related video game.

In block440, the process determines whether a target is within the soft-lock area. If a target is within the soft-lock area, the process proceeds to block450.

In block450, the process moves the crosshair onto the target that is within the soft-lock area. In many embodiments, the process moves the crosshair independently of the player's viewpoint. Alternatively, the process may move the crosshair and the player's viewpoint in correspondence.

The process then returns.

FIG. 5is an example of a block diagram of a processor and associated circuitry useful in a touchscreen-based device in accordance with aspects of the invention. As shown inFIG. 5, a processor511is connected to other components via a bus. The other components include a main memory513and a removable memory interface515, which may be coupled to a removable memory device, for example, a SD memory card. The processor may execute instructions retrieved from main memory and/or the removable memory device to control game play. For example, the instructions may be for determining possible movements, positions, and locations of the player's avatar and/or targets.

The processor is coupled to an audio driver521and a video driver523. The audio driver produces sound signals and the video driver produces image signals. The sound signals and image signals are transmitted via a display I/O device525. The display I/O device generally supplies the sound and image signals to a sound and display devices incorporated in the touchscreen-based device.

The processor may also be coupled to a user I/O device517, a wireless transceiver519, an Internet I/O device527, and other circuitry529. The user I/O device may receive signals from a touchscreen being used by the player and providing inputs, for example, during gameplay. The Internet I/O device provides a communication channel that may be used, for example, for multiple player games.

FIG. 6is a flowchart of a further process in accordance with aspects of the invention. The process discussed with respect toFIG. 6may be performed, for example, by a video game system as described in connection withFIG. 5.

In block611the process presents a virtual environment as part of video game play. The process may present the virtual environment, for example, on a display of a handheld device with a touchscreen, the handheld device providing a video game system. The virtual environment may present a view, from a particular viewpoint, of a virtual world that includes targets.

In block613the process presents a user interface. In various embodiments the presentation of the user interface may be accomplished before, during, or after the presentation of the virtual environment. The user interface includes at least one user selectable input for switching targets. In some embodiments the selectable input is associated with a particular direction in the virtual environment. In some embodiments the at least one selectable input is a plurality of user selectable inputs for switching targets, with each of the plurality of selectable inputs associated with a corresponding different direction.

In block615the process determines if a target switch request has been received. The target switch request is, in some embodiments, in the form of an input signal indicative of selection of one of the selectable inputs for switching targets. If a target switch request has been received, the process continues to block617, otherwise the process returns.

In block617the process determines a new target. In some embodiments the new target is a target having a highest priority. In some embodiments the new target is a target having the highest priority, excluding any target currently having a status as a selected target. A selected target is, in some embodiments, a target previously identified as a new target or, in some embodiments, a target which is currently within a predefined range of an aiming indicator, for example a crosshair, in the video game virtual world. In various embodiments the new target is a target having a highest priority in a direction associated with the selected input for switching targets. For example, in some embodiments, the crosshair serving as an aiming indicator may be resident on a first target when a left direction target switch input is received, and the process selects a highest priority target to the left of the crosshair as the new target.

In block619the process presents the virtual environment including display of the new target. In some embodiments the process pans from a current view of the virtual world from the viewpoint to a new view from the viewpoint. In some embodiments the new view is centered about the new target, in some embodiments the new view includes the new target, but the new target is not centered in the new view.

In block621the process places an aiming indicator near, but not on, the new target. In some embodiments the operations of block621occurs as part of the operations of block619, in other embodiments the operations of block621occur before or after the operations of block619. In some embodiments the aiming indicator is placed a predefined distance away from the new target. In some embodiments the distance is a distance such that a discharge from a weapon aimed at the aiming indicator would not hit the new target. In some embodiments the aiming indicator is placed a predefined distance and at a predefined direction from the new target. In some embodiments the predefined direction is based on the direction associated with the selected target switch input.

The process thereafter returns.

Although the invention has been discussed with respect to various embodiments, it should be recognized that the invention comprises the novel and non-obvious claims supported by this disclosure. Furthermore, all or portions of the subject innovation can be implemented as a system, method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware or any combination thereof to control a computer to implement the disclosed innovation.