User Creatable Machines

Abstract

A number of components parts are presented to a user in a game from which they can select and assemble a number of parts into a machine. Some or all of the component parts may have controllable parameters and these are mapped to an input on the games controller used to play the game.

Description

BACKGROUND

Some current computer games enable a user to customize vehicles, such as racing cars, by changing elements such as spoilers, wheels etc. However, the number of permitted variations is limited and the physical performance of each permitted combination of features has been pre-calculated and hard coded into the game. This limits the flexibility which can feasibly be offered to a user.

Some educational software games aimed at children exist which provide a greater degree of flexibility by providing a construction kit of parts and a drag and drop interface to enable a user to construct a Rube-Goldberg contraption to solve a puzzle.

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 number of components parts are presented to a user in a game from which they can select and assemble a number of parts into a machine. Some or all of the component parts may have controllable parameters and these are mapped to an input on the games controller used to play the game.

Many of the attendant features will be more readily appreciated as the same becomes better understood by reference to the following detailed description considered in connection with the accompanying drawings.

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 the functional elements of a game which enables a user to create machines;

FIG. 2 is an example flow diagram showing the operation of the game application;

FIG. 3 is a schematic diagram showing the data stored in the library of elements;

FIG. 4 is a schematic diagram of an example machine;

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

FIG. 6 is an example flow diagram of a method of operation of a gaming server; and

FIG. 7 illustrates an exemplary computing-based device in which embodiments of the methods described herein may be implemented.

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.

FIG. 1 is a schematic diagram of the functional elements of a game which enables a user to create machines, such as vehicles, weapons or other types of machines, from a library of component parts in any way they choose. These machines may then be used in game play, which may be on a single console or may be over a network (e.g. using a system such as Xbox Live (trade mark)). The game comprises a game application 101 which has associated with it, a library of elements 102 (these elements also referred to as components or building blocks), mapping data 103 and a controller interface 104. Each of the elements in the library of elements 102, which may comprise items such as metal panels, motors, wheels, steering elements, rocket boosters etc, have an associated set of physical parameters (such as one or more of mass, moment of inertia, centre of mass, friction, restitution, density, hardness etc) and where the element is controllable, a number of controllable parameters (such as steering, thrust, speed, firing control etc). Each of these controllable parameters is mapped to a control (also referred to as an input) on a games controller (e.g. the steering controllable parameter is mapped to a left/right control, a thrust controllable parameter is mapped to a forward/backward control, the firing control is mapped to a button on the controller etc) and the mapping relationship is stored in the mapping data store 103. It will be appreciated that the particular physical parameters and controllable parameters used may be dependent on the particular game. The physical parameter ‘restitution’ is used to refer to the amount of energy given back to an object when it collides with another object (e.g. a bouncy ball has a high value whilst a steel girder has a low value).

The operation of the game application 101 can be described with reference to FIG. 2 in which elements from the library of elements 102 are provided to a user (block 201). These elements provided may comprise a subset of or all the elements in that library and these elements may be provided by presenting representations of the elements to a user in a graphical user interface (GUI). The application enables a user to select a plurality of those elements provided and arrange them to create a machine (block 202), e.g. using a drag and drop interface in the GUI. Each of the controllable parameters (or features) of the selected plurality of elements are mapped to a control on a game controller (block 203) based on the mapping data 103. The resultant machine may then subsequently be tested, used in game play and/or saved for future use. The process may be iterated to improve the constructed machine (as indicated by the dotted arrow in FIG. 2). The assembled machine may be stored at any stage in the process (e.g. part way through the process or at the end). When the machine is used (in testing or game play) the forces on the machine are calculated in real-time based on inputs received from the controls to which controllable parameters are mapped and also based on the physical parameters stored for each element and the configuration of the elements (block 204). As described above, the physical parameters may be stored in the library of elements 102 or elsewhere. These forces (along with some or all of the physical parameters) may then be input to a rigid body simulator which defines the motion of the machine (block 205). The rigid body simulator may calculate additional forces (e.g. due to the connecting together of elements or machines) or consider additional forces (e.g. gravity, friction) in addition to those provided to it (which were calculated in block 204). The rigid body simulator may comprise a physics engine, such as one provided by Havok (trade mark), or may be implemented in any other manner.

Within the game application, a control module (not shown in FIG. 1) may be used to calculate the forces on the assembled machine (in block 204). More than one control module may be provided (e.g. a separate module may be provided for calculation of forces for particular machine types, such as cars) and different force applicators may be applied to the same rigid body.

As indicated by the dotted arrow in FIG. 2, the process may be iterated at any time. For example, components may have the ability to be ability to be damaged, wear out, depleted or upgraded/improved. In this, or other examples, the machine might be affected by another machine in some way as it operates, e.g. through the connection of machines together. The resultant joined machine may then be controlled by a single gamer or by more than one gamer (as described in more detail below). For instance, a “helicopter” lifting machine with a magnetic hook might attach itself to another machine (via the magnetic hook) to carry it away and this second machine may also have thrusters that will affect the control/direction/speed of the first machine. This may be exploited in some game applications, where, for example, the second machine (being hooked by the first) is controlled by the computer artificial intelligence (Al) or another player in a multiplayer game. The objective of this second controlling entity may be to either aid or obstruct the operation of the first machine when the second machine is “captured” or “hooked”.

Where a user created machine (assembled in block 202) comprises several elements which have the same controllable parameter (e.g. two rocket boosters, each having the controllable parameter of ‘thrust’), that controllable parameter for each element may be mapped to the same control on the games controller and therefore when a user operates that control, each element will provide thrust within the game play. The amount of the control parameter (e.g. thrust) provided by each of the elements may depend upon parameters associated with element and with that controllable parameter. For example, two identical rocket thrusters may provide identical amounts of thrust and respond identically to the same control, however, attaching thrusters of different sizes or types (rocket, jet, ion, propeller, etc) may provide different amounts of power, different power curves and/or different responses to the same control. In another example, however, a machine may comprise a number of sub-machines each of which may be operated by a separate gamer (e.g. a vehicle may comprise a first sub-machine whilst the weapon mounted on the vehicle may comprise a second sub-machine). In such an example, the controllable parameters for elements in each particular sub-machine may be mapped to controls on a different games controller (e.g. sub-machine 1 mapped to controls on games controller 1, sub-machine 2 mapped to controls on games controller 2, etc).

Unlike known games, the method and game described above does not include pre-calculated parameters for the performance of assembled machines, but instead the physical parameters for each component part, coupled with the inputs relating to the controllable parameters for those controllable component parts are used to generate, in real time, the control forces on the machine. Some initial calculations, in preparation for the calculation of the forces in real time, may be performed on assembly of the machine. The calculated forces may then be used to define the resultant motion of the machine. Therefore elements may be combined in any manner, according to the user's choice, rather than selection from a limited number of options which have been defined by the game developer.

It will be appreciated that whilst all component parts (or elements) will have at least one physical parameter, not all component parts will have a controllable parameter (e.g. a metal panel has no controllable parameters). Whilst some component parts are capable of moving (e.g. a wheel) they may still not have a controllable parameter because they require a motor or other power source to be able to move under the user's control (otherwise they will only move based on other applied forces, such as gravity).

Each of the elements may have an individual purpose and in some examples, each element may have only one controllable parameter, e.g. a motor may have the controllable parameter of ‘speed’, a rocket booster may have the controllable parameter of ‘thrust’ etc. Whilst elements may have a limited number of controllable parameters (e.g. only one), the effect of these controllable parameters on the forces applied to the assembled machine may result in changes to many aspects of the motion of an assembled machine. For example, a wheel or rudder may be able to control direction; however multiple thrusters strategically placed may also be used to control direction. A wheel may also be able to supply a braking force under a particular control, but so too might an anchor that has been deployed.

The physical parameters associated with each of the elements may be representative of the same element in the real world, for example a steel panel may have physical parameters such as mass and density that match a real steel panel. However many game worlds do not simulate accurate Newtonian Dynamics and therefore in many examples the physical parameters or the way in which the forces are calculated (in block 204) may be adjusted according to the particular requirements of the game (e.g. the panel may have a mass parameter which is less than the real life equivalent so that a war machine constructed from it may be able to fly or float).

Each of the elements may have one or more defined connection points where the element may be connected to another element (e.g. a wheel may have a single connection point of the axle, or two connection points of the axle on either side of the wheel). Details of these connection points 301 may be stored associated with the element 302 in the library of elements 102, as shown in the schematic diagram of FIG. 3, which also shows the controllable parameters 303 and physical parameters 304 discussed above.

The defined connection points for a particular element may be selective so that rather than having a standard connection point type that may be available in one or more locations on each component, and having any connection point on any component attach to any connection point on any other component, some/all of the connection points on some/all components may not attach to some/all connections points on some/all other components, or components of the same type. This selectivity of connection points may be defined in the mechanism within a particular game. For example, it might not be allowed to attach steerable wheels directly to a thruster to form a machine from only two components; however, a gamer may be able to attach the wheels to any connection point on a standard chassis component, and the thruster to any remaining connection point on the same chassis component.

In order to assist in the assembly of the selected elements (in block 202), the game application may provide a mechanism for aligning elements (or blocks). A number of example mechanisms are described below.

In a first example mechanism, a visual indication of a 3D matrix may be provided around the element showing the connection points and the object may jump from one connection point to the next in response to a control input from the user. In another example, instead of jumping from one point to another, the object may pause whilst at a connection point whilst waiting for an input to indicate the requirement to connect at that point.

In another example mechanism, the game application may provide a simulated magnetic attraction between connection points and a corresponding simulated repulsion force when a user attempts to connect elements at points other than the defined connection points (e.g. if two elements are brought together at points which are not connection points, the elements may be shown to spring apart when released by the user).

In a further example mechanism, any other kind of visual or audible indication may be provided to a user when two elements are aligned in a correct position for joining. Alternatively, alerts may be provided when two elements are brought together in a position which does not correspond to the defined connection points.

Whilst the description of the mechanisms for assisting in aligning elements relate to joining of individual elements, the mechanisms are also applicable to groups of elements, such as partially completed machines, sub-machines and whole machines. The connection points for a group of elements may be user defined (e.g. a user may define the connection points for a weapon which may be considered a sub-machine as it is subsequently mounted on a vehicle and operated by a second gamer) or the connection points may be the resultant effect of the particular combination of elements in the group (e.g. those connection points for the elements in the group which are not already used and which are accessible). In another example, the connection points for a group of elements may be selective in a similar manner to that described above for individual elements.

FIG. 4 shows an example machine 400 which may be created using the game application and the method described above. The machine comprises six elements: two wheels 401, a motor 402, a steering element 403, a panel 404 and a seat 405. It will be appreciated that this machine is a 2D machine for purposes of explanation only and that the machine (and the elements from which it is composed) may be 3-dimensional. Two of the elements (the motor and the steering element) may have controllable parameters (speed and direction) and these may be mapped to two different inputs on a games controller (e.g. speed may be mapped to a forward/backward control and direction may be mapped to a left/right control). The forces applied to the machine 400 may be calculated in real-time based on the physical parameters of each of the six elements and the inputs from the inputs on the games controller to which the controllable parameters are mapped (e.g. from the forward/backward and the left/right controls). These calculated forces may then be used to generate the motion of the machine.

Whilst all the elements in the library 102 may be provided by the games developer, in some examples additional elements may be provided by third parties, such as other games developers, or generated by gamers. This may lead to a situation, in networked game play, where gamers have different feature sets (i.e. different libraries of elements resulting in them being able to construct a machine using an element that others do not have). In order that gamers with different feature sets can still play together, the method described in co-pending U.S. patent application Ser. No. 11/425,258 entitled ‘Transfer of features between gaming devices’ and filed on 20 Jun. 2006 may be used. This method is described below with reference to FIGS. 5 and 6 and U.S. patent application Ser. No. 11/425,258 is incorporated herein by reference in its entirety.

This method of connecting gaming devices together, which is described below, 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.

FIG. 5 is a schematic diagram of a network 500 of gaming devices. The network comprises four gaming devices 501 (e.g. Xbox 360™) connected together via a server 502 (e.g. an Xbox Live® Server). Each gaming device comprises a console 503, a display 504 and a controller 505. 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 502 can be described with reference to FIG. 6. The server receives requests from each of the gaming devices 503 to join a game (step 601) and in response to these requests, the server polls each of the gaming devices for attribute information pertaining to the game in question (step 602). The attribute information may include details of elements in the library (e.g. in library 102 shown in FIG. 1) in addition to levels, weapons, avatars and other features of the game. Having received the attribute information, the server determines the differences in feature sets held by each of the devices (step 603) and transfers the required features to each console such that they have a common feature set (step 604). Once each gaming device has the same feature set, the game can start (not shown in FIG. 6).

In another example, the gaming devices 501 may operate without a central server 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 that 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.

FIG. 7 illustrates various components of an exemplary computing-based device 700 which may be implemented as any form of a computing and/or electronic device, such as a games console, and in which embodiments of the methods described above may be implemented.

Computing-based device 700 comprises one or more processors 701 which may be microprocessors, controllers or any other suitable type of processors for processing computing executable instructions to control the operation of the device in order to perform the methods described above. The device may further comprise processors having dedicated tasks, such as a graphical processing unit (GPU) 702 and/or a physics processor (not shown in FIG. 7).

The computer executable instructions may be provided using any computer-readable media, such as memory 703. The memory may be of any suitable type such as random access memory (RAM), a disk storage device of any type such as a magnetic or optical storage device, a hard disk drive, or a CD, DVD or other disc drive. Flash memory, EPROM or EEPROM may also be used.

The memory may be arranged to store platform software comprising an operating system 704 or any other suitable platform software may be provided at the computing-based device to enable application software 705 to be executed on the device. The application software stored in the memory 703 may include the game application 101 described above. The rigid body simulator (described above) may be included within the game application 101 or may comprise separate application software (not shown in FIG. 7). The memory may also be used to store the library of elements 102 and the mapping data 103 (also described above). The computing-based device 700 may comprise one or more inputs, outputs and interfaces, such as the controller interface 104 (or other interface to a user input device) and network interface 706.

Although the present examples are described and illustrated herein as being implemented in a games console and a networked gaming system, the apparatus and 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 computing systems. The methods may be implemented on any device on which games may be played and the device may be networked or a standalone device.

Whilst the above description refers to the use of a rigid body simulator to generate the motion of the assembled machine from the calculated forces, this is by way of example only and any suitable simulation tool may be used to generate the motion of the machine from the calculated forces. In other examples, the motion may be generated directly (e.g. through a combination of blocks 204 and 205) without first generating the forces on the object.

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 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. 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.

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.

It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. It will further be understood that reference to ‘an’ item refer to one or more of those items.

The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the spirit and scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

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 game comprising:

a library of elements;

a game application arranged to:

provide the library of elements to a user;

enable user selection and arrangement of a plurality of elements from the library to create a machine; and

map any controllable parameters of each element to an input on a games controller.

2. A game according to claim 1, wherein the game application is further arranged to store mappings in a mapping data store.

3. A game according to claim 1, wherein the library of elements comprises, for each element, at least one associated physical parameter.

4. A game according to claim 3, wherein the game application is further arranged to:

calculate at least one force on the machine at run time based on inputs received from the games controller and the at least one physical parameter associated with each of the plurality of elements.

5. A game according to claim 4, wherein the game application is further arranged to:

input said at least one force to a simulator for defining a motion of the machine.

6. A game according to claim 1, wherein the library of elements comprises, for each element, at least one connection point.

7. A game according to claim 6, wherein the game application is further arranged to:

provide a mechanism for aligning elements.

8. A game according to claim 1, wherein identical controllable parameters are mapped to the same input on a games controller.

9. A game according to claim 1, wherein the machine comprises a first sub-machine and a second sub-machine and mapping any controllable parameters of each element to an input on a games controller comprises:

mapping any controllable parameters of each element in the first sub-machine to an input on a first games controller; and

mapping any controllable parameters of each element in the second sub-machine to an input on a second games controller.

10. A method in a game comprising:

providing a library of elements to a user;

enabling user selection and arrangement of a plurality of elements from the library to create a machine; and

mapping any controllable parameters of each element to an input on a games controller.

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

storing mappings in a mapping data store.

12. A method according to claim 10, wherein the library of elements comprises, for each element, at least one associated physical parameter and wherein the method further comprises:

calculating at least one force on the machine at run time based on inputs received from the games controller and the at least one physical parameter associated with each of the plurality of elements.

13. A game according to claim 12, wherein the method further comprises:

inputting said at least one force to a simulator for defining a motion of the machine.

14. A method according to claim 10, wherein mapping any controllable parameters of each element to an input on a games controller comprises:

mapping identical controllable parameters to the same input on a games controller.

15. A method according to claim 10, wherein the machine comprises a first sub-machine and a second sub-machine and mapping any controllable parameters of each element to an input on a games controller comprises:

mapping any controllable parameters of each element in the first sub-machine to an input on a first games controller; and

mapping any controllable parameters of each element in the second sub-machine to an input on a second games controller.

16. A method according to claim 10, wherein the library of elements comprises, for each element, at least one connection point and wherein the method further comprises:

providing a mechanism for aligning elements.

17. A method in a game comprising:

displaying a plurality of machine components to a gamer;

enabling receipt of a first user input selecting at least two machine components from said plurality of machine components to be joined to create a machine; and

mapping any controllable parameters associated with each of said at least two machine components to at least one control on a user input device.

18. A method in a game according to claim 17, wherein said first user input further comprises information on relative positioning of said at least two machine components within said machine.

19. A method in a game according to claim 17, wherein each machine component has at least one associated physical parameter, and wherein said method further comprises:

on receipt of a second user input from said at least one control, calculating at least one force on said machine based on said second user input, said controllable parameters associated with each of said at least two machine components and physical parameters associated with each of said at least two machine components.

20. A method in a game according to claim 19, further comprising:

outputting said at least one force to a simulator arranged to generate motion parameters for said machine.