U.S. Pat. No. 9,526,980

DETAILED DESCRIPTION

The subject matter of embodiments of the invention is described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the terms “step” and/or “block” may be used herein to connote different elements of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.

Embodiments of the present invention enable rich control input to be used to control video games that are remotely executed. Rich control input includes three-dimensional image data, color video, audio, device orientation data, and touch input. A remotely-executed video game is one executed on a server or other computing device that is networked to a computing device receiving the control input. At least part of the video game image is rendered on the server and communicated to the client. For example, a game console may be networked with a game server using the Internet. The console receives controller input, which may be communicated to the game server. The game server executes the game code and manipulates it in accordance with the input and communicates a rendered game image or images back to the game console. In some embodiments, depth buffer data may also be included with the game image or images and used to generate a displayable image. The game console may then output the rendered image to a display.

Embodiments of the present invention pre-processes the rich sensory data on the client into data that may be uploaded to the game server. The rich input stream may be processed in a game-specific way or in a general way. Examples of client side processing of the rich input stream include generating skeletal tracking data, compression of a depth cloud image, subsampling, generating deltas, reduction to surfaces, reduction to geometry, and reduction to bounding boxes. A further reduction method is to isolate a motion blob within a depth cloud or video. Further, audio processing can be done on the client side and a game result sent to the game server.

The pre-processed rich input stream forms a reduced control input that comprises less data. Embodiments of the present invention communicate the reduced control input to the game server. The game server consumes the reduced control input to manipulate the game and generates a rendered game image that is communicated to the game client.

Having briefly described an overview of embodiments of the invention, an exemplary operating environment suitable for use in implementing embodiments of the invention is described below.

Exemplary Operating Environment

Referring to the drawings in general, and initially toFIG. 1in particular, an exemplary operating environment for implementing embodiments of the invention is shown and designated generally as computing device100. Computing device100is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing device100be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

The invention may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program components, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program components, including routines, programs, objects, components, data structures, and the like, refer to code that performs particular tasks or implements particular abstract data types. Embodiments of the invention may be practiced in a variety of system configurations, including handheld devices, consumer electronics, general-purpose computers, specialty computing devices, etc. Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by remote-processing devices that are linked through a communications network.

With continued reference toFIG. 1, computing device100includes a bus110that directly or indirectly couples the following devices: memory112, one or more processors114, one or more presentation components116, input/output (I/O) ports118, I/O components120, and an illustrative power supply122. Bus110represents what may be one or more busses (such as an address bus, data bus, or combination thereof). Although the various blocks ofFIG. 1are shown with lines for the sake of clarity, in reality, delineating various components is not so clear, and metaphorically, the lines would more accurately be grey and fuzzy. For example, one may consider a presentation component such as a display device to be an I/O component120. Also, processors have memory. The inventors hereof recognize that such is the nature of the art, and reiterate that the diagram ofFIG. 1is merely illustrative of an exemplary computing device that can be used in connection with one or more embodiments of the invention. Distinction is not made between such categories as “workstation,” “server,” “laptop,” “handheld device,” etc., as all are contemplated within the scope ofFIG. 1and refer to “computer” or “computing device.”

Computing device100typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by computing device100and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data.

Computer storage media includes RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. Computer storage media does not comprise a propagated data signal.

Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

Memory112includes computer-storage media in the form of volatile and/or nonvolatile memory. The memory112may be removable, nonremovable, or a combination thereof. Exemplary memory includes solid-state memory, hard drives, optical-disc drives, etc. Computing device100includes one or more processors114that read data from various entities such as bus110, memory112or I/O components120. Presentation component(s)116present data indications to a user or other device. Exemplary presentation components116include a display device, speaker, printing component, vibrating component, etc. I/O ports118allow computing device100to be logically coupled to other devices including I/O components120, some of which may be built in. Illustrative I/O components120include a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc.

Exemplary Online Gaming Environment

Turning now toFIG. 2, an online gaming environment200is shown, in accordance with an embodiment of the present invention. The online gaming environment200comprises various game clients connected through a network220to a game service230. Exemplary game clients include a game console210, a tablet212, and a personal computer214. Use of other game clients, such as smart phones, are also possible. The game console210may have one or more game controllers communicatively coupled to it. In one embodiment, the tablet212may act as an input device for a game console210or a personal computer214. In another embodiment, the tablet212is a stand-alone game client. Network220may be a wide area network, such as the Internet.

The controllers associated with game console210include game pad230, tablet232, headset236, and depth camera234. A game console may be associated with control devices that generate both a rich input and a basic input. Individual controllers are capable of generating different kinds of inputs and a single controller could generate both a rich input and an basic input.

The game pad230may be capable of generating basic control signals, such as those generated by button selections and joystick movement. Movement data such as that generated by accelerometers and gyros within the game pad230may be examples of rich sensory data. In some implementations, the movement data is not considered a rich sensory data.

The classification of an input stream as rich or basic depends on the latency caused to the game by uploading the full input stream. Factors such as available bandwidth and client capabilities may affect the classification. In one embodiment, an input device, or input that causes more than 80 ms of latency is classified as rich. Embodiments of the present invention may make a contextual determination of what constitutes a rich input for a particular game, under particular circumstances. Each game may have a latency sensitivity rating. The latency sensitive rating may be determined from user feedback collected from test groups, or though other method, and associated with the game. The latency sensitive rating may be different for different game features or set for the entire game. For example, avatar movement may be given a different sensitivity rating than background movement.

The rich or basic classification for each input stream may be determined by identifying the latency sensitivity rating for present game, determining available bandwidth, and determining client and server processing capabilities. The various factors may be combined to determine latency created for the input stream. If it is less than the latency sensitivity rating then the input stream is basic, if greater than the latency sensitivity rating then rich.

In an embodiment, the latency associated with an input stream is determined experimentally using a test instruction and test game response. The measured latency is used to determine whether the control is basic or rich.

When the control is determined to be rich via experimentation or calculation, then client side preprocessing of the input stream is brought on line. Various pre-processing method are described in more detail subsequently. If the control is basic, then it is uploaded without what this application considers pre-processing to avoid latency, but it may still be processed according to various transport protocols and other processing involved in communicating the control signal to the server. This other processing occurs to both pre-processed and unprocessed control signals.

The tablet232can be both a game controller and a game client as mentioned previously with tablet212. Tablet232is shown coupled directly to the game console210, but the connection could be indirect through the Internet or a subnet. In one embodiment, the game service230helps make a connection between the tablet232and the game console. The tablet232is capable of generating numerous input streams and may also serve as a display output mechanism. In addition to being a primary display, the tablet232could provide supplemental game information near information shown on a primary display coupled to the game console210, or simply be a control surface. The input streams generated by the tablet232include video and picture data, audio data, movement data, touch screen data, and keyboard input data.

The headset236, captures audio input from a player and the player's surroundings and may also act as an output device if it is coupled with a headphone or other speaker.

The depth camera234generates a depth cloud used as a control input. The depth camera234may an use infrared camera to determine a depth, or distance from the camera for each pixel captured. Stereoscopic depth cameras are also possible. In addition, the depth camera234may capture a typical color stream or picture. The depth camera234may have several image gathering components. For example, the depth camera234may have multiple cameras.

Game service230may comprise multiple computing devices communicatively coupled to each other. In one embodiment, the game service230is implemented using one or more server farms. The server farms may be spread out across various geographic regions including cities throughout the world. In this scenario, the game clients may connect to the closest server farms. Embodiments of the present invention are not limited to this setup.

The game service230allows the game to be executed within the computing devices provided by the game service230. A communication session between the game service and game clients carries input traffic to the game service230and returns a rendered game image. In this embodiment, a computing device that is part of the game service executes the video game code using an input stream generated by input devices associated with the various game clients. The rendered video game is then communicated over the network to the game client where the rendered game is output for display.

Exemplary Game Client and Game Service for Remote Gaming

Turning now toFIG. 3, an exemplary remote gaming environment300using rich input control data is shown, in accordance with an embodiment of the present invention. The game migration environment300includes a game client310communicatively coupled to a game server340through a network330. In one embodiment, the network may be the Internet. The game client310is connected to a first game input device312, a second game input device314, and a display316. Exemplary game input devices include game pads, keyboards, a mouse, a touch pad, a touch screen, a microphone for receiving voice commands, a depth camera, a video camera, and a trackball. Embodiments of the present invention are not limited to these input devices. The display316is capable of displaying video game content. For example, the display316may be a television or computer screen. In another embodiment, the display316is a touch screen integrated with the game client310.

The game client310is a computing device that is able to execute video games. The game client310could be a tablet or a laptop computer. In another embodiment, the game client310is a game console and the display316is a remote display communicatively coupled to the game console. The game client310includes an operating environment320, a video composite component321, a game execution environment322, a game data store324, a game-specific processing component326, and a generic pre-processing component328.

The operating environment320may be provided by an operating system that manages the hardware and provides services to application running on the game client310. The operating environment may allocate client resources to different applications as part of the pre-processing and other functions.

The game data store324stores downloaded games and partially downloaded games. Games may be downloaded in playable blocks. To play a game, the game may need to be loaded from the game data store324into active memory associated with the game execution environment322. The game data store324may also store player progress files.

The game-specific processing component326processes a rich controller input to generate a reduced controller input. The reduced controller input can take many forms and can vary depending on the type of rich controller input involved.

When the rich control input is a three-dimensional video stream, the reduced controller input may take the form of skeletal tracking data, a reduction to surfaces, a reduction to geometry, deltas, compressed imagery, and a reduction to bounding boxes. Each of these will be described in more detail subsequently, but they all result in control data comprising less data to communicate to the controller. The reduced controller input is communicated over network330to the game execution environment348on the game server340. The reduced controller input is used as an input that controls the game in progress.

The game-specific preprocessing326is specific to the particular game being executed. While the steps may be similar to the generic preprocessing described subsequently, a part of the game-specific processing is specific to a particular game. The code may be game specific to generate an output in a form that is consumable to the particular game. In other words, game specific code may be used to generate a compatible control signal. In other cases, the game specific code does something unique that other games do not do.

In one embodiment, the game-specific preprocessing generates a control input that is specific to the game. For example, a hand gesture could be interpreted to mean move the avatar right or to pick up an object in a first game, but something different in a second game. In this case, the reduced controller input would simply be a movement command instead of the depth cloud data. Interpreting depth cloud data to recognize a gesture and form a movement command is a transformation of one type of input data (depth data) to a second type (movement). In other embodiments, relevant control data is separated from irrelevant control data, but does not change form. For example, reduced controller input could be a portion of the depth cloud around an object of interest, for example a player's hand or face, without the rest of the depth cloud data. Isolating a portion of image data (3D or 2D) is described as a reduction to a bounding box. In the game-specific preprocessing of audio commands, the reduced controller input could be a unique game command or a common game command described in a game specific way, such as use of game specific slang.

In one embodiment, the game-specific processing component326is extracted or based on a video game originally written to be processed entirely on the client side. In this manner, the part of the video game that processes the rich controller inputs is separated and put on the client side and the commands for other game functions are sent up to the execution part of the game, which resides on the server340. In this case, there may be a need to reconcile data that would have otherwise been processed instantaneously within the game execution environment on a client. The signal reconciliation component346, explained in more detail subsequently, may perform this reconciliation.

The generic preprocessing328preprocesses the rich input in a way that is applicable to or consumable by multiple games. The reduced controller input generated by the generic processing component328is communicated over network330to the game execution environment348where it may be used to manipulate the game in progress. The examples of generic preprocessing steps include skeletal tracking, deltas, reduction to services, reduction to geometry, reduction to bounding boxes, and depth cloud compression. When the rich input includes audio signals the generic processing could be a speech-to-text translation. For example, the user could speak the word “pause” and the generic preprocessing could send a command to pause the game.

The game execution environment322comprises the gaming resources on the client310required to execute instances of a game or part of a game. In some embodiments, the client310does not include a game execution embodiment or the computing resources to execute the game. The game execution environment322comprises active memory along with computing and video processing. The game execution environment322receives gaming controls and causes the game to be manipulated and progressed according to its programming. In one embodiment, the game execution environment322outputs a rendered video stream that is communicated to the game client. In other embodiments, the game execution environment322outputs game geometry, or other representations, which may be combined with local objects on the gaming client to render the gaming video. The game execution environment322may execute part of a game to generate game images that are combined with rendered images received from the game server340by the video composite component321

The video composite component321merges rendered video game images received from the game server340with rendered video game images rendered by the client310to form a single image that is output to display316. Rendered video game images could refer to just a single color image or the color image and depth buffer data that is used to successfully composite server and client images. The video composite component may perform scaling and other functions to generate a video output that is appropriate.

The game server340comprises a connection manager342, a player profile data store344, a signal reconciliation component346, a game execution environment348, a game data store350, and a game manager352. Though depicted as a single box, the game server340could be a server farm that comprises numerous machines, or even several server farms.

The connection manager342builds a connection between the client310and the server340. The connection manager342may also provide various authentication mechanisms to make sure that the user is authorized to access the game service provided by the server340. The connection manager342may also analyze the bandwidth available within a connection and provide this information to components as needed. For example, the resolution of the video game image may be reduced to accommodate limited bandwidth.

The player profile data store344may work in conjunction with the connection manager342to build and store player information. Part of the player profile may comprise demographic and financial information such as a player's name, address and credit card information or other mechanism for paying for or purchasing games and experiences provided by the game service.

In addition, the player profile data store344may store a player's progress within an individual game. As a player progresses through a game, the player's score and access to game levels may be stored. Further, the player profile data store344may store information about individual player preferences such as language preferences. Information regarding a player's game client and speed of the network connection may also be stored and utilized to optimize the gaming experience. For example, in one embodiment, when a geographically proximate server farm is busy, players with higher latency Internet connections may be preferentially connected to proximate server farms while players with lower latency connections may be connected to server farms that are further away. In this way, the players with the network connections that are best able to handle the additional latency are connected to server farms that create additional latency because of their location.

The player profile data store344may also store a usage history for the individual player. A player's history of purchasing games, sampling games, or playing games through a game service that does not require the purchase of the games may be stored. The usage information may be analyzed to suggest games of interest to an individual player. In one embodiment, the purchase history may include games that are not purchased through the game service. For example, the purchase history may be augmented by the player entering in a key from a game purchased in a retail store. In some embodiments, the player may then have access to that game both on their game client310and through the game service.

The signal reconciliation component346may be present in some embodiments of the present invention. The signal reconciliation component346reconciles reduced controller input based on timing changes and other factors that occur as the signal is transported over a network. For example, the signal reconciliation component346may account for a latency generated by the time taken to transport the reduced controller input to the game execution environment348. The signal reconciliation component may use a time stamp on the control signal to determine reconcile player actions with game actions. In another embodiment, all control signals are adjusted by 30 ms based on measured or calculated amount of time taken to communicate the signal from the client310to the game server340. For example, the reconciliation component may adjust the signal to help determine whether a person hit another player based on the player's location at the time of the shot, not the time the control signal was received.

The game execution environment348comprises the gaming resources required to execute instances of a game. These are the resources described previously that are managed by the game manager352and other components. The game execution environment348comprises active memory along with computing and video processing. The game execution environment348receives gaming controls, such as reduced controller input, through an I/O channel and causes the game to be manipulated and progressed according to its programming. In one embodiment, the game execution environment348outputs a rendered video stream that is communicated to the game client. In other embodiments, the game execution environment348outputs game geometry, or other representations, which may be combined with local objects on the gaming client to render the gaming video.

The game data store350stores available games. The games may be retrieved from the data store and activated through an active memory. The game data store350may be described as passive or secondary memory. In general, games may not be played off of the game data store350. However, in some embodiments, the secondary memory may be utilized as virtual memory, in which case portions of the game data store350may also serve as active memory. This illustrates that active memory is not necessarily defined by a particular hardware component, but is defined by the ability of the game resources to actively manipulate and access objects within the memory to execute the game.

The game manager352manages players' connections into active games. In one embodiment, there are individual game managers for each game available through the game service. Taking a single game as an example, the game manager will drop players into requested games. The game manager352also manages active games. In one embodiment, a player may connect to a game through the game manager352. In other words, the game manager352may act as a gatekeeper for communications and connections between individual game instances. When a player drops out of a game, an instruction may go to the game manager to retrieve and save the player's progress into the player's profile within player profile data store344. Once a player drops out of a game, the game may be shut down by the game manager352.

Turning now toFIG. 4, an exemplary depth camera interface is shown, in accordance with an embodiment of the present invention. The depth camera410has a view of the player430. A depth camera410generates a depth cloud that describes a players size, shape, and orientation at a point in time. As the depth cloud changes over time, the player's430movement may be determined. The user's movements are able to form a control input. In this case, the player430is moving their left arm up and down. A game console or game server receives the input from the depth camera410and uses it to manipulate the avatar422shown on display420. As can be seen, the movements of the avatar422interact with virtual objects424and a second player426. A different person connected to the same game session in the game server may control the second player426. In this case, the virtual objects424are balls.

FIG. 4also includes a picture-in-picture (“PIP”) image470of the player430. This may be a standard video image captured by the depth camera410or some other camera. The PIP image may be rendered on the client without sending the image to the game server.

Turning now toFIG. 5, client side processing of rich controller input, within a network gaming environment500, is shown, in accordance with an embodiment of the present invention. Gaming environment500includes input device510, client520, network530, and game server540. These components may be similar to the components described previously with reference toFIG. 3.

The input device510generates a rich controller input, such as a depth cloud. The game server540executes game code and generates a rendered video game image responsive to the control input. The input generated by input device510is preprocessed by a generic processing component522and by a game-specific processing component524. The generic processing component522generates a reduced controller input that is communicated to the game server540over network530. The rich controller input is also processed by the game-specific processing component524and likewise communicated over network530to game server540.

In different embodiments, a game may rely only on a generic preprocessing522or on only a game-specific processing524or on a combination of both. In another embodiment, generic preprocessing may occur and be consumed by game-specific processing524for further refinement before a reduced controller input is communicated to the game server540. The game server540has code to process the reduced controller input whether received from the generic processing component522or the game-specific processing component524. The gamer server540uses the reduced controller to manipulate a game and generate a rendered video game image that is communicated to the client520.

Turning now toFIG. 6, a sequence diagram illustrating client side processing of a game signal is shown, in accordance with an embodiment of the present invention. The sequence diagram includes a depth camera610, a game client620, and a game server630. The game code is executed on the game server630. The game may be a multiplayer video game or single player game. The game client620may be capable of executing a game, but is not doing so in this example. Instead, the game client620is preprocessing the game signal and communicating a reduced version of the game signal to the game server.

Initially, an input signal650is received by the game client320from the depth camera610. The game client620preprocesses the input signal650at step652. The preprocessing may be game-specific or a generic. Generally speaking, generic preprocessing may be consumed by different games running on the game server640. On the other hand, game-specific preprocessing is unique to an individual game running on the game server640. When the online gaming session is initiated, the game server640may download game-specific preprocessing code to the game client620. In one embodiment, the game-specific processing code is modularized from a game designed to run entirely on a client without involvement from a game server. The game-specific code may operate to generate game specific commands, or refine environmental data in a way to make it consumable by the game running on the game server640.

Examples of the processing652include generating a skeleton or skeletal tracking data. A skeleton is a stick figure representation of an individual appearing in the depth cloud image. Skeletal tracking describes the person's movements with the person's joints and limbs and body reduced to lines or geometric shapes. Other examples of preprocessing will be described in more detail subsequently. The preprocessed signal data654is communicated to the game server630. The preprocessed signal654is consumed656by the game server630to change the game state and render a new video game image that depicts the new game state. The rendered image658is communicated over a network to the game client620which then outputs the rendered video game image for display.

Turning now toFIG. 7, a sequence diagram illustrating the interplay of generic preprocessing and game-specific preprocessing in a network gaming environment700is shown, in accordance with an embodiment of the present invention. InFIG. 7, the game controller710generates a rich input. Exemplary game controllers710include a depth camera, a video camera, an audio device, and movement sensitive controllers. The game client720is a computing device capable of outputting a video image to a video display. The game client720need not be a dedicated game client, but could be a personal computer, tablet, or other similar device. The game client720includes generic preprocessing722and game-specific preprocessing724. The game-specific preprocessing724is associated with a game currently being executed by game server730.

Initially, a rich input740is communicated to the game client720. At step742, the game client identifies at least a portion of the rich input740to be sent to the to the generic processing component722. The controller input748is communicated to the the generic processing component722. At step744all or a portion of the rich input740is communicated746to the game-specific processing component724.

At step750, the generic processing component722utilizes the data received to generate a reduced controller input752. The reduced controller input752may be a skeletal geometry for people appearing within the rich controller input. The reduced controller input752could be an identification of players within an image. The reduced controller input752is communicated to a game client transport component (not shown).

The game-specific processing component724preprocesses the input at step754to generate a reduced controller input756that is communicated back to the game client transport component (not shown). The game-specific preprocessing724could be a reduction to a bounded area. In one example, the game-specific processing component724uses a skeletal geometry generated by the generic processing component722to identify the area around a hand. The rich controller input corresponding to just the area around the hand forms the reduced controller input. As mentioned, other types of reduced controller input may be generated by either the generic processing component722or the game-specific processing component724.

Either way, the reduced controller input752received from the generic processing component722and the reduced controller input756received from the game-specific processing component724are communicated as a reduced controller input760to the game server730. The game server730uses the reduced controller input760to manipulate the executed game and to generate a rendered video at step762. The rendered video game image764is communicated back to the game client720where it is output to a display.

Turning now toFIG. 8, a method800of enabling game play over a remote connection using a data rich input device is shown, in accordance with an embodiment of the present invention. The remote game play may be similar to that described previously with reference toFIG. 2orFIG. 3or elsewhere. The rich input device may be a depth camera, audio component, a touch-screen device, or a movement-sensitive device that generates accelerometer or gyroscopic data. Other types of rich input devices may be possible. Generally speaking, a rich input is one that includes more information than can be uploaded without degrading the game play because of latency, which manifests as a delayed reaction to controller input. In one embodiment, an input stream taking more than 50 ms to communicate to the game server is considered rich.

At step810, rich controller input for a video game running on a game server is received at a client device. The game server renders at least a part of the video game image and communicates it back to the client device over the network. This is in contrast to other network gaming scenarios where game geometry or player movement information is communicated from a network to a client device, which then renders a video game image. In this case, the video game image is rendered by the server.

At step820, the rich controller input is processed on the client device to generate a reduced controller input. The reduced controller input includes less data than the rich controller input and is uploadable to the server within a time frame that does not degrade game play. As mentioned previously, the reduced controller input could be specific to the game being executed on the server or could be generic. A rich control input that depicts players includes a video image and a three-dimensional point cloud data, such as is generated by a depth camera. Skeletal tracking is one form of reduced input control formed from image data. Skeletal tracking information describes movements of a person in terms of their joints and limbs and body but may not include significant image data. Skeletal tracking may just communicate changes to the person upon evaluating the received controller input.

Another form of reduced controller input is player identification data. The player identification data describes which player is where within the image and may differentiate players from observers. This information may likewise be communicated to the server. The player identification information may also include a determination of which player is the active player at a given time.

Another form of reduced controller input is a product of signal reduction. Examples of signal reduction include compression and sampling. Sampling uploads every X frame of data received. For example, every 5th frame of data received could be uploaded within a sampling process rather than uploading every frame of data received. A frame refers to an image taken at a point in time, whether the image is a two-dimensional video image or a three-dimensional point cloud.

Deltas are an additional form of a reduced controller input. A delta can take many different forms, but each describes a change in the environment instead of the entire environment. For example, the change in location of an object in the room may be described as an object delta. The change in a player through movement may be described as a player delta, perhaps in skeletal form. Other forms of deltas are possible. The delta may be communicated in a form of image or depth data that describes the movement. In other words, only the portion of the depth cloud that has changed may be uploaded. In another embodiment, only relevant changes or changes deemed relevant by the preprocessing are uploaded. For example, changes to game observers may be ignored while changes surrounding the players or an active player may be used to form a delta.

Reduction to surfaces is another form of reduced controller input. A reduction to surfaces consumes depth data to generate a series of geometric shapes that form planes along the surface of objects. Those surfaces may be associated with colors of the object and allow an estimation of the depth to be uploaded. Reduction to geometry may be similar. A surface or geometric shape can be defined in very few mathematical equations compared to raw depth data. For example, when identifying a floor plane, the floor plane can be described as ax+by+cz=d, so just the four numbers for a, b, c, and d need to be sent to the server instead of the 3 d depth data. However, as used in this description, the reduction to geometry focuses on an object-by-object basis rather than surfaces. In other words, in reduction to geometry a couch may be described as a single object rather than broken into a series of planes.

An additional form of reduced controller input include isolated depth data. Isolated depth data describes only a portion of the depth cloud that is of interest to the game. The part of the depth cloud that is of interest may vary from game to game. For example, one game may be interested in a player's hands and feet while another game is interested in a face or game object, such as a tennis racket held by a player. In one embodiment, skeletal tracking information is used to isolate the relevant depth data. The skeletal tracking information is first used to generate a portion of the body that is of interest and then the depth data associated with this part of the skeleton forms the reduced input control. Conceptually, the skeletal tracking process is reversed in part. The skeleton takes depth cloud data as input and analyzes it to identify people and body parts. Once the body part of the skeleton is identified, the related depth cloud data may be associated with the body part.

Motion blobs are a form of reduced input control. A motion blob is the image or depth data associated with a moving object. The motion blob could either be an outline or a carve-out. The motion blob in outline form includes data that describes the outline of the moving object without including all of the interior of the object. The carve-out includes the data describing the moving object, including the interior, but without background data.

All of the previously-mentioned reduced controller inputs relate to image or three-dimensional image data. Reduced controller inputs for audio data include speech-to-text data and game controls directly derived from processing the audio data. For example, a pause command could be the reduced input control generated in response to detecting the word “pause” within the audio stream.

Touch-screen and motion data could similarly be interpreted to generate a game command. An example game command is “move player right three steps at a designated velocity” that corresponds to the input data. Orientation information could be interpreted to translate the game player in the direction indicated. These commands could be preprocessed and form reduced controller input instead of uploading the raw movement or touch-screen data received from the game controller.

At step830, the reduced controller input is communicated to the game server. For example, the reduced controller input could be communicated over the Internet from the game client to the game server. In one embodiment, the reduced controller input is communicated and the raw controller input is not communicated to the game server. At step840, a rendered video is received from the game server. The rendered video reflects game progress manipulated according to the reduced controller input communicated previously at step830.

Turning now toFIG. 9, a method900of enabling game play over a remote connection using a data rich input device is shown, in accordance with an embodiment of the present invention. At step910, rich controller input for a video game is received at a client device. The controller input is for a video game running on a game server that renders at least part of the video game image. The rich controller input comprises a three-dimensional image data having pixels associated with a location in three-dimensional space. The three-dimensional image data may be generated by a depth camera that uses infrared data to ascertain a depth in space. Sonar or other equivalent technology may also be used to determine an object's depth in space and to generate a depth cloud.

At step920, the rich controller input is processed from a client device using codes specific to the video game to generate a game-specific reduced controller input. The game-specific reduced controller input may be similar to the reduced controller inputs described previously with reference toFIG. 8and elsewhere. At step930, the game-specific reduced controller input is communicated to the game server.

At step940, a rendered video that reflects game progress manipulated according to the game-specific reduced controller input is received from the game server. The rendered video may be output to a display device associated with the game client. In one embodiment, generic reduced controller input is also generated at the game client and communicated to the server in combination with the game-specific reduced controller input. Generally, the generic input is not specific to a particular game and instead may be used in association with multiple games running on the server. The game-specific code is specific to the game running on the server and will not serve other games. In one embodiment, the game-specific code used to preprocess the rich control input is downloaded to the client device from the server upon initiation of the network gaming session. The preprocessing code may then be erased from a client when the game session concludes.

Turning now toFIG. 10, a method1000of enabling game play over remote connection using a data rich input device is shown, in accordance with an embodiment of the present invention. Method1000may be performed by a game server receiving input from a game client.

At step1010, a reduced controller input is received from a game client. The reduced controller input is generated from a rich controller input received by the game client. The reduced controller input comprises less data than is in the rich controller input. The rich controller input comprises three-dimensional image data. The types of reduced controller input have been described previously with reference toFIG. 8and elsewhere.

At step1020, the reduced controller input is processed by the game server to generate a rendered video game image that reflects game progress manipulated according to the reduced controller input. At step1030, the rendered video game image is communicated to the game client over a wide-area network.

Embodiments of the invention have been described to be illustrative rather than restrictive. It will be understood that certain features and subcombinations are of utility and may be employed without reference to other features and subcombinations. This is contemplated by and is within the scope of the claims.