Game with gate-crasher feature

The following disclosures generally relate to computer-based games, and more specifically to computer-based games implemented by console-based gaming systems.

Console-based video games used at home can be played in network-based multiplayer mode, or in offline multiplayer and singleplayer modes. In network-based multiplayer games, different players at remote locations can play the game at the same time, with each player controlling a particular enemy or fellow character in a common game space or simulated environment. For example, HALO® is a multiplayer game from Microsoft Corporation in Redmond, Washington, which has a co-op multiplayer mode. In co-op multiplayer mode, each player controls one character, and the characters must work together to achieve the goal of the game. Other known multiplayer games are also of a competitive nature. For example, first person shooters (FPS, first person) such as DOOM (registered trademark), QUAKE (registered trademark), UNREAL (trademark), etc. Each shooter game has one or more multiplayer modes, in which each player controls one character in a common game space, and each player defeats another player's character (frag). ) Is also called).

<p> In single-player games, the player often plays the role of a primary character interacting with an enemy and / or fellow character in a common game space. The behavior of enemy and fellow characters (hereinafter "non-player characters" or "NPCs") is typically controlled by program-defined artificial intelligence (AI) or other program routines. When simple program routines are used, NPC behavior tends to follow typical patterns, which is not useful for repetitive play as the behavior becomes predictable. On the other hand, more complex AI routines that include machine learning elements can be difficult and frustrating to beat NPCs. The purpose of carefully crafting AI or programming routines is to create NPC behavior that usually gives the illusion of playing with a living human. But in reality, it is extremely difficult to produce NPC behavior at this level and complexity. As a result, it is difficult to add elements of surprise and unpredictability to traditional single-player games. Using random number selection to change NPC behavior, and incorporating one-off gimmicks into NPC routines, are two known ways to add unpredictability and surprise to a single-player game. Is.</p>

<p> The following disclosure describes a game architecture that includes the option of shifting non-player character (NPC) control to human players at the start of or during the game to introduce new unpredictable NPC behavior at each game session. Describe. In one embodiment, the single player game is played by a host player connected to a network such as the Internet. During play, the game is gate crashed by a remote player, also connected to the network, without the host player's knowledge. This gate crasher can play the role of an enemy character fighting the host player or a fellow character cooperating with the host player. Gate crushers change the course of the game in a way that is different from what the host player might have expected based on a previous game (a game in which the NPC was controlled by a program-defined routine). Behave. This surprising element adds excitement and unpredictability to the normally repetitive and boring gaming experience.</p>

The following disclosure describes some embodiments relating to systems and methods for gate crashing computer-based games. In order to provide a complete understanding of such embodiments, specific details of some embodiments of the present invention are provided below. However, to avoid unnecessarily obscuring the description of the various embodiments, other details that describe well-known structures and routines often associated with computer-based games are not described below. Further, those skilled in the art can also have other embodiments that include additional elements, or that the invention lacks one or more of the elements described below with reference to FIGS. 1-12. You will understand.

In the figure, the same reference number identifies the same element, or at least generally similar elements. To facilitate consideration of any particular element, the most significant digit of any reference number refers to the figure in which that element was first introduced. For example, element 110 is first introduced and discussed with reference to FIG.

Hereinafter, some embodiments of the gate crash method and system will be described in the context of computer executable instructions implemented by a game console or by a general purpose computer such as a personal computer. In one embodiment, for example, these computer-executable instructions can be stored on a computer-readable medium such as a hard disk, floppy (registered trademark) disk, or CD-ROM. In other embodiments, these instructions can be stored in a server computer system and accessed via a computer network such as an intranet or the Internet. Since the basic structures and functions associated with computer executable routines and corresponding computer implementation systems are well known, these are also illustrated in detail herein to avoid unnecessarily obscuring the embodiments described. I haven't done it.

FIG. 1 is a schematic diagram showing a gaming system 100 suitable for playing computer games, video games, and / or other electronic games according to some embodiments of the present invention. In one aspect of this embodiment, the gaming system 100 includes a plurality of controllers 104 operably connected to the game console 102, individually identified as a first controller 104a and a second controller 104b. The controller 104 can be connected to the game console 102 via a wired or wireless interface. For example, in the illustrated embodiment, the controller 104 is compatible with the universal serial bus (USB) and is connected to the console 102 via a serial cable 130 that fits in the socket 110. The controller 104 may be provided with various user interaction mechanisms. For example, in the illustrated embodiment, each controller 104 comprises two thumbsticks 132a and 132b, a D pad 134, various buttons 136, and a corresponding trigger 138. These mechanisms are merely exemplary of the various types of user interaction mechanisms that can be provided in controller 104. Thus, in other embodiments, other controllers may include more or less such mechanisms without departing from the spirit and scope of the present disclosure.

Each controller 104 can be configured to accommodate two portable memory units 140 for portable storage capacity. The memory unit 140 allows the user to store game parameters and import them for use on other game consoles. In the illustrated embodiment, each controller 104 is configured to accommodate two memory units 140. However, in other embodiments, suitable controllers can be configured to accommodate more or fewer memory units.

The game console 102 can include multiple cables for connecting to the support system. For example, the game console 102 can be operably connected to a television or display device 150 via an audiovisual interface cable 120. The power cable 122 can also provide power to the game console 102. In addition, the cable or modem connector 124 can facilitate the exchange of information between the game console 102 and networks such as the Internet for wideband data transmission.

The game console 102 may include an internal hard disk drive (not shown) and a portable media drive 106. The portable medium drive 106 can be configured to support various types of portable storage media represented by the optical storage disk 108. Examples of suitable portable storage media can include game discs such as DVDs and CD-ROMs. The game console 102 can also include a power button 112 and an eject button 114. When the eject button 114 is pressed, the tray associated with the portable media drive 106 is alternately opened and closed, and the storage disk 108 can be inserted and removed.

The gaming system 100 allows players and other users to enjoy various forms of entertainment, including games, music, and video. The various storage options available allow such media to be played from a hard disk drive, portable media drive 106, memory unit 140, or online source. For example, the gaming system 100 can play music from a CD inserted in the portable media drive 106, from a file on the hard disk drive, or from an online streaming source. Similarly, the gaming system 100 also plays digital audio / video games from a DVD inserted in portable media drive 106, or from a file on a hard disk drive (eg, a file in active streaming format), or from an online streaming source. be able to.

Gaming system 100 is only an example of a system suitable for carrying out embodiments of the present invention. Thus, the methods and systems disclosed herein are not limited to implementations of the gaming system 100, but extend to many other general purpose or dedicated computing systems or configurations. Examples of well-known computing systems, environments, and / or configurations that are considered suitable for use in aspects of the present invention include personal computers (PCs), server computers, personal digital assistants (PDAs) and laptop PCs. Portable and handheld devices such as tablet PCs, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, electronic game consoles, and these Includes a distributed computing environment that includes one or more of the systems or devices.

FIG. 2 is a block diagram showing a functional component of the gaming system 100 configured according to an embodiment of the present invention. In one aspect of this embodiment, the game console 102 comprises a central processing unit (CPU) 200 and a memory controller 202. The memory controller 202 can facilitate processor access to various types of memory. Such memory can include flash read-only memory (ROM) 204, random access memory (RAM) 206, hard disk drive 208, and portable media drive 106. The CPU 200 may include a Level 1 cache 210 and a Level 2 cache 212 to temporarily store data to reduce the number of memory access cycles required, thereby increasing processing speed and throughput. The aforementioned CPU 200, memory controller 202, and various memory devices include serial and parallel buses, memory buses, peripheral buses, and / or processor or local buses using any of the various bus architectures. It is interconnected via one or more buses. Such architectures include, for example, ISA (Industry Standard Architecture), MCA (Micro Channel Architecture), EISA (Enhanced ISA), VESA (Video Electronics Standards Association) Local Bus Architecture, PCI (Peripheral Component Interconnects) Bus Architecture (Mezanin Bus). Can also include architecture).

In one embodiment, the CPU 200, memory controller 202, ROM 204, RAM 206 can be integrated into the common module 214. In this embodiment, the ROM 204 is configured as a flash ROM connected to the memory controller 202 via a PCI bus and a ROM bus (neither shown). The RAM 206 can be configured as a Double Data Rate Synchronous Dynamic RAM (DDR SDRAM) that is independently controlled by the memory controller 202 via separate buses (not shown). The hard disk drive 208 and the portable media drive 106 can be connected to the memory controller 202 via the PCI bus and the ATA (AT attachment) bus 216.

In the illustrated embodiment, the 3D graphics processing unit 220 and the video encoder 222 can form a video processing pipeline for high speed and high resolution graphics processing. Data can be transported from the graphics processing unit 220 to the video encoder 222 via a digital video bus (not shown). The audio processing unit 224 and the audio codec (coder / decoder) 226 can form a corresponding audio processing pipeline with high fidelity and stereo processing. Audio data can be carried between the audio processing unit 224 and the audio codec 226 via a communication link (not shown). These video and audio processing pipelines output data to audio / video (A / V) port 228 for transmission to display device 150. In the illustrated embodiment, the video and audio processing components 220-228 are mounted on module 214.

A USB host controller 230 and a network interface 232 can also be mounted on module 214. The USB host controller 230 can be coupled to the CPU 200 and the memory controller 202 via a bus (eg PCI bus) and acts as a host for peripheral controllers 104a-104d. Network interface 232 can provide access to networks (such as the Internet and home networks) and can provide access to a variety of wired or wireless interface components, including Ethernet cards, modems, Bluetooth modules, cable modems, and more. It can be either.

The game console 102 can include dual controller port subassemblies 240a and 240b, and each subassembly can support two corresponding peripheral controllers 104a-104d. The front panel I / O subassembly 242 supports the functionality of the power button 112 and eject button 114, as well as the functionality of any light emitting diode (LED) or other indicator exposed on the outer surface of the game console 102. Subassemblies 240a, 240b, 242 are coupled to module 214 via one or more cable assemblies 244.

It is shown that eight memory units 140a-140h can be connected to four controllers 104a-104d in two memory units per controller configuration. Each memory unit 140 provides additional storage that can store games, game parameters, and other data. When the memory unit 140 is inserted into the controller, the memory unit 140 can be accessed from the memory controller 202. The system power supply module 250 can provide power to each component of the gaming system 100, and the fan 252 can cool the circuit in the game console 102.

The game console 102 described above can implement a uniform media portal model that provides a consistent user interface and navigation hierarchy for navigating users through various entertainment areas. This portal model provides a convenient way to access different types of media content, including game data, audio data, and video data, regardless of the type of media inserted in the portable media drive 106.

A console user interface (UI) application 260 is stored on the hard disk drive 208 to implement a uniform media portal model. When the game console is powered on, various parts of the console application 260 are loaded into RAM 206 and / or caches 210, 212 and run on CPU 200. The console application 260 presents a graphical user interface that provides a consistent user experience when navigating the various media types available on the game console. The features of the UI application and some of the exemplary screen displays it presents will be discussed in more detail later.

The gaming system 100 can also be operated as a stand-alone system by simply connecting the system to the display device 150. In stand-alone mode, the gaming system 100 allows one or more players operating the controller 104 to play the game and see themselves on the display device 150. However, by enabling wideband connectivity via network interface 232, the gaming system 100 can also be operated in a larger network-based gaming community, as detailed below.

FIG. 3 is a schematic diagram of a gaming environment 300 suitable for implementing various embodiments of the present invention. In the illustrated environment, the gaming environment 300 includes a plurality of gaming systems 100 interconnected via a network 302 (individually identified as a host player gaming system 100a and a plurality of gate crusher gaming systems 100b-n). .. In one aspect of this embodiment, the host player 320 can operate the host player gaming system 100a, and the plurality of gate crushers 322a to n can operate the gate crusher gaming systems 100b to n, respectively. Network 302 can include one or more communication links such as point-to-point dial-up connections, local area networks (LANs), intranets, and the Internet. Each gaming system 100 can also be connected to a server computer 304. As will be described in more detail later, the server computer 304 can be provided with several mechanisms for carrying out each aspect of the gate crash routine described herein. Such mechanisms can include, for example, processors, memory, server engines, databases.

An example of a gate crash of a single player mode game that can be implemented in a gaming environment 300 according to the present invention is as follows. In this example, the host player 320 is playing a single player mode game on the host player gaming system 100a. In single player mode, NPCs in the game are controlled by program-defined AI and / or other routines. During the game, without the knowledge of the host player 320, one of the gate crushers 322 (eg, the gate crusher 322a) interrupts the game over network 302 and takes control of one of the NPCs. This NPC may be a companion character that helps the main character, or an enemy character that competes with the main character. Initially, the host player 320 may not be aware that the NPC is controlled by the gate crusher 322a. In addition, the host player 320 may not be aware of this until it recognizes that the NPC is behaving in a way that is completely different from any previously experienced behavior. The unpredictability introduced by the Gate Crusher 322a adds excitement to games that would otherwise be routine and might be predictable. As will be described in more detail later, various embodiments of the present invention are not limited to a single gate crusher. Therefore, in other embodiments, additional gate crushers (eg, gate crushers 322b ~ n) may also take control of other NPCs.

Additional embodiments relating to gate crashes in single player mode games are described in more detail below.

(Process flow on the host player side) Before or during a game in single player mode, the host player 320 has the option of allowing or disallowing gate crashes in his game on the host player gaming system 100a. If the host player 320 chooses to allow gate crashes, information about the host player 320 (eg player aliases, regions, net rankings, etc.) and information about the game (eg difficulty, playstage, etc.) , Sent to server computer 304 via network 302. At the start of play, the host player 320 controls the player character (that is, the main character). If necessary, character information (for example, parameters such as the position of the main character and physical strength) and stage information (for example, parameters such as the position of the enemy character and physical strength) are sent to the server computer 304. As will be described in more detail later, one or more gate crushers 322 can obtain this information from the server computer 304 and use this information to select a game for a gate crash. When the gate crusher 322 selects an NPC to control (that is, an enemy or fellow character), the gate crusher 322 will control that NPC.

Depending on the outcome of the play, the game can proceed in several ways. For example, if the host player 320 completes this stage, the host player 320 can proceed to the next stage. Similarly, the surviving Gate Crusher 322 can automatically continue to control each enemy / fellow character in the next stage. Instead, if the host player 320 is defeated, the host player 320 can choose to end the game or revive the main character and continue playing.

At the end of the game, the results can be sent to the server computer 304. Such results include, for example, the game score (eg, the number of enemies broke, points, etc.) and information about the gate crusher 322 broke by the host player 320 (eg, the alias of the gate crusher, the number of gate crushers broke, etc.). be able to. Alternatively, if the host player 320 is breached, information about the gate crusher 322 that broke the host player 320 (eg aliases, rankings, etc.) can be sent to the server computer 304. Such information can be edited by the server computer 304 and reflected in the network ranking of the host player.

(Processing flow on the gate crusher side) At a given point in time, one or more gate crushers 322 can select an option indicating that they want to crash the game on their gate crusher gaming system 100. .. At this time, the corresponding gate crusher gaming system 100 obtains information about the online candidate game / player in the gaming environment 300 from the server computer 304. As mentioned above, such information can include, for example, host player information (eg aliases, regions, net rankings, etc.) and game information (eg titles, stages, etc.).

There are various ways in which the gate crusher player 322 can use this information to select a game for a gate crash. For example, one method is to randomly select a game from a list of host players currently playing the game around the world. Another method is to filter random candidates based on one or more conditions. For example, such conditions expose candidates to those who are located in a particular area, or to those who have completed a particular stage of the game (eg, gimmicks related to higher stages). (To avoid), limit to candidates with the same / higher / lower net ranking (eg selection based on the relative strength of the opponent player), and / or a specific list such as the "friends" list It can be included to limit to candidates registered in.

Another way to select a game that gate crashes is to choose it arbitrarily. This method can include gate crashing a personally selected host player each time. Alternatively, games can be selected by searching the list of available games according to one or more preset conditions as discussed above for random selection. When the gate crusher 322 selects a game that gate crashes, a peer-to-peer connection is established between the game console 102b of the gate crusher 322 and the game console 102a of the host player 320.

Once the peer-to-peer connection is established, the Gate Crusher 322 can choose which enemy / fellow character takes control in the host player's gaming world. There are at least two ways to select a character that will gate crash. One method is random selection. In this method, the gate-crashing character is randomly selected from among the NPCs that have not been broken by the main character and are not controlled by other gate crushers. Another method is optional. The method can include selecting from a list of available characters based on personal preference or other criteria such as map information that determines the position of the character in the game.

The aforementioned methods for game / player selection by the gate crusher are not exhaustive. Thus, in other embodiments, other methods can be used to select games and / or characters that gate crash without departing from the spirit or scope of the invention. For example, in another embodiment, the gate crusher 322 can first select the character it wants to control, which will automatically select a game that can use that particular character and make a peer-to-peer connection with the corresponding gaming system. It can be established automatically.

At the beginning of Gate Crash Play, Gate Crusher 322 controls the selected enemy / fellow character. At least two scenarios are possible, depending on the outcome of the play. For example, if the gate crusher character 322 is defeated by the host player 320, in one embodiment the peer-to-peer connection can be terminated and the gate crusher 322 can find another gate crashing game. Alternatively, the gate crusher 322 may choose to start its own single player mode game and wait for another gate crusher player. In another embodiment, the gate crusher 322 may be breached and then automatically transitioned from one enemy / fellow character to another in the same game in which the gate crashed. In this way, a single gate crusher 322 can continue to compete with the same host player 320 in a continuous gate crash scheme.

Alternatively, if the host player 320 is breached by the gate crusher 322, in one embodiment the peer-to-peer connection can be terminated and the host player 320 can continue by gate crashing another player's game. Alternatively, the host player 320 may choose to start a new single player mode game and wait for another gate crusher. Alternatively, the game may continue in the absence of the host player 320 while the remaining gate crusher players continue to compete with each other. As the game progresses, the host player 320 may choose to revive his character and resume play as the main character. Alternatively, the remaining gate crusher 322 may continue to play the game in the absence of the main character until another gate crusher enters the game and takes control of the main character (and becomes the new host player).

At the end of the game, the results can be sent to the server computer 304. For example, if the gate crusher 322 defeats the host player 320, information about the defeated host player 320 (eg aliases, rankings, etc.) can be sent to the server computer 304. Such information can be edited by the server computer 304 and reflected in the network ranking of the gate crusher.

The embodiments described above with reference to FIG. 3 include a single host player 320, which is for illustration purposes only. In this embodiment, host player 320 may be playing a game in single player mode on gaming system 110a before the game is gate crashed by one or more gate crushers 322. However, in another embodiment, it is possible that two or more host players 320 are playing a game in multiplayer mode, for example, on the host player gaming system 100a. In this other embodiment, the one or more gate crushers 322 can crash the game in multiplayer mode using at least generally the same method as described above for games in single player mode. Therefore, the present invention is not limited to a gate crash in a single player mode game, but extends to a multiplayer mode game.

FIG. 4 is a flow chart showing a routine 400 for executing a gate crash in a game in a single player mode according to an embodiment of the present invention. In one aspect of the invention, all or part of the routine 400 can be performed by the host player gaming system 100a (more specifically, the game console 102a) of FIG. 3 at the start of a game in single player mode. At block 402, routine 400 receives a request to allow a gate crash. In one embodiment, the request may come from the host player 320 in the form of a selection made via one or more user interaction mechanisms of the game console 102 (FIGS. 1 and 2). In response to receiving a request from the host player 320, routine 400 sends information about the host player 320 to the server computer 304, as shown in block 404. Routine 400 can also send information about a particular game (eg titles, stages, available NPCs, etc.) to server computer 304, as shown in block 406. As will be described in more detail later, one or more gate crushers 322 can use this information when selecting a game that will gate crash. Further, when one of the gate crusher 322 selects a character for gate crash, routine 400 receives a gate crusher character selection, as shown in block 408. After block 408, routine 400 ends.

FIG. 5 is a flow chart showing a routine 500 for performing a gate crash during a single player mode game in progress according to an embodiment of the present invention. In one aspect of this embodiment, all or part of the routine 500 can be performed by the host player gaming system 100a of FIG. 3 while the host player 320 is playing the game in single player mode. At block 502, routine 500 receives control input from host player 320. At block 504, routine 500 controls a first game character, such as a main character, in response to a control input from the host player 320. At block 506, routine 500 controls a second character, such as an NPC, according to a predefined routine. For example, an NPC could be to fight a key character in a typical FPS scenario. At block 508, as the game progresses, Routine 500 receives a choice from one of the gate crushers 322 that this gate crusher 322 takes control of the NPC. From this point onwards, this NPC is controlled by this gate crusher 322 rather than a predefined routine. At block 510, for example, routine 500 receives control input from gate crusher 322. At block 512, routine 500 controls the NPC in response to control inputs from the gate crusher. After block 512, routine 500 ends.

FIG. 6 is a flow chart showing a routine 600 for performing a continuous gate crash according to an embodiment of the present invention. Similar to routines 400 and 500 described above, all or part of routine 600 can be performed by the host player gaming system 100a of FIG. At block 602, routine 600 receives control input from host player 320. At block 604, routine 600 controls a first game character, such as a primary character, in response to a control input from the host player 320. At block 606, routine 600 receives control input from one of the gate crushers 322. This control input is intended to control a second game character, such as a first enemy character. In determination block 608, routine 600 determines whether the first enemy character is still active or defeated by the main character. If the first enemy character is still active, routine 600 proceeds to block 610 to control the first enemy character in response to input from the gate crusher 322. If the first enemy character is no longer active, routine 600 proceeds to block 612 to control a third game character, such as the second enemy character, in response to control inputs from the gate crusher 322. In this way, the gate crusher 322 can continuously control various NPCs as the host player 320 defeats the NPCs. After block 612, routine 600 ends.

FIG. 7 is a flow chart showing a routine 700 for performing gate crusher character selection according to an embodiment of the present invention. In one aspect of this embodiment, all or part of the routine 700 can be performed by the gate crusher gaming system 100b shown in FIG. At block 702, routine 700 receives information about one or more games being played (or will be) in single player mode. Such information can include, for example, the alias of the host player, the region where the host player is located, the difficulty level of the game, the net ranking of the host player, and the like. Such information can also include status information about the game, such as a particular stage of the game at this time. At block 704, routine 700 displays game information. At block 706, after the gate crusher 322 has the opportunity to review the display information, routine 700 receives a character selection from the gate crusher 322. At block 708, routine 700 sends the gate crusher character selection to server computer 304. After block 708, routine 700 ends.

FIG. 8 is a flow chart showing a routine 800 for performing gate crusher character selection according to another embodiment of the present invention. In one aspect of this embodiment, all or part of the routine 800 can be performed by the gate crusher gaming system 100b of FIG. At block 802, routine 800 receives information about the first game. Such information can include, for example, host player aliases, regions, difficulty levels, net rankings, play stages, and the like. At block 804, routine 800 can receive similar information about the second game. At block 806, routine 800 randomly selects a game in which the gate crusher 322 crashes and a character controlled by the gate crusher 322. After block 806, routine 800 ends.

FIG. 9 is a flow chart showing a routine 900 for performing gate crusher character selection according to another embodiment of the present invention. Similar to routines 700 and 800 described above, all or part of routine 900 can be performed by the gate crusher gaming system 100b. At block 902, routine 900 receives a selection criterion (ie, a filter criterion) from the gate crusher 322. Such filter criteria can include parameters corresponding to one or more games the Gate Crusher 322 wants to play and / or one or more players who want to be involved. For example, such criteria can include player aliases, regions, net rankings, and game titles, difficulty levels, and so on. At block 904, routine 900 receives game information about the game in progress and / or the game in progress. At block 906, this information is sorted according to the filter criteria received at block 902. At block 908, routine 900 displays information about one or more games that meet the criteria. At block 910, routine 900 receives a character selection corresponding to one of the games from the gate crusher 322. After block 910, routine 900 ends.

FIG. 10 is a flow chart showing a routine 1000 for executing a gate crash in a game in a single player mode according to an embodiment of the present invention. In one aspect of this embodiment, routine 1000 can be performed by the server computer 304 described above with reference to FIG. At block 1002, routine 1000 receives information about multiple games being played and / or being played in single player mode. Some of this information can come from, for example, the host player gaming system 100a. At block 1004, routine 1000 receives a request from, for example, the gate crusher gaming system 100b for a list of games that meet the specified criteria. Such criteria can come from, for example, the gate crusher 322a and can be related to the type of game and / or host player with which the gate crusher 322a wants to be involved. At block 1006, routine 1000 sorts game information according to specified criteria in response to receiving a request. At block 1008, routine 1000 sends a list of games and / or other information that meets the specified criteria to the gate crusher gaming system 100b. A list of games and / or other information can be displayed on the display device 150 of the gate crusher gaming system 100b, as seen by the gate crusher 322a. At block 1010, routine 1000 receives a selection from the gate crusher 322a regarding one of the participating games and the corresponding control character. At block 1012, routine 1000 establishes a peer-to-peer connection between the gate crusher gaming system 100b and the host player gaming system associated with the host game. For example, the gate crusher 322a is a character associated with a game being played on the host player gaming system 100a. If selected, routine 1000 establishes a peer-to-peer connection between the gate crusher gaming system 100b and the host player gaming system 100a. After block 1012, routine 1000 ends.

Although the various parts of routines 400-1000 have been described above in a particular order, this particular order should not be construed as the only order in which the routine or parts thereof can be performed. Also, although some elements of the routine are described herein for illustration purposes, in other embodiments, other routines consistent with the present disclosure may include more or less elements. Further, these routines can be described in the context of specific components or component groups in the gaming environment 300 of FIG. 3, but the same routines or parts thereof, without departing from the spirit or scope of the invention. It can also be implemented by a component or component group.

FIG. 11 shows a host player screen display 1100 configured according to an embodiment of the present invention. In one aspect of this embodiment, the screen display 1100 can be displayed on the display device 150 of the host player gaming system 100a of FIG. 3, as seen by the host player 320. As described in more detail below, the screen display 1100 may include several user interaction mechanisms that allow the host player 320 to set gate crash parameters for a particular game. For example, in the illustrated embodiment, screen display 1100 may include one or more gate crusher selection fields 1102. The host player indicates that he or she wants to open the game to the gate crusher by checking the "Yes" field. Alternatively, if you check the "No" field, the game will be closed to the gate crusher. In the quantity field, the host player can indicate how many gate crushers are allowed in the game.

The screen display 1100 can also include multiple gate crusher attribute fields 1104. The Skill Level field can include a drop-down list that allows the host player to specify the skill level required for the potential gate crusher. The Region field can also be provided with a drop-down list that allows the host player to specify one or more regions where the potential gate crusher must be located. If the host player wants to limit the game to specific gate crushers, the host player can enter aliases for these gate crushers in the "alias" field. The screen display 1100 can also include one or more NPC fields 1106. NPC field 1106 allows the host player to specify which NPCs can be gate crashed. For example, the host player can decide that all NPCs can be gate-crashed, or can limit gate-crashes to specific NPCs only.

The screen display 1100 may also include other features that allow the host player to further define the parameters of the gate crash that can be performed during a particular game. For example, the host player can indicate whether to allow the gate crusher character to be resurrected after being defeated by selecting the "Resurrection" button 1108. Similarly, the host player can enable continuous gate crashes by selecting the "Continuous" button 1109. The host player can start the game by selecting the submit button 1110 after selecting the desired gate crash parameters.

FIG. 12 shows a gate crusher screen display 1200 configured according to an embodiment of the present invention. In one aspect of this embodiment, the screen display 1200 is displayed on the display device 150 of the corresponding gate crusher gaming system 100b-n of FIG. 3, as seen by one or more gate crushers 322a-n. .. Therefore, the gate crusher can use the screen display 1200 to set parameters related to the game that it wants to crash. For example, the screen display 1200 can include a random selection button 1202 and a plurality of filter fields 1204. The gate crusher can select the random selection button 1202 if he wants to crash a randomly selected game. Alternatively, the gate crusher can use one or more of the filter fields 1204 to select the game based on specific criteria. For example, if you want to crash a game of a particular type or title, the gate crusher can select that type or title from the Game Types drop-down list. In addition, if only games played by host players of a particular skill level are desired to be crashed, the gate crusher may use the "skill level" drop-down list to indicate this preference. The gate crusher can also use the "Region" drop-down list and the "Alias" drop-down list to indicate other preferences. After setting the parameters for the game you want to crash, the gate crusher can select submit button 1214 to request information about the game that meets the parameters, or a connection to this game.

From the above, although specific embodiments of the present invention have been described in the present specification for illustration purposes, it is understood that various modifications can be made without departing from the spirit and scope of the present invention. There will be. Therefore, the present invention is not limited except that it is limited by the appended claims.

<figref num="1">FIG. 6 illustrates a gaming system suitable for playing computer games, video games, and / or other electronic games according to some embodiments of the present invention.</figref><figref num="2">It is a block diagram which shows the functional component of the gaming system of FIG. 1 configured by one Embodiment of this invention.</figref><figref num="3">It is a schematic diagram of a gaming environment suitable for carrying out various embodiments of the present invention.</figref><figref num="4">It is a flow chart which shows the routine which carries out the gate crash in the game of a single player mode by one Embodiment of this invention.</figref><figref num="5">It is a flow chart which shows the routine which carries out the gate crash during the game of the single player mode in progress by one Embodiment of this invention.</figref><figref num="6">It is a flow chart which shows the routine which carries out the continuous gate crash by one Embodiment of this invention.</figref><figref num="7">It is a flow chart which shows the routine which carries out the gate crusher character selection by one Embodiment of this invention.</figref><figref num="8">It is a flow chart which shows the routine which performs the gate crusher character selection by another embodiment of this invention.</figref><figref num="9">It is a flow chart which shows the routine which performs the gate crusher character selection by another embodiment of this invention.</figref><figref num="10">It is a flow chart which shows the routine which carries out the gate crash in the game of a single player mode by one Embodiment of this invention.</figref><figref num="11">It is a figure of the host player screen display configured by one Embodiment of this invention.</figref><figref num="12">It is a figure of the gate crusher screen display configured by one Embodiment of this invention.</figref>

Code description

102 Game Console 104 (a) Controller 104 (b) Controller 104 (c) Controller 104 (d) Controller 106 Portable Media Drive 140 (a) (b) Memory Unit 140 (c) (d) Memory Unit 140 (e) ( f) Memory Unit 140 (g) (h) Memory Unit 150 Display 200 Central Processing Device 202 Memory Controller 204 Flash ROM Memory 206 RAM Memory 208 Hard Disk Drive 210 Level 1 Cache 212 Level 2 Cache 216 ATA Bus 220 3D Graphics Processing Unit 222 Video Encoder 224 Audio Processing Unit 226 Audio Codec 228 A / V Port 230 USB Host Controller 232 Network Interface 240 (a) Dual Controller Port Subassembly 240 (b) Dual Controller Port Subassembly 242 Front Panel I / O Subassembly 250 System Power supply module 252 fan 260 UI application 302 network