Note: Descriptions are shown in the official language in which they were submitted.
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
USER CREATABLE MACHINES
BACKGROUND
[00011 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.
[0002] 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
[0003] 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.
[0004] 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.
[0005] 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.
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
2
DESCRIPTION OF THE DRAWINGS
[0006] 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
[0007] 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.
[0008] 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
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
3
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).
[00091 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
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
4
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.
[0010] 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.
[00111 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
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
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 (AI) 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".
[0012] 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).
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
6
[0013] 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.
[0014] 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).
[001 5] 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.
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
7
[0016] 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).
[0017] 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.
[0018] 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.
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
8
[0019] 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.
[0020] 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.
[00211 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).
[0022] 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.
[0023] 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
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
9
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.
[0024] 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.
[0025] 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 US
patent
application no. 1 1/425,258 entitled 'Transfer of features between gaming
devices'
and filed on 20 June 2006 may be used. This method is described below with
reference to FIGS. 5 and 6 and US patent application no. 1 1/425,258 is
incorporated
herein by reference in its entirety.
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
[00261 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.
[0027] FIG. 5 is a schematic diagram of a network 500 of gaming devices.
The network comprises four gaming devices 501 (e.g. Xbox 360T"') 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).
[00281 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
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
11
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.
[0029] 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.
[00301 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.
[00311 Computing-based device 700 comprises one or more processors 701
which may be microprocessors, controllers or any other suitable type of
processors
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
12
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).
[0032] 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.
[0033] 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.
[0034] 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.
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
13
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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
CA 02689153 2009-11-26
WO 2009/006052 PCT/US2008/067807
14
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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
