US20090005138A1 - User Creatable Machines - Google Patents

User Creatable Machines Download PDF

Info

Publication number
US20090005138A1
US20090005138A1 US11/770,118 US77011807A US2009005138A1 US 20090005138 A1 US20090005138 A1 US 20090005138A1 US 77011807 A US77011807 A US 77011807A US 2009005138 A1 US2009005138 A1 US 2009005138A1
Authority
US
United States
Prior art keywords
machine
elements
game
input
mapping
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/770,118
Inventor
Timothy Stamper
Gregg Mayles
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Priority to US11/770,118 priority Critical patent/US20090005138A1/en
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: STAMPER, TIMOTHY, MAYLES, GREGG
Priority to JP2010515005A priority patent/JP2010531711A/en
Priority to KR1020097026669A priority patent/KR20100024427A/en
Priority to CN200880022402A priority patent/CN101687114A/en
Priority to EP08771694.0A priority patent/EP2158016A4/en
Priority to CA002689153A priority patent/CA2689153A1/en
Priority to PCT/US2008/067807 priority patent/WO2009006052A2/en
Publication of US20090005138A1 publication Critical patent/US20090005138A1/en
Priority to IL201951A priority patent/IL201951A0/en
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Abandoned legal-status Critical Current

Links

Images

Classifications

    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/60Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor
    • A63F13/63Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor by the player, e.g. authoring using a level editor
    • A63F13/10
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/34Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using peer-to-peer connections
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/40Processing input control signals of video game devices, e.g. signals generated by the player or derived from the environment
    • A63F13/42Processing input control signals of video game devices, e.g. signals generated by the player or derived from the environment by mapping the input signals into game commands, e.g. mapping the displacement of a stylus on a touch screen to the steering angle of a virtual vehicle
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45Controlling the progress of the video game
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/408Peer to peer connection
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55Details of game data or player data management
    • A63F2300/5526Game data structure
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/60Methods for processing data by generating or executing the game program
    • A63F2300/6009Methods for processing data by generating or executing the game program for importing or creating game content, e.g. authoring tools during game development, adapting content to different platforms, use of a scripting language to create content
    • A63F2300/6018Methods for processing data by generating or executing the game program for importing or creating game content, e.g. authoring tools during game development, adapting content to different platforms, use of a scripting language to create content where the game content is authored by the player, e.g. level editor or by game device at runtime, e.g. level is created from music data on CD
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/60Methods for processing data by generating or executing the game program
    • A63F2300/64Methods for processing data by generating or executing the game program for computing dynamical parameters of game objects, e.g. motion determination or computation of frictional forces for a virtual car

Definitions

  • Some current computer games enable a user to customize vehicles, such as racing cars, by changing elements such as spoilers, wheels etc.
  • vehicles such as racing cars
  • elements such as spoilers, wheels etc.
  • 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.
  • 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.
  • 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.
  • FIG. 7 illustrates an exemplary computing-based device in which embodiments of the methods described herein may be implemented.
  • 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.
  • 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).
  • GUI graphical user interface
  • 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).
  • 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 ).
  • the physical parameters may be stored in the library of elements 102 or elsewhere.
  • 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.
  • 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.
  • the process may be iterated at any time.
  • components may have the ability to be ability to be damaged, wear out, depleted or upgraded/improved.
  • 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).
  • 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.
  • 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”.
  • 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.
  • 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).
  • 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).
  • 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.
  • 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.
  • a motor may have the controllable parameter of ‘speed’
  • a rocket booster may have the controllable parameter of ‘thrust’ etc.
  • elements may have a limited number of controllable parameters (e.g. only one)
  • 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.
  • a steel panel may have physical parameters such as mass and density that match a real steel panel.
  • 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.
  • 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.
  • the game application may provide a mechanism for aligning elements (or blocks).
  • a number of example mechanisms are described below.
  • 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.
  • the object 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.
  • 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).
  • 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.
  • alerts may be provided when two elements are brought together in a position which does not correspond to the defined connection points.
  • 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).
  • 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 .
  • 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.
  • 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 360TM) 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.
  • 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 ).
  • 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.
  • 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.
  • 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.
  • 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 ).
  • GPU graphical processing unit
  • 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 .
  • the motion may be generated directly (e.g. through a combination of blocks 204 and 205 ) without first generating the forces on the object.
  • 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.
  • 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.
  • 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).
  • a dedicated circuit such as a DSP, programmable logic array, or the like.

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 (20)

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.
US11/770,118 2007-06-28 2007-06-28 User Creatable Machines Abandoned US20090005138A1 (en)

Priority Applications (8)

Application Number Priority Date Filing Date Title
US11/770,118 US20090005138A1 (en) 2007-06-28 2007-06-28 User Creatable Machines
PCT/US2008/067807 WO2009006052A2 (en) 2007-06-28 2008-06-21 User creatable machines
EP08771694.0A EP2158016A4 (en) 2007-06-28 2008-06-21 User creatable machines
KR1020097026669A KR20100024427A (en) 2007-06-28 2008-06-21 User creatable machines
CN200880022402A CN101687114A (en) 2007-06-28 2008-06-21 user creatable machines
JP2010515005A JP2010531711A (en) 2007-06-28 2008-06-21 User-createable machine
CA002689153A CA2689153A1 (en) 2007-06-28 2008-06-21 User creatable machines
IL201951A IL201951A0 (en) 2007-06-28 2009-11-05 User creatable machines

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/770,118 US20090005138A1 (en) 2007-06-28 2007-06-28 User Creatable Machines

Publications (1)

Publication Number Publication Date
US20090005138A1 true US20090005138A1 (en) 2009-01-01

Family

ID=40161268

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/770,118 Abandoned US20090005138A1 (en) 2007-06-28 2007-06-28 User Creatable Machines

Country Status (8)

Country Link
US (1) US20090005138A1 (en)
EP (1) EP2158016A4 (en)
JP (1) JP2010531711A (en)
KR (1) KR20100024427A (en)
CN (1) CN101687114A (en)
CA (1) CA2689153A1 (en)
IL (1) IL201951A0 (en)
WO (1) WO2009006052A2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2280054A2 (en) 2009-07-31 2011-02-02 Koito Manufacturing Co., Ltd. Europium doped halogen-silicate phosphor and light emitting device
US20110136568A1 (en) * 2009-12-09 2011-06-09 Sony Computer Entertainment America Inc. Portable Game Controller Settings
US20110219130A1 (en) * 2010-03-05 2011-09-08 Brass Monkey, Inc. System and method for two way communication and controlling content in a game
US9183676B2 (en) 2012-04-27 2015-11-10 Microsoft Technology Licensing, Llc Displaying a collision between real and virtual objects
US20210379487A1 (en) * 2018-10-19 2021-12-09 Hit Box, L.L.C. Ergonomic game controller and system

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10232255B2 (en) * 2015-04-30 2019-03-19 Microsoft Technology Licensing, Llc Paddle accessory for a game controller
CN107930121B (en) * 2017-12-12 2020-09-01 苏州蜗牛数字科技股份有限公司 Method and device for controlling game target to move according to input device type

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5577185A (en) * 1994-11-10 1996-11-19 Dynamix, Inc. Computerized puzzle gaming method and apparatus
US6283858B1 (en) * 1997-02-25 2001-09-04 Bgk International Incorporated Method for manipulating images
US6428413B1 (en) * 1994-12-19 2002-08-06 Rolf Carlson Universal game engine for a game network and method therefor
US20030207704A1 (en) * 2002-05-01 2003-11-06 Shinya Takahashi Game machine and game program
US20050075154A1 (en) * 2003-10-02 2005-04-07 Bordes Jean Pierre Method for providing physics simulation data
US7001270B2 (en) * 1999-06-17 2006-02-21 Cadent Ltd. Virtual dental game
US20060258448A1 (en) * 2005-05-16 2006-11-16 Nintendo Co., Ltd. Storage medium storing game program, game apparatus and game controlling method
US20070101291A1 (en) * 2005-10-27 2007-05-03 Scott Forstall Linked widgets
US20090181769A1 (en) * 2004-10-01 2009-07-16 Alfred Thomas System and method for 3d image manipulation in gaming machines

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000157741A (en) * 1998-11-26 2000-06-13 Namco Ltd Game machine and information storage medium
US7874921B2 (en) * 2005-05-11 2011-01-25 Roblox Corporation Online building toy

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5577185A (en) * 1994-11-10 1996-11-19 Dynamix, Inc. Computerized puzzle gaming method and apparatus
US6428413B1 (en) * 1994-12-19 2002-08-06 Rolf Carlson Universal game engine for a game network and method therefor
US6283858B1 (en) * 1997-02-25 2001-09-04 Bgk International Incorporated Method for manipulating images
US7001270B2 (en) * 1999-06-17 2006-02-21 Cadent Ltd. Virtual dental game
US20030207704A1 (en) * 2002-05-01 2003-11-06 Shinya Takahashi Game machine and game program
US20050075154A1 (en) * 2003-10-02 2005-04-07 Bordes Jean Pierre Method for providing physics simulation data
US20090181769A1 (en) * 2004-10-01 2009-07-16 Alfred Thomas System and method for 3d image manipulation in gaming machines
US20060258448A1 (en) * 2005-05-16 2006-11-16 Nintendo Co., Ltd. Storage medium storing game program, game apparatus and game controlling method
US20070101291A1 (en) * 2005-10-27 2007-05-03 Scott Forstall Linked widgets

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
http://www.youtube.com/watch?v=qKk6yKDSxkY, The Incredible Machine, 1993. *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2280054A2 (en) 2009-07-31 2011-02-02 Koito Manufacturing Co., Ltd. Europium doped halogen-silicate phosphor and light emitting device
US20110136568A1 (en) * 2009-12-09 2011-06-09 Sony Computer Entertainment America Inc. Portable Game Controller Settings
US10912991B2 (en) * 2009-12-09 2021-02-09 Sony Interactive Entertainment LLC Portable game controller settings
US20110219130A1 (en) * 2010-03-05 2011-09-08 Brass Monkey, Inc. System and method for two way communication and controlling content in a game
US20110219062A1 (en) * 2010-03-05 2011-09-08 Brass Monkey, Inc. System and Method for Two Way Communication and Controlling Content on a Display Screen
US8166181B2 (en) * 2010-03-05 2012-04-24 Brass Monkey, Inc. System and method for two way communication and controlling content on a display screen
US8171145B2 (en) * 2010-03-05 2012-05-01 Brass Monkey, Inc. System and method for two way communication and controlling content in a game
US9183676B2 (en) 2012-04-27 2015-11-10 Microsoft Technology Licensing, Llc Displaying a collision between real and virtual objects
US20210379487A1 (en) * 2018-10-19 2021-12-09 Hit Box, L.L.C. Ergonomic game controller and system
US11890533B2 (en) * 2018-10-19 2024-02-06 Hit Box, L.L.C. Ergonomic game controller and system

Also Published As

Publication number Publication date
CA2689153A1 (en) 2009-01-08
WO2009006052A3 (en) 2009-03-12
KR20100024427A (en) 2010-03-05
EP2158016A4 (en) 2014-01-15
WO2009006052A2 (en) 2009-01-08
EP2158016A2 (en) 2010-03-03
JP2010531711A (en) 2010-09-30
CN101687114A (en) 2010-03-31
IL201951A0 (en) 2010-06-16

Similar Documents

Publication Publication Date Title
US20090005138A1 (en) User Creatable Machines
JP6154057B2 (en) Integration of robotic systems with one or more mobile computing devices
KR101246938B1 (en) Personalized behavior of computer controlled avatars in a virtual reality environment
US7922584B2 (en) Image generation method and information storage medium with program for video game in which operation of the controller beyond a predetermined angle causes a character to attack
CN110860089B (en) Seasonal rewards distribution system
Paul et al. History and comparative study of modern game engines
US11724191B2 (en) Network-based video game editing and modification distribution system
Miles Unity 3D and playmaker essentials: game development from concept to publishing
TWI804031B (en) Multi-human body sensing system combining virtual and reality, method, equipment, and storage medium
US20100323775A1 (en) Systems and Methods for Evolving Content for Computer Games
CN104919813A (en) Computationally generating turn-based game cinematics
GB2354417A (en) Determining level of detail according to the number of moving objects present
JP7389275B2 (en) Multi-user experience system, method, device and computer program combining virtual and reality
JP2001067494A (en) Image generation system and information storage medium
Busby et al. Mastering unreal technology, volume i: Introduction to level design with unreal engine 3
Parker Game Development Using Python
JP2000306115A (en) Image forming device and information storage medium
JP2000237449A (en) Game device and information storage medium
Qiu et al. Design and Implementation of “Winning Luding Bridge” Immersion FPS Game Based on Unity3D Technology
JP4204059B2 (en) GAME DEVICE AND INFORMATION STORAGE MEDIUM
CN116547045A (en) Toy system for multi-person social games
Williams et al. Recreational Motion Simulation: A New Frontier for Virtual Worlds Research
Slater et al. What is the future of massively multiplayer online gaming
Loiacono et al. Computational intelligence and games
Boronin Game Development: Sci-Fi Endless Runner

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:STAMPER, TIMOTHY;MAYLES, GREGG;REEL/FRAME:019842/0985;SIGNING DATES FROM 20070327 TO 20070530

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0509

Effective date: 20141014