DYNAMIC DATA HANDLING

TECHNICAL FIELD

Implementations of the current subject-matter relate to a computer-implemented method, a system and an apparatus for a virtual environment and in particular to enhancing the user experience by tailoring the virtual environment to the user.

BACKGROUND

It is known to provide a virtual environment mat a user can experience via an arcade station, a computer or other electronic device. Such a virtual world can be downloaded via the internet or an intranet or can be installed on the device from a media such as a disk. It may also be implemented in permanent form as hardware, most usually on an arcade station. When run, the user can experience a virtual world which may represent the real world to a greater or lesser degree. This sort of simulation of the environment around us can be used for many purposes such as game play, social or business networking and as a teaching means. One of the most well-known uses for a virtual environment is in combat-type games but games involving social interaction are also very popular. One of the most well known of these is "Second Life", developed by Linden Research, Inc, which allows players to interact with other user's avatars in a virtual environment. Each user is represented by an avatar such that they can see 'themselves" i.e. their avatar on screen in the environment. Their avatar can be a stock avatar or the user can create it to have certain characteristics. The purpose of this game is social interaction via chats and messaging with other user's avatars, as well as general navigation around the virtual world, although it is possible to make money through in-game transactions.

The design of such games is a complex, highly-skilled task. This is because the characters must appear to behave and move in a real, human sort of way. Thus their physical movement must be such that they interact with fixed objects and other characters in a way that would be expected of a real person. This means that the game engine must include a physics engine, implemented either in hardware or software, that performs calculations to simulate movement of an object, taking into account rigid body dynamics, soft body dynamics, fluid dynamics and collision between objects. The implementation must be in real-time, although for the purposes of a game or other of the uses mentioned above, it need not be as accurate as a high-precision physics engine of the sort used in scientific and movie applications, since the main aim is quick response and perceptual correctness. This is usually achieved by means of a dedicated microprocessor that can process data to make the necessary calculations for movement of objects and people, for example using a mesh representation or by finite element analysis. The microprocessor must also handle softer effects such as hair and clothing simulation.

The appearance of characters, including non-player characters (NPCs) and a user's avatar, can be important for the purposes of simulating social interaction, since a player may choose to interact with characters of a particular appearance, or indeed, may choose the appearance of their own avatar to create a particular impression. Of course sound effects including environmental sound effects and character speech can also be provided to facilitate simulated social interaction. Typically, computer-simulated characters are created either from a stock selection of

characteristics or, in some cases, using a form of artificial intelligence (AI) engine. The creation and behavior of an NFC may be controlled for particular types of interaction with a user's avatar or objects in the environment. The AI used does not have a genuine "learning" ability as performed by high-performance AI engines because the game engine can be queried to provide relevant data, thus bypassing the need to learn to carry out certain reactions to certain types of events. Instead, it provides the illusion of a real person, for example by applying certain predetermined rules to information received such that the character appears to be reacting to events and players' avatars. The output of such rules is applied to a graphics engine such that the user sees the behavior at the graphical user interface (GUI) in the form of visual and or sound effects, including text-based effects.

Whilst the type of NPC described above has advanced the interactive experience for a user, such characters are still limited by the standard, fixed, rules under which the AI engine operates. This limits the level of realism which a user experiences when playing such games and therefore the game can become routine and less interesting to the user. This is a problem in terms of selling further copies or licences of the game and is also a problem for internet-based games which rely on further interaction to generate revenues through on-line purchases or sponsored links and objects. It would be desirable to provide a means for tailoring a virtual environment to a particular user's experience by technical manipulation of the virtual environment that the user experiences.

SUMMARY OF THE INVENTION

According to a first implementation of the current subject-matter, there is provided a computer- implemented method for a virtual environment, comprising: maintaining a profile of the user; enabling a user to engage in a conversation by selecting a branch from multiple branches of a first tier of a conversation tree, each branch belonging to one or more of a plurality of categories; and in dependence on the one or more categories to which the selected branch belongs, selectively updating the user's profile.

The method may further comprise selecting a second one of multiple further tiers of the conversation tree to present to the user based on at least one of the updated user profile and information associated with the selected branch.

Preferably the method further comprises: enabling a user to select a branch from multiple branches of the second tier of the conversation tree, each branch belonging to one or more of a plurality of categories; in dependence on the one or more categories to which the selected branch belongs, selectively updating the user's profile; and based on at least one of the updated user profile and information associated with the selected branch, either selecting a third one of multiple further tiers of the conversation tree to present to the user or terminating the

conversation.

Conveniently the categories are indicated by one or more flags associated with the branches. Further conveniently, updating the user's profile comprises incrementing or decrementing a counter associated with a part of the profile. In this case, the user profile can comprise a database of personality traits, wherein the database comprises at least one pair of entries associated with first and second opposing personality traits and the counter is one of a first and second counter provided in relation to each entry of the at least one pair respectively. The method can further comprise determining the value of the first and second counters, the higher of the two values indicating a bias of the user towards one of the first and second personality traits.

Suitably, the method further comprises creating multiple conversation trees; and storing the created trees in an accessible database. Thus enabling the user to select a branch from a first tier of a conversation tree can comprise: deploying a character to a user's virtual world with which the user can have a conversation; selecting, based on at least a part of the user's profile, a conversation tree from the multiple stored conversation trees; displaying a first character dialogue string of a first tier of the selected conversation tree; and displaying multiple branches of the first tier of the conversation tree from which the user can select a branch.

Preferably, the method further comprises maintaining profiles of multiple users, indexed by a user identification. Conveniently, the user profile and conversation tree are maintained remote from the user and access to the virtual world is via a network.

It is possible for the user's profile to be also updated in response to any one of: achievement of a goal by the user; progress of the user in a social situation; information provided by the user; receipt of a message from another user; purchase of a real or virtual item by the user; and termination of conversation in which user is participating.

Preferably the presenting to the user is implemented using one or more characters, the method further comprising: selecting, based on a user's profile, a character to deploy into the user's virtual world; and controlling the selected character to present to the user a conversation element associated with the first tier of the conversation tree, the conversation element being further associated with a plurality of possible branches for the user to select following the presentation. Thus a character can be created having one of: predetermined characteristics; characteristics having regard to a user's profile; and characteristics based on a user's profile. The characters can be controlled, based on at least one of the updated user profile and a selected branch, to present other types of information to the user, including one of text-based feedback on conversation branches selected; visually-animated feedback on conversation branches selected; a suggestion as to a place to visit in the virtual world; suggestions as to actions to be taken by the user to interact in the virtual world; information on other users ¹ avatars; and information on other user's interactions in the game.

It is possible for the method to further comprise providing an avatar-interface for a user in the virtual environment, wherein the user profile is associated with the avatar and wherein the selecting by the user is through the avatar. According to a second implementation of the current subject-matter, there is provided a computer program product comprising executable instructions which are arranged, when executed to perform operations comprising: maintaining a profile of the user; enabling a user to engage in a conversation by selecting a branch from multiple branches of a first tier of a conversation tree, each branch belonging to one or more of a plurality of categories; and in dependence on the one or more categories to which the selected branch belongs, processing information to enable selective updating of the user's profile.

The operations may further comprise selecting a second one of multiple further tiers of the conversation tree to present to the user, based on at least one of the updated user profile and information associated with the selected branch.

Preferably the operations further comprise: enabling a user to select a branch from multiple branches of the second tier of the conversation tree, each branch belonging to one or more of a plurality of categories; in dependence on one or more categories to which the selected branch belongs, selectively updating the user's profile; and based on at least one of the updated user profile and information associated with the selected branch, either selecting a third one of multiple further tiers of the conversation tree to present to the user or terminating the

conversation. Conveniently the categories are indicated by one or more flags associated with the branches. Further conveniently, updating the user's profile comprises incrementing or decrementing a counter associated with a part of the profile. In this case, the user profile can comprise a database of personality traits, wherein the database comprises at least one pair of entries associated with first and second opposing personality traits and the counter is one of a first and second counter provided in relation to each entry of the at least one pair respectively. The operations can further comprise determining the value of the first and second counters, the higher of the two values indicating a bias of the user towards one of the first and second personality traits.

Suitably the operations further comprise: creating multiple conversation trees; and storing the created trees in an accessible database. Thus enabling the user to select a branch from a first tier of a conversation tree can comprise: deploying a character to a user's virtual world with which the user can have a conversation; selecting, based on at least a part of the user's profile, a conversation tree from the multiple stored conversation trees; causing display of a first character dialogue string of a first tier of the selected conversation tree; and causing display of multiple branches of the first tier of the conversation tree from which the user can select a branch.

Preferably the operations further comprise maintaining a profile of multiple users, indexed by a user identification. Conveniently the user profile and the conversation tree are maintained remote from the user and access to the virtual environment is via a network connection.

It is possible for the user's profile to be also updated in response to any one of: achievement of a goal by the user; progress of the user in a social situation; information provided by the user; receipt of a message from another user; purchase of a real or virtual item by the user; and termination of conversation in which user is participating.

Preferably the presenting to the user is implemented using one or more characters, the operations further comprising selecting, based on the user's profile, a character to deploy into the user's virtual world; and controlling the selected character to present to the user a conversation element associated with the first tier of the conversation tree, the conversation element being further associated with a plurality of possible branches for the user to select following the presentation. Thus the operations can further comprise creating the one or more characters in the virtual world having one of: pre-determined characteristics; characteristics having regard to a user's profile; and characteristics based on a user's profile. The operations can further comprise controlling the one or more characters to present other types of information to the user, including one of text- based feedback on conversation branches selected; visually-animated feedback on conversation branches selected; a suggestion as to a place to visit in the virtual world; suggestions as to actions to be taken by the user to interact in the virtual world; information on other users' avatars; and information on other user's interactions in the game.

It is possible for the operations to further comprise providing an avatar-interface for a user in the virtual environment, wherein the user profile is associated with the avatar and wherein the selecting by the user is through the avatar. According to a third implementation of the current subject-matter, there is provided an apparatus comprising: a user interface module capable of receiving instructions from a user and generating instructions for presentation of information to a user in the virtual environment; a profile database arranged to store profile data relating to the user; a conversation database arranged to store one or more conversation trees each comprising multiple tiers, wherein each tier comprises one or more character dialogue strings associated with multiple branches and wherein each branch belongs to one or more of a plurality of categories; a conversation engine arranged to select a first tier for presentation to the user via the user interface module, such that the user can engage in a conversation by selecting a branch from multiple branches of the selected tier of the conversation tree; and an updating module arranged to, in dependence on the one or more categories to which the selected branch belongs, selectively update the user's profile.

The conversation engine may be further arranged to, based on at least one of the updated user profile and information associated with the selected branch, select a second tier of the conversation tree for presentation to the user and wherein the updating module is further arranged to, in dependence on the one or more categories to which the selected branch belongs, selectively update the user's profile. Preferably the conversation engine is further arranged to, based on at least one of the updated user profile and the selected branch, either select a third one of multiple further tiers of the conversation tree to present to the user or terminate the conversation.

Conveniently the conversation database is further arranged to store one or more flags in association with at least some of the one or more branches, wherein each flag indicates a category to which the branch belongs. Further conveniently, the apparatus further comprises a counter module in communication with a part of the user profile and which can be incremented or decremented by the updating module in accordance with the category to which a selected branch belongs. In this case, the profile database can be arranged to store profile data comprising a table of personality traits, which table comprises at least one pair of entries associated with first and second opposing personality traits and wherein the counter comprises first and second counters for the first and second entries of each pair.

Advantageously the apparatus further comprises a display module arranged to cause display of a first character dialogue string of the first tier of a conversation and of the multiple branches of the first tier. The apparatus can further comprise a character module for creating one or more characters of one or more types : a stock character having predetermined characteristics, created by reference to stored or received information; a user-specific character having characteristics suitable for interaction with the user, created having regard to the stored user's profile; and a user's avatar having characteristics determined by mapping from a user's stored profile.

Preferably the user interface is arranged to provide a created avatar to the user via the user interface module for use in selecting branches, and the profile database is arranged to store profile data relating to the user such that the profile data is associated with the avatar. According to a fourth implementation of the current subject-matter, there is provided a database comprising a conversation tree having multiple tiers, at least one tier comprising one or more character dialogue strings each having multiple selectable branches, wherein each of the multiple branches is connected to a character dialogue string of another tier.

Requests for access to the database and sending of information back to the user's terminal can be secured by one or more of: password protection; and encryption. The computer program product may comprise instructions which, enable requests for access to the database and sending of information back to the user's terminal to be secured by one or more of: password protection; and encryption. The visually-animated feedback may comprise one or more of: facial expressions of one or more of the characters; physical movement of one or more of the characters; and provision of a visual meter indicating a player's level of attainment of a particular attribute.

The providing of an avatar-interface may comprise providing choices to the user regarding the avatar characteristics; receiving user responses to the choices; creating an avatar based on the user's choices; and placing the avatar in the virtual world environment. Aspects of the avatar may be manipulated in response to user inputs, including appearance and particulars of dialogue strings presented. The method or computer program product operations may comprise storing, in association with a user's profile, a conversation or partial conversation in which a user has participated and enabling subsequent retrieval of the stored conversation. In response to a retrieval request, a retrieved conversation may be exported to a platform outside the virtual environment or to another user within the virtual environment. The apparatus may be arranged to perform these actions.

The method or operations of the computer program product may form part of a game played by a user. The apparatus may be used to provide a game or part of a game to be played by a user. BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example only, in which:

Fig. 1 shows an overview of multiple users connected to a computer-implemented apparatus on which a game is run;

Fig. 2 shows diagrammatically a conversation tree as used in the invention;

Fig. 3 is a screen shot showing presentation of multiple conversation responses to a user;

Fig. 4 shows diagrammatically the various contents of a memory associated with the game;

Fig. S shows a visual representation of parts of an exemplary conversation tree, showing examples of flags used in the tree and their connection to an NPC and a player;

Fig. 6 shows a visual representation of details of a user's profile;

Fig. 7 shows a schematic representation of an apparatus on which the game could be stored, run and controlled; and

Fig. 8 is a flow chart showing operation of features of the invention. In the figures, like reference numerals indicate like parts.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

The present invention provides a virtual environment in which a user can interact with features and characters in the virtual environment. In the particular embodiment described, the virtual environment is a social game environment but the technical manipulation to suit the user would be equally applicable to other types of virtual environment, for example training for other activities involving social interaction such as for teaching or business purposes. In the described game, the general challenge of the game is for the user to improve their social interactions by making choices when interacting with other characters, and then receiving an indication of the consequence of the choices made. Thus a user can learn that certain choices are good and certain choices are bad and hence improve their social interactions. In technical terms, this process is assisted by dynamic control and updating of the game in dependence on the choices made by the user and other characteristics of the user. Figure 1 shows a high-level view of a system 1 within which the game is delivered to user devices. There are shown three exemplary user devices: a personal computer 2, a mobile device 4 and a tablet 6. These devices are merely exemplary and it will be understood that the game can be ported to similar devices, provided they have a suitable client application to provide a viewer and to enable connection to some sort of network via which they can receive the necessary data. In this embodiment the network used is the internet 8 but other types of network such as an intranet could be the transport medium. An apparatus 10 is provided on which the core computing operations of the game are run and from which the necessary data is sent to users via the internet 8. Thus the apparatus 10 acts as a server which can communicate with multiple user devices and run an independent game for each user. However, an aspect of the invention allows data sharing between the independent games, as will be explained below.

The apparatus 10 may in practice comprise multiple servers to enable large numbers of user devices to run the game. The apparatus 10 is shown as having a separate memory 12 as this may or may not be in the same physical location as the apparatus 10. It will be appreciated that the memory 12 could be incorporated in the apparatus 10. It will further be appreciated that the memory 12 could be provided by multiple memories which may be in different physical locations. It will be understood that the apparatus 10 is able to port the game to multiple user devices and that this is not limited to the number or type shown in figure 1. The game may be run as a direct download on the device or, alternatively, may be accessed when the user is connected to an existing social network such as Facebook. In other words, the game can be accessed via a link provided within the Facebook or other website. In this case the user's device will be a "thin" client merely providing the visible on-screen graphics and user interface, whilst any local processing is done by the Facebook website. This access method could be applied to any user device on which the game is being played but is particularly advantageous when the user device has limited storage, such as in a mobile telephone. The game of this embodiment is a social role-playing game about personal relationships. One aim is to enable players to develop relationships with on-line characters, which may or may not represent real people. The game includes challenges, particularly challenges to improve one's ability to interact successfully with other people (in the form of on-line characters). Players are rewarded in dependence on their level of attainment, either with various points systems or by gaining the ability to acquire virtual or non-virtual items.

The game includes a visual backdrop designed to simulate a real world environment and therefore comprises various locations. Some locations are outside and can be particular towns or cities or locations of interest. The location may include one or more streets or the outside of a particular building such as a cinema. Other locations are inside particular rooms or buildings, for example the inside of a bar or a character's house.

The game also includes various NPCs. These may be characters purchased from a third party and imported into the game. However, in view of the nature of the game, most of the characters are custom-designed to provide a wide variety of appearances and personality types of both genders.

Such a virtual world and characters were created for this embodiment using 3d Studio Max and Character Studio software provided by Autodesk Media and Entertainment. Static images and the GUI were created using Adobe's Photoshop and After Effects. It will be understood that the backdrop and characters could be created by other means and other software.

In this embodiment the game was developed on the 3D Unity Professional game engine provided by Unity Technologies. This engine assists development of the technical aspects of a game by providing short-cuts to full programming for creating certain graphic effects. For example, it supports a physics engine to provide the game developer with a means for character movement and collision. It allows integration with the above-mentioned world and character-creation engines and enables the game to be run.

In operation, a user is represented by an avatar, which the user can customize themselves as is known in the art. This customizing can be done when the user joins the game for the first time and also at other times should the user desire. A user may choose to customize his or her avatar to represent his or her own appearance and personality or it may be quite different from the actual user.

As mentioned above, other characters are used in the game and appear to the user from time to time. These characters may be commercially-available characters which can be purchased or licensed and then written into the game. However, one feature of this embodiment of the invention is to provide characters which are custom-designed. These fall into three types:

• Stock characters - these are custom-designed but do not vary in appearance or general personality. Multiple such characters are available in the game and are designed to have a variety of appearances. The game engine can control deployment of these characters to the individual game of a particular user but they are characters that can appear in the individual games of all users e.g. the bartender of a particular bar. Such characters are apprised of information about multiple users, such that they can inform one user about something relating to another user e.g. that the other user's avatar visited the same cinema as the user is currently in. They can also provide visual or text-based information to a user to advise the user how they are doing or have done in a particular virtual world situation and suggest to the user places to visit, items to purchase etc.

• User-targeted characters - these are custom-designed for interaction with a particular user. Thus their appearance and personality may be chosen to appeal to a particular user or to provide the user with a particular type of interactive experience. Details of how this is achieved will be provided below.

• User-based characters - these are custom-designed based on characteristics of a particular user. Thus their appearance will reflect information on a user's appearance that the user has provided to the game and their personality will reflect that of the user. Details of how the personality is captured will be provided below. Such characters can be deployed by the game engine into the individual game of another user in order to simulate an interaction between two real-life users.

Thus it can be understood that a user will experience the visual and audible backdrop features of a virtual world and during gameplay will come across various of the above-described characters. This enables conversations between the characters, which in turn enables the inventive dynamic adjustment of the game, as will now be described.

Figure 2 shows diagrammatically an exemplary conversation tree 14 which is used in operation of the invention. The tree 14 comprises multiple tiers 16. The first tier resides at the top of the tree and is labeled 16a, the second tier sits beneath it and is referenced as 16b. In this

embodiment the tree 14 has 5 tiers descending down the page, and thus 16e is the final tier, signifying multiple endings to a conversation. However, it will be appreciated that the conversation tree could have a different number of tiers.

As can be seen in figure 2, each tier comprises a prompt 18, all of which are depicted as numbered circles (two are labeled by way of example) and one or more branches 20 (several are labeled by way of example) emanating from the prompt 18. The prompts 18 represent a dialogue string presented to the user by a character. The branches 20 represent possible responses to each prompt 18. In this embodiment, each prompt 18 has four branches 20 emanating from it, which represent four possible user responses to the prompt 18.

The first tier 16a of the tree 14 is an initial prompt by a character of one of the types described above. The prompt is represented on a GUI, for example as a speech bubble associated with the character. This tier gives rise to four branches, 20a, b, c & d. These branches are response options and also appear to the user on screen in the form of text, for example in speech bubbles. An exemplary screen shot of this is shown in figure 3, in which a character 22 which presented the prompt is still visible to the user in one region of the screen and the four prompts 20a, b, c & d are shown, each in its own speech bubble, in another region of the screen. It will be appreciated that the layout of the screen could be varied as desired.

It will be noted in passing that the face of the user's avatar 24 is visible in one corner of the screen and also that, "behind" the speech bubbles a rear view of the user's avatar can be seen, positioned to appear to be having a conversation with the character 22.

Referring back to figure 2, if the user selects either of the first two branches 20a or 20b, the next prompt 18 is number 2 on the left hand side of the second tier 16b of the tree. If the user selects either of the second two responses 20c or 20d, the next prompt 18 is number 3 on the right hand side of the second tier 16b of the tree. Thus the chosen response can lead to one of two next character prompts 18. Following selection of a branch by the user, the next character prompt will be displayed on screen, for example as a speech bubble emanating from the character 22. The next tier of the tree has three possible prompts 18. If the user received prompt 2, he would then be shown four response options 20e, f, g or h to prompt 2. If he chooses the first one 20e, the next prompt is number 4 on the left hand side of the third tier of the tree. If he chooses either the second or third response 20f or 20g, the next prompt is number 5 in the middle of the tree. If he chooses the fourth response 20h, the next prompt is number 6 on the right hand side of the tree.

Similarly, if the user received prompt number 3, he would be shown four different response options, which also lead to prompt numbers 4, 5 or 6.

From prompts 5, 6 or 7 there are four possible prompts, numbers 7, 8, 9, 10, that the user can be navigated to in dependence on the response chosen. Hence each of the prompt numbers 5, 6 and 7 has a branch connection to each of the four prompt numbers 7, 8, 9, 10. The final tier of the tree has five prompts, numbers 11, 12, 13, 14, 15 but any one of prompt numbers 7, 8, 9 and 10 can only lead to four of these five prompts because the user is still given four possible response options. Prompt numbers 7 & 8 are connected to prompt numbers 11, 12, 13 & 14 and prompt numbers 9 & 10 are connected to prompt numbers 12, 13, 14 and 15. The prompts 18 are arranged such that the more skillfully a user chooses his responses, the closer to the left hand side of the tree the user will be navigated. Thus the best place for the user to end up is at prompt number 11 and the worst place is at prompt number 15, prompt numbers 12, 13 and 14 representing a sliding scale downwards of desirable conversation outcomes. However, because of the arrangement of the tree, in which branches 20 emanating from different prompts 18 may lead to the same next prompt, even if a user starts off with unskillful responses, it is possible to navigate back towards the left hand side of the tree if the skill level of the response chosen improves during the conversation. Equally a user that starts with skillful responses may become less skillful as the conversation progresses and thus head towards the right hand side of the tree. Regardless of the user's response skill level, each of the prompt numbers 11-15 terminates the conversation.

The game comprises multiple conversation trees which can be deployed to a user. This arrangement is described further below. The skill level of a user's response choices can be based on various criteria. One such criteria is how the response choices fit into a particular Myers-Briggs personality type. The Myers-Briggs psychometric test aims to put people into one of a number of personality categories in accordance with their psychological preferences. The test identifies four opposing pairs of personality traits, as set out in Appendix 1. The various possible combinations of these eight traits, gives rise to sixteen possible personality types, each represented by four letters, where each letter represents the stronger of an opposing pair of the four pairs of personality traits. For the purposes of the game and by way of example only, sixteen pairs of characters have thus been named as each representing one of these personality types, a male and a female forming each pair. An explanation of these characters is set out in Appendix 2, together with an indication as to compatibility with other personality types.

Thus it can be understood that the user-targeted characters mentioned above can be created to reflect one of the sixteen personality types, although of course this is not essential. At a minimum it is desirable to provide 32 user-targeted characters, a male and a female of each personality type. Of course, it is possible to have more than this number of characters with each personality type, having different appearances. It can further be understood from Appendix 2 that a skill level of the user's responses can be assessed based on their compatibility with the Myers-Briggs personality type of the NPC with which the user is in conversation.

The dynamic nature of the game is facilitated by an on-going assessment of a user's personality type, based on the same Myers-Briggs criteria. This is achieved by an on-going analysis of the responses 20 that the user chooses within the conversation trees 14 that he or she participates in. In order to facilitate the analysis, the branches of the conversation tree are categorized in association with flags. The structure and operation of the conversation trees and flags will now be explained. Whilst a conversation tree has been represented diagrammatically in figure 2, the multiple conversation trees 14 are in practice stored as multiple text files in a database. Associated with each response 20 is a pointer as to which prompt to go to next, although this can be overridden, as will be explained by way of example below. The various flags are also stored as menus in a database so that they can be added to conversation trees before or during running of the game. There is a further database storing a profile of each user, in this particular embodiment, referenced by their Facebook ID, although this is not essential.

Figure 4 shows an overview of the various databases within the memory 12, which in practice may be implemented as relational databases. There are multiple conversation trees 14a, 14b....l4n. There are multiple NPC character files 88 Char #1, Char #2 Char #n. There are multiple player files 86, which may in practice be stored as multiple rows of an Access database,

User #1, User #2 User #n. Finally, there are multiple flag types 84, each of which may comprise multiple flags. Each type of flag is represented by one file, with sample flag formats shown. Various permanent and dynamic associations exist between some of these databases but these are too numerous to show in the figure. Permanent connections exist to store the history of a user's game play, for example, a user may have interacted with several NPCs and a record of this, together with any conversations held between them, is stored. It is also desirable to store a record of which conversation trees 14 have been presented to each user so that the user's interest can be maintained by always presenting them with a new conversation that they have not participated in previously. Dynamic associations are created as the game is played, as will be explained in more detail below.

The possible flags used in this embodiment are set out in more detail in Appendix 3. The flags are written into the game in particular locations so that a particular action may be taken as appropriate. Various of the flags can be associated with the conversation trees, the NPC files and/or the user files. The flags are explained under nine different headings, each of which indicates a type or sub-type of flag (for example, there are several different sub-types of game state flags). Different types of flag can be used to categorize user responses and for other purposes. Appendix 3 refers in some places to the likes and dislikes of NPC characters and their feelings to user-selected responses - these parameters are determined based on the personality type on which an NPC is based and a presumption about how a real person of that personality type would react. Some examples of use of these flags will now be explained.

A sample of some of the possible connections between some of the databases and files in the memory 12 is shown diagrammatically in figure 5. This figure shows part of the first conversation tree 14(1), specifically the first tier 16a and parts of the second tier 16b and the fifth tier 16e. Also shown is a data file representing character number 20, Jan (see Appendix 2) and a user profile for a first user (#1).

The first tier of the conversation tree is represented by a table 26a in which the first column 28 is an identifiable and searchable text file for the first prompt and the possible responses 20a-d. The actual text is not shown but it will be appreciated that e.g. "Response 20b" indicates a text string of the actual words shown in a speech bubble as visible to the user plus an ID string that is used to identify the response. Associated with the Response 20a is the number 2 in a pointer field 29, indicating that the next prompt to go to if the Response 20a is chosen is Prompt 2 of the second tier 16b of the conversation tree 14(1). Emanating from the Response 20a is an arrow 30, which represents a pointer and this leads to "Prompt 2" of the second tier 16b of the conversation tree 14(1), in accordance with the designation in the pointer field 29 for the Response 20a. The second tier 16b of the conversation tree is represented by a second table 28. Similarly, the number 2 is also shown in the pointer field 29 as associated with the Response 20b, since, as can be understood from figure 2, this is also the next prompt following selection of the Response 20b. Thus a second arrow 32 emanates from the Response 20b, and also represents a pointer to "Prompt 2" of the second tier 16b of the conversation tree 14(1). In practical terms, the tables 26a and 26b will be relational databases, linked by a pointer system, as is known in the art.

Arrows 32 and 34 respectively are shown emanating from the Responses 20c and 20d respectively. These represent pointers to the Prompt 3 of the second tier 16b of the conversation tree but the table representing this part of the second tier 16b is omitted for clarity. However, arrows 32 and 34 provide an indication of the destination of pointers associated with this prompt.

A table 26c is shown to represent the Prompt 11 of the fifth tier of the conversation tree 14(1). Since this is one possible end to the conversation, no responses are listed in this table. The data file representing the female character J is shown as having various fields. The first field is the name of the character, Jan. The second field is a flag that indicates her occupation. The next four fields show which of the Myers-Briggs personality trait pairs she has been created to have and the fifth field shows an emotion that she can display i.e. an indication to alter the facial expression and body language of the character, Jan, in certain circumstances. It will be appreciated that there could be many other fields in such a data file, including fields representing aspects of her appearance, but these are omitted for clarity.

Part of a database in which the profile of the user #1 is stored is shown as having a number of fields. These are Facebook ID (used to identify the user), gender, age, personality type, skills, likes, dislikes, NPC relationships and game stage reached. It will be appreciated that there could be many other fields in such a data file, some of which could relate to further information provided by a user, but these are omitted for clarity. One important set of data which is stored in the user profile, although this is not essential to the invention, is data relating to the user's avatar as custom-designed by the user.

The remaining fields of the tables 26a-c are filled with various flags or remain empty. These flags are shown purely by way of example and it will be appreciated that different flags could be used in different locations and in different quantities associated with each Prompt/Response. The exemplary flags shown have the following effects:

• The Prompt 1 is associated with the flag «UP_TS_actress». This type of flag is explained in section 4 of Appendix 3 and indicates than NPC character number 20, Jan (see Appendix 2) has been created to be an actress. This information is stored in the associated profile of Jan and can be woven into a prompt of a conversation if desired. The connection is shown by an arrow 36 from the second field of Jan's character file to the row of the table 26a in which the Prompt 1 is stored, such that a mention of Jan being an actress can be included in the Prompt 1.

• The Response 20a is stored in association with three flags, «UP_PT_I», «UP_PT_J» and «UP_PT_K». Thus this response is put into three categories, all of which are personality-related. This means that if the Response 20a is chosen by the user #1 during the conversation 14(1), these flags are implemented in the profile of the user #1. The initiation of this implementation is indicated by an arrow 38 from the row of the table in which the Response 20a is stored to the "Personality Type" field in the user #l's profile table. This type of flag is explained in Section 3a) of Appendix A, from which it can be understood that they indicate a personality trait. Thus the last letter indicates one of the eight types of Myer-Briggs personality traits. Details of the updating of the profile of the user #1 in response to these flags will be explained below with reference to figure 6.

• The Response 20b is stored in association with the flag «UP_humor». Thus this response is designated as belonging to one category. This type of flag is explained in Section S of Appendix 3 as representing one of a number of skill attributes of the user #1 , in this case "humor". An arrow 40 runs from the Response 20b to the "Skills" field in the user #1 's profile. Thus in the event that the user #1 selects the Response 20b, this flag is used to add the skill of "humor" to that field in the profile.

• The Response 20c is stored in association with two flags, «UP_LIKE_14» and «gs_info» and thus belongs to two categories. The first of these is of the type described in Section 7 of Appendix 3 and is used as an indication that a user who selects this prompt likes Cooking and Dining. Thus an arrow 42 is shown connecting the location of the table 26a in which this flag is stored to the "Likes" field of the profile of the user #1. The second of these flags is a game state flag, as detailed in Section 8 of Appendix 3 and indicates that there has been an exchange of information between the user #1 and the NPC Jan. An arrow 44 is shown linking the location of the table 26a in which this flag is stored to the "NPC relationships" field of the profile of the user #1. Thus if the response 20c is selected and the flag is therefore triggered, a connection is created between the character Jan and the profile of the user #1 to indicate that they have exchanged information.

• The Response 20d is stored in association with the flag <UP_DONT_22». Thus this response falls into one category. This flag is of the type described in Section 7 of Appendix 3, as indicating a user who does not like animals. An arrow 46 runs from the location of the table 26a in which this flag is stored to the "Dislikes" field of the profile of the user #1. The Response 20e has two flags stored in association with it, «GS_LO_l l» and «gs_date». The first of these is of a type described in Section 1 of Appendix 3 and indicates an override of the pointer associated with the Response 20e. In the absence of this flag, a pointer associated with the Response 20e would point to Prompt number 4 of the conversation tree 14(1) and this is the next prompt that the user would be shown if he selects the Response 20e. However, the «GS_LO_l l» flag signifies an override to this pointer such that the next prompt presented to the user is the Prompt number 11, which, as can be seen from figure 2, is a terminating prompt. In this particular case this override is used because selection of this Response indicates a high skill level of the selecting user in directing the conversation in a positive way. Thus the user successfully arrives at the best final result for the conversation 14(1), bypassing the need to progress through each tier of the conversation tree 14(1). The second flag is another example of the type described in Section 8 of Appendix 3 and indicates that this response has generated a future virtual meeting between the user and the NPC character with which they are in conversation. Both these flags are shown connected to the profile of the user #1 by an arrow 48, directed to the "NPC Relationships" field of the profile.

The Response 20f has no flags associated with it and therefore is categorized as not causing any updating of the profile of the user #1.

The Response 20g is categorized by the flag «UP_DONT,7» stored in association with it, which indicates a dislike of TV. This flag is shown connected to the "Dislikes" field of the profile of the user #1 by an arrow SO.

The Response 20h has the flag «GS_HO_10» associated with it. This response is thus in contrast to the Response 20e because it indicates a poor selection on the part of the user as being incompatible with or even offensive to the NPC, in this case Jan. This flag also overrides a pointer associated with the Response 20e which would ordinarily direct the conversation to the Prompt number 6. Instead, this flag directs the conversation to the Prompt number 10, thus skipping the third tier 16c of the conversation tree 14(1). This flag is shown connected to the "NPC Relationships" field of the user #1 's profile by an arrow referenced as 52. • The Prompt 11 has two flags stored in association with it. The first of these is GS_S2, which indicates that the user has completed stage 2 of the game. The stages of the game can be delineated as desired but typically include a requirement to attain a particular level of multiple parameters. For example, a player will be awarded points in dependence on their skill at selecting "good" responses from the selections offered and for establishing themselves in the virtual community. Some examples of these can be viewed in figure 3, towards the top of which are shown meters for "energy", "level" and "hugs". The meters are visible indications of a number of points gained in each of these parameters. The "level" meter represents the stage that a player is currently playing in, whilst the "hugs" meter represents the skill that they have attained during conversational interactions. The

"energy" meter represents the quantity of game-specific currency that the player currently possesses - this currency is awarded for certain actions and or can be purchased with real money. The game can be arranged to progress a user to the next stage or level when certain values of such parameters have been attained, or on the basis of other requirements. The second flag is «gs_over» which indicates the end of the conversation. All prompts in the 5 ^th tier of a conversation tree carry this flag so that the conversation can be terminated. As an alternative, this flag could be placed in one of the branches in the previous tier 16d, such that the conversation finishes with a user response. A connection between the Prompt 11 in the table 26c is shown by an arrow pointing to the "Game Stage" field of the profile of the user #1.

Thus it can be understood that the user's profile can be selectively updated in dependence on whether a chosen response is categorized by having any or no flags associated with it. The specific nature of any updating is dependent on any particular flags that are associated with it.

It will be understood that the above-described exemplary flags can be used differently from the examples shown. For example, the override flags (e.g. «GS_LO_X») could alternatively be used to stop a conversation from terrninating. If placed with, say, one of the responses 20 to the Prompt 9, an override flag could be used to go back to, for example the Prompt 6, so as to give the user #1 a prolonged opportunity to engage with the character, Jan.

Another example is the flags exemplified above by «JP_TS, actress» i.e. the text string flags described in Section 4 of Appendix 3. These flags could carry a name of a place or person (e.g. an NPC or a real user), stored with the character file of an NPC to indicate that that NPC should mention the particular place in a prompt. Thus more than one NPC can use a same conversation tree with merely the name place customized to the particular NPC for that prompt. Furthermore, multiple conversation trees 14 can be stored, which differ only in a specific location or name mentioned in one prompt or response. Alternatively, a particular place or person name can be put into a conversation in dependence on a particular name stored with an NPC or in a user's profile. The required word can be stored as a text file, together with an indication as to the conversation or NPC to which this word relates and where it is to be used.

Figure 6 shows again the profile of the user #1, in an expanded format which shows sub-tables for some of the fields in the basic profile as shown in figure S. The expansions shown are purely exemplary and diagrammatic and it will be appreciated that other fields could be provided in the user profile and that various sub-tables of various formats could be associated with some or all of the fields.

In particular, figure 6 shows in more detail the "Personality Type" field associated with the user #1. This table includes eight counters 56, one provided for each Myers-Briggs personality trait i.e. E, I, S, N, T, F, J and P. For each of the eight personality traits, its respective counter 56 indicates the score that the user #1 has attained in that trait. These counters 56 are incremented or decremented in response to a user selecting a response that carries a "personality-related" flag of the type set out in Section 3 a) or b) of Appendix A. Examples of these flags are shown in figure 5 as being associated with the Response 20a, as explained above. The final row 58 of the table shows which of the two personality traits of each pair currently carries the higher score attributed to the user #1. This row 58 thus indicates four of the eight personality traits, and thereby its fields together indicate which of the sixteen Myers-Briggs personality types the user #1 is currently considered to belong to. It can be understood that the final row 58 of the "Personality Type" table is dynamically adjusted each time the user #1 selects a response which carries a personality-related flag. Such a flag could have the format as shown in Section 3 of Appendix 3 of either format a) or format b). As shown in figure 6, the current personality type of the user #1 is ESTP (equating to personality I) and this is the type contained in. the current profile of the user #1 as current following their latest response selection. A historical record of personality types that a user has migrated through can also be stored if desired.

The next field of the user #1 's profile shown in figure 6 is the "Skills" field. The view shown in figure 6 reflects the latest skill which would be acquired should the user select the Response 20b. Thus this field contains a sub-field for the skill "humor" and a numerical field associated with it. Each time the user selects a response which is associated with a «UP_humor» flag, this numerical field is updated. Equally, further sub-fields are created or populated and stored as part of the user profile each time a user selects a response associated with another «UP_X» flag. A numerical field representing a count for instances of display of each skill is also created and populated in association with each sub-field. Thus in practice the "Skills" field will contain multiple sub-fields, each with a corresponding counter.

The next field of the user #1 's profile shown in figure 6 is the "Likes" field. The view shown in figure 6 reflects the latest hobby/interest which would be included in this part of the profile should the user select the Response 20c. Thus this field contains a sub-field for the interest "Cooking-Dining" (interest number 14). Again, this field would likely, after the user has been playing the game for a while, contain multiple sub-fields, one for each "like" that has been indicated by selection of responses carrying a flag of the type «U_LIKE,X». Thus this field can be added to as the user participates in further conversations.

The next field of the user #1 's profile shown in figure 6 is the "Disikes" field. The view shown in figure 6 reflects the latest hobby/interest which would be included in this part of the profile should the user select the Response 20d and the Response 20g. Thus this field contains a sub- field for the interests "TV" (interest number 7) and "Animals" (interest number 22). If only one of these responses were selected, only one corresponding field would be populated. Again, this field would likely, after the user has been playing the game for a while, contain multiple sub- fields, one for each "dislike" that has been indicated by selection of responses carrying a flag of the type «U_DONT,X». Thus this field can be added to as the user participates in further conversations.

The last field of the user #l's profile shown in figure 6 is the "NPC Relationships" field. In figure 6 this field has a sub-field for the NPC character Jan. Associated with the name Jan is a first entry 60 which has been populated in response to the user selecting the Response 20c and indicates that the user and the NPC Jan have exchanged information. In this case the information exchanged was that the user likes interest number 14. The entry 60 could either be populated with this specific information or have associated with it a link to either the corresponding field in the "Likes" section of the user profile and/or to the relevant flag in the flags database. Further associated with the name Jan is a second entry 62 which has been populated in response to the user selecting the response 20e. This entry indicates that the user and Jan have agreed to go on a virtual date and this information can be accessed to implement the date in the future. The final entry 64 is a status of this information and in this case is shown as "current". The "NPC relationships" field can maintain a record of historical interactions between the user and NPC characters and the final entry 64 could alternatively be recorded as "historic" i.e. "not current" as appropriate.

It will be understood that figure 6 shows possible updates to the various fields of the user's profile, should the user select particular responses. It will be further understood that in reality, when participating in a single conversation, not all the responses can in fact be chosen and thus at the end of the conversation 14(1) the fields would not all be updated as shown in figure 6. However, the fields shown are updated through multiple conversations in accordance with particular responses chosen and the examples shown can be extrapolated to understand this principle. It should be noted that in this embodiment the user selects responses such that it appears that his avatar is selecting the response, although this is not essential for operation of the invention.

Turning now to figure 7, the apparatus 10 and its connections to the memory 12 are shown in more detail. This is a schematic representation of some of the components which could form part of a server on which the game is run and the necessary data processed and stored. It will be understood by those skilled in the art that the various components shown could be arranged differently and/or have a different arrangement of connections between them and could have a degree of overlap in their functions but they are shown as various modules to aid understanding of the processing of data involved in implementing features of the game as described above. It will also be understood that various of the features described could be implemented in hardware or software or a mixture of both. Within the apparatus 10 on the side which can be understood rom figure 1 as being representative of the connection to the network 8, there is shown a user interface module 66. This has three connections within the apparatus 10, to a conversation engine 68, a display module 70 and a controller 72. The conversation engine 68, the display module 70 and the controller 72 are also all connected to each other. The controller 72 comprises a processor and has a local memory 76 available to it The controller 72 is further connected to an updating module 78, a counter module 80 and a character module 82. The conversation engine 68 is connected to the updating module 78. The updating module 78 is connected to the counter module 80. In the memory 12 are shown the conversation trees 14, the flags database 84, the user profile database 86 and the NPC characters database 88, as shown in more detail in figure 4. All four of these items are all connected to each other. As explained with reference to figure 4, the memory 12 is shown as separate from the apparatus 10 but could form part of it if desired.

There are various connections between the apparatus 10 and the memory 12, The conversation engine 68 is connected to the conversation tree database 14 and the NPC characters database 88. The updating module 78 is connected to the player profiles database 86. The character module 82 is connected to the NPC characters database 88.

In operation, the apparatus 10 has the central controller 72 to manage all the various operations and the other modules and carry out data processing. As is known in the art, the controller 72 optimizes running of the apparatus 10 to process and transfer data in an efficient manner. For example, the controller can schedule operations in order of importance in response to requests from the various other modules. It is likely that the various modules will have some coding and decoding functionality but the controller 72 is used for any major processing. The controller 72 may make use of the local memory 76, which comprises RAM and/or cache memory, for storing blocks of data to be processed.

The user interface module 66 acts as the means by which data and instructions are sent out to a user over the network 8 and by which user input is received. The user interface module 66 is capable of receiving and transmitting data associated with a plurality of players at any one time or at multiple times. The data can be segmented for transmission and reassembled such that data streams associated with multiple users can be interleaved, as is known in the art.

The user interface module 66 receives data and instructions from the conversation engine 68 regarding conversations to present to the user and is able to receive and decode selections received back from the user and pass those to the conversation engine 68 for processing. The user interface module 66 also receives data and instructions from the display module 70 as to what to send out to the users for display. This data and instructions can be used by a display driver on the user's local terminal to display the backdrop to the game, the characters and the conversation bubbles etc. The display module 70 receives data and instructions via the controller 72 but may also receive information directly from the conversation engine, regarding conversations to be displayed.

The conversation engine 68 operates in conjunction with the conversation trees database 14 and the NPC characters database 88. The conversation engine 68 carries out some or all of the following functions:

• Retrieval of conversation trees to present to users

• Retrieval of NPC data for deployment of NPC characters into players' worlds

• Instructing the user interface module 66 regarding presentation of tiers from conversation trees

• Instructing the display module 70

• Receiving data from the user interface module regarding a response 20 selected by a user and analyzing the response 20 to determine whether it is categorized by one or more flags

• Instructing the updating module 78 to update a part of a user's profile based on the analysis results on data received from the user interface module

• Overriding the pointers within the conversation tree to re-direct the conversation to a different tier should the analysis reveal a flag of the override type as described in Section 1 of Appendix 3 • Instructing the counter module 80 regarding updating of "Personality Type" and "Skills" fields of user profiles. It will be understood that having a counter module in the apparatus 10 allows the updating of this aspect of the user profiles, however the current result of such updates can be stored in the profiles database 86. · Storing new conversation trees in the conversation trees database 14 should new ones be required during running of the game.

Selecting a conversation tree to present to a particular user. This may be done by a randomized selection from the conversation tree database 14 and/or with reference to the historical record stored with the user's profile as to which conversation trees have previously been deployed to the user. For example, it may be desirable to select a conversation tree that the user has not been presented with before, so as to maximize the user's enjoyment of playing the game. Other aspects of the user's profile could also be used to select a conversation, for example selecting those which might appeal to a user of a particular age. It is important that integrity of the data stored in the memory 12 is maintained and so an encryption is used between the conversation engine 68 and the memory 12 to avoid hacking of the data. Similarly, such precautions are taken between the counter module 80 and the profiles database 86, as well as between the character module 82 and the NPC database 88. This is particularly important if the memory 12 resides off- site from the apparatus 10.

Further, figure 7 shows a connection between the counter module 80 and the updating module 78 - this enables the counter module 80 to pass the results of counter increments and decrements to the updating module 78 for the updating module 78 to carry out the actual user profile updating.

The character module 82 is used for creating NPCs and arranging storage of NPC data in the NPC database 88. Should new characters be created during the game, the character module can instruct storage of the data details of such characters. In view of the fact that the NPC database 88 is connected to the user profiles database 86, user-targeted characters can be created with the data profile of a particular user in mind, for example for particular compatibility with a user. This could be done by querying the Personality Type field of a user's profile and creating an NPC of a compatible personality type, and/or with reference to other fields of the user's profile such as Likes and Dislikes. Such characters can then be deployed into the virtual world of that user. Equally, the user profile information can be used to create a user-based character having characteristics modeled on a particular user. Again, such characters can then be deployed into the virtual world of another user, allowing that user to interact with a character that represents a real other user. Finally, the character module 82 controls deployment of stock characters into users' games. This can be done in conjunction with access to the user profiles database 86 so that such stock characters can be arranged to inform one user about a character's previous actions within the virtual world. These types of interaction are in real time for the user to whom they are being presented and are implemented using stored data. Thus the user experiences an illusion of real time interaction with another player but in fact reported actions about the other player could have happened many hours previously.

Referring now to figure 8, an exemplary process in accordance with the invention is shown. The process begins at step 90 and can start with one of two processes. If the user is new to the game he or she opens a new account to register with the game (step 90a). If the user is an existing user he or she logs back into the game having been logged out (step 90b). At step 92 the user provides basic personal information. This is either for the purposes of secure login of an existing user (step 92b) or for a new user to provide information to allow creation of an account (step 92a). At step 94, an account is created for a new user and a corresponding profile created in the profile database 86 (step 94a). For an existing user the user profile is amended to store a record that the user has logged in at the date and time in question and, if appropriate, to update user details should they have changed.

The two initial branches merge at step 96 where an NPC is deployed to the user's virtual world. Of course many other things may also happen, for example asking the user where he or she would like to go or offering items for sale etc. At step 98 a conversation tree is selected and the first tier of the selected tree is presented to the user. It should be understood that the 'Tirst tier" may not necessarily be the first tier as shown by way of example labeled as number 1 in figure 2. The term "first tier" refers merely to the first tier presented to the user and it may or may not be the first tier as stored in the file for that tree. In other words, it could be decided to start the conversation at a different tier and furthermore, the actual storage arrangement in memory of a tree should not be considered to be limiting on a tier presented. At step 100 the user selects a response 20. The conversation engine 68 then analyzes the response to determine whether or not it has a flag associated with it.

If the response is not characterized by a flag (step 102), the next prompt is presented to the user at step 104. At step 106, the conversation engine 68 determines whether the presented prompt is flagged as a conversation end (e.g. prompts 11, 12, 13, 14 or 15 in figure 2). If not, the process loops to step 100 where the user selects a response. If it is flagged as a conversation end, the conversation terminates at step 108. However the process continues at step 110 to determine whether or not the user is still logged in. If not, the process ends at step 112. If the user is still logged in, the process loops back to step 96 and either the same or a different NPC is deployed to interact with the user. Step 96 may occur after some time delay, for example if the user is busy with other activities e.g. travel or purchasing activities.

If, on the other hand, the response selected at step 100 is characterized by one or more flags, the user profile is selectively updated accordingly at step 114. This is done in the manner explained with reference to figures 5, 6 and 7. At step 116 the conversation engine determines whether one of the flags is an override flag. If not, the process loops to step 104 where the next prompt as indicated by the pointer in the conversation tree database is presented to the user. If one of the flags is an override flag, at step 118 the conversation engine overrides the pointer at step 118 and then the next step is to determine whether the prompt which is now to be presented is flagged as a conversation end (step 120). If not, the process loops back to step 100 where the user provides a response. If the prompt is flagged as a conversation end, the conversation terminates at step 122. However the process continues at step 124 to determine whether or not the user is still logged in. If not, the process ends at step 126. If the user is still logged in, the process loops back to step 96 and either the same or a different NPC is deployed to interact with the user.

One other aspect of the embodiment is that conversations which a user has with NPCs are stored in a queriable and retrievable manner as part of, or in association with, the user's profile. Thus, if a user wishes to play back a conversation that he or she previously had, the conversation can be retrieved from the memory 12, for example with reference to the NPC identity and a date time, and sent via the user interface to the user's device. Thus the conversation could be made available for the user's Facebook contacts to view. It will be understood that the above-described apparatus and method could be varied within the scope of the invention. Some alternatives to certain aspects of the described embodiment have already been mentioned. In particular, another aspect which could be varied is the characterization of user responses by flags. It will be understood that this is not essential and that the user responses could be used to update the user's profile and for overriding the next tier to which a conversation is directed by other means. It is not essential to base characters on Myers-Briggs personality profiles, nor to use the Myers-Briggs criteria to update and maintain the user profiles. Other criteria could be used, such as other psychological systems, or this means of assessing the user could be omitted altogether and other information only such as likes and dislikes be used instead. Regardless of whether the Myers-Briggs criteria are used, users' profiles can be updated for additional reasons such as achievement of a goal and general social progress.

It would be possible to update user profiles based additionally or alternatively on other criteria than responses to a conversation prompt. Some of these have already been mentioned and include achievement of certain game goals by the user, progress of the user in an interaction with an NPC or in some other social situation, information provided by the user and receipt of a message from another user. The user's purchasing habits could also be analyzed and used for such updates. For example, if a user purchased a particular virtual or real item, this might indicate a certain "like" which could be used to update the Likes field of the user profile. In the described embodiment, all the tiers 16 of the conversation tree 14 have four branches. This number could be varied, either globally in a tree or differently as between different prompts 18 of the tree.

It will be understood that the above-described apparatus in figure 7 relates generally to an apparatus owned or rented by an owner or licensee of the game. By such means, the owner can control participation of multiple users in the game. However, depending on the type of device through which the game is accessed, some of the modules and processing operations could be performed at the user's end. Indeed, should the game be purchased in a format for running on a non-web-enabled platform, all the processes and storage would take place locally, for example on a user device such as an arcade game. Thus the described method could run on a user device without the need for a web interface. Embodiments of the invention provide improvements over prior art games which do not store a user profile comprising fields relating to choices made by the user, which can be updated as a result of those choices. It will be understood that the use of an avatar for making such choices is not essential. Whilst override flags have been used in the above-described embodiment to "jump" tiers of a conversation tree, such omitting of some tiers could be done for other reasons, for example based on aspects of a previous encounter with the NPC with which the conversation is taking place.

Whilst the use of multiple conversation "trees" having a finite number of "tiers" which are connected as a conversation thread has been used in the above-described embodiment, this structure of storage of dialogue strings could be varied. A "tree" could be much larger, comprising dialogues which are not associated with other dialogues and the conversation presented to the user could be more random in nature. In other words it could resemble an array of dialogues. Thus the navigation between tiers need not occur by means of a fixed pointer, but could be implemented differently, in dependence on the structure of the database in which conversation dialogues are stored. The "branches" do not necessarily need to be user responses but could be questions posed by the user - thus a "tier" could be defined as multiple branches and multiple NPC responses. Additionally, the percentage of responses in a tree or in an array which carry flags and/or trigger an update could be varied as desired.

One or more aspects or features of the subject-matter described herein can be realized in digital electronic circuitry, integrated circuitry, specially designed application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) computer hardware, firmware, software, and/or combinations thereof. These various aspects or features can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, including the exemplary processor 74. The programmable system or computing system may include the clients (user devices) and servers such as the apparatus 10. As previously explained, a client and server are generally remote from each other and typically interact through a communication network such as the network 8. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. These computer programs, which can also be referred to as programs, software, software applications, applications, components, or code, include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object- oriented programming language, and/or in assembly/machine language. Indeed, whilst the exemplary game engine used in creation of the game, 3D Unity Professional is written in C++ and C# aspects of the data management may be implemented in other code, such as structured query language (SQL) and extensible mark-up language (XML). As used herein, the term "machine-readable medium" refers to any computer program product, apparatus and/or device, such as for example magnetic discs, optical disks, memory, and Programmable Logic Devices (PLDs), used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor. The machine-readable medium can store such machine instructions non-transitorily, such as for example as would a non-transient solid- state memory or a magnetic hard drive or any equivalent storage medium. The machine-readable medium can alternatively or additionally store such machine instructions in a transient manner, such as for example as would a processor cache or other random access memory associated with one or more physical processor cores.

To provide for interaction with a user, one or more aspects or features of the subject-matter described herein can be implemented on a computer having a display device, such as for example a cathode ray tube (CRT) or a liquid crystal display (LCD) or a light emitting diode (LED) monitor for displaying information to the user and a keyboard and a pointing device, such as for example a mouse or a trackball, by which the user may provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well as the visual and text- based information described in the above embodiment. For example, feedback provided to the user can be any form of sensory feedback, such as for example visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including, but not limited to, acoustic, speech, or tactile input. Other possible input devices include, but are not limited to, touch screens or other touch-sensitive devices such as single or multi-point resistive or capacitive trackpads, voice recognition hardware and software, optical scanners, optical pointers, digital image capture devices and associated interpretation software, and the like.

The subject-matter described herein can be embodied in systems, apparatus, methods, and/or articles depending on the desired configuration. The implementations set forth in the foregoing description do not represent all implementations consistent with the subject-matter described herein. Instead, they are merely some examples consistent with aspects related to the described subject-matter. Although a few variations have been described in detail above, other modifications or additions are possible. In particular, further features and/or variations can be provided in addition to those set forth herein. For example, the implementations described above can be directed to various combinations and sub-combinations of the disclosed features and/or combinations and sub-combinations of several further features disclosed above. In addition, the logic flows depicted in figure 8 and described herein do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Other implementations may be within the scope of the following claims.

Appendix 1 - Myers-Briggs Personality Types

World Focus: Extroversion (E) or Introversion (I).

Energy Flow - How do we receive the essential part of our stimulation? Is it from within ourselves from other sources? Do you prefer to focus on the outer world or on your own inner world?

Information: Sensing (S) or Intuition (N).

Taking in Information - How do we take in information? Do we trust our 5 senses or do we rely on instinct and intuition? Do you prefer to focus on the basic information you take in or do you prefer to interpret and add meaning?

Decisions: Thinking (T) or Feeling (F).

Decision Making - Are we prone to choose logic and objective consideration when deciding or base a decision on personal, subjective values? When making decisions, do you prefer to first look at logic and consistency or first look at the people and special circumstances?

Structure: Judging (J) or Perceiving (P).

Dav-to-Dav - Do we prefer an organized, purposeful, and structured environment, or are we more comfortable with a flexible and casual setting? In dealing with the outside world, do you prefer to get things decided or do you prefer to stay open to new information and options?

Appendix 2 - Example NPCs with Personality Guidelines

A- Amy and Adam - ISTJ Planner, Inspector GUARDIAN

Quiet, serious, earn success by thoroughness and dependability. Practical, matter-of-fact, realistic, and responsible. Decide logically what should be done and work toward it steadily, regardless of distractions. Take pleasure in making everything orderly and organized - their work, their home, their life. Value traditions and loyalty.

ROMANTIC IDEALS : Practicality & Responsibility - A - B - M - N

INCOMPATIBLE : Idealistic or Theoretical Thinkers & Touchy-Feely Artsy-Fa rtsy" Types - H - G B- Barb and Ben - ISFJ Protector, Supporter GUARDIAN

Quiet, friendly, responsible, and conscientious. Committed and steady in meeting their obligations.

Thorough, painstaking, and accurate. Loyal, considerate, notice and remember specifics about people who are important to them, concerned with how others feel. Strive to create an orderly and harmonious environment at work and at home.

ROMANTIC IDEALS : Practicality & Responsibility - B - A - M - N

INCOMPATIBLE: Idealistic or Theoretical Thinkers & "Touchy-Feely Artsy-Fartsy" Types- H - G

C- Cindy and Carl - INFJ Foreseer, Counselor IDEALIST

Seek meaning and connection in ideas, relationships, and material possessions. Want to understand what motivates people and are Insightful about others. Conscientious and committed to their firrn values.

Develop a clear vision about how best to serve the common good. Organized and decisive in implementing their vision.

ROMANTIC IDEALS: Idealism & Empathy - C - G - O - H

INCOMPATIBLE: Pragmatic Thinkers & "Living in the Moment" Types- E - F

D- Dina and Dan - INTJ Director, Mastermind RATIONAL

Have original minds and great drive for Implementing their ideas and achieving their goals. Quickly see patterns in external events and develop long-range explanatory perspectives. When committed, organize a job and carry it through. Skeptical and independent, have high standards of competence and performance - for themselves and others.

ROMANTIC IDEALS: Competence & Results - D - M - H

INCOMPATIBLE: Pragmatic Thinkers & "Living in the Moment" Types- E - F

E- Eve and Evan - ISTP Analyzer, Crafter ARTISAN

Tolerant and flexible, quiet observers until a problem appears, then act quickly to find workable solutions. Analyze what makes things work and readily get through large amounts of data to isolate the core of practical problems. Interested in cause and effect, organize facts using logical principles, value efficiency. ROMANTIC IDEALS: Flexibility & Tolerance - E - 1 - O - F

INCOMPATIBLE: Opinionated Thinkers & "Visionary" Types- C - D F- Fran and Fred - ISFP Composer, Producer ARTISAN

Quiet, friendly, sensitive, and kind. Enjoy the present moment, whaf s going on around them. They like to have their own space and to work within their own time frame. Loyal and committed to their values and to people who are important to them. Dislike disagreements and conflicts, do not force their opinions or values on others.

ROMANTIC IDEALS: Spontaneity & Flexibility - F - E - 1 - J

INCOMPATIBLE: Opinionated Thinkers & "Visionary" Types- C - D

G- Gina and Gavin - INFP Harmonizer, Healer IDEALIST

Idealistic, loyal to their values and to people who are important to them. Want an external life that is congruent with their values. Curious, quick to see possibilities, can be catalysts for implementing ideas. Seek to understand people and to help them fulfill their potential. Adaptable, flexible, and accepting unless a value is threatened.

ROMANTIC IDEALS: Idealism & Understanding - G - C - K - O

INCOMPATIBLE: Rigidly Traditional Thinkers & "Organized" Types- A- B

H- Hilda and Henry - INTP Designer, Architect RATIONAL

Seek to develop logical explanations for everything that interests them. Theoretical and abstract, Interested more In Ideas than in social Interaction. Quiet, contained, flexible, and adaptable. Have unusual ability to focus in depth to solve problems in their area of interest. Skeptical, sometimes critical, always analytical.

ROMANTIC IDEALS: Self Control & Insight - D - P - L - C

INCOMPATIBLE: Rigidly Traditional Thinkers & "Organized" Types- A- B I- Ivy and Ian - ESTP Promoter, Executor ARTISAN

Flexible and tolerant, they take a pragmatic approach focused on immediate results. Theories and conceptual explanations bore them - they want to act energetically to solve the problem. Focus on the here-and-now, spontaneous, enjoy each moment that they can be active with others. Enjoy material comforts and style. Learn best through doing.

ROMANTIC IDEALS: Self Gratification & Dramatic Impact- l - L -J - F - E - C

INCOMPATIBLE: Teachers, Leaders & "Long-Term Planners" - O- P

J- Jan and Jay - ESFP Motivator, Performer ARTISAN

Outgoing, friendly, and accepting. Exuberant lovers of life, people, and material comforts. Enjoy working with others to make things happen. Bring common sense and a realistic approach to their work, and make work fun. Flexible and spontaneous, adapt readily to new people and environments. Learn best by trying a new skill with other people.

ROMANTIC IDEALS: Self Gratification & Dramatic Impact- J - 1 - F

INCOMPATIBLE: Teachers, Leaders & "Long-Term Planners" - O- P

K- Kay and Kyle - ENFP Advocate, Champion IDEALIST

Warmly enthusiastic and imaginative. See life as full of possibilities. Make connections between events and information very quickly, and confidently proceed based on the patterns they see. Want a lot of affirmation from others, and readily give appreciation and support. Spontaneous and flexible, often rely on their ability to improvise and their verbal fluency.

ROMANTIC IDEALS: Idealism & Understanding - 0 - K - G

INCOMPATIBLE : "Result-Oriented" Thinkers & Those who Value Stability & Routine - M-N

L- Lisa and Les - ENTP Explorer, Inventor RATIONAL

Quick, ingenious, stimulating, alert, and outspoken. Resourceful in solving new and challenging problems. Adept at generating conceptual possibilities and then analyzing them strategically. Good at reading other people. Bored by routine, will seldom do the same thing the same way, apt to turn to one new interest after another.

ROMANTIC IDEALS: Honesty & Flexibility - P - H - 1

INCOMPATIBLE : "Result-Oriented" Thinkers & Those who Value Stability & Routine - M-N

M - Mary and Mike - ESTJ Implemented Supervisor GUARDIAN

Practical, realistic, matter-of-fact. Decisive, quickly move to implement decisions. Organize projects and people to get things done, focus on getting results in the most efficient way possible. Take care of routine details. Have a clear set of logical standards, systematically follow them and want others to also. Forceful In implementing their plans.

ROMANTIC IDEALS : Practicality & Decisiveness - M - P - A - N

INCOMPATIBLE: Independent Thinkers & "Spontaneous" Types- K-L

N- Nora and Nick - ESFJ Caretaker, Provider GUARDIAN

Warmhearted, conscientious, and cooperative. Want harmony in their environment, work with

determination to establish it. Like to work with others to complete tasks accurately and on time. Loyal, follow through even in small matters. Notice what others need In their day-by-day lives and try to provide it. Want to be appreciated for who they are and for what they contribute.

ROMANTIC IDEALS : Thoughtfulness & Practicality - M - N - B

INCOMPATIBLE: Independent Thinkers & "Spontaneous" Types- K-L O- Olivia and Otto - ENFJ Mentor, Teacher IDEALIST

Warm, empathetlc, responsive, and responsible. Highly attuned to the emotions, needs, and motivations of others. Find potential in everyone, want to help others fulfill their potential. May act as catalysts for individual and group growth. Loyal, responsive to praise and criticism. Sociable, facilitate others in a group, and provide inspiring leadership.

ROMANTIC IDEALS: Empathy & Efficiency - O - E - K - G

INCOMPATIBLE: Impulsive, In-The-Moment Types who Value Material Comforts - l-J

P- Pam and Paul - ENTJ Mobilizer, Field Marshall RATIONAL

Frank, decisive, assumes leadership readily. Quickly sees illogical and inefficient procedures and policies, develop and implement comprehensive systems to solve organizational problems. Enjoys long-term planning and goal setting. Usually well Informed, well read, enjoy expanding their knowledge and passing it on to others. Forceful In presenting their ideas.

ROMANTIC IDEALS : Practicality & Resourcefulness - P - M - H - L

INCOMPATIBLE: Impulsive, In-The-Moment Types who Value Material Comforts - l-J Appendix 3 -Flags

« » indicates a FLAG 1. Game State Flags for relative Attraction

Love Override I.e., «GS_LO, X» [Set as -50 or below]

...where X is the Number of the alternate PROMPT the conversation is to take.

This Flag says that the Response will go to the stated result unless the NPC is Very Attracted to the Player, in which case it goes to an alternate more positive prompt instead. This should be used when a somewhat ambiguous negative response could be interpreted as positive by an NPC who is really enthralled by the Player. The field "X" is replaced with a particular number in a particular conversation to indicate the # of the alternate positive response.

Hate Override I.e., «GS_HO, X» [Set as +50 or above]

...where X is the Number of the alternate PROMPT the conversation is to take.

This Flag says that the Response will go to the stated result unless the NPC dislikes the Player, in which case it goes to an alternate negative prompt instead. This should be used when a somewhat ambiguous positive response could be interpreted as negative by an NPC who really dislikes the Player. The field "X" is replaced with a particular number in a particular conversation to indicate the # of the alternate negative response.

Attraction Override I.e., «GS_AO, X» [Set at Zero]

... where X is the Number of the alternate PROMPT the conversation is to take.

This says that the Response will go to stated result unless the NPC is even slightly attracted to the Player, in which case it will go to the alternate more positive prompt instead. This powerful Flag should be used whenever a statement or response is inherently neutral or arguably ambiguous... e.g. "Hello..." and it makes sense to let the game stats decide which way to go.

[How does this happen?] The field "X" is replaced with a particular number in a particular conversation to indicate the # of the alternate response.

Discomfort Override I.e., «GS_DIS» [Reduces COMFORT by 5]

This Flag tells the Game that the Response has caused the NPC extreme discomfort, and that the Game should immediately & visibly reduce the NPC's current Comfort level. [How is this implemented?]

This should ONLY be used when the discomfort is unequivocal.

2. Stage Completion Flags

As the user progresses through a conversation they will sometimes give responses indicative of their successful completion of a specific Stage. These Responses are marked with appropriate "Stage Flags". The game can then recognize each time a Stage has been completed and can give advice to Players based on the type(s) of Stages with fewer completions.

«GS_S1»: Approach

«GS_S2»: Transition

«GS_S3»: Attraction

«GS_S4»: Qualification

«GS~ S5»: Comfort «GS_S6»: Seduction

3. UPDATE Game State Flags - PLAYER & NPC

Player Personality - Setting Attributes

The database will Model the Player's Personality based on Responses that demonstrate an attitude or mindset indicative of one of the 16 CAST - Personality types (A through P) ... Any responses that are from one (or more) specific CAST Types are flagged accordingly.

a) Update Player Personality Type Flags:

«UP_PT, X» where X is the LETTER of the Specific CAST-Personality Type [ A-P ] e·g· .

The Response: "...I have very high standards... " might indicate that the Player is a D type of personality and the following Flag is set....

«UP_PT, D»

The Response: "...I love spontaneity... " might indicate that the Player is an I, J, K or L type of personality and all four flags are used.

«UP_PT, I» «UP_PT, J» «UP_PT, K» «UPJ>T, L» b) Individual Meyers Brigg Flags:

«UP_MB, X» where X is the number of the Specific Personality Type as listed below. 1 Extroversion

2 Introversion

3 Sensing

4 Intuition

5 Thinking

6 Feeling

7 Judging

8 Perceiving 4. NPC Text String Flag to describe an NPC's job or identifying characteristic

«UAI_TS, X» where X is the text string to be recalled later which relates to the job or characteristic.

e.g., "I am a dog food taster." ...or, "didn't you used to be a dog food taster ? 5. Custom RPG Attributes - Skill Sets

The database entry for a user will keep track of a set of RPG (Role Playing Game) Attributes, which will be used to measure and quantify Character compatibility. A Response that warrants an addition to a Player's RPG Skill set includes the appropriate Flag. The player's skill set can also be updated outside of the Conversations as well.

e.g. The Response: "...I love to dance... " calls for the flag «UP_Dancing» Thus the general format is:

«UP_ X» where X is the name of the RPG Type as shown below.

The Attributes of the Player's RPG Skill Set are:

Charm*

Leadership

Confidence

Initiative

Creativity*

Dancing

Music

Art

Charisma*

Humor ^'

Playfulness

Etiquette

Empathy*

Understanding

Listening

'If one of the general headings is used as the flag, all of the Sub headings are flagged as well.

6. NPC ZODIAC Flag

«UAI_zodiao> where zodiac is the Zodiac sign of the NPC.

«UP__zodiac» where zodiac is the Zodiac sign of the Plaver.

If the Player or NPC has already indicated their Sign, the Game will insert the appropriate Sign. If not, the conversation engine will assign one. [How does this work?]

7. HOBBIES & INTERESTS - Likes and Dislikes

The database entry relating to each user or NPC will keep track of a set of Interests which can be flagged as Liked / Disliked by EITHER the NPC or the Player.

UPDATE NPC INTEREST Flags:

«UAI_LIKE, X» ...where X is the Number of the Hobby/Interest the NPC likes.

«UAI_DONT, X» ...where X Is the Number of the Hobby/Interest the NPC does NOT like.

«UP LIKE, X» ...where X is the Number of the Hobby/Interest the Player likes.

«UP~DONT,X» ...where X is the Number of the Hobby/Interest the Player does NOT like. ~ The X field is replaced in a particular use with the appropriate Number from the List below...

8. Game State Flags that Inform the game about a Change In the relationship

These Flags are used when the conversation suggests that the user and NPC have mutually changed their relationship. For example, a conversational exchange in which both agree to get together sometime in the future would indicate that they EXCHANGED INFO. These Flags are linked with either a Target Prompt or Player Response to signal a mutually agreeable game state change. The possible flags are:

«gs_info» Player - NPC info exchange

«gs date» Player - NPC make Date

«gs_sex» Player - NPC share Intimacy

«gs_love» Player - NPC make Commitment

9. Conversation Pyramid Over This Flag will be linked with a Player Response to signal the end of a conversation: «gs_over»

This Flag is placed in all Final prompts... (11, 12. 13, 14, 15)