U.S. Pat. No. 10,252,164

DETAILED DESCRIPTION OF THE INVENTION

The inventors provide a virtual reality control scheme and method for controlling teleporting of an avatar in a three-dimensional virtual reality (VR) game or environment that is restricted by time and travel speed to create a more level playing field for other players not equipped with VR, that are using differing devices and controllers to operate their own avatars in the same game or environment. The present invention is described in enabling detail using the following examples, which may describe more than one relevant embodiment falling within the scope of the present invention.

FIG. 1is an architectural overview of a communications network100over which virtual reality sessions may be practiced according to an embodiment of the present invention. Communication network100includes the Internet network represented herein by a network backbone101. Internet backbone101includes all of the lines, equipment and access points that make up the Internet as a whole including all connected sub-networks and carrier networks both wired and wireless. Carrier networks and sub-networks are not specifically illustrated in this embodiment but may be assumed present such as would be in place for users to access the Internet.

Internet101supports a Web server102hosting a Website (WS)104. Website104may be an access point for clients of an Internet gaming site players. Web server102has connection to a data repository103containing client data including profile, membership, billing, and other related data for players. In one embodiment players that are site members of a gaming site may log into WS104and select games or environments from a searchable list that provides links to the servers hosting such games. One such server is a game server105hosting a game engine (GE)107. Game server105may be a cloud server that the gaming enterprise leases or otherwise maintains as an available server for playing games and navigating virtual environments. Game server105has connection to a data repository103that may contain game data and instruction for service.

It may be noted herein that a game provider may host games built by game developers, wherein the provider does not write the game code or modify any code that the developers have written relative to control schemes or platform/device support. However, it is possible that a game provider may seek to add players, including VR players, to their existing games in a fashion that does not create unequal quality of play for players and that the VR players have an optimum experience in an Avatar or character-based game or environment.

Internet101supports a design server (DS)108running software (SW)110. SW110enables a game provider to make control schemes available for VR players that may join a game that was not designed specifically for VR, but that supports VR in a way that is fair for VR players and those not using VR. In this example, a developer is depicted as using a computing device117having connection to Internet backbone101via an Internet access line or network. Device117has software (SW)118executable thereon. SW118enables the developer to design and create alternative controller schemes for VR players that may play an Avatar-based game. Design server108has connection to a data repository109containing controller scripts designed by such a developer operating from device117using SW118. VR control scripts may be served to client end devices to be prioritized over default schemes.

A VR-equipped player111is depicted in this example, and has access to Internet101via a line, sub-network or carrier network, and appropriate Internet service provider (ISP). VR player111may have a 3-axis controller113and a head-mounted display (HMD)112, which together provide the VR experience to the user. The 3-axis remote controller may be an existing implement in VR such as a daydream™ controller, a Vive™ controller, Oculus™ touch controller, etc. HMD112may be any HMD supporting VR such as Google Cardboard™, Oculus™ HMD, etc.

HMD112may execute a gaming application or software (SW)114for rendering a VR presentation accordingly. In one implementation, SW114provides a laser pointer function that is part of a control script and avatar movement control method for directing teleportation of the avatar in a game, by projecting a parabolic laser from the controller, to be visualized in display such that the end of the pointer intersects with a selected destination in game for the avatar. In this implementation, there may be one or more conditions imposed on teleporting for a VR player in a same game with potential players who are not VR equipped, whereby they do not teleport but walk, run, or fly etc. from an avatar perspective.

VR player111may use pointer described above to emit a parabolic laser to mark a destination for teleport that may be held to a certain distance from the Avatar, based on a time factor relative to how long a walking or running avatar of a client not using teleport could travel (walking running or flying) over the same distance. Player111may push a button on HMD112, or on controller113, to initiate avatar teleport to the destination marked by the laser, with at least one physical limitation that prevents the avatar from teleport travel at a rate faster or more advantageous than a competing avatar that must walk, run or fly. It is noted herein hat the camera perspective of the VR player is that of the avatar, so the camera is mapped 100 percent to the VR player's HMD. In this implementation, a function for emulating a visible and expanding ripple or bubble governed by time, and a common travel speed (VR player, other player), may be initiated and visualized in VR by the VR player.

Such a visual ripple described in more detail below may be annular and may expand out equally and at a constant speed from the Avatar's teleported position at the instant the Avatar arrives. The VR player may visualize the ripple in a manner that does not obstruct objects in the VR environment. This effect may be achieved using translucent features that may be seen, but that may not obstruct the vision of the client for objects in the environment.

A second player device115is depicted having connection to Internet101through a wireless carrier network (not depicted). Device115is a gaming station running a gaming software (SW)119. Device115has standard controller interfaces116to control avatar movement amongst other gaming functions. In this embodiment, player device115and player device112are in the same gaming session with server105and game engine107, as depicted herein by broken session lines connecting each device to GS105and GE107. The player' devices have different controllers for interacting with the game. In this embodiment, a game developer does not have to build or otherwise add any VR control scripts to game data106for game engine107for any games served. VR control scripts may be created in LUA, which is a very light-weight, object-oriented program language. Other languages may also be used without departing from the spirit and scope of the present invention.

In general use of the present invention, a developer may build a 3D game for general play for players using disparate platforms. The hosting entity may create control schemes for VR support that may replace traditional control schemes that may be VR defaults for a character or avatar to move. During a session, the hosting entity may detect a VR platform joining a game that supports VR alongside those not equipped with VR. The default scheme normally used by the VR player may be replaced in game with the overriding avatar teleport control script that uses the parabola or straight laser to select a position for the VR avatar to teleport to in game. This might be accomplished in a few different ways, for example, by making the control schema available to the VR client just before joining the game as a download ahead of the gaming stream. In one embodiment, the overriding control schema may be preselected by the VR client before playing.

In another embodiment, the overriding control scheme may be inserted as lightweight LUA scripts by proxy into the game stream and based on detection of platform and peripheral input device be prioritized over other schemes for other players. In one implementation, there may be more than one avatar control schema for differing VR platforms without departing from the spirit and scope of the invention, wherein the device selects the appropriate schema based on the nature of the VR hardware used. For example, the laser parabola may emanate from the gaze point of a VR HMD like HMD112in the absence of a remote 3-axis controller, for example. In this way, a VR player and a player not equipped with VR may play a same avatar-based game or environment or application on a more equal and competitive playing field. It is noted that in VR the camera associated with the avatar is mapped 100% to the clients head relative to three-dimensional space.

FIG. 2is an example of a display of a game with a virtual-world landscape supporting restricted teleporting of a VR player's avatar according to an embodiment of the present invention, as well as movement of an avatar controlled by a player not VR-equipped. In this example the VR-equipped player uses a HMD for visualizing the environment, and a 3-axis controller to move an avatar202. The display is of a courtyard or similar area with a raised level205accessible via a stairway203. In this example, a player that is not using VR equipment is depicted as controlling an avatar201in the same game at the same time as avatar202is controlled by the player using VR equipment.

VR-controlled avatar202and non-VR-controlled avatar201are, in this example, in a process of movement through the landscape, as is depicted logically herein with representations of the player's avatars depicting a first position in the game, and future moved positions, which are marked consecutively in this example as A, B, C. Therefore, element numbers202for the VR player's avatar shall apply to all representations of that avatar. Likewise, element number201applies to all representations of the non-VR player's avatar in this example.

Note that each succeeding position of avatar202is marked as A, B, then C, as described above. The same is true for avatar201. The non-VR player controlling avatar201may control avatar201by using a joy stick controller or a similar non-VR controller to initiate avatar walking or running or jumping, as is known in the art. It may be assumed herein that avatar201is making its way, controlled by the non-VR-equipped player, (dotted directional arrows), from position A, through position B, to stairway203, position C. Within a same or similar time frame, VR player's avatar202is repeatedly teleporting toward stairway203, from position A, through B, to C. The VR player's avatar202may be teleported along while the non-VR player's avatar may not be teleported and must walk or run to stairway203.

It is emphasized that the movement of the avatars in this example is entirely exemplary, and the non-VR player may be moving avatar201in another direction or away from stairway203, and the VR-equipped player may be moving avatar202anywhere in the landscape, subject to restrictions detailed herein.

At any position of avatar202, consider position A for example, a ripple effect206is generated, visible to the VR-equipped player, and this begins as soon as the avatar enters the game or completes a teleporting move, and the ripple effect expands outward radially from the new position of avatar202. In this implementation, the rate of expansion of ripple effect206is equal to a maximum walk or run speed of avatar201as controlled by a non-VR player.

The ripple effect in one embodiment is an effect visible to the VR-equipped player, and the VR-equipped player may select any point within the expanding area of the ripple and may teleport immediately to the selected point. The visual nature may be thin rings as shown inFIG. 2, or just one expanding ring, or may, for example be an expanding halo, or ring of brightness. The essential quality is that the VR-equipped player is informed by this expanding ring of all the real estate open to teleportation of the controlled avatar.

VR avatar202, while stationary at the point of game entry A, may select a teleport destination by a laser pointer208, via the VR player's hand-held 3-axis controller in this example, as described above, that may intersect a spot near the current edge of the expanding ripple effect206as depicted, and may immediately teleport there. The camera is specifically mapped to the VR player's avatar's head. In one embodiment, the laser pointer may be a straight line. Further, the pointer may be controlled in some cases by an input device on the HMD.

Again, it is emphasized, that although in this example the VR-equipped player has chosen to teleport avatar202to point B, at the edge of expanding ring202, any other point within the region of the expanding ring may have been selected.

The expanding ring prevents the player controlling avatar202from selecting a destination that is beyond the current outer peripheral edge of expanding ripple effect206, which indicates the movement ability of avatar201, controlled by a non-VR-equipped player. Thusly, the two players, using very different platforms, are rendered rather more equal in movement ability than would otherwise be the case. This restriction may be applied relative to a speed that avatar201must walk or run in the game. In one implementation, avatar201may move at a speed which may be the same speed that ripple effect206expands. In another implementation, the expansion rate of ripple effect206may be variable and controllable by the VR player but still entirely based on the rate or speed of travel that the non-VR player's avatar can travel. For example, if the non-VR avatar changes speed, the VR player may adjust the speed of expansion of ripple effect206accordingly.

After teleporting to position B, a second ripple effect207immediately begins at that point and expands outward in the same fashion as the first ripple effect206. Ripple effect206disappears, in this example, once a second effect is initiated. Ripple effect207will take some time to expand all of the way to the face of staircase203, the presumed destination for both of the avatars in this example. Avatar202controlled by the VR player, may launch another laser toward stair case203, however it cannot mark a destination unless ripple effect207has expanded to that point.

It is noted herein that the ripple effect (206,207) is the same effect repeated every time the VR player teleports the avatar to a new destination. It may also be noted herein that the ripple effect may be a two-dimensional or a flat effect such as spreading across a floor or the ground, it might also transform or be transformed into an expanding spherical ripple effect in three dimension (3D). To illustrate, a VR avatar may be teleporting through an atmosphere or in space whereas another non-VR player avatar is physically flying or jumping through the same space. The VR player may use the laser to mark the edge of the expanding spherical ripple effect to teleport to that destination in space. In one implementation, a ripple effect may be designed to climb up vertical walls up to ledges or prepuces in a game architecture in order to enable teleportation to such places as long as the ripple has made it to that point in the expansion.

FIG. 3is a process flow chart300depicting steps for timed teleporting of an avatar in a VR environment that may also be navigated by players not using VR equipment or control schemes. At step301a VR equipped player may join (enter into) a game or environment. At step302a first ripple effect initiates about the player's avatar and begins expanding at a set speed radially outward of the avatar. The VR player may see the effect in the display of the HMD.

At any time during the expansion of the ripple effect initiated at step302, the VR player may determine whether or not to teleport his avatar to a new position or destination. If at step303the VR player (client) determines not to teleport, the process may loop back to step302where the ripple effect continues to expand in the space. If at step303the VR player decides to teleport, then at step304the VR client may use a 3-axis controller analogous to controller113ofFIG. 1to mark a destination. In order to successfully mark a spot for teleportation, the spot marked must be within the outer boundary of the expanding ripple effect., or just behind the lead ripple for maximum efficiency. In one implementation, in step304, where the user has a VR HMD but no 3-axis controller, the laser may be a straight laser. A button on the display may be assigned to mark the spot and initiate the travel such as for Google cardboard, which as an input button on one side.

Once a destination is marked, at step305the VR player may teleport the avatar to a marked destination within the ripple effect. It is noted that the camera is mapped to the HMD of the VR player and is the viewpoint of the avatar, so the camera is teleported together with the avatar. The VR client immediately sees the landscape from the perspective of the new teleported position. At step306, a next ripple effect automatically initiates and begins expanding when the avatar lands at the new spot in the landscape. The process may then resolve back to step303waiting for the VR player to decide to teleport again. In this process, the rate at which the VR avatar may move through the game space is limited by the rate of expansion of the ripple effect, which is tied to the rate of travel allowed by non-VR avatars. There may be one rate or more than one rate depending on the travel speed capabilities of the avatars. A VR player may toggle the rate of expansion of the ripple if more than one speed is allowed for avatar travel.

FIG. 4is a UML diagram depicting a control scheme model400for VR players in a game that also supports players not equipped with VR. Diagram400depicts a control scheme402(ripple/teleport control) specifically for a VR player401. VR player401has a head-mounted VR viewer403such as an Oculus™ system or Google Cardboard™. VR player401has input indicia404such as a button or teleport selector to initiate movement of an avatar. Model attribute404may also be an attribute of VR viewer403or of laser pointer406(3-axis enabled) without departing from the spirit and scope of the present invention, such as on a Google Cardboard™ viewer or a hand- held 3-axis controller.

Avatar ripple control402has access in this example to an input detection or listener407. Control402has access to an avatar teleporter function410for teleporting an avatar according to at least one constraint or limitation governed by the ripple effect. Input listener407may detect input from a VR client marking a destination for avatar teleportation and call a ripple generator408to configure and initiate an expanding ripple visible to the VR player. The ripple generator may receive information from a location tracker411responsible for tracking an avatar within the game space. The generator may initiate the ripple at the last location of the avatar.

Avatar teleporter function410may receive information from the ripple generator to initiate avatar teleportation. Timer function409may calculate how much time it may take for an avatar that does not have VR equipment to travel a path based on geographic distance (in game) and speed of avatar motion currently used by the player. Ripple function408may receive information from timer function409in conjunction with receiving a call from input listener407and may adjust the expansion rate of the ripple based on the input and allowed travel rates for non-VR avatars. Attribute data412includes a fly speed or speeds for an avatar, a run speed or speeds for an avatar, and a walk speed or speeds for an avatar. These speeds may be standard in game constants and the number of options may depend upon avatar capabilities and may also include swimming or other modes of locomotion such as driving. Further, each speed value may include more than one separate static value, like slow run time and fast run time, etc. For example, input listener407may detect a toggle action by a VR player physically moving from one speed to another speed of ripple expansion and report that to the ripple generator, whereby the ripple expansion rate may be accordingly adjusted in real time. In one implementation Timer function409may notify avatar teleporter410to commence teleportation of an avatar in place of the ripple generator without departing from the spirit and scope of the present invention.

The present invention enables VR players to play a VR supported Game on an equal playing field with other players in a manner that prevents the VR player from becoming uncomfortable using a HMD. It will be apparent to one with skill in the art that the system of the present invention may be practiced using all or a combination of components described in this specification. It will also be apparent to the skilled artisan that the embodiments described above are specific examples of a single broader invention that may have greater scope than any of the singular descriptions taught. There may be many alterations made in the descriptions without departing from the spirit and scope of the present invention.

It will be apparent to the skilled person that the arrangement of elements and functionality for the invention is described in different embodiments in which each is exemplary of an implementation of the invention. These exemplary descriptions do not preclude other implementations and use cases not described in detail. The elements and functions may vary, as there are a variety of ways the hardware may be implemented and in which the software may be provided within the scope of the invention. The invention is limited only by the breadth of the claims below.