COMPUTER SIMULATION METHOD WITH USER-DEFINED TRANSPORTATION AND LAYOUT

Abstract

In one implementation, a method comprises: obtaining a first input from a user of a client device associated with creating a personal transportation center within a virtual environment; in response to obtaining the first input, instantiating the personal transportation center within the virtual environment; in response to obtaining a second user input from the user of the client device, instantiating a first portal within the personal transportation center, wherein the first portal corresponds to a first destination environment within the virtual environment specified by the user; and in response to obtaining a third user input from the user of the client device, instantiating a second portal different from the first portal within the personal transportation center, wherein the second portal corresponds to a second destination environment different from the first destination environment within the virtual environment specified by the user.

Claims

1. A method comprising: modeling a three-dimensional environment; causing display of a portal at a first location in the three-dimensional environment, wherein the portal is associated with a second location in the three-dimensional environment; in response to obtaining a first user input from a user, disassociating the portal from the second location and associating the portal with a third location in the three-dimensional environment; and in response to obtaining a second user input from the user, transporting an avatar of the user from the first location to the third location.

2. The method of claim 1, wherein causing display of the portal at the first location is performed in response to obtaining a third user input from the user placing the portal in the three-dimensional environment.

3. The method of claim 1, wherein the first user input includes a first portion interacting with the portal to open a customization menu and a second portion interacting with the customization menu to select the third location.

4. The method of claim 1, wherein the second user input includes a portion maneuvering the avatar of the user into the portal.

5. The method of claim 1, further comprising, in response to obtaining the first user input, changing an appearance of the portal at the first location.

6. The method of claim 1, further comprising, prior to obtaining the first user input, in response to obtaining a third user input from the user, transporting the avatar of the user from the first location to the second location.

7. The method of claim 1, further comprising, in response to obtaining a third user input from the user, transporting the avatar of the user from the third location to the first location.

8. The method of claim 1, further comprising, in response to obtaining a third user input from the user, transporting the avatar of the user from the third location to a fourth location.

9. The method of claim 1, further comprising, in response to obtaining the first user input, further associating the portal with one or more fourth locations.

10. The method of claim 9, wherein, in response to obtaining the second user input, the avatar of the user is transported to the third location based on a random selection between the third location and the one or more fourth locations.

11. The method of claim 9, wherein, in response to obtaining the second user input, the avatar of the user is transported to the third location based on a temporal selection between the third location and the one or more fourth locations.

12. A device comprising: non-transitory memory; and one or more processors to: model a three-dimensional environment; cause display of a portal at a first location in the three-dimensional environment, wherein the portal is associated with a second location in the three-dimensional environment; in response to obtaining a first user input from a user, disassociating the portal from the second location and associating the portal with a third location in the three-dimensional environment; and in response to obtaining a second user input from the user, transporting an avatar of the user from the first location to the third location.

13. The device of claim 12, wherein the one or more processors are to cause display of the portal at the first location in response to obtaining a third user input from the user placing the portal in the three-dimensional environment.

14. The device of claim 12, wherein the first user input includes a first portion interacting with the portal to open a customization menu and a second portion interacting with the customization menu to select the third location.

15. The device of claim 12, wherein the second user input includes a portion maneuvering the avatar of the user into the portal.

16. The device of claim 12, wherein the one or more processors are further to, in response to obtaining the first user input, change an appearance of the portal at the first location.

17. The device of claim 12, wherein the one or more processors are further to, in response to obtaining the first user input, further associate the portal with one or more fourth locations.

18. The device of claim 17, wherein, in response to obtaining the second user input, the avatar of the user is transported to the third location based on a random selection between the third location and the one or more fourth locations.

19. The device of claim 17, wherein, in response to obtaining the second user input, the avatar of the user is transported to the third location based on a temporal selection between the third location and the one or more fourth locations.

20. A non-transitory memory having instructions encoded thereon which, when executed by a device having one or more processors, causes the device to: model a three-dimensional environment; cause display of a portal at a first location in the three-dimensional environment, wherein the portal is associated with a second location in the three-dimensional environment; in response to obtaining a first user input from a user, disassociating the portal from the second location and associating the portal with a third location in the three-dimensional environment; and in response to obtaining a second user input from the user, transporting an avatar of the user from the first location to the third location.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG. 1 is a schematic diagram showing a system for simulation method with user-defined transportation.

[0015] FIG. 2 is a schematic diagram showing a second system for simulation method with user-defined transportation.

[0016] FIGS. 3A-3B are schematic plan views showing exemplary customization of portals in a common environment.

[0017] FIGS. 4A-4B are schematic plan views showing exemplary operation of an expanded environment space within a VRU.

[0018] FIGS. 5A-5C are schematic plan views showing exemplary operation of a customized doorway for different participants.

[0019] FIG. 6 shows exemplary steps of a method for operating a VRU portal.

[0020] FIG. 7 is an exemplary view of a VRU with avatars.

DETAILED DESCRIPTION

[0021] The disclosed solution to enhance VRU's is a system, apparatus and method for allowing users dynamically to create user-defined doorways and other portals. In the detailed description that follows, like element numerals are used to denote like elements appearing in one or more of the figures.

[0022] Referring to FIG. 1, a system 100 for providing a VRU to multiple users may comprise a plurality of client sites, nodes or terminals, for example a personal computer 104, portable computers 106, 110, a compact player, cell phone or digital assistant 108, and/or router 112 communicating via a WAN 102 to one or more servers 114. Servers 114 store and serve game data and software to the client sites. Software or firmware may also be located at each client site, configured to work cooperatively with software or firmware operating on servers 114. Generally, any number of users may be communicating with servers 114 for participation in the VRU at any given time.

[0023] Referring to FIG. 2, a system 200 for providing a VRU may be considered to be comprised of server-side components (to the left of dashed line 222) and client-side components (to the right of dashed line 222). Server-side components may comprise a portal 220 for managing connections to multiple simultaneous players. Portal 220 interacts with a VRU engine 218, passing user input from multiple clients to a game engine, and passing game data from the VRU engine to respective individual players. VRU engine 218 is operatively associated with two memory spaces, a common memory space 204 holding common elements of the VRU, and a personalized space 210. As known in the art, objects in a VRU are modeled as three-dimensional objects, or two-dimensional objects, having a defined location, orientation, surface, surface texture, and other properties for graphic rendering or game behavior. Common memory space 204 may be considered as comprised of a core area 206 for holding core common elements, and a non-core area 208 for holding non-core common elements 208. Customized space 210 may be comprised of various different customized areas 212, 214, 216, each assigned to a different user.

[0024] A portal or other transportation may be made up of a combination of personalizable and common elements. For example, the appearance of a door may be a common element that is the same, regardless of the destination to which it leads. The transport characteristics of the door, in comparison, may be personal to a user or a group of users. The door may lead to a first environment “A” by default, but may be customized to lead to any other environment, e.g., environment “B” for a particular user or users. Similarly, a road or path may be made to have a different destination, depending on who is traversing it. Therefore, in determining the result of a player passing through a portal or other transportation element, VRU engine 218 will draw from both common element space 206 and customized space 210.

[0025] A separate administration module 202 may operate at the server level to create, update, modify or otherwise control the content of the VRU as defined in the memory areas 204 and 210. Generally, changes in the personal space area 210 are driven by individual users, either through the VRU administrator 202 or another module. Control of common areas, i.e., the game environment and the objects in it, may be via the administrator module 202.

[0026] At the client level, a player interface module 224 may be installed to receive player inputs from one or more user input devices, such as a keyboard, mouse or other pointer, or microphone, and provide data to the VRU engine 218 via portal 222 in response to the input. The player interface module may also receive game data from portal 220 and process the data for display on display 226 and/or for audio output on speaker 230. Various systems and methods for providing a three-dimensional, multiplayer interactive animation to multiple players are known in the art, or may be adapted by one of ordinary skill for use with the technology disclosed herein. The technology is not limited to a particular hardware or software architecture for carrying out the steps described herein.

[0027] As disclosed herein, a user may be provided with the ability to define or redefine the destination of existing transportation mechanisms within an environment or area. FIGS. 3A and 3B show exemplary 3-D environments 300, 300′ in plan view. Both environments share common elements, such as a road 302 and buildings 304, 306, 308. Each of these buildings may have an external appearance to clients represented by avatars on road 302, and one or more doors leading to the road. Receipt of user inputs for moving an avatar through the doorway may result in placing the avatar in a new environment that may be configured to represent the interior of each respective building. Environment 300 may include certain doors that lead to other environments that a participant does not desire to visit. For example, the interior of buildings 312 and 310 may not be of interest to the user.

[0028] Therefore, the user should be provided with a link or command, that when provided to the game engine, permits the user to change the transport characteristics of a portal or other transportation element. For example, double-clicking on a door or building may cause a customization menu 320 to appear. The customization menu should allow the user to select a custom destination from one or more alternative destinations. In the illustrated example, the customization menu displays a map of the immediate environment with alternative destinations 322 shown in a separate screen area. A user may “click and drag” a desired building in or out of the displayed environment to change the building located on road 302. In effect, this action changes both the external appearance of the doorway and the place to where it leads. In the alternative, or in addition, the destination of the portal may be changed without changing its external appearance in the common environments 300, 300′.

[0029] Using the system herein described, the user may change the destination of those doors such that when the user who has made the changes directs her avatar to move through those doors, that user arrives in a destination that the user has selected rather than the original destination set by the environment's designer. The instant technology contemplates that all other users who have not similarly changed the destination of that doorway may still arrive at the original destination as set by the environment's designer. The new destination may be a common environment, or a private environment accessible only to a particular user and that user's invitees (or other club members, etc.). In addition, the system may be configured so that changes as made by one or more users authorized by the user also affect the user's own destination settings.

[0030] Optionally, some doorways in the environment may be locked so that they cannot be changed, while other portals may be customized. For example, buildings 304 and 306 may represent buildings or environments belonging to commercial sponsors, which are locked to protect the value of these commercial properties. In addition, a user may be permitted to change the destination on both sides of the portal—to change not only where it leads, but where it leads back to. Some limitation on the ability to change portals to lead to private environments may be desirable, to prevent participants from getting lost or stuck in private environments with no convenient passage to the common environments of the system.

[0031] Another feature of the instant technology is that the user may be able to customize the look of the transportation mechanism. Thus, the user may wish to change the destination of a portal in a primary environment, and he may also wish to change the look of the portal as well as the facade surrounding the area of the portal such that it is more suitable for the new destination, as illustrated by FIGS. 3A and 3B. The instant technology permits the user to make those changes by any suitable procedure, such as creating the new graphics, or copying and pasting existing graphics, or instructing the environment to display any of the available graphics, or any other manner for effecting these changes as is well known in the art, such that the user who has made those changes experiences those changes via interaction of the user's avatar with the environment. For example, a user presented with an editing screen 320 may remove building 310 and replace building 300 with building 326 to create the modified environment 300′.

[0032] All other users who have not similarly requested or effected those changes may still perceive the environment as set by the environment's designer, e.g., default environment 300 in the illustrated example. However, users may have the ability to establish a mechanism whereby changes as made by one or more users authorized by the user may effect the user's own environmental and area perception settings. Thus, for example, a wife may make changes to the various portal and facade graphics, and the husband, if he has established that he would prefer to have all changes effected by his wife also affect him, will also realize those changes. User's may be identified as known in the art; for example, requiring user's to log in with a user name and password, and/or writing user identifying information to client machines that access the multi-user environment.

[0033] In some embodiments, a user may be provided with an ability to create a fully customized environment by selecting other environments or areas that the user wishes, copying and pasting them into a custom area or environment. By so obtaining existing facades, portals, environments and areas, and assembling them, the user will be able to establish an environment that is customized to the user's specific interests and needs. Such customized environments may be used only by the user, or, in the alternative, by other users who are permitted, invited or otherwise allowed to use the environment, or in the alternative, by everyone who desires to use the custom environment. Thus, for example, a user may take her favorite environment and replace several stores and meeting halls that she does not use with other stores and meeting halls that she frequents, and thereby create an essentially fully customized environment with all of her favorite environments and areas, all within easy navigation of her primary environmental destination.

[0034] Customization or environments may be configured to permit other users to be within the same original environment, and thus be visible and capable of interacting with the user(s) of the custom environment, even though for those other users, the various environments and areas may be different. For example, unrelated users may see each other on the street 302 that is outside of the various doors/portals, but if the two users walk through a door or portal that is not set to the same destination, the users will then arrive in different destinations and no longer be in the same environment or area. Referring to FIGS. 3A and 3B, a first user may be present on road 302 and walk into building 312 to arrive in a different destination than a second user who walks with through the same door into a different building 326.

[0035] The system may also enable users to create areas or environments that will serve as personal transportation centers. Under this feature, a user could create a personal environment that is totally customized, with no pre-existing base environment. The environment that the user creates can be assembled using any available techniques, but such that at least one portal is placed within the environment. The destination of that at least one portal may be established by the user. The geometry of the environment may also be established by the user so that the user has the ability to customize that transportation area so that it optimally suits their desire. A transportation center may be provided as a private environment linked to one or more common environments via a portal. At least one portal in the transportation center may be locked so that it always leads to a defined common environment. Other portals may be located closely adjacent to one another to provide convenient access to desired common and private destination environments.

[0036] The system may further be configured to permit the user to customize the destination of portals such that one portal may serve more than one destination depending on user defined parameters including but not limited to: time of day, day of week, time of year, preset sequential destinations, user commands upon entry to the portal, user commands prior to entry, how the user signed in to the VRU, random destination, results of a search, prior actions of the user, or the prior location or locations of the user in the VRU. Thus, a single portal may allow the user the ability to transport to more than one destination area or environment based on parameters and preferences as established by the user and/or the operator of the VRU.

[0037] An advantage of the instant technology is that it provides users with a way to organize their portals and thus simplify their ability to navigate in a VRU. This is highly advantageous over existing transportation methods used by existing VRU's. Thus, a user may, for example, have a portal for all their work related destinations and a different portal for all of their shopping destinations. As the user is entering the portal, if they wish to go to a work destination, the user could use a method as is well known in the art, such as selecting from a drop-down menu, to find an appropriate destination when entering the first portal, or from a similar organized drop-down menu to find a shop for her shopping needs, from her second portal. The advantages compound as users create additional custom portals with greater granularity of defined destinations.

[0038] In some embodiments, a user's customized portals in her main transportation center lead to other customized environments which contain customized portals that are of greater specificity, which portals may lead to an unlimited number of additional environments with portals of greater and greater specificity until the user uses a final portal to arrive at a new environment. For example, a user may pass through a “shopping” portal to arrive at an environment that includes her favorite shopping destinations. She may then pass through a “clothing” portal, then through a portal leading to a specific dress shop to find an item she is looking for.

[0039] In yet another embodiment of the technology, portals in the customized transportation center and any more specific custom transportation centers that the user uses, may contain facades of the destination, an actual view of the outside and/or interior of the destination (through use of virtual video cameras as is well known in the art, or through other similar mechanisms) and other graphical or textual or other information, which may provide the user with information such as but not limited to whether the destination has been modified since they last visited, or whether other users are inside or are entering and exiting the environment.

[0040] The space available to a destination need not be limited to its apparent size. Referring to FIGS. 4A and 4B, a building 402 may have an apparent area footprint “A” when viewed from the outside environment 400 by a user 404. After the user 404 enters the building 402′, it may be assigned second apparent area footprint “B” that is not equal to “A.” Ordinarily, “B” should be larger than “A,” although it can also be smaller. This feature is not limited to enclosed structures or environments. It may apply to any bounded area or volume of the VRU. For example, a parcel of virtual real estate may be increased in size after a user enters it. This permits neighbors to dwell in close proximity, which is more convenient for visiting, while still permitting large areas within each plot. This feature is also useful for relieving overcrowding that may occur as a VRU increases in popularity.

[0041] To enable this expanded space feature, the VRU system may maintain separate maps of non-expanded and expanded spaces. Some portion or all of the boundary around the expanded space is configured to act as a portal (or as numerous separate portals) from the non-expanded space into the expanded space. For example, as shown in FIG. 4A, a door in the wall of the building 402 acts as a portal to an expanded interior space. For non-enclosed spaces, a line or surface surrounding the expanded space in the non-expanded space may be mapped to a line or surface surrounding the non-expanded space inside the expanded space via a non-unitary mathematical transform (i.e., not merely multiplication by one), or using a look-up table. For example, if an expanded area is provided with a hundred-fold (102) expansion of space, every meter of boundary around the expanded space in the non-expanded space may be linearly mapped to a corresponding boundary around the expanded space in the expanded space by a factor of ten. Thus, an avatar entering the expanded space from the 4.5 meter boundary position in the non-expanded space may be placed at the 45 meter boundary position in the expanded space. If the avatar later returned to the non-expanded space at the 87 meter boundary position in the boundary of the expanded space, the avatar may be placed at the 8.7 meter boundary position in the non-expanded space.

[0042] After a user passes through a portal, the VRU system uses the map of the expanded space to generate the user environment, with the user placed in the expanded space at an entry point defined for the passed portal. Likewise, some portion or all of the boundary of the expanded space is configured as a return portal or portals to the originating non-expanded space. Optionally, a portion of the boundary may be configured as a portal to other spaces, or the expanded space, like the non-expanded space, may simply contain portals to other places. After a user has passed through a return portal, the VRU system uses the map of the non-expanded space to generate the user environment, with the user placed in the non-expanded space at a re-entry point defined for the passed portal. In this way, seamless transitions may be made between expanded and non-expanded areas. The effect of such transitions may therefore be as if objects passing into the expanded space shrink in size, and shrunken objects passing back into the non-expanded space are restored to their normal size.

[0043] FIGS. 5A-5C illustrate operation of a customized portal for different users. Initially, avatars 506, 508 belonging to different participants are located in a common area 500, shown in plan view. Each avatar is therefore rendered to both participants; i.e., each participant can see and control his own avatar, and can see and interact with the avatar controlled by the other participant. The two avatars 506, 508 are next to a doorway 501 that has been customized for avatar 506 to lead to a custom environment 504. The default destination for the doorway is environment 502, in which another avatar 510 happens to be present.

[0044] FIGS. 5B and 5C show what happens after the avatars 506, 508 pass through the doorway 510. As shown in FIG. 5B, avatar 508 is in environment 502 with avatar 510. Avatar 506, however, is absent as far as avatar 508 is concerned. As shown in FIG. 5C, avatar 506 is in environment 504 with another avatar 512 that happens to be present there. Avatar 508 is not in environment 504. Operation of doorway 501 may be configured such that if both avatars 506, 508 (and either of avatars 510, 512) pass back through the door, these avatars will be present together again in the common environment 500.

[0045] FIG. 6 shows exemplary steps of a method 600 for operating a VRU portal. The method may be performed by a VRU engine in a system such as described above. The system includes customization data for various portals in the VRU and instructions for operating in response to such data. At step 602, the VRU engine may receive or generate a signal indicating that a player has entered a portal, or is about to enter a portal. For example, the VRU engine may generate a signal indicating that an avatar moving in the VRU space in response to input from a client device has triggered an entry transaction with a portal object of the VRU space. Generally, such a signal will be generated when some portion of an avatar's surface has broken a portal plane, the avatar coordinates pass through a defined plane or space, the user causes the avatar to perform some action, such as pushing a virtual button or moving to a defined place, or by any other suitable change in state of the avatar.

[0046] At step 604, the VRU engine receives an identifier for the avatar. This may be supplied, for example, by a data record maintained for the avatar at the server level, client level, or some combination of the foregoing. In the alternative, the user may be required to provide an identifier and/or password. The identifier should be unique to the avatar performing the action. Note that a single participant may register more than one avatar, and may desire to customize portals differently for different avatars. Such capability may be facilitated by providing identifiers for avatars, not merely for users. Generally, unique identifiers may be assigned to any or every object in the VRU space. This includes, of course, the portal through which the avatar is passing, which may have its own unique identifier.

[0047] At step 606, the VRU engine may determine whether a custom destination has been defined for the portal and avatar in question. For example, the VRU may maintain an index of custom destinations, organized by avatar and portal ID. If a record exists in the index, the custom destination may quickly be determined from it. If no record exists, then it is determined that no custom destination has been defined.

[0048] If no custom destination is defined, the avatar is caused to enter a default destination for the portal, at step 608. Conversely, if a custom destination environment is defined for the avatar and portal, the avatar is caused to enter the custom destination environment at step 612. At the VRU engine level, such entry to a default or custom destination environment may be facilitated by identifying the respective environment, pulling the environmental data for the destination environment, and ether rendering the scene and providing the scene to the player interface at the client level, or sending the environmental data to the client for rendering at the client level. It should be appreciated that data for certain elements, such as core elements, may be stored locally at the client level to reduce bandwidth demands. The server-located engine in such case may merely provide the client with data concerning non-core elements and elements controlled by other clients, which may then be added to the core elements at the client level to render the scene.

[0049] At optional step 610, the VRU engine may determine whether the destination is subject to other conditions, for example a code specified by the user, a time preference, a frequency-of-use preference, or other condition. The other condition may be specified by the user operating the avatar when configuring the portal. In the alternative, the other condition may be specified by another user, or a system administrator, according to examples provided hereinabove. If no other conditions apply, the avatar is delivered to a first custom destination, at step 612. Optionally, if another condition applies, then the avatar is delivered to a second custom destination, at step 614.

[0050] FIG. 7 shows an exemplary common scene 700 containing multiple avatars, e.g., avatars 702, 704. Each avatar is controlled by a different player via a remote interface. The common scene 700 appears to be the same for each avatar. However, each player may select a different viewpoint of the scene, so the rendered view of the scene may be different for different players. Scene 700 includes multiple storefronts, such as storefront 706, that may serve as portals to common spaces, personalizable spaces, or some combination of the foregoing.

[0051] Having thus described a preferred embodiment of simulation method with user-defined transportation and space, it should be apparent to those skilled in the art that certain advantages of the within system have been achieved. It should also be appreciated that various modifications, adaptations, and alternative embodiments thereof may be made within the scope and spirit of the present disclosure. For example, implementation of the method over a wide area network has been illustrated, but it should be apparent that the inventive concepts described above would be equally applicable to other networks.