|Publication number||USRE35314 E|
|Application number||US 08/254,482|
|Publication date||Aug 20, 1996|
|Filing date||Jun 6, 1994|
|Priority date||May 20, 1986|
|Publication number||08254482, 254482, US RE35314 E, US RE35314E, US-E-RE35314, USRE35314 E, USRE35314E|
|Inventors||George E. Logg|
|Original Assignee||Atari Games Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (18), Non-Patent Citations (12), Referenced by (59), Classifications (9), Legal Events (7)|
|External Links: USPTO, USPTO Assignment, Espacenet|
.Iadd.This is a continuation of 07/473,262, filed Jan. 31, 1990, now abandoned, which is a Reissue of 06/865,387 filed May 20, 1986, now U.S. Pat. No. 4,738,451. .Iaddend.
The invention pertains to the field of video games, and, more particularly, to the field of video games where multiple players may simultaneously control multiple characters and are encouraged by the game to cooperate in defeating a maze populated by longevity decreasing entities to obtain limited resources in the form of longevity increasing resources.
In prior video games, multi-player games have been available where each player controls a character independently and without being forced to cooperate by the game. One example is Dandy. In this game, each player may control his particular character in a maze, but the characters are not forced by the game to cooperate in negotiating the maze in the sense that each player may independently move his character off the screen to wander blindly, while the other players are manipulating their characters on the screen. In another game, Ali Baba, the players are also allowed to independently control the actions of their characters, but each player is assigned a time slice during play of the game and may control his character only during this time slice. The time slice is rotated so that each player may take a turn, but the players may not all simultaneously control their characters at the same time to independently or cooperatively negotiate the maze or defeat longevity decreasing entities in the maze. The characters do not need to be all in the same portion of the maze. Each character's portion of the maze is displayed independently during the character's time slice. Thus no cooperation between characters to negotiate the maze is forced by the game.
It is useful in a multi-player video game to allow any player to enter the game or leave at any time. This makes the game more social in the sense that a game may be started by any player or players and other players may join at will and begin cooperating or competing with the other players by simultaneously controlling his charater while the other players are manipulating their respective characters. Neither of the aforementioned games allows simultaneous control of all characters, independent entry and departure of players at will and forced cooperation between players. In Ali Baba, the players may enter and leave at any time, but may not all simultaneously control their characters. Further, there is no restriction on the characters wanderings through the maze in the sense that the display changes during each player's time slice to show the particular portion of the maze in which that player's character is located. The characters do not have to all be visible at all times in the same portion of the maze. In Dandy, there is no restriction which prevents the characters from leaving the visible area, and the players must all start at the same time. Thus, no current video game of which the applicants are aware provides the features of allowing the players to join the game or leave at any time and simultaneously control their characters. Further, the games known to the applicants do not encourage the players to cooperate in defeating the maze.
In accordance with the teachings of the invention, an apparatus and method are provided to fill the above described need. The invention includes known video game apparatus including a computer, typically a microprocessor, which runs a program implementing the rules of the game and which causes the computer to read the controls at each player station and determine how many players are in the game and which characters each player is controlling. The computer provides for multiple characters, each of which may have different attributes such as speed of movement, fighting abilities, magical powers, shot power, shot width and/or other attributes. Each character has a longevity attribute which the computer individually calculates based upon events which happen to that character in the game. In arcade versions of the game, each player may add to the longevity of his character by adding more coins at any time during play of the game. The computer also provides a maze (some embodiments provide multiples mazes with exits between mazes which may be opened if the player's character obtains possession of a key) in which the computer places certain limited resources. Such limited resources may include such things as longevity increasing resources, e.g., food, or other attribute affecting items such as potions which may enhance certain attributes such as magical powers or keys which allow a player to leave one maze through an exit and enter another maze. In some embodiments of the invention, when a character obtains possession of a key, that character may open a door in the maze through which all the characters may pass to enter another maze. In some embodiments, the characters have their longevity attributes increased as they pass through the door. In still other embodiments, the character which first obtains possession of the key gets bonus longevity points added to that character's longevity which is greater than any longevity points, if any, added to the other character's longevity attribute. In still other embodiments, the other characters receive longevity points in accordance with the order in which they exit through a door in the maze to another portion of the maze or to another maze. All these embodiments are equivalent in that they encourage competition among the players to increase their longevity.
The computer also populates the maze with one or more types of longevity decreasing entities which detract from a character's longevity unless the character successfully avoids the effects of the entity. Typically, these entities are monsters which attack the characters but which may be destroyed by the character's actions in fighting the monster or monsters. In some embodiments, there are more than one maze or levels of the same maze, and the monsters may act differently in different mazes or on different levels or in different portions of the same maze. The entities may also be traps, poisoned food or other things. The players move their controls and the computer responds by causing the characters to move through the maze. The players may cause their characters to fight attacking monsters, and to attempt to obtain possession of the limited, longevity enhancing or attribute affecting resources. All of the above action is displayed by the computer on a video display by accessing graphic data stored in a memory, typically a ROM, and causing standard video display driver circuitry to use the graphic data to display the maze, the characters, their shots or other fighting action, the monsters and the limited resources.
The computer allows any player to join the game at any time regardless of how many other players are in the game provided there is an unused character available for a new player to manipulate. Entry of a new player or departure of a player may occur regardless of how long the game has been played or when other players leave the game. In arcade versions of the game, players are forced to depart in the sense that their control inputs are ignored when the player's character dies, i.e., the longevity attribute for that character falls to zero. However, in these embodiments any player may extend the longevity of his character indefinitely by adding more coins to the coin slot dedicated to his character. The computer reads the coin accepting apparatus as a peripheral device and takes the number of coins dropped for each character into account when computing the longevity attribute of each character. Other factors taken into account during the longevity attribute calculation for each character are the number of successful attacks on each character by monsters, and/or the number and magnitude of other longevity decreasing events which have happened to that character during the game. When a particular character's longevity attribute reaches zero, that character is out of the game until more coins are dropped or other revival actions are taken to bring the character back to life. Control of the characters is simultaneous in that all players may simultaneously move their controls and the computer will update the positions or actions of their respective characters on the next video frame or as soon as possible after all computations and comparisons have been made and the proper video data has been accessed and sent to the video driver circuitry.
The computer also encourages the players to cooperate during play by comparing the player's character position or desired position with the current displayed screen limits. The current displayed screen may be thought of as a window on the maze (sometimes herein also called the "playfield") which is larger than the displayed window. The current window is scrolled over the playfield based on the center of the currently active characters or by any other suitable measure which keep all the active characters displayed in the current window. The characters are not allowed to leave the current window. Thus, if three characters are cooperating to fight monsters and move in the same direction toward a longevity enhancing resource, but one player wants his character to go in a direction which would take the character out of the current window where the other characters are, the window will not scroll further when the four characters have reached the window limits and are attempting to move in directions which would require expansion of the window to keep them all on the screen. This feature causes the movements of the other three cooperating players/characters to be stymied until the fourth, non-cooperating player decides to move in a direction which will allow the other players to move their characters in the direction toward their objective or vice versa.
FIG. 1 is a block diagram of a standard video game system which may be used to implement the invention.
FIG. 2 is a flow diagram of the main loop of the program.
FIG. 3 is a flow diagram of the substeps in the process of responding to player control inputs in the main loop of the program.
FIG. 4 is a flow diagram ofthe substeps in the process for checking for the addition of new coins by existing or new players and for starting new players in the game by placing their characters in the current maze.
FIG. 5 is a flow diagram of the substeps in the process of checking for and processing of collisions of characters or character shots with monsters, walls, attribute affecting entities, exits, etc.
FIG. 6 is a flow diagram of the substeps in the collision processing routine for processing collisions with exits.
Referring to FIG. 1 there is shown a block diagram of a typical video game system which may be used to implement the video game of the invention. Such systems are known in the art of video game hardware design and the exact implementation details will be known to practitioners in this art. Other systems will also work to implement the video game apparatus of the invention in other embodiments. For example, the GAUNTLET (trademark of Atari Games Corporation of Milpitas, Calif.) game hardware will work with the object code software of the appendices hereto to implement the invention.
In FIG. 1, various player controls 11 such as joysticks for controlling movements of characters, fire buttons, magic buttons and coin accepting apparatus are coupled to computer 12 by bus 14. In the preferred embodiment, the computer 12 is a Motorola 68010, and the program memory 16 stores the programs of the appendices hereto. Typically, the player controls will be treated as peripheral devices and will either be periodically read in polled systems or will generate interrupt signals to the computer 12 in interrupt systems. In the latter, the service routines for the interrupts will cause the computer 12 to determine which player control caused the interrupt and will cause the computer 12 to read the data from the player control that caused the interrupt. The routines to read the player controls are stored in a program memory 16, and are well known.
The program memory 16 stores the program which controls the actions of the computer 12 and which implements the rules of the game. The control flow of the program to implement the novel features of the video game of the invention will be described in more detail below in connection with the discussion of other figures.
The program in program memory 16 establishes a cast of several characters each of which may have different attributes such as speed of movement, magical powers, fighting ability, movement ability, shot power, shot width, etc. Each character also has its own longevity attribute which is changed by an independent calculation of the computer for each character based upon events which happen affecting that character during play of the game. The program also establishes a maze populated by attribute affecting entities. Some entities adversely affect any character's longevity attribute upon which the entities act and are typically monsters, traps or other things which the characters should avoid to prolong their lives. Hereafter these adverse entities will be called monsters, but this term is to be understood as meaning any entity which reduces longevity of characters it affects. Other attribute affecting entities increase longevity and may take the form of food, resting places, healers, energy sources or any other thing which increases longevity. The longevity attribute might also be expressed to the players by the computer in terms of health, power or some other measure of vitality of a character. Hereafter longevity increasing entities will be referred to as food, but this term is to be understood as meaning any entity which increases a character's longevity attribute.
There are also established by the program certain other attribute affecting entities in the game. Such entities change or enhance an attribute or attributes of any character which comes into possession of same, and may affect the attributes of some characters more than others. Such entities may take the form of keys allowing exit from one maze to another, potions to change or enhance magical powers, objects found in the maze or which have fallen into it, treasures etc. All such attribute affecting entities which affect character attributes in a positive manner in the sense of helping the character in some way to negotiate the maze, defeat monsters or increase longevity will sometimes hereafter be referred to as limited resources. In the preferred embodiment, these limited resources will be limited in the sense that there are not enough of them present in the maze to allow all the characters to have as much of them as they want. In other embodiments, these "limited resources" may not be limited at all.
The computer uses a video data base memory 18 to keep track of all the attributes, positions and longevity of the characters and the positions of monsters, shots and other entities in the maze. The graphics data is stored in a graphics data memory 20. The particular graphics data used in the preferred embodiment is given in the appendices hereto. The graphics data for all moving and nonmoving objects in the game such as maze walls, traps, exits, treasures, limited resources, monsters characters, shots, etc. are stored in the memory 20. Some equivalent embodiments may use a separate memory for maze graphics data and another memory for the character graphics. Separate routines performed by the computer 12 or some dedicated logic would be used to access and display each of the sets of graphic data for the maze and non-moving objects therein and for the characters, their fighting actions, movements, shots, etc.
The computer 12 performs the routines stored in the program memory 16 (see appendices hereto for exact object code of preferred embodiment) to read the player controls, compute longevity attributes for each character, cause the characters to move, determine collisions of the characters with monsters, limited resources, maze walls, exits, and the perimeter of the currently displayed window, or collisions of character shots with monsters, exits or other characters etc. Calculations of attributes affected by these events if any are made, and the computer 12 updates the data records in the data base memory 18.
The proper graphic data is then accessed when it is time to display the objects in the current window at their proper positions in the window. The proper addresses for the desired graphic data are sent to the graphics data memory 20 via the bus 22 from the video data base memory 18 under the control of a video display driver subsystem 26. This control is exercised by the video display driver subsystem 26 via addresses sent to the video data base memory 18 over the bus 27. The 65 addresses of the desired graphics objects to be displayed are then sent to the graphics data memory 20 via the data bus 22. The desired graphics data is output at the proper time on a bus 24 to the video display driver subsystem 26. This is a conventional system which generates the proper raster scanning and synchronization control signals on a bus 28 to control a conventional video display 30. Typically, the video subsystem 26 includes logic to convert the graphic data from the graphics data memory 20 to pixel data suitable for creating a bit mapped display of the desired image. The video subsystem also typically contains a line buffer in which the bit mapped pixel data is stored prior to being displayed. Some embodiments may include one or two frame buffers, the purpose of which is to assemble and store the bit map for the current or next frame's displayed window image. The video subsystem also usually contains counters for keeping track of the current row and column position in the raster scanned image of the electron beam in the video display 30 for purposes of properly accessing the corresponding pixel data for that row and column position. The computer 12 may control or read some of the operating parameters of the video display driver subsystem via the bus 32. All of the foregoing is well known technology and further details will not be given here. Typical hardware systems that will work for the tangible elements of the system are taught in U.S. Pat. No. 4,116,444 to Mayer et al. Other patents which describe hardware systems and subsystems which may be used in implementing the invention are U.S. patents: Nos. 4,054,919; 4,045,789; 3,793,483; and 4,016,362. The disclosures of these patents are hereby incorporated by reference.
Referring to FIG. 2 there is shown a block diagram of the program run by the computer 12 in implementing the preferred, coin operated video game of the invention. The game is started when the first player drops a coin to bring his character to life in an arcade version the game or when a player presses his start button in a home version of the game. The computer first draws a maze and places certain limited resources therein, such as longevity increasing food, keys, potions to affect certain character attributes such as magic, etc., treasures and so on as symbolized by block 33. Such routines are well known and need not be detailed here. The computer 12 does not draw in enough of the limited resources for all the characters in the game to have unlimited extensions of their longevity attributes. Only enough longevity increasing resources are drawn in the maze for some of the characters thereby encouraging competition among the players to obtain possession of these limited resources.
After the maze is drawn, the character or characters which have been brought to life are placed in the maze somewhere in the visible window as symbolized by block 34. The details of this process will be supplied below in connection with a discussion of the flow chart of FIG. 3.
Typically, the graphics data memory 20 has stored therein graphic data for a maze which is larger than the window which can be displayed on the screen. The computer 12 keeps track of where the characters are in the maze by updating the x and y coordinate fields (which define the position of the character in the current window) of each character in the database memory 18. The computer 12 then scrolls the window so as to keep all the characters visible in the window at all times. Only so much of the maze as is visible through the current window location is displayed. In the preferred embodiment, when a game is started, the window is located at some known position in the maze and the characters which have been activated are placed somewhere in the window.
Next, the computer 12 polls the player controls 10 to determine what the first player currently playing is doing with his character in terms of desired movements, fighting action, etc. This is symbolized by block 36 where controls for currently active characters are read. The routines to read player controls are well known to those skilled in the programming of video games. Block 36 represents the process of either polling all controls for all players and storing the data read in memory for processing in block 38 or the process of servicing interrupts from player controls as they occur and storing the data read during the interrupt service routines in menory to await processing by the computer 12.
The computer then attempts to respond as symbolized by block 38. This is a task which involves several sub-tasks which are detailed in FIG. 3. Referring to FIG. 3, the first sub-task the computer 12 performs as indicated by control flow line 37 to block 31 is to pick a character which has not been processed yet. Control then flows on path 40 to a test 41 to determine whether that character is still alive, i.e., in the game. The test of block 41 represents a process of accessing the data record for the character picked in block 31 and reading the longevity attribute field and determining if the character is still in the game. If the character is not still in the game, the control inputs from the player attempting to control the dead character are ignored as symbolized by block 43. Control then flows on path 39 to a block 62. If the the character is still active in the game per the test of block 41, the control inputs from the corresponding player must be processed.
The first step in this process is to decide whether the player has manipulated any special control other than a move control, e.g., is trying to exercise a special attribute of his character. The computer 12 provides predefined characters which the players are allowed to manipulate with controls to cause them to shoot, move, excercise their magical powers, etc. Each character, in the preferred embodiment, has different attributes such as speed, magic powers, shot power, shot width, armor strength, etc. In other embodiments, all characters have the same attributes. Either situation will suffice to practice the invention claimed, and each situation is eqivalent to the other in terms of what is critical to the practice of the invention. In embodiments where all players have the same attributes, the computer 12 need not check for whether a particular player is attempting to exercise an attribute which his character may not have so the next step, test 44 may be skipped. In the preferred embodiment, the computer 12 does check to see whether the player is requesting an action other than move, and does check whether the corresponding character has the attribute the player wants to exercise as symbolized in blocks 42 and 44. If the answer to both questions is yes, then block 46 is entered to cause the character to perform the requested function, e.g., shooting, increasing longevity by receiving new coins, starting a new player's character in the maze or exercise of magic powers. Typically, special attributes would include magical powers that not all characters have. The computer 12 keeps a data base of records defining character attributes and the status of each character in terms of his or her position in the maze, longevity of the character, possession of any limited resources such as keys or potions and other necessary information. Step 42 is merely a reading of the player controls 11 to determine what action, if any, has been requested by the player currently being processed. Step 44 is an access to the data record for the particular character to determine if the special attribute is present or to obtain any other information needed to perform the requested function. Step 46 symbolizes the process of actually carrying out the requested function, and involves accessing the proper graphic data to display the exercise of the special attribute or to place the character in the maze or to show shots or to increase the character's longevity attribute in accordance with the number of new coins received for that character.
Either ater performing block 46, or if the answer to the test of block 42 was no, the computer 12 tests to determine if all the active players requested actions other than move have been processed as symbolized by path 47 and block 48. If not, flow goes back to step 42 to process the control inputs from the next player as shown by line 51. If the answer is yes, control flows to block 50 as shown by line 52.
Block 50 symbolizes the action of the computer 12 polling the current player's movement controls to see if the player is requesting movement of his character or shots from his character. If yes, control flows on line 54 to block 56 to determine if the desired movement would cause a collision. The collision test is to determine if the character's movement or shots would cause collision of the character or his or her shots with walls of the maze, monsters, attribute affecting items such as limited resources, the boundaries of the current window or an exit to another maze or another level of the same maze. If the answer to this test is yes, then control flows on path 58 to a collision action routine 59 which will be detailed below in connection with discussion of FIG. 5. If there is no collision, the computer 12 moves the character or his shot to the desired position by calculating the amount of the desired movement in known fashion and updating the character's record or the shot's record in the data base by changing the x and y coordinate fields in the data record for that character or shot as symbolized by block 60.
After the character or shot has been moved or the collision action routine has been performed, control flows to the test of block 62 to determine whether all the active players have had their control inputs processed. Block 62 is also entered if the answer to the test of block 50 was that the player did not desire to move his character. If all player's control inputs are found in block 62 to have not been processed, control flows on path 64 back to block 31 on FIG. 3 to pick the next character and process the corresponding player's control inputs. Processing then proceeds as described above.
If the answer to the test of block 62 is yes, control flows to a block 68 which will be described below.
Although the computer services only one player's inputs at any particular time, this process is invisible to the players since the processing is so fast that it appears simultaneous to them. There are no assigned time slots for each player during which he or she may operate the character controls where at all other times the controls are "dead". Each player may move his controls at any time, and the computer will appear to respond instantaneously. Of course there are situations to be described in the description of the collision routine where the player may wish to move his character but his character will not move because of a collision with a wall, the screen limits, etc. However, even when this occurs the character may still do whatever other things the character can be controlled to do, and the controls are not "dead".
After all player control inputs have been processed, control flows to block 68 where the window is moved to a new location, if required, corresponding to the new locations of all the active characters, i.e., those characters whose longevity attributes have not been reduced to zero. In the preferred embodiment, the new window location is determined by calculating the center of all the active characters and placing the window such that all the active characters are displayed in the window. However, in other embodiments any other method of determining the new window position will suffice for practicing the invention. It is only critical that whatever method is used be such that all the active characters be visible in the window after it is moved.
After the window has been moved or scrolled across the maze to its new position, the processing of block 38 on FIG. 2 is complete, and control flows on path 39 to point B, block 41 on FIG. 2, This step is to find a monster or a monster generator which has not been destroyed by the characters which may be used by the computer 12 to attack the players. Once a monster or a generator has been found, the computer 12 tests in block 43 whether what has been found is a monster or a generator. If it is not a monster, control flows to block 45 to generate new monsters. If it was a monster, control flows on path 74 to routine 76 to move the monsters to attack the nearest character or characters. The routine at 76 may be any one of several different processes, e.g., the positions of the monsters may be compared to the position of all the characters to determine the closest character and the monsters may be moved only toward the closest character, or the positions of the monsters may be compared to all the characters and the monsters may be split up such that some attack each active character. The process of moving monsters by updating their data records in the video data base and calling up the corresponding graphic data for the monster at the appropriate time is well known and any known code to accomplish this task may be used to practice this aspect of the invention.
Referring again to the main loop flow chart of FIG. 2, after the process of block 76 is performed, control flows on path 78 to the process of block 80. Block 80 represents a test of whether any of the monsters have collided with any of the characters being attacked. If the answer is yes, then control flows to block 82 where the longevity attribute of any character which collided with a monster is reduced. This is a process of accessing the data record for each character which suffered a collision with a monster and updating the longevity field by subtracting some assigned number of longevity units thereform and then rewriting the record in the data base.
After the process of block 82 is performed, control flows to the test of block 84 where it is determined whether all the monsters have been moved to attack characters. If not, control flows back to block 41 to find the next monster or generator, and processing then proceeds as described above. If all the monsters have been moved, then control flows to block 86 where the computer 12 waits for the video display driver subsystem 26 to signal that the current frame has been displayed. This fact may be determined by an interrupt from the video display driver subsystem 26 or by polling of the video display driver subsystem 26 by the computer 12. After the frame is displayed, processing returns to block 34 on FIG. 2, and processing proceeds as described above.
Referring to FIG. 4, there is shown a flow chart for the processing sequence the computer 12 follows for starting a player. The flow chart of FIG. 4 is an expansion of the process represented by block 34 in FIG. 2. Block 34 is the process the computer 12 implements in allowing any one of a plurality of players to enter the game at any time and bring an unused character to life and control that character. This process may occur regardless of how many other players are playing (providing there is an unused character available), regardless of how long they have been playing or when they elect to leave the game or when their characters die. The computer 12 loops through the process of FIG. 4 once for each character.
The first step in the process of FIG. 4 is a test shown at block 100 to determine whether a coin has been dropped for the first character for which the loop is performed. In the preferred embodiment, adding coins allows a character to start or increases the longevity of a currently active character. Accordingly, if the answer to the test of block 100 is yes, block 102 is performed to add to the longevity attribute of the character for which a coin or coins was received. The longevity of the character is increased in proportion to the number of coins which were received. This is done by accessing the character's data record and adding some number of longevity units to the longevity attribute field of the data record.
In the preferred embodiment, the test of block 103 is performed to account for the case where a coin is dropped for a character which is alive and whose player wishes to extend the life of that character. In such a case there is no need to place the character in the maze or to wait for the player to press the start button, so subsequent steps in the process of FIG. 4 will be skipped and control will flow along the path 105 to the test of block 107 to determine if all coin slots have been read to detect the presence of new coins. If the character whose coin slot received a coin was not previously alive before the new coin was received, control flows along the path 109 to the test of block 104.
In block 104, a determination is made whether the start button has been pushed by the player corresponding to the character whose coin slot received the new coin. If it has not, there is no need to place the character on the screen, and control flows along the path 111 to the test of block 107. If the start button has been pressed, the computer 12 accesses the graphics data for the character and creates a data record for that character placing it somewhere in the current window and writing the fields of the data record to reflect its current longevity attribute and position and assigning it the attributes that said character has. This process is symbolized by block 106. The initial values of attributes assigned to the character may be stored in a look up table. In some embodiments, some or all of the attributes of all or selected ones of the characters may have their values changed by the computer 12 based upon prior events which happened in the game, e.g., collisions with treasures, potions, keys, thieves, etc.
After the process of block 106 is performed, the test of step 107 is performed to determine if all the coin slots for all the characters have been processed. If they have not, control flows along path 108 back to block 100. If all coin slots have been read, control flows on path 110 to block 36 in FIG. 2, and processing continues as previously described.
In embodiments suitable for use in the home, steps 100, 102 and 103 are not present as coins are not customarily used in the home environment. In such embodiments the test of block 104 is performed as the first step of the process of FIG. 3.
Referring to FIG. 5 there is shown a flow diagram of the collision processing performed in blocks 56 and 59 on FIG. 3. It is this processing which causes attributes to be affected both positively and negatively and which forces the players to cooperate to at least some extent. If the result of the test of block 50 is that the player does not desire to move his character, then control bypasses block 56, and control flows to block 62 on FIG. 3. If the result of the test of block 50 in FIG. 3 is that the player desires to move the character currently beng processed, control passes along path 54 to a collision test in block 130. If the test of bock 130 indicates that a collision with the edge of the window would result, then control flows on path 132 to block 133 where an appropriate edge of window routine is performed. The exact details of the edge screen routine as to processing of collisions of shots with the edge of the screen is not critical to the invention. In some embodiments, the shots may be allowed to continue past the edge of the screen, and in other embodiments, the shots are caused to disappear when they collide with the edge of the screen, i.e., the window edge. However, if the collision was between s character and the edge of the screen, the character is not allowed to move until the current window position is moved except in certain circumstances. After the process of block 133 is performed, processing flows to block 62 on FIG. 3 along path 66. There, processing proceeds as described earlier. Block 130 is the portion of the program run by the computer 12 which encourages the players to cooperate in the sense that all the active characters must move through the maze toward their objective in such a manner that they all remain simultaneously visible in the current window. For example, assume that one character's longevity is getting low, and thus that player needs to get his or her character to a longevity increasing entity. Such an entity could be food, a power source, a healer, etc. located elsewhere in the maze at a place not currently visible on the screen. Because of the processing at block 130, the character whose longevity is low may not move further than the edge of the current window or screen edge toward the longevity increasing entity until the other characters decide to move with him toward his or her objective. Actually, in the preferred embodiment, the character desiring to move toward the off screen food may only move until the character reaches the current edge of the window and then will be blocked from further movement until the edge of the window moves. Sinde the window center is recomputed every frame based upon the center of the characters, If the characters are cooperating and moving in the general direction of the objective, the window will continue to scroll over the playfield until the objective is within the perimeter of the window. In other embodiments, one character may cause the current window to move by his movements alone in certain circumstances. Those circumstances can be defined to exist when the center of the currently active characters is such that there is room for the window to be scrolled without causing the edge of the window to collide with another character. In such a circumstance, the character may move to the edge of the current window and continue to move thereby causing the edge of the window to move with him or her until the window has moved to a point where another character has collided with an edge of the window. When the window can no longer be moved without causing an active character to disappear from the current window, the characters are under constraints in that they may only move in directions which will keep them in the perimeter of the current window. The foregoing situation persists until cooperation among the players cause them to move in the same general direction such that their collective center is located so as to allow the current window to be moved to a new position with all characters still visible in the window.
After the players have cooperated enough that the current window contains the desird attribute affecting entity within its perimeter, then cooperation is not longer necessary. At that time, the players may begin competing against each other to take possession of the attribute affecting entity for themselves. Each player can decide on an individual basis whether to continue to cooperate and subjugate his self interest to the interest of the group or to act solely in his own self interest.
Other forms of cooperation in the game include the ability of the characters to simultaneously move as a group and to protect each other flanks by fighting all monsters approaching in their assigned zones of defense for the group. Another form of cooperation is the decoy strategy. This strategy relies upon the fact that the monsters are attracted to player's position to attack them, and generally are attracted to the closest player. The decoy strategy is to use one character as a decoy or magnet to attract the monsters while the other characters ambush the monsters from positions further away. Another form of cooperation in the game is the ability of the players to share the limited resources. The players may decide among themselves to allow the weakest character, i.e., the character with the least longevity left, to have all the limited resources. Or, in the case of multiple piles of limited resources, the players may divide them among themselves to best utilize the longevity enhancement effect for the good of the group. Another form of cooperation is to allow the character with a particular attribute to obtain possession of a particular limited resource if that character may use the resource more effectively for the good of the group than the other characters in the group. An example of this would be to let any character with extensive magical powers to obtain a possession of a magic anhancing resource as opposed to having a character with limited or no magical powers take possession of the resource. The portions of the program which implement these other possible forms of cooperation will be described below in connection with, inter alia, block 146, 150, 160 and 178. Certain other aspects of this cooperation feature of the game are implemented by portions of the program described above, e.g., blocks 80, 82, 42, 44 and 46. This cooperation aspect of the game provides for very exciting action and interesting social interplay among the players.
If the test of block 130 indicates no collision with the edge of the window would result from the move (in some embodiments the character is moved, a collision is found, and the character is moved back), then control flows on the path 134 to a test symbolized by block 136. This test determines whether the move would cause the character or his or her shot to collide with an impassable entity such as a wall in the maze. If the answer is yes, control flows on a path 138 to a block 137. There an appropriate routine is performed to implement the effects of the collision. The details of this block 137 are not critical to the invention, and the processing performed in block 137 may cause any type of action the game designer desires. For example, the character my be stopped, the shot hitting a wall or trap may destroy th wall or trap or may cause a cloud of poisonous gas to be released. Any imaginable action may be performed by the block 137. After the processing of block 137, process control flows to block 62 in FIG. 3 via the path 66.
If the answer to the test of block 136 is no, control flows on a path 140 to the test of block 142. This is test to determine if the move would cause a collision between the character or the character's shot with an attribute affecting entity. Such entities may be any typical video game entity such as traps, black holes, time warps, keys, potions, objects which have fallen into the maze, treasures, food, energy or power sources, healers, etc. Neither what the entity .[.or.]. .Iadd.is .Iaddend.nor its affect on attributes is critical to the invention. Typically collisions with such entities do any of the following things: increase longevity; decrease longevity; enhance other attributes such as magical powers; decrease attributes; add new attributes such as different movement abilities, e.g., jumping or flying; change fighting ability; change armor capacity; and/or provide the ability to leave the maze through an exit.
If the answer to the test of block 142 is yes, control flows on a path 144 to a block 146 where the attribute is changed accordingly by accessing the data record for the character and adjusting the field of the attribute affected to implement the change. After this process is completed, control flows on path 66 to block 62 on FIG. 3.
If the answer to the test of block 142 is no, control flows on path 147 to the test of block where a determination is made of whether the proposed move would cause a collision of the character or character shot with another player. In the preferred embodiment, one character may push another character and move that character's position in the maze until such a time as the pushed character begins to push back. In other embodiments, the characters may be able to shoot and damage or destroy each other or otherwise hinder the progress of other characters toward their objectives. This feature provides for the competitive aspects of the game once a desired attribute affecting entity is located within the perimeter of the current window. If the answer to the test of block 148 is yes, control flows to a block 150 along path 152 where the characters have their attributes and/or positions changed in accordance with whatever competitive rule is adopted for the particular embodiment implemented. Of course player competition can take many other forms as well. For example, one character may refuse to move when that character is preventing movement of the current window toward the objective of another player. Further, one character may refuse to cooperate in shooting or fighting monsters which are attacking another character. Also some characters may be faster or be able to jump or fly, and these characters may speed ahead of another character which is headed for a longevity increasing entity and take possession of the entity for itself.
If the answer to the test of block 148 is no, control flows on a path 154 to a block 156. There the proposed move is tested to determine if it would cause the character or character shot to collide with an exit. If the answer is yes, control flows on a path 158 to a block 160. There the appropriate action for the rule adopted for the particular embodiment at hand is performed. The particular rule adopted for processing in block 160 is not critical to the invention. The processing for block 160 in the preferred embodiment is shown in more detail in FIG. 6.
Referring to FIG. 6, the processing of collisions between characters or character shots and exits is detailed for the preferred embodiment. The processing of FIG. 6 is to determine if the game conditions, e.g. attribute status of the character such as possession of a key, are such that the character may pass through the exit, and to determine what to do for a shot/exit collision. Accordingly, the first step in the processing is to determine if a shot/exit collision has occurred as symbolized by block 159. If the answer is yes, processing proceeds to block 160 where an appropriate shot/exit collision routine is performed. In some embodiments, the shot may disappear, and in other embodiments, the exit may be destroyed. The possibilities are numerous, and any may be used in equivalent embodiments of the invention. If the answer is no to the test of block 159, control flows to a test symbolized by a block 161 to determine if predefined conditions for exit by a character are satisfied. The predefined conditions may be anything the game designer desires, and the exact conditions selected are not critical to the invention. For example, in some embodiments a character may not be allowed to leave through an exit until a particular monster holding the key for that exit is destroyed and the character picks up the key. If the answer to the test of block 161 is no, control flows on a path 66 to block 62 of FIG. 3, and now movement of the character through the exit results. If the answer to the test of block 161 is yes, control flows on a path 164 to a block 166 where a test is made to determine if the other characters have left the maze. If the answer is no, the character desiring to exit is allowed to exit and is placed on another level in a safe haven where the character cannot be attacked by monsters as symbolized by block 168. There the character awaits the arrival of the other characters.
If the answer to the test of block 166 is yes, then processing proceeds to block 170 where a new maze is drawn. In some embodiments, the new maze will have different kinds of monsters and attribute affecting entities therein and usually will have exits, monsters and entities placed differently. The character exiting is then placed in the next maze. In some embodiments, the characters may only move forward to new mazes which they have not previously occupied. In other embodiments, the characters may move back to levels or mazes which they have previously occupied. Control then flows on a path 168 to block 33 on FIG. 2 and processing continues as previously described for the new maze. In some embodiments the characters attributes remain the same in the new maze, and, in some other embodiments, the character's attributes are changed. The order of exit may be determine in some embodiments the position the characters will assume in the new maze.
Returning to FIG. 5, if the answer to the test of block 156 is no, control flows on a path 170 to a block 172 where a test is performed to determine whether a character's shots or character have collided with a monster. If the answer is yes, control flows on a path 174 to a block 178 where an attempt is made to damage the monster. In embodiments where the characters have different attributes, often the shots of one character may not be powerful enough to kill a monster whereas the shots of another character may be powerful enough to kill a monster. Further, some monsters may be stronger than others. To account for these embodiments, the process of block 178 is implemented to perform damage routines to monsters which have collided with characters or shots. After the process of block 178 is performed, control flows along path 180 to the test of block 182 to determine if the monster was destroyed. If not, then control flows to block 62 in FIG. 3 along path 184/176 to path 66. If the answer to the test of block 182 was yes, control flows along path 186 to a routine symbolized by block 188 which deletes the monster. Control then flows on a path 176/66 to block 62 and processing continues as described above.
Although the invention has been described in terms of the preferred embodiment herein and the other alternative embodiments, those skilled in the art will appreciate still other equivalent embodiments which may be implemented. All such embodiments are intended to be included within the scope of the claims appended hereto. ##SPC1##
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US3793483 *||Nov 24, 1972||Feb 19, 1974||Bushnell N||Video image positioning control system for amusement device|
|US4016362 *||Oct 29, 1975||Apr 5, 1977||Atari, Inc.||Multiple image positioning control system and method|
|US4045789 *||Oct 29, 1975||Aug 30, 1977||Atari, Inc.||Animated video image display system and method|
|US4054919 *||Sep 15, 1975||Oct 18, 1977||Atari Incorporated||Video image positioning control system|
|US4116444 *||Jul 16, 1976||Sep 26, 1978||Atari, Inc.||Method for generating a plurality of moving objects on a video display screen|
|US4477069 *||Sep 27, 1982||Oct 16, 1984||Crudgington Jr Cleveland B||Electronic amusement center|
|US4504055 *||Jan 10, 1983||Mar 12, 1985||Wells Charles D||Electronic video game apparatus adapted for use to play a simulated game of golf|
|US4572509 *||Sep 30, 1982||Feb 25, 1986||Sitrick David H||Video game network|
|GB2153189A *||Title not available|
|JPS581483A *||Title not available|
|JPS5440744A *||Title not available|
|JPS5881064A *||Title not available|
|JPS5957397A *||Title not available|
|JPS55122577A *||Title not available|
|JPS57211381A *||Title not available|
|JPS58121091A *||Title not available|
|JPS58185284A *||Title not available|
|JPS59141976A *||Title not available|
|1||"Balloon Fight" instruction booklet, ©1986 Nintendo.|
|2||"Dandy", (©)1983 John Howard Palevich.|
|3||"Mario Bros." instruction booklet, ©1986 Nintendo.|
|4||*||Balloon Fight instruction booklet, 1986 Nintendo.|
|5||*||Claim Your Treasures With Exidy s Venture , Exidy, Inc.|
|6||Claim Your Treasures With Exidy's Venture™, Exidy, Inc.|
|7||*||Dandy , ( )1983 John Howard Palevich.|
|8||*||Mario Bros. instruction booklet, 1986 Nintendo.|
|9||*||Stern Goes Berzerk ad; Stern Electronics, Inc.|
|10||*||Tutankham, Video game ad, Kjonami Industry Co., Ltd.|
|11||*||Warlord video game ad, Stern Seeburg Entertainment Guide, Vol. One, Issue One, Atari Games Corporation.|
|12||Warlord video game ad, Stern-Seeburg Entertainment Guide, Vol. One, Issue One, Atari Games Corporation.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US6270402 *||Dec 9, 1999||Aug 7, 2001||Kabushiki Kaisha Konami Computer Entertainment Osaka||Video game device, control method for processing of soliciting video characters to join simulated team, and readable recording medium recording control programs for processing of soliciting video characters to join simulated team|
|US6299535 *||Apr 28, 2000||Oct 9, 2001||Square Co., Ltd.||Method of processing interactive game, program product and game system for the same|
|US6315668||Apr 13, 1999||Nov 13, 2001||Midway Games, Inc.||System and method for networking video games|
|US6347995 *||Oct 2, 2000||Feb 19, 2002||Konami Corporation||Method, computer-readable storage medium and video game device for automatically generating a maze map with at least one correct path|
|US6354940 *||Aug 9, 1999||Mar 12, 2002||Square Co., Ltd.||Game apparatus, game fight processing method, and computer readable storage medium storage program therefor|
|US6371856 *||Mar 23, 1999||Apr 16, 2002||Square Co., Ltd.||Video game apparatus, video game method and storage medium|
|US6630914 *||May 28, 1997||Oct 7, 2003||Canon Kabushiki Kaisha||Display apparatus having facility for selective indication of apparatus use term|
|US6666764 *||Apr 26, 2000||Dec 23, 2003||Konami Co., Ltd.||Method of controlling a character in a video game|
|US6676519 *||Sep 28, 2001||Jan 13, 2004||Kabushiki Kaisha Square Enix||Video game including character capability setting|
|US6688981 *||Apr 26, 2001||Feb 10, 2004||Konami Computer Entertainment Japan, Inc.||Game system, judgment table producing method, and computer-readable storage medium carrying game program|
|US6729954 *||Aug 15, 2001||May 4, 2004||Koei Co., Ltd.||Battle method with attack power based on character group density|
|US6764399 *||Jul 13, 2001||Jul 20, 2004||Konami Corporation||Portable terminal apparatus, a game execution support apparatus for supporting execution of a game, and computer readable mediums having recorded thereon processing programs for activating the portable terminal apparatus and game execution support apparatus|
|US6852034||Oct 8, 2003||Feb 8, 2005||Konami Corporation||Portable terminal apparatus, a game execution support apparatus for supporting execution of a game, and computer readable mediums having recorded thereon processing programs for activating the portable terminal apparatus and game execution support apparatus|
|US6881149||Jul 25, 2002||Apr 19, 2005||Sony Computer Entertainment Inc.||Entertainment system, entertainment apparatus, recording medium, and program|
|US7001280 *||Apr 26, 2000||Feb 21, 2006||Konami Co., Ltd.||Method of switching background images in accordance with movement of characters, storage medium for storing programs, and video game device|
|US7452268||Feb 11, 2003||Nov 18, 2008||Sony Computer Entertainment America Inc.||System and method for modifying actions of a group of characters via group interactions|
|US7500916 *||Nov 7, 2005||Mar 10, 2009||Microsoft Corporation||Game strategy analysis tool generating a two dimensional image overlaid with telemetry data|
|US7559834 *||Dec 2, 2002||Jul 14, 2009||Microsoft Corporation||Dynamic join/exit of players during play of console-based video game|
|US7594847||Oct 11, 2002||Sep 29, 2009||Microsoft Corporation||Squad command interface for console-based video game|
|US7789741||Feb 28, 2003||Sep 7, 2010||Microsoft Corporation||Squad vs. squad video game|
|US7945856||Jan 13, 2009||May 17, 2011||Worlds.Com, Inc.||System and method for enabling users to interact in a virtual space|
|US8082501||Dec 20, 2011||Worlds.Com, Inc.||System and method for enabling users to interact in a virtual space|
|US8096863||Jan 17, 2012||Sony Computer Entertainment America Llc||Emotion-based game character manipulation|
|US8118676||Jul 8, 2005||Feb 21, 2012||Activevideo Networks, Inc.||Video game system using pre-encoded macro-blocks|
|US8172656||May 8, 2012||Sony Computer Entertainment America Llc||Attribute-driven gameplay|
|US8187094 *||Sep 22, 2005||May 29, 2012||Sega Corporation||Game program|
|US8194862||Jul 31, 2009||Jun 5, 2012||Activevideo Networks, Inc.||Video game system with mixing of independent pre-encoded digital audio bitstreams|
|US8270439||Jan 5, 2007||Sep 18, 2012||Activevideo Networks, Inc.||Video game system using pre-encoded digital audio mixing|
|US8284842||Jul 8, 2005||Oct 9, 2012||Activevideo Networks, Inc.||Video game system using pre-encoded macro-blocks and a reference grid|
|US8491394||Aug 16, 2010||Jul 23, 2013||Microsoft Corporation||Squad vs. squad video game|
|US8619867||Sep 10, 2012||Dec 31, 2013||Activevideo Networks, Inc.||Video game system using pre-encoded macro-blocks and a reference grid|
|US8727845||May 8, 2012||May 20, 2014||Sony Computer Entertainment America Llc||Attribute-driven gameplay|
|US8808090 *||Nov 7, 2011||Aug 19, 2014||Konami Digital Entertainment Co., Ltd.||Game device, game control method, program, recording medium and game management device|
|US8932136 *||Aug 24, 2001||Jan 13, 2015||Opentv, Inc.||Method and system for initiating an interactive game|
|US9005021||Feb 21, 2013||Apr 14, 2015||Wms Gaming Inc.||System and method for flexible banking of wagering game machines|
|US9021541||Oct 14, 2011||Apr 28, 2015||Activevideo Networks, Inc.||Streaming digital video between video devices using a cable television system|
|US9042454||Jan 11, 2008||May 26, 2015||Activevideo Networks, Inc.||Interactive encoded content system including object models for viewing on a remote device|
|US9061206||Jul 8, 2005||Jun 23, 2015||Activevideo Networks, Inc.||Video game system using pre-generated motion vectors|
|US9077860||Dec 5, 2011||Jul 7, 2015||Activevideo Networks, Inc.||System and method for providing video content associated with a source image to a television in a communication network|
|US9108108||Jul 27, 2009||Aug 18, 2015||Sony Computer Entertainment America Llc||Real-time, contextual display of ranked, user-generated game play advice|
|US9123084||Apr 12, 2012||Sep 1, 2015||Activevideo Networks, Inc.||Graphical application integration with MPEG objects|
|US9126116||Sep 5, 2007||Sep 8, 2015||Sony Computer Entertainment America Llc||Ranking of user-generated game play advice|
|US20020119824 *||Feb 26, 2002||Aug 29, 2002||Allen Jeffrey L.||Tournament network for linking amusement games|
|US20040029625 *||Feb 11, 2003||Feb 12, 2004||Ed Annunziata||Group behavioral modification using external stimuli|
|US20040029626 *||Feb 11, 2003||Feb 12, 2004||Ed Annunziata||System and method for modifying actions of a group of characters via group interactions|
|US20040063501 *||May 20, 2003||Apr 1, 2004||Hitoshi Shimokawa||Game device, image processing device and image processing method|
|US20040072620 *||Oct 8, 2003||Apr 15, 2004||Konami Corporation||Portable terminal apparatus, a game execution support apparatus for supporting execution of a game, and computer readable mediums having recorded thereon processing programs for activating the portable terminal apparatus and game execution support apparatus|
|US20060116186 *||Sep 22, 2005||Jun 1, 2006||Tsuyoshi Sawada||Game program|
|US20060230428 *||Apr 11, 2005||Oct 12, 2006||Rob Craig||Multi-player video game system|
|US20070009043 *||Jul 8, 2005||Jan 11, 2007||Robert Craig||Video game system using pre-encoded macro-blocks and a reference grid|
|US20070010329 *||Jul 8, 2005||Jan 11, 2007||Robert Craig||Video game system using pre-encoded macro-blocks|
|US20070105631 *||Jan 5, 2007||May 10, 2007||Stefan Herr||Video game system using pre-encoded digital audio mixing|
|US20090063463 *||Sep 5, 2007||Mar 5, 2009||Sean Turner||Ranking of User-Generated Game Play Advice|
|US20090082076 *||Oct 21, 2008||Mar 26, 2009||Sony Computer Entertainment America Inc.||Emotion-based game character Manipulation|
|US20100029371 *||Aug 1, 2008||Feb 4, 2010||Gennady Medvinsky||Personal Game Services Commerce System (PGSCS)|
|US20100041475 *||Feb 18, 2010||Zalewski Gary M||Real-Time, Contextual Display of Ranked, User-Generated Game Play Advice|
|US20100311483 *||Aug 16, 2010||Dec 9, 2010||Microsoft Corporation||Squad Vs. Squad Video Game|
|US20130130791 *||Nov 7, 2011||May 23, 2013||Konami Digital Entertainment Co., Ltd.||Game device, game control method, program, recording medium and game management device|
|WO2000025877A1 *||Nov 5, 1999||May 11, 2000||Gordon David P||Multiplayer electronic games|
|U.S. Classification||463/2, 463/15|
|International Classification||A63F9/00, A63F11/00, G06F19/00, A63F13/10|
|Cooperative Classification||A63F13/10, A63F2011/0095|
|Jun 10, 1999||FPAY||Fee payment|
Year of fee payment: 12
|Jun 18, 2001||AS||Assignment|
|Oct 18, 2002||AS||Assignment|
Owner name: MIDWAY GAMES WEST INC., CALIFORNIA
Free format text: CHANGE OF NAME;ASSIGNOR:ATARI GAMES CORPORATION;REEL/FRAME:013380/0545
Effective date: 19991119
|Mar 8, 2004||AS||Assignment|
|May 30, 2008||AS||Assignment|
Owner name: MIDWAY GAMES WEST INC., CALIFORNIA
Free format text: RELEASE OF ASSIGNMENT OF SECURITY OF PATENTS;ASSIGNOR:WELLS FARGO FOOTHILL, INC.;REEL/FRAME:021040/0984
Effective date: 20080229
Owner name: NATIONAL AMUSEMENTS, INC., MASSACHUSETTS
Free format text: RELEASE OF ASSIGMENT FOR SECURITY OF PATENTS;ASSIGNOR:MIDWAY GAMES WEST INC.;REEL/FRAME:021172/0106
Effective date: 20080319
|Feb 10, 2009||AS||Assignment|
Owner name: ACQUISITION HOLDINGS SUBSIDIARY I LLC, NEW YORK
Free format text: SECURITY AGREEMENT;ASSIGNOR:NATIONAL AMUSEMENTS, INC.;REEL/FRAME:022235/0505
Effective date: 20090120
|Feb 25, 2011||AS||Assignment|
Owner name: WARNER BROS. ENTERTAINMENT INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MIDWAY GAMES WEST INC.;REEL/FRAME:025867/0559
Effective date: 20090710