Abstract:
In order to facilitate rendering of scenery elements in a role playing game, or in any other virtual universe (also known as a metaverse), there is provided a scenery container together with a play manager which cooperatively interact to achieve the loading, saving and storage of sets of scenery elements. Renderings are thus carried out more quickly and efficiently and with easier efforts on the part of the users.

Description:
TECHNICAL FIELD 
       [0001]    This invention relates, in general, to virtual world program applications and, more particularly, to methods and systems for controlling the rendering of scenery in role playing games. 
       BACKGROUND OF THE INVENTION 
       [0002]    Role Playing Games (RPGs) provide a powerful mechanism for performing many activities in fully immersive virtual environments known as metaverses. One of the most famous examples of such a metaverse is the program referred to as Second Life®. While these programs are often referred to as “games,” they are nonetheless highly practical devices used in education, psychotherapy and in benchmarking to name just a few applications. Those involved with virtual universes, and particularly developers of them, make a distinction between “games” and what they refer to as “serious games.”However, in general, Role Playing Games typically comprise two principal elements: scenography and a script. The scenography is related to the stage, the scenes and the costumes. The script is related to roles, actions, dialogs and events. 
         [0003]    A play is usually divided into acts and scenes. Different scenery is associated with each scene. Each scene may be quite complicated and may contain both active and inactive elements. Active elements may interact with avatars, whereas inactive elements are used by avatars but have no inherent automatic programmed behavior. An avatar is a graphical representation that a user selects that other users can see, often taking the form of a cartoon-like human but with increasing desire to render the depiction in more realistic fashion. Active elements are usually found in specific states in a time sequence. Once a role playing game is started, it is often desirable to rapidly change the scenery as the play proceeds. Since a scene is made of many objects in specific positions and states, it often takes a lot of time and manual effort to remove the previous scenery and something to do with new scenery elements. 
         [0004]    The present invention is seen to have many uses and applications. In particular, it may be used in an education environment for simulations related to on-the-job training. In cinematic applications, it is useful for providing a substitute for storyboard production. In an architectural environment, it is useful for simulating the flow of people in malls and in other locations, both public and private. In a business environment, it is applicable for use in serious game playing, role playing, and in the analysis of user interaction scenarios. 
         [0005]    Note that, throughout this disclosure, for clarity of presentation only, reference is made to an individual or avatar, which is a digital representative of the individual. However, it should be noted that this term not only applies to an individual, but to any computerized processes that may execute on behalf of the individual, using the same credentials and capabilities of the individual that owns/controls the process. In general, this embodies many forms, such as prescheduled, automatically running maintenance processes, system level processes (owned by the system administrator), etc. In all cases, this process is treated like an avatar, with the same inputs and outputs, regardless of whether the credentials come directly from an individual or from a computerized process acting in his or her stead. 
         [0006]    From the above, it is therefore seen that there exists a need in the art to overcome the deficiencies and limitations described herein and above. 
       SUMMARY OF THE INVENTION 
       [0007]    The shortcomings of the prior art are overcome and additional advantages are provided by taking advantage of two auxiliary objects: a Play Manager (PM) and a Scenery Container (SC). The play manager takes care of generating and removing scenery. The scenery container manages the storing and rendering of each element of a scene in the right position and state. These two objects work together in a coordinated fashion to minimize user effort and to maximize the speed at which objects are rendered. Duplication of effort on the part of a user is avoided. 
         [0008]    In accordance with one embodiment of the present invention, a computer-implemented method for rendering scenery in a virtual universe environment comprises: creating a set of scenery elements for a stage; providing a scenery container for these scenery elements; storing these scenery elements in the scenery container; and loading the scenery container into the inventory of a play manager. It should be particularly noted that it is not necessary that a scene represents real objects, that is, real life. One can use a metaverse to represent symbolic objects as well. 
         [0009]    The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a computer program product for rendering scenery in a virtual universe environment. The computer program product comprises a storage medium readable by a processing circuit and storing instructions for execution by a computer for performing a method. The method includes, for instance, steps for both loading and saving sets of scenery elements. 
         [0010]    Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. Methods and systems relating to one or more aspects of the present invention are also described and claimed herein. Furthermore, services relating to one or more aspects of the present invention are also described and may be claimed herein. 
         [0011]    Accordingly, it is an object of the present invention to render scenes more quickly and to thus provide the user with a more realistic experience. 
         [0012]    It is also an object of the present invention to trace the evolution of a set of dynamic objects in a metaverse and store them as snapshots to be reproduced as separated scenes. 
         [0013]    It is yet another object of the present invention to create a 3D storyboard from action. 
         [0014]    It is a still further object of the present invention to simulate the evolution of a system in a simulation environment. 
         [0015]    It is also an object of the present invention to provide a system and method for rendering a scenery which is independent of a specific metaverse. 
         [0016]    The recitation herein of desirable objects which are met by various embodiments of the present invention is not meant to imply or suggest that any or all of these objects are present as essential features, either individually or collectively, in the most general embodiment of the present invention or in any of its more specific embodiments. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0017]    The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of practice, together with the further objects and advantages thereof, may best be understood by reference to the following description taken in connection with the accompanying drawings in which: 
           [0018]      FIG. 1  illustrates the structure of commands provided to the Play Manager in relation to the processing of an illustrative scene set; 
           [0019]      FIGS. 2A-2D  is a series of illustrations illustrating the process in which a set of scene elements is saved and stored in a Scene Container; 
           [0020]      FIG. 3A-3D  is a series of illustrations similar to  FIGS. 2A-2D  except that it illustrates the reverse process namely that of loading the contents of a scene container onto a given stage; 
           [0021]      FIG. 4  illustrates the splitting of scene elements into inactive elements and active elements and further provides exemplary illustrations thereof, 
           [0022]      FIG. 5  is a flowchart illustrating the steps in the process of loading a set of scenery elements onto a stage; and 
           [0023]      FIG. 6 . Is a flowchart similar to  FIG. 5  except that it illustrates the process of saving a set of scenery elements in a Scene Container. 
       
    
    
     DETAILED DESCRIPTION 
       [0024]    Before proceeding, some preliminary comments are in order. For the purposes of the present description of scenery can be considered to be everything except the avatars. The stage upon which play takes place can be considered to be either a fixed element existing outside of the scenery or it may in fact be included as part of the scenery, depending upon the specific were playing game be used. In the case that the stage exists outside of the scenery, the stage itself may play the role of the Play Manager. 
         [0025]    The present invention identifies a mechanism and a set of standards which are used to design and implement role playing games. The present invention develops and infrastructure based upon a set of objects and scripts which are used in role playing games. The present invention also defines a process to instruct participants, manages the game and capitalizes on evidence generated during the game. A more advanced implementation of the present invention also “learns” during the performance. For example, a theatre scene is determined to always be rendered in the same way at the beginning of act even if during act some object is moved by actors. However, in a brainstorming session where objects represent a model to be refined, a mechanism is provided to store the position of objects at the end of the act in order to render them in the same position next time that act is performed. This is useful in breaking an action and starting again from where it was left off. 
         [0026]    The present invention is independent of the specific metaverse being imported. In particular, the present invention is not tightly coupled to the architecture employed in Second Life®. However, it is only necessary that the metaverse provides some way to script actions, that is, a programming language to control metaverse objects. This is true for almost all currently developed metaverses. The present invention is open and is not based upon proprietary standards. The present invention is flexible in that it is able to realize any scenario and is not limited by its size. The present invention is also advantageous in that skill and effort needed for setup are minimal. The process of the present invention is simple, easy to learn and easy to teach. The present invention is also manageable in that it is easy to apply it to any given scenario. In addition, specific tools are developed to setup the Play Manager and the Scenery Container without knowledge of a programming language, that is, by using visual techniques “in world.” The term “in world” is used by those skilled in the metaverse arts to distinguish tools that are used while the avatar is inside the metaverse as opposed to tools that are used outside of a metaverse environment and which require that the resulting product be loaded into the metaverse at a later time by an importing mechanism. 
         [0027]    The method of the present invention is based upon two auxiliary objects: the Scene Container and the Play Manager. The method of the present invention is also based upon an event driven object to object protocol which is simple and language independent. In particular, the language structure of the present invention is simple in that it simply comprises a command coupled with a parameter list. It is also to be specifically noted that since many metaverse implementations do not provide an efficient parser for XML, XML is not being employed in a first version of the architecture of the present invention. 
         [0028]    In the present invention, a role playing game is structured as a theatrical play, that is, it is divided into acts and scenes. Every act and scene is numbered and is associated with a specific scenery set. Each scenery set is made up of a number of objects of any kind and shape. The objects in each scenery set may be either active or inactive and they exist within a well-defined space. This well-defined space is typically referred to as the “stage.” 
         [0029]    For the purposes of the present invention, a Scenery Container is an object in the Object Oriented Programming (OOP) sense and includes operational code and a database, file or similar data structure which includes a set of scenery elements described in sufficient detail for purposes of visually rendering them on a screen together with information as to their position, either absolute or relative, and indications as to how these elements change or are modified in response to the passage of time and/or other events. Both Play Manager and Scenery Container are objects in OOP terminology, that is, they comprise data which is encapsulated by methods. In operation Play Manager controls the flow of action in a role playing game or virtual universe and which interacts with the Scenery Container to provide visual information to be portrayed on a screen. 
         [0030]      FIG. 1  provides an illustration of an exemplary scene  100  together with a segment of program code  90  which is used to produce the elements in the scene by means of a visual rendition which is linked to the name of a particular play, a particular act within the play, and a particular scene within the act. The terms “PLAY,” “ACT,” “SCENE,” and “SCENERY” are keywords used to interpret a value, which is usually positioned after the keyword. 
         [0031]      FIGS. 2A-2D  illustrate a process in which elements of a scene on stage  110  are saved within Scenery Container  200  which is linked by play name, act and scene number to be part of a role playing game. In particular, it is noted that the saving progression proceeds from  FIG. 2A  to  FIG. 2D . In the first portion of the process illustrated, cup  116  is saved in Scene Container  200 . See  FIG. 2B . In a second portion of the process, second cup  114  is saved in the same Scene Container. See  FIG. 2C . In a third portion of the process, the table and chairs  112  are likewise stored in Scene Container  200 . Lastly, scenery container  200  is stored with Play Manager  300 . See  FIG. 2D . This latter storage operation does not, however, have to be direct but rather may be accomplished via an external link. It is also noted that, solely for purposes of ease of illustration, the table and chairs are described herein in a monolithic fashion. However, in practice, it is noted that not only would the table and chairs comprise individual scenery elements in their own right, but it is also the case that the table and chairs are typically described within the scenery container as themselves comprising individual subelements. The same is true of cups  114  and  116 . 
         [0032]      FIGS. 3A-3D  illustrate a process which is the reverse of that shown in  FIGS. 2A-2D . In this process, as a first step, Play Manager  300  loads Scenery Container  200 . Such an action may, for example, be invoked by program code  90  shown in  FIG. 1 . See  FIG. 3A . In a second step, Scenery Container  200  renders (that is, visually creates) table and chairs  112 . See  FIG. 3B . In a third step, Scenery Container  200  renders cup  114 . See  FIG. 3C . In a fourth step, Scenery Container  200  renders cup  116 . See  FIG. 3D . 
         [0033]      FIG. 4  illustrates the fact that a scene may comprise both active and inactive elements. For example, an inactive element may comprise a scene wall, as illustrated by element  122  or may in fact also include stage  120 . Active elements may include such items as clock  132 , beating heart in  134  or lightning bolt  136 . 
         [0034]      FIG. 5  illustrates a detailed process for loading a Scenery Container. In this respect, it is useful to keep in mind that this is a process step which is used for structuring the contents of a Scene Container. Moreover, it should be specifically noted that it is this process which facilitates the ease of scene construction by a user and or virtual universe developer. Each of the steps  210  through  240  are also illustrated in greater detail in  FIG. 5 . In first step  210 , a scene that is set for a stage is created. In second step  220  a Scenery Container is placed on the stage. In third step  230  the scenery set is stored in the Scenery Container. In a last step, the Scenery Container is loaded (or otherwise linked to or associated with) the Play Manager. 
         [0035]    In preferred embodiments of the present invention, step  210  includes placing all of the objects on the stage (step  211 ) and activating all necessary scripts (step  212 ). 
         [0036]    In step  220 , the scenery container asks for the name of the play (step  221 ) and the scenery container initializes itself (step  222 ). Initialization includes defining a coordinate system to be used to store relative position and orientation for all of the objects in the scene, and if necessary, to allocate memory. 
         [0037]    In step  230 , the Scenery Container asks for the specific act and scene numbers (step  231 ). The scenery container then scans all of the objects in its inventory (step  232 ). All of the objects that are on the stage are then loaded into the Scenery Container (step  233 ) as part of its inventory of set elements for this particular play act and scene. The objects that were loaded onto stage are now preferably removed (step  234 ). The attributes of the set elements are also now stored in the scenery container (step  235 ). Lastly, the Scenery Container renames itself in accordance with the name of the play, the specific act, and scene number (step  236 ). 
         [0038]    In step  240 , the Play Manager loads the scenery container in its own inventory (step  241 ). The scenery container is then removed from the scene (step  242 ). Lastly, the Play Manager acquires the attributes of the scenery container (step  243 ). 
         [0039]    In effect,  FIG. 6  represents a reversal of the process shown in  FIG. 5 . Broadly this process begins with a request to the Play Manager to load a scene set (step  310 ). Next, the Scenery Container loads the scene set (step  320 ). Lastly, the Scenery Container removes itself and informs the Play Manager (step  330 ). 
         [0040]    Looking at the process illustrated in  FIG. 6  in greater detail, one finds that step  310  typically involves the following set of steps. In step  311 , the Play Manager removes objects from the previous scene. In step  312 , the Play Manager resolves any references to the Scene Container. In step  313 , the Play Manager activates the Scene Container. In step  314 , a copy of the Scenery Container is maintained by the Play Manager. Following this, step  330  is carried out. 
         [0041]    Moreover, one or more aspects of the present invention can be provided, offered, deployed, managed, serviced, etc. by a service provider who offers management of customer environments. For instance, the service provider can create, maintain, support, etc. computer code and/or a computer infrastructure that performs one or more aspects of the present invention for one or more customers. In return, the service provider can receive payment from the customer under a subscription and/or fee agreement, as examples. Additionally or alternatively, the service provider can receive payment from the sale of advertising content to one or more third parties. 
         [0042]    In one aspect of the present invention, an application can be deployed for performing one or more aspects of the present invention. As one example, the deploying of an application comprises providing computer infrastructure operable to perform one or more aspects of the present invention. 
         [0043]    As a further aspect of the present invention, a computing infrastructure can be deployed comprising integrating computer readable code into a computing system, in which the code in combination with the computing system is capable of performing one or more aspects of the present invention. 
         [0044]    As yet a further aspect of the present invention, a process for integrating computing infrastructure comprising integrating computer readable code into a computer system may be provided. The computer system comprises a computer usable medium, in which the computer medium comprises one or more aspects of the present invention. The code in combination with the computer system is capable of performing one or more aspects of the present invention. 
         [0045]    While the invention has been described in detail herein in accordance with certain preferred embodiments thereof, many modifications and changes therein may be effected by those skilled in the art. Accordingly, it is intended by the appended claims to cover all such modifications and changes as fall within the spirit and scope of the invention.