 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to the field of interactive video games.
2. Background Art
Existing video games have the disadvantage of lack of physical interaction
with the game. Typically only the player's hands are used to manipulate
controllers, such as a joystick, buttons, trackballs, etc. As a result,
the games are relatively sedentary. The feedback from a prior art video
game is only visual and or auditory. When a goal is accomplished during
play of the game, such as "shooting" a space ship, "striking" a displayed
opponent, etc. the act itself is displayed, and a confirming sound or
musical cue is generally reproduced.
Some prior art video games provide movement of the player in response to
play of the game. For example, video games that involve driving or flying
may include, for example, a cockpit in which the player sits. Movement of
the joystick causes the cockpit itself to tilt left or right, or possibly
to pitch forward and back, in association with movement of a display
element or icon. Even in such a system, the player is relatively passive,
all movement being initiated by movement of the joystick. In addition,
there is no other event feedback in the event of collisions, etc.
Some prior art video games employ a stylized "motorcycle" on which a player
sits. By leaning left or right, and turning the handlebars, the player
"steers" a displayed motorcycle. Such a system is limited to left and
right movement of the player and lacks tactile event feedback.
Another disadvantage of prior art video games is the limited number of
players that can participate simultaneously. In prior art video games,
typically two players alternate play, with no interaction between them. In
some games, players can compete simultaneously as a team or sometimes as
opponents. However, prior art video games do not provide the ability for
large numbers of players to participate simultaneously.
SUMMARY OF THE INVENTION
An interactive video game with physical feedback is described. A plurality
of icons are provided on a display. Each icon represents one of a
plurality of players. A plurality of positioning devices, one for each
player, are provided in front of the display. Each player stands on the
positioning device, and the positioning device reacts to shifts in weight
of the player and tilts in the direction in which the player shifts.
Movement of the positioning device causes the display icon corresponding
to the positioning device to move accordingly. When the player shifts
left, the positioning device shifts left, and the display icon moves left.
Each player moves the player's own positioning device to control and move
the player's corresponding display icon.
Each player attempts to cause collisions with the icons of other players
and avoid the icons of players attempting to cause collisions. In one
embodiment, each player begins with a predetermined number of points. A
player on the receiving end of a collision loses points, A player causing
a collision does not lose points. At the end of a predetermined time
period, the player with the most points is the winner.
In addition to the display icons representing each player, the display
includes planets, galaxies, and meteor showers. Colliding with any of
these objects results in loss of points. The meteor shower occurs at
random one or more times during active game play.
When there is a collision involving a display icon or the edge of the
display, a feedback mechanism causes a composite jolt to the positioning
device in one of a number of possible ways, depending on the type and
speed of collision. This tactile feedback adds realism to the playing of
the game. In addition to the auditory and visual cues of a collision, the
player actually feels the bumps indicating a collision. The collision is
affected on the positioning device itself, requiring the player to recover
or attempt to hold a desired course during game play.
In addition to the objects with which a player's icon may collide, there
are also areas on the display representing regions of turbulence. These
regions are found around certain planets and gas clouds.
When a player's icon enters one of these turbulent regions, the feedback
mechanism causes the positioning device to vibrate at varying speeds and
in a number of possible ways depending upon the area of turbulence and the
speed of motion of players' icons. This tactile feedback also adds realism
to the playing of the game.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1A is a block diagram of the game system of the present invention.
FIG. 1B is a top view of a positioning means.
FIG. 1C is a perspective view of a positioning means.
FIG. 1D illustrates the platform and game axes.
FIG. 2 is a flow diagram of the overall operation of the invention.
FIG. 3 is a flow diagram of the attract mode of the invention.
FIG. 4 is a flow diagram of the game play mode of the invention.
FIG. 5 is a flow diagram of the initialization process.
FIG. 6 is a flow diagram illustrating the calculation of acceleration and
velocity.
FIG. 7 is a flow diagram illustrating the identification of collisions.
FIG. 8 is a flow diagram illustrating a method for identifying the type of
a collision.
FIG. 9A is a flow diagram illustrating the scoring of the invention.
FIG. 9B illustrates velocity normal to the collision point.
FIG. 10 is a flow diagram illustrating screen update.
FIG. 11 is a flow diagram illustrating the end of game sequence.
FIG. 12 illustrates display region crossover.
FIG. 13 illustrates the arrangement of the positioning devices with respect
to the display.
FIG. 14 illustrates the display of the present invention.
FIG. 15 illustrates the beam splitter of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
A method and apparatus for providing an interactive video game with
physical feedback is described. In the following description, numerous
specific details are set forth in order to provide a more thorough
description of the present invention. It will be apparent, however, to one
skilled in the art, that the present invention may be practiced without
these specific details. In other instances, well-known features have not
been described in detail so as not to obscure the invention.
The present invention is a video game for multiple simultaneous
participation. Each player "rides" his own joystick or positioning device.
A perspective view of a positioning device that can be used with the
present invention is illustrated in FIG. 1C. Referring to FIG. 1C, a
steering mechanism 182 is mounted on the top surface of a support platform
180. The steering mechanism 182 is mounted to the top surface of upper
platform 180 at a radial position near the periphery of circular platform
180. A player stands on support platform 180 and holds the handlebars of
steering mechanism 182. By shifting the players weight, the support
platform is tilted about a central pivot. Displacement of the support
platform is translated into position signals that control movement of a
display icon.
FIG. 13 illustrates one arrangement of positioning devices in the present
invention. Eleven positioning devices 1-11 are disposed in an array of
three rows of four, three, and four positioning devices respectively. The
plurality of positioning devices 1-11 are disposed in front of a display
1300. One display icon is displayed on the display 1300 for each
positioning device in the array.
FIG. 14 illustrates the display 1300 of FIG. 13. The display 1300 displays
a plurality of icons 1-11 that correspond to each of positioning devices
1-11. To aid a player in identifying his associated display icon, each
icon includes a number corresponding to the number of the player's
positioning device. In addition, each display icon has a different
geometric border and/or color than any other icon, so that each display
icon has a unique appearance. In the present invention, the display icons
may be thought of as space craft or space ships that are to be piloted
(i.e. "steered") by each player. The display icons are illustrated in the
"begin game" orientation, to permit easy identification. During active
game play, each player may move his display icon about the display 1300 by
moving his associated positioning device.
The image viewable by a player includes other objects such as planets 1320
and 1330, gas cloud 1340, and meteors 1310A-1310D. These objects have
special properties that affect the movement of the display icons during
the active play of the game.
During the pre-game period, players are encouraged to step onto a
positioning device. Each positioning device is marked with a
representation of a display icon in the same shape and color, and with the
associated number. In addition, the physical location of each positioning
device in the array corresponds to the physical location of the display
icon in the pre-game array.
During game play, each player uses shifts in body weight to move the
positioning device. In response, the player's associated display icon
moves in the direction in which the positioning device is tilted. In this
manner, the player "steers" the display icon about the display. The player
attempts to "hit" other display icons to obtain points, and to avoid
collisions with other display icons, the planets 1320 and 1330, and
meteors 1310A-1310D to avoid the deduction of points. The player can move
the player's associated display icon for a fixed period of time. At the
end of the time period, the player with the most points is the winner.
When a player's associated display icon collides with another object or the
edge of the display 1300, a feedback mechanism causes a composite jolt of
that player's positioning device. In this manner, the play of the game is
more realistic, as auditory, visual and physical feedback is provided to
the player. When the display icon of a player moves into the gas cloud
1340, the feedback system provides continuous shaking and vibration of the
positioning device, as if the player is subjected to drag turbulence.
Positioning Device
The present invention uses a positioning device on which a player stands.
The device consists of a support member and a steering bar or handle bar
to be grasped by the player. The player shifts his weight on the support
member and thereby displaces the support member. Position sensors coupled
to each positioning device detect the displacement and translate it into
x-y coordinates. One such positioning device that can be used with the
present invention is described in co-pending U.S. patent application Ser.
No. 08/069,566, filed May 28, 1993, entitled Apparatus for Providing
Position Signals and assigned to the assignee of the present invention and
incorporated herein by reference.
The positioning device provides the position and weight data and player
feedback for the present invention. FIG. 1B provides a top-view of the
Positioning Device 146 comprising upper platform 180, linear transducers
162A-162B, air cylinder 178, and pneumatic spring 170.
Linear transducers 162A-162B produce Y- and X-position signals 196-198,
respectively, that are provided to Device Controller 150. Memory storage
means within the positioning device 146 hold algorithms for converting the
platform position, x-position 198 and y-position 196, and player weight,
weight and pressure sensors 194, into the correct game information for
transmission to CPU 100. That is, Device Controller 150 transfers Y- and
X-position signals 196-198 as well as weight and pressure sensor signals
194 to computer 100 through communication channel 145.
Device Controller 150 receives weight and pressure signals 194 from air
cylinder 178. The Device Controller 150 provides a fill signal 172 and a
kick signal 174 to fill valve 168 and kick valve 166, respectively. Kick
valve 166 controls air flow 184 to air cylinder 170 from air supply 186.
Similarly, fill valve 168 controls air flow 184 from air supply 186 to
platform stabilization air cylinders that are located along the periphery
of platform 180.
Kick valve 166 (or pneumatic servo valve) in FIG. 1B produces various
"bumps" in the system in response to a kick control signal 174 from the
computer 100 through control/interface 144. The kick control signal 174
opens and closes the pneumatic servo valve 166 causing pancake air
cylinder 178 to expand thereby driving platform 180 upward in a vertical
direction momentarily. These "bumps" are used in the present invention to
provide physical signals or cues to a player such as when the player's
vehicle collides with an object in the game. This provides an added
dimension of realism to the computer game.
The Device Controller 150 operates the valves 166 and 168 using kick and
fill control signals 174-172, respectively. The weight and pressure sensor
signal 194 is provided to Device Controller 150 from the linear
transducers of air cylinder 178. User-detection sensors are incorporated
in the system to detect when a user is on upper platform 180. The weight
and pressure signal 194 is provided to Device Controller 150 to indicate
the presence of a user. In response, Device Controller 150 provides fill
control signal 172 to fill valve 168 causing it to retract.
Once the user is loaded onto upper platform 180, upper platform 180 is able
to pivot smoothly through 360.degree.. FIG. 1C illustrates the reference
coordinate system for X- and Y- position signals 198-196 generated by the
system. The X-Y coordinate system indicates that Y values change in the
longitudinal direction along the front-back axis 192A. Accordingly, X
values change in the lateral direction along the left-right axis 192B. The
Y- and X-position signals 196-198 produced by linear transducers 162A-162B
are provided to Device Controller 150.
In one embodiment of the present invention, linear transducers 162A-162B
are mounted 45.degree. to the front-back axis 192A and left-right axis
192B. To produce front-back and left-right X and Y vectors, the Y-and
X-position signals 196-198 must be combined and rotated by Device
Controller 150.
Device Controller 150 processes and transmits the position signals 196-198
to computer 100 through communication link 145. Display 164 provides a
tally of the score achieved by a player during the operation of the
present invention. Further, at the end of a game, each positioning device
is placed in a locked, stationary position.
Positioning Calculations
If X and Y transducers 162A-162B are not placed in line with the
left-to-right (i.e., X) axis or the front-to-back (i.e., Y) axis
(respectively), the X and Y values must be rotated to produce X and Y
vectors relative to the left-to-right and front-to-back axes of the
platform of the positioning device.
If linear transducers 162A-162B are mounted 45.degree. to the front-back
axis 192A and left-right axis 192B of the positioning device, the Y-and X-
position signals 196-198 must be combined and rotated by Device Controller
150 to produce front-back and left-right X and Y vectors. FIG. 1D
illustrates the orientations of the raw input, and the positioning vectors
generated by Device Controller 150. That is, X and Y input values received
from the positioning device and within the platform.sub.-- x and
platform.sub.-- y coordinate system must be combined and rotated to
produce X and Y positional input within the game x and game.sub.-- y
coordinate system as follows:
rotated.sub.-- X=(platform.sub.-- x+platform.sub.-- y)*cos(45.degree.)
rotated.sub.-- Y=(-platform.sub.-- x-platform.sub.-- y)*cos(45.degree.)
To increase the speed of the calculation, cos(45.degree.) can be
approximated to 707/1000. This approximation should have sufficient
accuracy for game play. Thus, the resultant range of the rotation
calculation is .+-.723. If the X and Y position values expected by the
game play module are within the range of 0-254, a further scaling can be
performed on the rotated value (i.e., rotated.sub.-- x or rotated.sub.--
y) to produce a game value within the expected range. The scaling
calculation is as follows:
game.sub.-- value=(rotated.sub.-- value+723)*100)/569)
Further, platform readings for X and Y axes should be centered at zero when
the platform is in its stabilized position. To meet this requirement, raw
platform readings are normalized as follows:
platform.sub.-- x-raw.sub.-- x.sub.-- reading+x.sub.-- offset
platform.sub.-- y=raw.sub.-- y.sub.-- reading+y.sub.-- offset
where:
x.sub.-- offset and y.sub.-- offset are calculated from a series of x and y
readings taken each time the positioning device is subjected to a
calibration process.
Operation Overview
FIG. 2 illustrates an overview of a processing flow of the operation of the
present invention. An initialization procedure is invoked at processing
block 200. Once the initialization procedure is completed, the attract
mode of the present invention is invoked at processing block 202. The
present invention operates in the attract mode when a game is not in
progress (e.g., in between games or when a game is paused). In attract
mode, the present invention generates visual and audio effects to provide
a center of interest for potential players. Once the attract sequence is
completed and a game is not in a pause mode, the game play module is
invoked at processing block 204. The system returns to attract mode after
the game play module is completed.
Initialization
An initialization process is performed when the system is initially
invoked. Referring to FIG. 5, Initialization reads screen calibration
values from a file. These values are used to provide a smooth transition
between the multiple displays used in the present invention. The present
invention uses multiple rear projection screens. The output to each screen
is blended with the other screen output such that the screens appear to be
one screen. The blend is provided by overlapping some portion of the
screens' display area. When an object moves from one screen to the next,
the object appears to remain in the same position on the display, and the
object's coordinates are updated to reflect its new coordinate location in
the new screen.
A calibration process is performed to identify the areas of overlap, a
transition point between the screens, and the offset (in pixels) from one
screen to the next. The calibration process establishes the coordinates of
the top left corner of each screen relative to the top left screen, and
the coordinates of the dimensional props as seen by the game software.
Once the calibration has been performed, calibrations are only necessary in
special cases such as when equipment is physically moved from its current
location. However, the calibration process can be performed any time the
game is in attract mode and paused.
The present invention provides the ability to provide objects that are
viewable by the players as dimensional props positioned behind the
"pepper's ghost" glass. These objects are merged with other, projected
images into a single, combined image. For such objects, a calibration
process further provides calibration data to indicate the location of
these objects relative to the display and the projected images. This
information can be used to determine, for example, when ships collide with
these objects.
Referring to FIG. 5, the screen calibration data from the calibration
process are read at block 500. The calibration data for dimensional prop
objects (e.g., planet or gas cloud) are read at block 502. At processing
block 504, the "ship" game icons are added to the system. The process of
adding an icon includes drawing the icon in an offscreen memory location.
The icon in memory can be copied to or erased from an onscreen location
during the animation process to speed up animation during a game. At block
508, processing returns to the GamePlayModule (i.e., after processing
block 406 in GamePlayModule).
To provide real-time response to the players, GamePlayModule illustrated by
FIG. 4 creates a virtually simultaneous reaction to different processing
stimuli such as player input, collisions between two or more icons, screen
updates, and game termination. At decision block 407 (i.e., "processing
necessary?"), GamePlayModule responds to processing stimuli, or waits for
such stimuli.
Attract Module
Referring to FIG. 3, the Attract Module of the present invention begins, at
processing block 302, to display an animation sequence and to generate
sound effects. If, at decision block 304 (i.e., "attract sequence
completed?"), the attraction sequence is not finished, processing
continues to check for completion of the attract sequence at decision
block 304. If the attract sequence is finished at decision block 304,
processing continues at decision block 306.
A game may be paused during its execution for various reasons. When a pause
mode is detected, the attract sequence is invoked and loops indefinitely,
or until a resume mode is detected. When play is to be resumed, play
starts at the end of the current attract sequence. At decision block 306
(i.e., "operator pause?"), if a pause is not detected, processing
continues at decision block 308 (i.e., "end of attract sequence?"). If the
current attraction sequence is not finished at decision block 304,
processing continues to check for the completion of the sequence at
decision block 304 (i.e., "attract sequence completed?"). When the
completion of the attract sequence is detected at decision block 304, the
GamePlayModule is invoked at processing block 310. When the GamePlayModule
is finished, the attract sequence starts at processing block 302.
GamePlayModule
When the GamePlayModule is invoked, players are astride a positioning
device of the type illustrated in FIG. 1C. A player can determine the
direction and speed of an associated display icon by tilting the device
(i.e., by shifting weight) in a direction. The direction of the tilt, or
pivot, determines the direction of movement of the game icon. The degree
of change in the tilt determines the speed (i.e., faster or slower) of the
movement of the display icon.
The positioning device further provides an ability to determine a player's
weight. Weight information is used to make the positioning device more
responsive to each player. In addition to the weight input, the
GamePlayModule receives positioning input from the player via the
positioning device, and responds by providing feedback to the player
(e.g., via the screen icon).
FIG. 4 provides an implementation flow of the GamePlayModule. At processing
block 400, a player's weight is input from the positioning device. A
player's weight affects the ease with which the positioning device is
moved, and may result in a "ship" icon that moves in a sluggish manner.
Compensation without reference to a player's weight may result in a ship's
movement that appears to jerk in each direction. Thus, information about a
player's weight can be used to customize the feedback provided to a
player.
To optimize the transmission of weight input from the positioning device to
the game computer, weight input can be passed to the game computer as a
byte containing a value from zero to two. A zero value indicates that no
player is present. A value of one indicates a lighter player, and a value
of two indicates a heavier player.
A compensation factor is applied to the velocity calculation to provide
more of a response from a slighter movement of the positioning device by a
lighter player (e.g., children). A second weight compensation factor is
applied for heavier players (e.g., adults). Weighing a player at the
beginning of the game is done to identify the correct weight compensation
factor to be used to scale the raw X and Y positioning input from the
position device.
If the player's weight is less than or equal to a weight threshold (e.g.,
fifty pounds) at decision block 402 (i.e., "player's weight >50 pounds?"),
a "lighter weight" compensation factor is calculated at processing block
404, and processing continues at decision block 407. If the player's
weight is greater than a given weight threshold, a second weight
compensation factor is selected at processing block 406, and processing
continues at decision block 407. Processing continues by identifying
processing requirements (e.g., input detected from a player, collision
detected, screen update, or end of game) at decision block 407 (i.e.,
"processing necessary?"), and processing them when necessary.
Player Input
At decision block 408 (i.e., "input detected?"), the system reacts to input
detected from the player. If no input is detected, processing continues by
identifying other processing requirements at decision block 407 (i.e.,
"processing necessary?"). If input is detected at decision block 408,
CalcAccellerationVelocity is invoked at processing block 410.
CalcAccelerationVelocity
Movement of a player's positioning device is used to determine the
direction and speed of the player's display icon.
CalcAccellerationVelocity uses this movement, or tilt, of the positioning
device to calculate the speed that the player's display icon travels in
the direction of the tilt.
The tilt is input in the form of x and y values. In the preferred
embodiment, the tilt in either the x or y direction is a number between
zero and two hundred and fifty-four (i.e., 254). A zero value represents
the extreme movement on the x and y axes in the leftward or downward
directions, respectively. A value of 254 represents extreme movement in
the right and upward direction on the x and y axes, respectively. A value
in the exact middle of the range represents no change in movement.
Referring to FIG. 6, the new tilt, Anew is obtained from the positioning
device at processing block 602 by subtracting the offset for the center
position (i.e., determined at calibration) from the positioning device
input. The current tilt, previous tilt, and two compensation factors
(i.e., a weight compensation factor and a derivative control) are used to
calculate a new velocity. The new velocity is calculated at processing
block 604 as follows:
V.sub.new =V.sub.old +K.sub.1 (A.sub.new +K.sub.2 (A.sub.new -A.sub.old))
where:
V.sub.new is the velocity computed in this calculation;
V.sub.old is the velocity computed in the previous calculation;
A.sub.old is the positioning device input used in the calculation of
V.sub.old ;
A.sub.new is the most-recent positioning device input;
K.sub.1 is the weight compensation factor; and
K.sub.2 is a scaling factor to adjust the amount of derivative control.
Once the new velocity is calculated, V.sub.old and A.sub.old are updated
with the present velocity and tilt values, V.sub.new and A.sub.new,
respectively. Processing returns to GamePlayModule at block 608 (i.e.,
decision block 407 in GamePlayModule).
Game Object Collisions
Scoring is determined based on the number and type of collisions. A player
causing a collision with another player is awarded points. A player that
is collided with by another player, or by an asteroid, or who collides
with a planet, loses points. So, for each collision, the type of collision
is determined, and, in the case of a player to player collision, the
"winner" of the collision is determined. The winner of a collision is the
player whose display icon has the highest velocity.
In the GamePlayModule of FIG. 4, collisions between one or more game icons
provide feedback to each player of a game object involved in a collision.
At processing block 414, IdentifyCollisions is invoked to identify any
collisions. FIG. 7 provides an implementation flow of IdentifyCollisions.
Each game icon is examined with respect to all of the other game icons
until all icon combinations are examined. At decision block 702 (i.e.,
"processed all objects?"), if all game icons have been examined, no
collision exists, and processing returns to GamePlayModule at block 720.
If all of the game icons have not been examined, processing continues at
block 706 to get the next icon combination.
The process used to detect a collision depends on the footprint of each
icon in the icon combination. Each game icon can be contained in a
spherical or non-spherical object. The type is examined at decision block
708 (i.e., "type of objects?"). If the objects are spherical, a collision
is detected by calculating the difference between the center points at
processing block 710. The difference is compared to the sum of the radii
at decision block 714 (i.e., "difference<sum of objects' radii?"). If the
difference is greater than or equal to the sum of the objects' radii, no
collision has occurred, and processing continues at decision block 702
(i.e., "processed all objects?"). If the difference is less than the sum
of the radii, a collision condition exists and processing returns to
GamePlayModule at block 720 (i.e., decision block 416 in GamePlayModule)
to process the collision.
If the object is non-spherical at decision block 706 (i.e., "type of
objects?"), a scan is performed to-determine if the objects' footprints
overlap. The result of the scan is examined at decision block 716 (i.e.,
"scanline process detect collision?") to determine whether a collision
exists. If an overlap is not present, a collision has not occurred, and
processing continues at decision block 702 (i.e., "processed all
objects?"). If an overlap exists, a collision condition exists and
processing returns to GamePlayModule at block 720 (i.e., decision block
416 in GamePlayModule) to process the collision.
Referring to the GamePlayModule illustrated by FIG. 4, if a collision
condition is not detected in IdentifyCollisions, processing continues by
identifying other processing requirements at decision block 407. Decision
block 416 (i.e., "collision detected?"), determines whether a collision
was detected by IdentifyCollisions. If a collision condition does not
exist at decision block 416, processing continues at decision block 407
(i.e., "processing necessary?") to identify other processing requirements.
If a collision is detected by IdentifyCollisions, Collision is invoked at
processing block 418 to process the collision and provide feedback to the
player.
Ship-Ship Collision
Referring to FIG. 8, the type of game objects involved in a collision
determines the type of output generated by the system to simulate a
collision. Thus, at decision block 802 (i.e., "type?"), the type of
objects involved in the collision is examined. If two ships collide,
sparks are generated at processing block 804.
A collision further provides audio feedback. The present invention includes
a MIDI sound effects generation means to provide additional player
feedback. Each positioning device used in the present invention has an
associated MIDI channel. When two ships collide, the sound associated with
the collision is sent over each of the channels assigned to the involved
ships at processing block 806.
Further, in the present invention ships are treated as having equal mass.
Thus, the ships rebound from one another at block 808. A "bump" signal is
sent to the positioning device's controller at block 810. The "bump"
commands results in a slight jolt of the positioning device of each player
of a ship involved in the collision. This provides additional feedback
that a collision has occurred. Finally, a command is generated to flash
strobe lights associated with each positioning device at block 812.
Scoring is invoked to at processing block 813 to determine the score
modifications for each ship. Processing returns to GamePlayModule at block
860 (i.e., processing block 407 in GamePlayModule).
Ship-Planet Collision
If it is determined at decision block 802 of FIG. 8 that a ship and a
planet are involved in the collision, processing continues at processing
block 814. An explosion is generated at processing block 814. The sound
associated with a collision between a ship and planet is sent over the
channel assigned to the involved ship at processing block 816. The ship is
deflected from the planet (i.e., repelled) at block 818. A "bump" signal
is sent to the positioning device controller associated with the ship at
block 820. The "bump" commands results in a slight jolt of the positioning
device on which the ship's player stands. The ship's score is decremented
at processing block 821. Processing returns to GamePlayModule at block 860
(i.e., decision block 407 in GamePlayModule).
Ship-Asteroid Collision
If it is determined at decision block 802 of FIG. 8 that a ship and an
asteroid are involved in the collision, processing continues at processing
block 822. An explosion is generated at processing block 822. The sound
associated with a collision between a ship and an asteroid is sent over
the channel assigned to the involved ship at processing block 824. The
asteroid is broken up into fragments at block 826. The ship is deflected
from the asteroid at processing block 828. As the fragments of the
asteroid reach the edge of the combined display, the pieces are removed
from the display at processing block 828. As a further result of the
collision, a "bump" signal is sent to the positioning device controller
associated with the ship at block 832. The "bump" commands results in a
slight jolt of the positioning device upon which the ship's player stands.
Further, the ship's score is decremented at processing block 834.
Processing returns to GamePlayModule at block 860 (i.e., decision block
407 in GamePlayModule).
Ship-Edge Collision
If it is determined at decision block 802 of FIG. 8 that a ship and an edge
of the combined display are involved in the collision, processing
continues at processing block 836. Th | | |
