INTERACTIONS BETWEEN MULTIPLE ENGINES IN COOPERATIVE AND COMPETITIVE GAMEPLAY IN ELECTRONIC ENTERTAINMENT

Abstract

A system for real-time communication between a plurality of different games, including: a plurality of different gaming engines that transmit and receive a plurality events between the plurality of different games; an interchange protocol for permitting use of a common vocabulary between the plurality of dissimilar/different engines of the plurality of events; and a vocabulary generation system for mapping internal events from a first engine of the plurality of different gaming engines to external events of a second engine of the plurality of different gaming engines; wherein each of the plurality of different games includes an event table, a build event mapping function, and a use built-in event mapping function, the event table being unknown in advance to each of the plurality of different games.

Description

TRADEMARKS

IBM® is a registered trademark of International Business Machines Corporation, Armonk, N.Y., U.S.A. Other names used herein may be registered trademarks, trademarks or product names of International Business Machines Corporation or other companies.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to gaming systems, and particularly to a method of communication between two or more dissimilar/different gaming engines.

2. Description of Background

There are two basic types of multiplayer gameplay associated with computer gaming systems. These are competitive multiplayer gameplay and cooperative multiplayer gameplay. In competitive gameplay, players attempt to defeat each other. In cooperative gameplay, players work together to achieve a common goal. In team-based gameplay, groups of players compete against each other, but the members of the groups cooperate with their teammates.

In general, cooperative game modes are similar to single-player game modes. In cooperative mode, human players replace computer-controlled allies, but the same tasks/goals/achievements laid out in single player mode carry over to cooperative mode. More simply, in today's cooperative gaming, all players use the same gameplay and control scheme (engine) because the feature is built around the single player mode of the game. This leads to players having to complete the same kinds of tasks as the others on their team, with only slight differences. For example, in first person shooters games, squad members may have slightly different roles (such as attacking the enemy base, defending the home base, item collection, etc.), but the interface for a first-person shooter games remains constant for all players.

Also, there are frequently people in the same household who have different preferences in gaming. People outside of the traditional 18-24 age group are more likely to play simple games such as card or puzzle games (e.g., Solitaire®, Bust A Move®, or Tetris® rather than more traditional console games like shooters games or fighting games (e.g., HALO, Half-Life, Guilty Gear, etc.) This makes it difficult for people who prefer simple (casual) games to play with people who prefer more complex games (hardcore gamers). Hardcore gamers are frequently uninterested in simple games, and casual gamers have a hard time playing the more involved games and simulations that the hardcore gamers favor. This is one of the major roadblocks to growth of the gaming industry. A solution that would allow the entire household to game together would be of very high value to game publishers and console manufacturers.

Considering the limitations of the aforementioned methods, it is clear that there is a need for a method of communication between two or more dissimilar/different gaming engines.

SUMMARY OF THE INVENTION

The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a system for real-time communication between a plurality of dissimilar games, including: a plurality of dissimilar gaming engines that transmit and receive a plurality events between the plurality of dissimilar games; an interchange protocol for permitting use of a common vocabulary between the plurality of dissimilar engines of the plurality of events; and a vocabulary generation system for mapping internal events from a first engine of the plurality of dissimilar gaming engines to external events of a second engine of the plurality of dissimilar gaming engines; wherein each of the plurality of dissimilar games includes an event table, a build event mapping function, and a use built-in event mapping function, the event table being unknown in advance to each of the plurality of dissimilar games.

The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method for real-time communication of a plurality of events between a plurality of games, the method comprising: providing a plurality of dissimilar gaming engines that transmit and receive a plurality events between the plurality of dissimilar games; permitting use of a common vocabulary between the plurality of dissimilar engines of the plurality of events via an interchange protocol; and mapping internal events from a first engine of the plurality of dissimilar gaming engines to external events of a second engine of the plurality of dissimilar gaming engines via a vocabulary generation system; wherein each of the plurality of dissimilar games includes an event table, a build event mapping function, and a use built-in event mapping function, the event table being unknown in advance to each of the plurality of dissimilar games.

Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. For a better understanding of the invention with advantages and features, refer to the description and the drawings.

TECHNICAL EFFECTS

As a result of the summarized invention, technically we have achieved a solution that provides for a method of communication between two or more dissimilar/different gaming engines.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter, which is regarded as the invention, is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

FIG. 1 illustrates a flow diagram describing an exemplary flow of communication between dissimilar/different gaming engines, according to the exemplary embodiments of the present invention;

FIG. 2 illustrates a flowchart describing a method of communication between two or more dissimilar/different gaming engines, according to the exemplary embodiments of the present invention; and

FIG.3 illustrates a system describing an exemplary flow of communication between dissimilar/different gaming engines, according to the exemplary embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

One aspect of the exemplary embodiments is a system for communication of events between two or more dissimilar/different gaming engines for improved multiplayer gameplay as well as a system for developing an event interchange vocabulary so that games that support one protocol can still interact meaningfully with one another without any foreknowledge of the types of events generated in the other game(s).

The exemplary embodiments of the present invention describe a method for two or more separate game engines to interact with one another in real-time. In addition, the exemplary embodiments describe a system for generating a common protocol with which two or more games can be made to communicate. This would permit a casual gamer's puzzle game to influence their hardcore gaming friend's first person shooter and vice-versa, for example, bringing everyone into a shared gaming experience.

Integrating multiple game engines today would require the two engines to agree to a predetermined set of messages that could be sent between them. This greatly limits the flexibility of the multi-engine concept by requiring 1) foreknowledge of the messages to be sent by each engine and/or 2) a limited predetermined vocabulary of messages. The exemplary embodiments use of an interchange protocol for developing a common vocabulary between two or more engines when they first encounter each other. For the sake of brevity, the interchange protocol is referred to as the Action Interchange System (AIS).

Use of the vocabulary generation system is not mandated; however, the possibility is still left open for a predetermined vocabulary. This would most likely see use in co-branded games. For example, a racing game that supports AIS would be able to communicate with a puzzle game that supports AIS. The event vocabulary used between the two systems could be created on the fly using the language determination systems described with respect to the exemplary embodiments. If the two games were made by the same company (or two companies in partnership), they could negotiate beforehand the vocabulary and include it in the games. In this way, the vocabulary determination stage could be skipped and the integration between the two engines could be tighter since the event mapping would be determined by game designers rather than by a vocabulary generation algorithm.

The two or more game engines would not have to have much in common, but be separate games in and of themselves. In a cooperative contest, all players on a team would have to work together and be skilled at accomplishing tasks in the game they are playing in order to make significant progress in the contest for the team. In a competitive contest, accomplishing objectives in one engine will directly affect the difficulty of accomplishing objectives in another engine. However, as one skilled in the art would predict, these are not actual requirements, but merely recommendations. Unskilled players would still benefit from the exemplary embodiments of the present invention and sometimes teammates chose not to work together as they should. In other words, two teammates might actually do each other's characters harm using this system accidentally or on purpose.

AIS defines a system for communication of events between game engines. The events are communicated using an event-description system that is specific to the game engines communicating. Each game supporting AIS would contain a table of events that can occur in the game. Some of these would be internal events that happen during normal gameplay. Some would be external events that can be triggered by another game engine. Some events could be both internal and external, indicating that they can happen both through normal gameplay and in response to a signal from another game engine. Each event also has at least two other factors: its impact on the game on a scale from, for example, −100 to 100, and an expected frequency of occurrence. Positive impact values are beneficial to the player experiencing the event. Negative impact values are detrimental to that player.

Sending the external event table to the other game is the first step in AIS. A game identifier would also be sent so that game engines with specific knowledge of another particular engine could handle the table differently, possibly ignoring it altogether. The interchange vocabulary is a mapping from internal events (or combinations thereof) in one engine to external events in another. The vocabulary description system defines how the mapping can be defined at runtime if the two games do not already share a common vocabulary.

Once a common vocabulary is determined, the games are played as normal. As the internal events in one game combine to fit the mapping in that game's side of the vocabulary, event messages are sent to the other game, triggering that external event in that game. When choosing which external event to trigger, the game engine only launches negative events at enemies and positive events at allies. Sending an event consists of sending the external event identifier and the identifier of the player or players that triggered the internal events that mapped to that external event.

Referring to FIG. 1, a flow diagram describing an exemplary flow of communication between different gaming engines describing the flow in two different games, according to exemplary embodiments of the present invention is illustrated. Although FIG. 1 describes the flow in both games, it omits the details of the player and team negotiation phases, which occur before the actual AIS process is initiated. The solid lines indicate program flow. The dashed lines indicate communication between one engine and the corresponding portion of the other.

The elements of the games are as follows. Concerning the first game, the system comprises: a first engine 12, an “engine discovery and player team negotiation” 14, a decision block 16, a “use built-in event mapping” 18, a request event table 20, a build event mapping 22, and a play game block 24. Concerning the second game, the system comprises: a second engine 26, an “engine discovery and player team negotiation” 28, a decision block 30, a “use built-in event mapping” 32, a request event table 34, a build event mapping 36, and a play game block 38.

In particular, when the first engine 12 requests the event table 20, it communicates with the second engine 26 as indicated by the dashed line in FIG. 1. Then the first engine 12 proceeds to build the event mapping 22 as indicated by the solid line in FIG. 1.

A few examples can clarify this process. For instance, consider two AIS compliant games. One is a Tetris clone, the other is a racing game. Of course, one skilled in the art may select any two type of games. Neither game has a built-in event mapping for the other. In the Tetris-like game, clearing a line would be an internal event. If this game wanted another game to be able to trigger a line clearing, then that event could also be external. In the racing game, passing another car would be an internal event. Getting a speed boost might be both internal and external. An oil slick appearing might be an external-only event.

The table of Tetris events is presented below:

	ID Name	Source	Impact	Frequency
	A) Line Cleared	internal	1	11
	B) Double	internal	10	35
	C) Tetris	internal	80	52
	D) Drop many blocks	external	−60	93
	L) Hide next block	external	−30	27

The table of Racing events is presented below:

	ID Name	Source	Impact	Frequency
	A) Pass Opponent	internal	20	30
	B) Extra Fuel	external	30	41
	C) Extra Boost	both	90	75
	D) Oil Slick	external	−60	187

Once the two games are connected, each would send the other its list of external events along with the game impact and expected frequency of those events. Each engine 12, 26 would then build a mapping 22, 36 from its internal events (or combinations thereof) to those external events of the other engine. The term “impact” refers to the relative degree to which a particular event affects a game. Events with a negative impact score harm the target of the event. Positive scores aid the target. Within a game, an event with a higher absolute impact score will have a greater effect on the game state than one with a lower absolute impact score. In this way, the game authors can provide a ranking of the games events. To summarize, a game should react to help the gamer when it receives a positive event, and to hurt the gamer when it receives a negative event. Events with higher (absolute) impact scores should have a greater effect than those with lower absolute scores. Of course, all the data in the above-mentioned tables may be designated in various ranges depending on the software manufacturers specifications and requirements.

Below are the tables that would constitute the AIS vocabulary for these two games. Table headings are explained as follows:

• iEvents: the combination of internal events that triggers the external event
• iImpact: the sum of the impacts of the iEvents
• iFreq: the sum of the frequencies of the iEvents
• eEvent: the external event to trigger
• eImpact: the impact of the eEvent
• eFreq: the desired frequency of the eEvent

The positive table that Tetris generated is presented below:

iEvents	iImpact	iFreq	eEvent	eImpact	eFreq
B × 3	30	105	B	30	41
B + C	90	87	C	90	75
B × 2 + A × 10	30	180	B	30	41

The negative table that Tetris generated is presented below:

iEvents	iImpact	iFreq	eEvent	eImpact	eFreq
B × 6	60	210	D	−60	187
B × 5 + A × 10	30	285	D	−60	187
C + A × 10	100	190	D	−60	187

The Racing game generated no positive table since Tetris has no positive external events listed.

The negative table that the Racing game generated is presented below:

	iEvents	iImpact	iFreq	eEvent	eImpact	eFreq
	A × 3	60	90	D	−60	93
	B	30	41	E	−30	27
	C + A	110	105	D	−60	93

These tables illustrate that when both a Tetris (four-line clear) and a double (two-line clear) are achieved by a player in Tetris, the Tetris engine sends a boost event to an ally in the Racing game. When a player passes three cars in the Racing game, a massive block drop event is sent to an opponent in Tetris. Of course, all the data in the above-mentioned tables may be designated in various ranges depending on the software manufacturers specifications and requirements.

The vocabulary is determined using an algorithm. In particular, the system attempts to find combinations of internal events whose impact values add up to (or close to) the impact value of one of the external events, while keeping the sum of the frequency values as close to the frequency value of that external event as possible. Once several combinations have been generated, the one with the closest match to the impact value and frequency value is selected for mapping to the external event. Once those internal events have been triggered in game, the game sends the mapped external event to the other engine. Since the impact values and frequencies are close, the gameplay remains balanced.

It is possible that after the mapping has been generated, some internal events may not have been used in the mapping since they do not fit in well with the external events. A more complete mapping system would find any underutilized internal events and create alternate mappings for external events using those internal ones. These would be unbalanced in favor of the external event. It would take more effort to trigger one of these substandard mappings on the part of the player, or it would take unusually long to trigger these events. This keeps all of the internal events utilized while not allowing the player of one engine to have undue impact on the other because the mapping failed to utilize all of the internal events. This can be seen in the example above in the last line of the positive Tetris table, the last two lines of the negative Tetris table, and the last line of the negative Racing table. Optionally, game balance can be improved by restricting the triggering of external events to the stated external event frequency regardless of the speed with which the player triggered the event.

If there are not enough internal event combinations to map to the external events, there are two options that can be used singly or together: event sequences and multiple mapping. Event sequences would replace the combination of internal events needed to trigger an external event with a sequence of internal events that must be triggered in sequential order. This would allow two identical combinations of internal events that map to an external event to be differentiated by the order in which the internal events are triggered. The other choice is to have sequences or combinations of internal events map to multiple external events. The game engine would then choose which external event to trigger each time the sending mechanism is triggered. This choice could be made by comparing the actual in-game frequency to the desired frequency of the external event, by randomly choosing an external event, or by choosing the next external event using a scheduling algorithm such as round-robin.

Referring to FIG. 2, a flowchart describing an exemplary process flow of a method of communication between two or more dissimilar/different gaming engines, according to the exemplary embodiments of the present invention is illustrated. The method starts at step 40. At step 42, an interchange protocol is generated with which the plurality of dissimilar/different games communicate with each other. At step 44, a common vocabulary between the plurality of dissimilar/different games is developed. At step 46, events between engines of each of the plurality of dissimilar games are generated. At step 48, the process ends.

Referring to FIG. 3, a system describing an exemplary flow of communication between dissimilar/different gaming engines, according to the exemplary embodiments of the present invention is illustrated. The system 50, which can be a any type of communication network, includes a first game 52 having a first engine 54, and a second game 56 having a second engine 58. The first engine 54 communicates via a communication link 60 with the second engine 58.

The AIS may be looked as a scheme that affects the future of gaming interaction. Lately, video game publishers have been financing/creating products containing very few innovative ideas, and this, has resulted in decreasing game sales across the industry. Gamers have been asking for innovation, but publishers, confronted with rising development costs, have failed to deliver. Instead, they rely on the game equivalent of the formulaic big-budget “blockbuster” and leave casual gamers out of the loop entirely. The next step in revolutionizing the game industry is to give both casual gamers and hardcore gamers the ability to play together in such a way as to maximize enjoyment potential for both groups. A future is envisioned where many games are marketed as AIS compatible, meaning that they can work intelligently with other AIS compatible games.

In addition, this technology has an impact in areas outside of gaming. Other areas where this technology could be implemented aside from gaming include several types of training simulations: Military training simulations which require more than one interacting engine Pilot/commercial airline training simulations that combine pilot and traffic control training applications College/University training simulations—an example would be a program used by computer systems and business departments to simulate running of a company with tech-based and business-based integrated applications.

In conclusion, the exemplary embodiments describe a method, which allows two completely different gaming engines to interact by creating of a protocol, which can be used for any type of game or simulation, and also in the fact that the exemplary embodiments allow for a generation of event tables on the fly so the games/simulations communicating with one another need not know characteristics of each other in advance. AIS-aware games would negotiate their own positive and negative event mappings, which would allow players of multiple games to influence the games of others.

The capabilities of the present invention can be implemented in software, firmware, hardware or some combination thereof.

As one example, one or more aspects of the present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately.

There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.

While the preferred embodiment to the invention has been described, it will be understood that those skilled in the art, both now and in the future, may make various improvements and enhancements which fall within the scope of the claims which follow. These claims should be construed to maintain the proper protection for the invention first described.

Claims

1. A system for real-time communication between a plurality of different games, the system comprising:

a plurality of different gaming engines that transmit and receive a plurality events between the plurality of different games;

an interchange protocol for permitting use of a common vocabulary between the plurality of different engines of the plurality of events; and

a vocabulary generation system for mapping internal events from a first engine of the plurality of different gaming engines to external events of a second engine of the plurality of different gaming engines;

wherein each of the plurality of different games includes an event table, a build event mapping function, and a use built-in event mapping function, the event table being unknown in advance to each of the plurality of different games.

2. The system of claim 1, wherein the vocabulary generation system defines how the mapping is defined at runtime.

3. The system of claim 1, wherein when the internal events of a first game combine to fit a mapping in a vocabulary of the first game, one or more event messages are sent to a second game to trigger the external events in the second game.

4. The system of claim 3, wherein the one or more event messages are either negative event messages sent to enemies or positive event messages sent to allies.

5. The system of claim 1, wherein sending one or more events consists of sending an external event identifier and an identifier of a player of a first game that triggered the internal events to a second engine.

6. A method for real-time communication of a plurality of events between a plurality of games, the method comprising:

providing a plurality of different gaming engines that transmit and receive a plurality events between the plurality of different games;

permitting use of a common vocabulary between the plurality of different engines of the plurality of events via an interchange protocol; and

mapping internal events from a first engine of the plurality of different gaming engines to external events of a second engine of the plurality of different gaming engines via a vocabulary generation system;

wherein each of the plurality of different games includes an event table, a build event mapping function, and a use built-in event mapping function, the event table being unknown in advance to each of the plurality of different games.

7. The method of claim 6, wherein the vocabulary generation system defines how the mapping is defined at runtime.

8. The method of claim 6, wherein when the internal events of a first game combine to fit a mapping in a vocabulary of the first game, one or more event messages are sent to a second game to trigger the external events in the second game.

9. The method of claim 8, wherein the one or more event messages are either negative event messages sent to enemies or positive event messages sent to allies.

10. The method of claim 6, wherein sending one or more events consists of sending an external event identifier and an identifier of a player of a first game that triggered the internal events to a second engine.

11. A method for real-time communication of events between a plurality of gaming engines of a plurality of games, the method comprising:

generating an interchange protocol with which the plurality of games communicate with each other;

using a predetermined vocabulary; and

generating and sending events between engines of each of the plurality of games.

12. The method of claim 11, wherein the predetermined vocabulary defines how the mapping is defined at runtime.