US20070293319A1

US20070293319A1 - Transfer of Features Between Gaming Devices

Info

Publication number: US20070293319A1
Application number: US11/425,258
Authority: US
Inventors: Timothy Stamper; Paul Machacek; Christopher Stamper
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2006-06-20
Filing date: 2006-06-20
Publication date: 2007-12-20
Also published as: CN101473341A; EP2036021A1; JP2009540920A; RU2008150478A; WO2007149147A1; KR20090021172A

Abstract

A method of connecting gaming devices together is described which enables multi-party gaming between devices with different feature sets. A device receives data from several gaming devices and determines which features each gaming device requires These required features are those which are not held at the particular device but are held by one or more of the other devices. Code relating to the particular features required by each gaming device is then transferred to each of the gaming devices.

Description

BACKGROUND

Games consoles, such as Xbox 360™, have been developed which enable a gamer to play games with other gamers over a network. Typically the game play is controlled by a server although the software for running the game resides on the individual games consoles. In order for a group of gamers to play a game together over the network (also referred to a live game or an online game), each gamer must have a license for the game (e.g. obtained when the game is purchased on a disc or downloaded) and each gamer must have the same features for that game. Where gamers have different feature sets, they cannot play an online game together because it would result in their games console receiving data that it cannot interpret. The problem is exacerbated by the increasing ability of gamers to purchase additional levels, weapons etc for a game, for example through micropayments.

SUMMARY

The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.
A method of connecting gaming devices together is described which enables multi-party gaming between devices with different feature sets. A device receives data from several gaming devices and determines which features each gaming device requires. These required features are those which are not held at the particular device but are held by one or more of the other devices. Code relating to the particular features required by each gaming device is then transferred to each of the gaming devices.

DESCRIPTION OF THE DRAWINGS

The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein:

FIG. 1 is a schematic diagram of a network of gaming devices;

FIG. 2 shows an example flow diagram of the operation of a server;

FIGS. 3 & 4 show example flow diagrams of steps of the flow diagram in FIG. 2 in more detail;

FIG. 5 shows the virtual positions of many characters in a game world;

FIG. 6 shows an example flow diagram of a method of limiting the transfer of features;

FIG. 7 shows an example flow diagram of a step of the flow diagram in FIG. 2 in more detail;

FIG. 8 shows a schematic diagram of a console;

FIG. 9 shows an example flow diagram for the purging of data;

FIG. 10 shows a schematic diagram of a server; and

FIG. 11 is a schematic diagram of another network of gaming devices.

Like reference numerals are used to designate like parts in the accompanying drawings.

DETAILED DESCRIPTION

The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.
As described above, gamers with different feature sets are currently prevented from playing an online game together because it would result in their games console receiving data that it cannot interpret. The problem of mis-matched feature sets is exacerbated by the increasing ability of gamers to purchase additional features, such as additional levels, weapons etc and the ability of gamers to create their own custom features (egg. avatars, custom vehicles, custom landscapes etc). In addition to gamers purchasing additional software features, gamers may also purchase additional peripherals for their gaming devices (e.g. guns etc).
FIG. 1 is a schematic diagram of a network 100 of gaming devices. The network comprises four gaming devices 101 (e.g. Xbox 360™) connected together via a server 102 (e.g. an Xbox Live® Server). Each gaming device comprises a console 103, a display 104 and a controller 105. The connections may be wired or wireless, direct or indirect (e.g. over the internet). It will be appreciated that a network may comprise more or fewer devices and that each device may have one or more controllers connected to it, with different gamers using different controllers to play the same game. The operation of the server 102 can be described with reference to FIG. 2. The server receives requests from each of the gaming devices 103 to join a game (step 201) and in response to these requests, the server polls each of the gaming devices for attribute information pertaining to the game in question. The attribute information may include details of levels, weapons, avatars and other features of the game (step 202). Having received the attribute information, the server determines the differences in feature sets held by each of the devices (step 203) and transfers the required features to each console such that they have a common feature set (step 204). Once each gaming device has the same feature set, the game can start (not shown in FIG. 2)
In an example, a common scripting language may be used to transfer the features. In another example, XML (extensible mark-up language) may be used as an interface for sharing attribute information between gaming devices.
In some situations, for example where gamers have created their own features (such as new personalized avatars) or where gamers have purchased third party software or hardware (e.g. a gun, a steering wheel etc), the server may not have the required code to enable it to distribute the code to the gaming devices without it. In such a situation, (as shown in FIGS. 3 and 4), the server may first identify the differences (step 203 a) and then identify what code it does not hold (step 203 b). Having identified what code it needs (in step 203 b), the server then uploads that code not held at the server from a gaming device which does hold the code (step 204 a) and then transfers the differences to all devices as required (step 204 b), as described above. Where the features have been created by the gamer, they may be made from sub-features from a standard library or they may be totally new and may be in a standard data format, (such as JPEG for avatars or other visual information) to enable them to be imported into the game. Where new hardware has been purchased by a gamer, the code may relate to the display of the new feature (e.g. the image for the gun) or other parameters relating to the hardware. The code may also include control information, drivers or emulators for the hardware which may enable other gamers to have the functionality of the hardware, with perhaps limited functionality, where they have alternative compatible hardware (e.g. an alternative peripheral, such as a different gun).
This enables gaming devices with different feature sets to be connected together in order that gamers can play a multi-party game. By transferring only the differences, the data transfer is minimized which minimizes delays due to transmission between the host and the gaming devices. The method also enables custom or third party features to be shared between gaming devices.
By transferring the features to the gaming devices prior to commencement of any game play, this method avoids problems which might otherwise be caused by low data rate connections between the gaming devices and the server. If, instead, the differential features were downloaded by the server to the gaming device when required (e.g. when entering a new level or when a new weapon is about to be used, where only one of the gaming devices has the required attributes for the new level or weapon), a poor network connection would result in delays in rendering the correct display by the console.
If a new gaming device requests to connect to the game after it has started (i.e. after the initial transfer of differences as shown in FIG. 2) or one of the original devices disconnects and subsequently requests to reconnect (e.g. if the disconnection was unplanned), the server may only poll the joining device (as in step 202) and then compare the data to the common feature set established for the other devices (in steps 202-204). The server may then identify the differences between the joining device and the common feature set and transfer any required code to the joining device. If the joining device has features that are not part of the common feature set, code will also be transferred to all the other devices.
Polling of devices (step 202) may be repeated periodically during game play (e.g. every 5 minutes or in response to a trigger) to determine whether any gaming devices have obtained additional features. In such situations, code transfer will only occur (step 204) where new differences are identified (in step 203).
In some situations, the bandwidth between a gaming device and the server may be limited such that it may not be possible to transfer all the additional feature information to a gaming device. In that situation the code relating to a particular feature (e.g. a new weapon) may be replaced by a smaller size file containing basic descriptive attributes relating to the feature (e.g. the polygon model, animations, textures etc may not be transferred in their entirety). This would enable the object's functionality to remain intact for the owner who would be able to use and see the feature as normal whilst the other gaming devices may only display a simplified version of the feature or a standard graphic when it is being used.
In an example, several different quality models of the same object (or other feature) may exist with each model providing a different level of detail (LOD) relating to the feature. For example, a vehicle may be modeled three times, one in high detail for close up viewing, one in medium detail and one in low detail for viewing at a distance. The lower detail model will therefore have fewer polygons, textures, animations and general detail than the high quality model with the medium quality being somewhere between the two. The low quality model therefore is a smaller block of data which is much easier to transfer over a network to other gaming devices. Having determined which feature code needs to be transferred between devices (in step 203) the server may (as part of step 204) assess the available bandwidth to each gaming device and determine whether it is possible to transfer the highest quality versions of any feature code within an acceptable timeframe (e.g. a maximum delay time may be predetermined). In a situation where the high LOD model cannot be transferred in an acceptable time period, the server may then determine whether the medium LOD code versions can be transferred and if not it will transfer the low LOD feature code to gaming devices with restricted bandwidth connections to the server. It will be appreciated that there may be more or less than 3 LOD versions for each feature and the number of LOD versions of a feature may depend on the nature of that feature. For example, a knife is small and may require only one LOD (as it can only be seen close up) whereas an aeroplane may require five, for instance (for views from varying distances). The transfer of the different LODs enables the original owners of the features to still use the feature with the display looking normal to them whilst the other gaming devices will be able to understand the new features, display them and enable a gamer to interact with them but they may be graphically downgraded.
In the situation where a reduced quality feature is transferred to a gaming device, this may be upgraded automatically by transferring the higher quality LOD versions in the background, e.g. whilst the game is proceeding. This would result in all gaming devices eventually receiving the highest quality LOD versions of each feature it required whilst providing a quick solution to immediate usage when there is a bandwidth restriction on a connection.
In some situations, for example when a game is played by very large numbers of gamers (e.g. a MMORPG, a massively multiplayer online role-playing game), it may not be possible to transfer all the features before the game starts or at a pause in the game play (e.g. prior to the start of a new race in a racing simulator driving game) because gamers are constantly joining and leaving the game. Furthermore, with a very large number of gamers, the differences in attributes held by each of the gaming devices may be very large (e.g. each of the millions of gamers may have their own customized avatar). In such a situation, the transfer of features between gaming devices may be limited according to predetermined parameters and examples of a limiting method are described below with reference to FIG. 5.
FIG. 5 shows the virtual positions of many characters 501-504 in a game world, each character being controlled by a gaming device. In determining the differences in attributes between devices and transferring those differences to a particular gaming device (in steps 203 and 204), only those differences which relate to the gaming devices whose characters are close to the gaming character of the particular device in the gaming world are transferred to that device. In the example shown in FIG. 5, an area 505 is defined around the position of a particular character 501 controlled by a first gaming device. Code relating to differences in features between that first gaming device and the gaming devices controlling any characters within the area 505 are transferred to the first gaming device, however, code relating to differences between the first gaming device and other gaming devices which are controlling characters outside of the area 505 are not transferred to the first gaming device. A second area 506 is defined around the position of another character 502 controlled by a second gaming device. Code relating to differences in features between that second gaming device and other gaming devices that are controlling characters within the second area 506 are transferred to the second gaming device.
An example flow diagram of the method is shown in FIG. 6. The server polls all the devices playing a particular game for attribute information (step 601) and, for each device, identifies a subset of devices associated with that device (step 602), e.g. in the example of FIG. 5, subset of devices associated with the first gaming device comprises all those devices controlling characters located within area 505. The server then identifies the differences in attributes between the particular device and the other members of a subset (step 603). These two steps (steps 602-603) are repeated for each device and the server transfers to each device the code associated with the identified differences in features (from step 603) between that device and the other devices within its subset (step 604).
It will be appreciated the order of method steps is provided by way of example only and for example, the server may identify all the differences between a device and the other devices in the game and then filter those differences based on the subset, etc.
The method may be implemented by the server periodically, e.g. every 30 seconds or whenever characters move within the game such that the subset of device associated with a particular devices changes. This may result in the method being implemented by the server on a quasi-continuous basis, with small amounts of code being transferred quasi-continuously to each of the gaming devices.
Where a gaming device controls more than one character, the subset associated with that gaming device may comprise the sum of multiple subsets, one associated with each of the characters being controlled.
According to the method described above, if the first gaming device (controlling character 501) holds a feature set A, B and C whilst the second gaming device (controlling character 502) holds a feature set A, B, C and D, the code relating to feature D will be transferred by the server to the first gaming device. However, if a third gaming device (controlling character 503) holds a feature set A, B, C and E, the code relating to feature E will be transferred by the server to the second gaming device (because character 503 is within area 506) and not to the first gaming device (because the character 503 is not within area 505) and this leads to a further mismatch between features held by the first and second gaming devices. However, the first gaming device will still be able to operate properly because, as character 503 is not close to character 501, the first gaming device will not need to display or otherwise use any of the features held by the third gaming device. Consequently, the transfer of features between gaming devices (e.g. in step 604) may be limited by one or more parameters, such as the ownership and/or control of the particular features. This is described in more detail below.
By limiting the transfer of information between gaming devices playing the same game, delays due to poor network connections between the gaming devices and the server can be minimized.
The size of the area used to identify the subset of devices (as described above) may be variable according to one or more predetermined parameters. The size of the area may be fixed for a particular device or may vary dynamically. In an example, the size of the area may be varied according to the data rate of the connection between the particular gaming device and the server. Where a gaming device has a high data rate connection to the server, the area for that device may be larger. In another example, the size of the area may depend on a service level paid for by a gamer (e.g. a higher service level demanding a higher fee may offer a larger area) in a further example, the size of the area may be dependent on the amount of data to be transferred, such that there is a target data rate for the transfer of data from the server to a gaming device. With such a target data rate, the size of the area will change dependent on the amount of feature code to be transferred (e.g. according to the density of characters with new features). Use of a target data rate may increase the efficiency of usage of the link between the server and the gaming device. In another example, the area may be varied such that the feature sets for a predetermined number of gaming devices are compared (e.g. 10 gaming devices). It will be appreciated that there may not be a 1:1 relationship between characters and gaming devices because a single device may have multiple controllers each used by a different gamer to control a different character in the game world.
In another example, more than one area may be defined around each character to determine a plurality of subsets of devices associated with each device. For example, the first gaming device (controlling character 501) may have a first associated subset containing all those devices controlling characters within a first area 505 and a second associated subset containing all those devices controlling characters within a second area 507 and not within the first area 505. The transfer of features to the first gaming device (based on differences between that device and those in each of the first and second associated subsets) may be limited according to different parameters. For example, all the code relating differences between the first device and those devices in the first associated subset may be transferred to the first device, whilst only the code relating to the avatar (or other display) differences between the first device and those devices in the second associated subset may be transferred to the first device. This would enable the first device to display each of the characters (or items) in the second area 507 (and not the first area 505) correctly, but the first device would not receive other differences, e.g. differences in levels owned, differences in weapons, strengths, etc. In another example, low resolution avatar code may be transferred relating to those characters in the second area 507 whilst high resolution avatar code may be transferred relating to those characters in the first area 505. Progressive downloading techniques may be used to first download a lower quality image and then to continue to download further data and improve the quality of the image displayed.
In another example, as described above feature code may exist in multiple different quality versions. In an example, high LOD code may be transferred relating to features located in a first area 505 whilst a low LOD code may be transferred relating to those features in a second area 507. Again, progressive downloading or other techniques may be used to subsequently download the high LOD code for features in area 507 if there is available capacity over the connection.
In another example, multiple areas may be defined and each area may have different predetermined rules on which features are transferred (e.g. different levels of detail, different types of features etc).
In the above description, the set of features to be transferred was determined based on the locations of characters (as shown in FIG. 5). In addition to, or instead of this, features may be transferred according to the level of effect (LOE) of a feature. LOE is similar to LOD (described above) but covers the level (or degree) of an object's effect rather than the size of the code. For example, if three different weapon types are considered: a knife, a tank and a bomb. A knife is a small object that can only be seen close up. It also has a small level of effect, i.e. it can only be used locally whereas a tank is a large object which can be seen and heard a long way off and also has a high level of effect because it can attack things from a large distance. Finally, a bomb may be a physically small feature with a much larger LOE because although it may be a very long way away (such that it cannot be seen) it may still affect a character. The devices having a high LOE may require their feature codes to be transferred even though they may be located further from a character than those with a low LOE (where the feature code may not need to be transferred). In the example shown in FIG. 5 therefore, the first gaming device (controlling character 501) may have a first associated subset containing all those devices controlling characters within a first area 505 and a second associated subset containing all those devices controlling features with a high LOE which are located within a much larger area (e.g. second area 507).
In another example, the multiple areas which may be defined (as described above) may be used to determine subsets of devices (for subsequent transfer of features) according to feature size (in addition to or instead of using LOD and/or LOE as described above). For example, small features such as the knife mentioned above may only be transferred if they relate to the first area 505 whilst larger devices which may therefore be seen at a larger distance may have their feature code transferred when they are in the second area 507.
The transfer of features between gaming devices may be prioritized based on the type of feature to be transferred. This prioritization may operate independently or in conjunction with any of the other techniques described herein. For example, the highest priority feature data to transfer may be whether a character is a bipedal humanoid, a quadraped, an armored car, a bird etc. The next priority may be similar information and basic functionality for any object being carried by that character, with the next priority being animations for special moves of that character. This may be followed by low LOD textures, higher level model detail and then higher LOD textures. By using such a prioritization, the receiving gaming device obtains the most important feature information about objects in a game first and less important information regarding specifics of animation or objects carried subsequently.
In the methods described above, code relating to features is transferred between the server or a gaming device and another gaming device when one or more gaming devices hold a particular feature. Whilst this enables gamers with different features sets to participate in games together, it may be necessary to control the subsequent use of those transferred features by the recipient gaming devices, particularly where the features are ones which have been paid for, earned etc. A gamer, having purchased a number of new weapons, would be reluctant to play a game with other gamers who have not purchased those weapons if it meant that those other gamers were subsequently able to use the weapons (e.g. when not playing with the garner who purchased them) without having to pay for them. Consequentially, it may be advantageous for features to be tagged with ownership information.
There are a number of different ways in which code relating to a feature may be tagged with ownership information. In a first example, the code may contain embedded ownership information, which may be encrypted. The ownership information may comprise an identifier associated with a gamer (e.g. a gamertag, an account/subscription number etc) or an identifier associated with a gaming device (e.g. the unique ID for a particular gaming device) or an identifier associated with a group or category of gamers. The features may in some situations only be enabled for use (by the server or the gaming device) when the identified owner is participating in the game play. This may be achieved by encrypted code being transferred between gaming devices and the encryption key being held by the owner. Use of the gaming devices may then be limited to the situation where the recipient gaming devices have access to the encryption key. In another example, the ownership information may comprise no ownership details but instead may indicate that no further change of ownership is permitted (e.g. that the feature is on loan as a volatile asset), In this manner the owner's privacy is kept intact whilst the feature code can be sent to other gaming devices. Where ownership information is flagged in this manner the feature code may then be discarded and not permanently held at the end of a gaming session or at another appropriate time. Use of encryption and/or digital signatures may prevent tampering of the ownership information. Digital Rights Management methods may be used to prevent copying of the code.
In a second example, each gamer or gaming device may have an associated inventory of features owned by that gamer or device. Each feature may have a unique ID which is securely attached to the object or encrypted within the object. This ID can be used to link the feature to the inventory. The inventory may be stored either on the gaming device or at the server and may be encrypted to prevent tampering. Again, the server or the gaming device may prevent use of features which are not owned by anyone who is participating in the game by checking the features against stored inventories.
In a third example, the server may maintain a central ownership register for features of a game. This register may be checked by the server and gaming devices before enabling any features which are downloaded to devices (e.g. in step 204 or 604). Use of such a central register may be advantageous because it is more secure. The register may also record any transfer of ownership. By using a register in this way, the amount of data held can be remotely expanded (e.g. by including a full ownership history and/or a list of key events in the feature's lifespan) without expanding the actual size of the feature's data which would make it larger to transfer when transferring it between gaming devices. In another example, both a central register and individual inventories associated with a gamer/gaming device may be used.
The transfer of ownership of an object or other feature may occur within the game (as described below) or external to the game (e.g. via a web sales/auction site). Where the transfer occurs external to a game, the transfer may only take effect when the gamers meet within a game world. At this point the ownership tag (or other ownership information, for example in a register) may be updated.
The server and/or the gaming devices may be arranged to reject objects or features where the identifiers have been tampered with or where false identifiers have been inserted into feature data. Furthermore, objects may be automatically removed or added depending on other circumstances or criteria. In an example, if an object is sold to another person via a web sales site, the object may be automatically added once the seller and buyer meet in a game world. The object may have been previously temporarily removed/suspended following the transaction between the buyer and the seller. In another example, if the buyer defaults with their payment after the ownership of the item/feature has been transferred, then the seller may be able to request the removal of control of the feature until the dispute between seller and buyer has been resolved. In a further example, there may be ways that an item could be stolen in the game that was beyond the accepted bounds of stealing and so the item may need to be suspended or disabled (e.g. by a moderator) until the situation had been resolved. In other examples, items which (for whatever reason) become “faulty” or “corrupted” may be suspended from use until corrected, or removed altogether, In a further example, items that might have entered the game world and which are deemed “undesirable” by gamers, a moderator or other controlling entity, may also suspended, deleted or otherwise removed from game play.
As mentioned above, the transfer of features between gaming devices may, in some situations, (e.g. in step 604), be limited by one or more parameters, such as the ownership of the particular features. FIG. 7 shows an example flow diagram of step 202 in more detail which incorporates such a limitation. The devices are polled for attribute information (step 202 a) and for each feature identified in the attribute information, the ownership of each feature is checked (step 202 b). The received attribute information is then filtered (step 202 c) to remove references to any features which are not owned by either the device from which the attribute information was received or a gamer logged in (or associated with in any other way) that device. Consequently in subsequent steps (e.g. of FIGS. 2 or 6) the comparison of difference only relates to attributes which are owned by the device/gamer and therefore the transfer of code relating to features (in step 204 or 604) is similarly limited.
In the specific example described above in relation to FIG. 5, the first gaming device (controlling character 501 owns features A, B and C whilst the second gaming device (controlling character 502) owns features A, B, C and D, and the third gaming device (controlling character 503) owns features A, B, C and E. Consequently, code relating to feature D will be transferred by the server to the first gaming device and code relating to feature E will be transferred by the server to the second gaming device. This leads to the first gaming device holding features A-D, whilst only owning features A-C and the second gaming device holding features A-E, whilst owning features A-D. Although the features held by the first and second gaming devices are not the same, there is no requirement for further transfer of features because the first gaming device holds all the features which are owned by the second gaming device (the second gaming device is in the area 505 associated with the first gaming device) and vice-versa (the first gaming device is in the area 506 associated with the second gaming device).
Although the description above refers to characters within a game, the methods described are also applicable to other controllable objects within a game, such as vehicles, or other user defined objects, such as buildings, scenery etc.
Although the example described above shows the transfer of feature code being limited by both area and ownership, the two filters may be implemented independently (e.g. by filtering only on ownership) and the transfer of feature code may be filtered using any suitable parameter(s) including LOD, LOE etc.
In addition to tagging features with ownership information (e.g. in the code or via an inventory/register as described above), they may be tagged with other information, (e.g. scope of usage, time stamps etc) which may be more transient (e.g. identity of controlling device/gamer, which may be different to the owner). For example the features may be tagged with information detailing which device can use the feature for a limited period of time. This may be used to enable the feature's control to be transferred during a game from the owning device (e.g. the owner or the device with which the owner is associated where ownership is linked to a gamer rather than a gaming device) to another device (e.g. if a new weapon is taken in the gaming world by another character). Such applications are described in more detail below. The feature may be tagged with the other information in the same way as the ownership information, as described above, or in a different way. In particular, it may not be necessary to encrypt this information where the information is transient and expires at some point in the future because there may be less concern about tampering. Where the controlling entity and the owning entity are different, it may be necessary for the server to check that the owning entity is not, in the time period specified, using the particular feature. In such an example, the transfer of feature code may be limited by both ownership and control, (particularly where also limited by area).
The features transferred to gaming devices using the methods as described above, may be used in different ways by the device within subsequent game play. In a first example, the feature code may be used to ensure that the display is correctly rendered at the receiving device (e.g. to correctly display the image of a new weapon purchased by another gamer). In another example, the device may be able to use all the features received in the game play, for example, if a new weapon has been purchased by another gamer and the associated code transferred to the device, the new weapon may be available to all those playing the game. Where the new feature relates to new hardware (e.g. a new gun) the code may be used to enable other gaming devices to emulate that hardware using an existing controller or other peripheral. The manner in which features may be used may be specified by the server or may alternatively be specified within the feature code.
Where the feature is not available for full use by all devices, the control of the feature may be enabled to change during game play (e.g. if a character steals/borrows/loans an item). In such a situation, a control tag associated with the feature may be changed such that a different device has full use of the feature (for a limited time) whilst the owning device does not. As described above, an inventory or central register may be used in addition to or instead of a control tag to record control (and ownership). Therefore the transfer of control may be recorded in an inventory, a register or by any other suitable means. Such transfer of control may be accompanied by a micropayment between the owner and the gamer taking control of the device. It may further be possible for the feature to be sold or exchanged within the game world, for example in return for a micropayment or another feature, and in such a situation the ownership information may be updated (e.g. in an ownership tag, an inventory, a register etc).
The use of features within the game may be linked to an advertising/sale window such that if a character controlled by a first gaming device is approached/attacked by a character which owns a different feature (e.g. a new weapon), a window may appear providing details on that different feature (e.g. “You have just been attacked using weapon X” or “You have just been attacked by a character having new skill Y” etc). The details may include a description of the feature and a link/button to purchase the feature (e.g. in return for a micropayment) either from a store (e.g. from a store operated by the server) or the current owner (e.g. “You have just been attacked using weapon X. Would you like to purchase weapon X?”).
Information on the differences in feature sets owned by each gamer may be available for display to each gamer, for example in the form of an upgrade (or feature) list. This would enable a gamer to review the features held by others participating in the same game and decide whether they wished to upgrade, to continue to play the game etc. This list may include links to enable the features to be purchased or borrowed for a limited period, e.g. as a trial. Inventory information may be collected by the server by polling all devices (as in step 202) when they connect to the server (e.g. prior to receiving the request to connect to a game) and this would enable the information to be displayed to a gamer before they decide to join a game.
In the examples described above, the differences in feature sets held by different gaming devices are transferred to devices to provide a common feature set. However, in another example, a feature that is not owned by any of the devices may be transferred to each of the devices by the server, for example, as part of a free trial of the feature for a specified number of games (e.g. for one game) or a limited period of time (e.g. for 24 hours). In such a situation, an advertising/sale window (as described above) may presented to a gamer via the display of a gaming device (e.g. at the end of the game or towards the end of the 24 hour trial period), to provide a quick and easy method of the gamer purchasing the feature during or at the end of the trial period.
In the situation where a device is able to use all the features received from the server although the device does not own the feature or where a device has taken control of a feature that it does not own, if the actual owner of the feature stops participating in the game, the feature may continue to be available for the other devices participating in the game until the game is completed. If a gaming device is inadvertently disconnected (and may rejoin within a small time period) this may reduce the churn of features (which might degrade playing experience) and minimize transfer of feature code. In another example, as soon as the owner of the feature drops out, the server may send a signal to all the devices which disables the use of the feature.
Having received additional feature data, as described above, this data is stored at the gaming device e.g. in the memory 801 (as shown in FIG. 8) internal to the console 103 or in external memory. FIG. 8 shows a schematic diagram of a console 103 in more detail. The console comprises a processor 802 connected to the memory 801, a display I/O 803, a controller I/O 804 and a network interface 805. The memory 801 is arranged to store instructions to cause the processor 802 to perform some or all of the method steps described above. The memory may also be used to store feature data received (as mentioned above). The feature data received (over the network via the network interface 805) may be retained by the gaming device until it is deleted in response to a command input by a user (i.e. manual deletion e.g. in response to a signal received via the controller I/O 804) or it may be automatically deleted. The features downloaded may be deleted at the end of a game, at the end of a session, when the device is switched off (or put into standby), after a predetermined period of time (e.g. after 24 hours of non-use of a feature) or at any other suitable point. In another example, a signal may be received from the server when the owner of a feature drops out and this signal may trigger the automatic deletion of the relevant feature. The trigger may, in another example, be received from the owning gaming device. In another example, the code may be deleted when the amount of memory associated with the gaming device (internal and/or external) which is full reaches a threshold level (e.g. when the memory gets to 90% full or when there is only 100 MB free memory etc).
An example flow diagram for the purging of data is shown in FIG. 9. A trigger to purge the memory is received by a gaming device (step 901). This trigger may be received from outside the device (e.g. from the server or another gaming device) or may be generated within the device (e.g. when the amount of memory which is full exceeds a threshold or in response to an input to the controller etc). The device then identifies all the features of a game where code is stored at the device but where the feature is not owned by the device or associated gamers (step 902) and of these identified features, all the features which are not owned by anyone in current game play are identified (step 903) and the code relating to these remaining identified features is then deleted (step 904). Where the game play has already stopped, step 903 will not filter out any features because there are no devices/gamers in current game play.
The above description relates to a network of gaming devices 101 connected by a server 102 as shown in FIG. 1 and shown in more detail in FIG. 10. The server 102 comprises a processor 1001, a memory 1002 and a network interface 1003. The memory 1002 may be arranged to store code relating to features of the game and/or instructions to cause the processor to perform one or more of the steps of any of the methods described herein. However, the methods described above may also be applied to a network 1100 of gaming devices 101 which are inter-connected without control by a server, as shown in FIG. 11. These gaming devices may be connected directly to each other (e.g. via a network, via direct links etc) or may be connected to each other via other intermediate devices (e.g. other gaming devices), for example in a peer-to-peer network. In such a network, one of the gaming devices may act as a host and control the transfer of features (e.g. perform the method steps 202-204). A gaming device may be identified at random to act as host or the host may be selected based on predetermined criteria, such as, first to join or request to join the game, the one with the largest feature set, the one with the largest differences to the other devices etc. If the identified host disconnects or otherwise stops participating in the game, one of the other devices becomes the host. Where a gaming device acts as host, they may not hold the code for all the features and therefore may need to upload code from other gaming devices, as shown in FIGS. 3 and 4.
In the methods described above, the difference calculation is performed centrally by a host (such as a server or a gaming device). However, the methods may be performed in a distributed manner (whether or not a server is present) with each gaming device determining what feature data it requires and requesting it from the gaming device holding the appropriate code (e.g. each gaming device performs steps 202-204) or from the server (if present).
In another example, the gaming devices 101 shown in FIG. 11 may operate in a peer-to-peer scenario where no one gaming device is dominant. Each gaming device may use standard peer-to-peer techniques to communicate and transfer feature data in a complex parallel networking mesh between each other. In an example implementation, the first gaming device may compile a list of its feature set and then send the list to the next gaming device which analyses this list, notes in it what extra features are held by that gaming device and which of the previous gaming devices features it does not hold. This list can then be sent on to each of the gaming devices in turn with each recipient gaming device annotating the list as described above. Having been annotated by all the gaming devices the list is passed back to the first gaming device. At this point each gaming device in the system is aware of which features are held by the other gaming devices and which gaming devices require feature data that they hold. The gaming devices can then stream out the required feature data to those other gaming devices which need it.
In another example in this peer-to-peer scenario, each gaming device sends a list of the features that it holds to each of the other gaming devices in the network. Having received a list from each of the other gaming devices in the network, any gaming device can determine which gaming devices need to be sent code that it holds. The code can then be streamed to the other gaming devices who require those features. Alternatively, gaming devices can, using the list received, request feature data from a particular other gaming device in the network (rather than have it streamed to them without first requesting it). It will be appreciated that there may be other ways in which the data relating to feature sets can be shared between gaming devices in a peer to-peer network such that code relating to differences in feature sets can be subsequently transferred between gaming devices.
In the examples described above, the code relating to the game runs on the gaming device. If however the code runs on the server, the methods described above are also applicable. In such a situation, the server checks the attributes (or inventories) associated with each gaming device and instead of downloading the differences to the gaming devices, the server enables all the devices participating in a game to have access to all of the features owned by any of the devices connected to the particular game.
Although the examples described above relate to multiple gaming devices participating in the same game, the methods described above may also be used to join together separate gaming worlds. In an example, there may be an overlap between some of the objects/features/upgrades in two separate gaming worlds. For example, world A might have guns and knives, but world B might have guns and bombs. Therefore the concept of knives and bombs may be only known to their respective worlds but guns may be common and may therefore be meaningfully transferred where two games worlds are connected. In such a situation, XML may be used to export a world or its data, whether for guns, knives or bombs, and the receiving world may only take from that the data relevant to objects understood in the receiving world. Therefore, in the example given above world A may transfer XML detailing all guns and knives but world B may only take the guns data from the XML data received and ignore the knives data. XML is just one such possible mechanism which may be used and others may be alternatively used.
In the above description, features are identified with particular gamers or with the gaming devices with which a gamer is associated. In another example, identifiers may be used which are associated with a group or category of gamers. The use of such an identifier associated with a group or category of gamers enables features to be associated, for example, with a particular team, rank or achievement level within the game world or gaming community. Such features may comprise privileges which are associated with the particular group or category of gamers.
Although the present examples are described and illustrated herein as being implemented in a network of gaming devices, the system described is provided as an example and not a limitation. As those skilled in the art will appreciate, the present examples are suitable for application in a variety of different types of networks with any number of gaming devices. The networks need not be dedicated to gaming and the gaming devices may be able to perform many other functions (as described below),
The methods described herein may be performed by software in machine readable form on a storage medium. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.
This acknowledges that software can be a valuable, separately tradable commodity. It is intended to encompass software, which runs on or controls “dumb” or standard hardware, to carry out the desired functions, (and therefore the software essentially defines the functions of the register, and can therefore be termed a register, even before it is combined with its standard hardware). For similar reasons, it is also intended to encompass software which “describes” or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.
Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.
The terms ‘gaming device’ and ‘gaming console’ are used herein to refer to any device on which a user can play a game, including, but not limited to, dedicated games consoles (e.g. Xbox®, Xbox360™ etc), computers, PDAs, and mobile telephones. Although the gaming devices shown above comprise a console, a display and a controller, this is by way of example only and it will be appreciated that some/all of the functions may be integrated (e.g. into a handheld gaming device) or that the device may not comprise all the features (e.g. the console may be connected to a television which although used to display the game is not part of the gaming device itself).
The term ‘feature’ is used herein to refer to any aspect of a game, including, but not limited to, items (such as weapons, belongings, vehicles etc), backgrounds/environments (e.g. buildings, interiors, terrains et), music, avatars, models, textures, animations, other abilities/methods, game levels and upgrades. An ability/method may include tactical commands, moves etc which may be obtained through training, experience, buying, hiring, stealing, promotion etc. Where an ability/method is obtained through experience, training or promotion, the ability/method may be associated with a group of gamers (as described above).
The term ‘computer’ is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the term ‘computer’ includes PCs, servers, mobile telephones, personal digital assistants and many other devices
The ideas and individual aspects of any of the methods described above may be used independently or in any combination. Where the examples described above show ideas used in combination, this is by way of example only and does not imply any limitation in the way they may be implemented.
Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person.
The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. It will be appreciated that the repeating of steps within methods (e.g. the loop back from step 603 to step 602 in FIG. 6) is shown by way of example only and may be implemented in different ways (e.g. loop back from step 604 to step 602 in FIG. 6).
It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. The above specification examples and data provide a complete description of the structure and use of exemplary embodiments of the invention. Although various embodiments of the invention have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention.

Claims

1. A method of connecting gaming devices together to enable a multi-party game, the method comprising:

receiving data from a plurality of gaming devices, the data detailing features of a game associated with each of the plurality of gaming devices;

determining one or more required features associated with a first of the plurality of gaming devices, wherein a required feature comprises a feature associated with one of the plurality of gaming devices and not associated with the first of the plurality of gaming devices;

transmitting code relating to the required features to the first of the plurality of gaming devices; and

repeating the determining and transmitting steps for each of the plurality of gaming devices.

2. A method according to claim 1, further comprising, prior to transmitting code:

accessing a store of code relating to features of the game;

determining if the code relating to each of the required features is stored in the store; and

if not, requesting the code from one of the plurality of gaming devices.

3. A method according to claim 1, wherein transmitting code relating to the required features to the first of the plurality of gaming devices comprises:

filtering the required features according to predetermined parameters; and

transmitting code relating to the filtered required features to the first of the plurality of gaming devices.

4. A method according to claim 3, wherein filtering the required features according to predetermined parameters comprises:

identifying a subset of the plurality of gaming devices associated with the first of the plurality of gaming devices according to predetermined parameters; and

filtering the required features such that the filtered required features comprise one or more features associated with one of the subset of the plurality of gaming devices and not associated with the first of the plurality of gaming devices.

5. A method according to claim 4, wherein identifying a subset of the plurality of gaming devices associated with the first of the plurality of gaming devices comprises:

determining a game position for objects in the game controlled by each of the plurality of gaming devices;

defining an area around a game position for an object controlled by the first of the plurality of gaming devices based on predetermined parameters;

identifying any objects located with the area; and

determining the one or more of the plurality of gaming devices controlling the identified objects.

6. A method according to claim 4, wherein the predetermined parameters comprise one or more of: a data rate of a connection to the first of the plurality of gaming devices, and a target data transfer rate to the first of the plurality of gaming devices.

7. A method according to claim 3, wherein filtering the required features according to predetermined parameters comprises:

determining ownership information for each of the required features; and

filtering the required features to remove any features not owned by one of the plurality of gaming devices or a gamer associated with one of the plurality of gaming devices.

8. A method according to claim 1, wherein the code relating to a required feature comprises ownership information.

9. A method according to claim 8, wherein the ownership information identifies a gaming device, a gamer or a group of gamers.

10. A method according to claim 1, wherein the method further comprises, prior to receiving data from a plurality of gaming devices:

receiving a request from each of the plurality of gaming devices to participate in the game; and

requesting data from each of the plurality of gaming devices, the data detailing features of a game associated with each of the plurality of gaming devices.

11. A method according to claim 1, further comprising:

enabling the use of the required features by a receiving one of the plurality of gaming devices according to predefined rules.

12. One or more device readable media with device-executable instructions for performing steps comprising:

13. A method of connecting a plurality of gaming devices together to enable a multi-party game, the method comprising, at a first of the plurality of gaming devices:

sending data detailing features of a game associated with the first of the plurality of gaming devices to a remote device;

receiving code relating to a set of required features, wherein a required feature comprises a feature associated with another of the plurality of gaming devices and not associated with the first of the plurality of gaming devices; and

storing the received code.

14. A method according to claim 13, further comprising, prior to sending data detailing features of the game:

sending a request to participate in the game to the remote device; and

receiving a request for data from the remote device, the data detailing features of a game associated with the first of the plurality of gaming devices.

15. A method according to claim 13, further comprising:

receiving a trigger to purge received code;

determining ownership information for each required feature; and

deleting received code relating to any required features not owned by any gaming devices connected to the remote device or by gamers associated with any of the gaming devices connected to the remote device.

16. A method according to claim 13, wherein the code relating to the set of required features is received from the remote device.

17. A method according to claim 13, wherein the code relating to the set of required features is received from one or more of the plurality of gaming devices.

18. A method according to claim 17, wherein the remote device is one of the plurality of gaming devices.

19. A method according to claim 13, wherein the remote device comprises a server.