U.S. Pat. No. 8,613,646

DESCRIPTION

As described above in the summary, the disclosure is generally related to systems and methods for providing a user with an interactive multiplayer story and/or a virtual world application.

FIG. 1is a network diagram of an interactive multiplayer story system or framework100according to an illustrative embodiment of the invention. The system100includes a network102, a system administrator104, a development server126, a game server124A, a story application122A, a database128A, a game server124B, a story application122B, a database128B, an author client106A, an author client106B, a user client110A, a user client110B and a user client110C.

The network102may include a data network, packet data network, circuit switched network, wireless network, Public Switched Telephone Network (PSTN), or any network capable of exchange information between a sender and receiver. The system administrator104may communicate with the servers124and the clients106and110using the network102. The system administrator104may retrieve data from or send data to the servers124and clients106and110. Furthermore, the system administrator104may communicate with the database128A and the database128B through the game servers124A and124B, respectively, or directly through the network102.

Each of the game servers124A and124B may include a plurality of servers. These severs,124A and124B may be any computing system, such as described with respect toFIG. 2, or portions of a computing system, capable of delivering a service, such as a gaming service, to a user or a plurality of users. The development server126may communicate directly with other servers, such as the game server124A or database128. Such communication may be done through the network102. In one embodiment, the game servers124A and124B can host the story applications122A and122B, respectively. In another embodiment, the game servers124A and124B are connected to the databases128A and128B, respectively, to allow for electronic communication.

The game servers124A and124B may include a web site and have a web application. Web applications may include applications developed based on .NET, Java, SAP, Siebel, Oracle, web services and/or other suitable web-based platforms. The game server124A or124B may be a computer server implementing an instance of the story application122A or122B, and may be operated as a web server.

In some embodiments, the story application122A and/or122B is accessible by multiple users. Users may be persons that perform various roles associated with the story applications122A and/or122B, such as the system administrator104, the author106A and the user (or player)110A, and developers. Each user may access and/or interact with the story application122A or122B via the network102using a web browser implemented on a client machine110A or110B or via a direct interface. User interaction with the story application122A or122B may include configuring and/or executing games applications122A or122B, and performing related activities. Related activities may include creating an avatar and/or player character, purchasing access to story applications or modules, reviewing information related to the story applications122A and/or122B, and/or communication with a game administrator and/or other players.

Each of the author clients106A,106B, the user clients110A110B and110C may include a plurality of clients. These clients can be any computer systems and applications capable of accessing remote information on a server, such as servers124A and/or124B. In one embodiment, the author client106A and106B are clients used by authors or game level designers or other content publishers for interacting with the servers and/or the system administrator104through the network102. For example, an author may develop a virtual actor, i.e., a “vactor”, an item, a dungeon, an adventure, a story line, and then upload and/or publish this data to the game server124and/or story application122to be used by players. Similarly, the users clients110A,110B and110C may enable players to interact with the servers124A and124B, and/or with the system administrator104through the network102.

The system administrator104may monitor an on-going story application122, gaming environment, and/or an avatar's social interactions within a virtual world. For example, if a user has committed a certain prohibited behavior, the system administrator may decide to expel him or freeze his account for some amount of time. Additionally, the system administrator104may provide technical support for all backend servers and frontend applications to ensure that the infrastructure is sufficient to support an interactive multiplayer story system. For example, when the game server124A goes offline, the system administrator104may migrate workload from the game server124A to the other game server124B, while conducting business recovery on the game server124A.

The development server126may process content submitted by the author106A and/or the author106B. A submission may be a story or an excerpt of a story for a game or an adventure, or a level created by a level designer, and/or merchandise. Additionally, these submissions can be stored in the database128A. In one embodiment, the development server126includes, as a quality control, application130. The quality control application130may be operated and/or used by one or more system administrators or quality control reviewers, who review submitted gaming data (e.g., dungeon, adventure, story line, item, character, and so on) and determine whether the data quality is adequate for publication and/or use as part of gaming applications122A and/or122B. The adequate and selected submissions may then be stored in the database128and/or another database, such as publication database312. One submission may also be distributed among various databases. The selected and/or approved submissions may then be offered for purchase and/or use by end users. Depending on the game, adventure, book, and/or other published content selected and/or purchased by a user, the game servers124A and/or124B may retrieve data from databases, such as database128A or312, to install and run story applications122A and/or122B to serve user clients.

FIG. 2is a functional block diagram of a general purpose computer accessing a network according to an illustrative embodiment of the invention. The system administrator104, the development server126, the game server124A, the story application122A, the database128A, the game server124B, the story application122B, the database128B, the author client106A, the author client106B, the user client110A, the user client110B and the user client110C may be implemented as a general purpose computer200shown inFIG. 2.

The exemplary computer system200includes a central processing unit (CPU)202, a memory204, and an interconnect bus206. The CPU202may include a single microprocessor or a plurality of microprocessors for configuring computer system200as a multi-processor system. The memory204illustratively includes a main memory and a read-only memory. The computer200also includes the mass storage device208having, for example, various disk drives, tape drives, etc. The main memory204also includes dynamic random access memory (DRAM) and high-speed cache memory. In operation and use, the main memory204stores at least portions of instructions and data for execution by the CPU202.

The computer system200may also include one or more input/output interfaces for communications, shown by way of example, as interface210for data communications via the network212. The data interface210may be a modem, an Ethernet card or any other suitable data communications device. To provide the functions of a computer104according toFIG. 1, the data interface210may provide a relatively high-speed link to a network212and/or network102, such as an intranet, internet, or the Internet, either directly or through an another external interface. The communication link to the network212may be, for example, optical, wired, or wireless (e.g., via satellite or 802.11 Wi-Fi or cellular network). Alternatively, the computer system200may include a mainframe or other type of host computer system capable of web-based communications via the network212and or network102.

The computer system200also includes suitable input/output ports or may use the Interconnect Bus206for interconnection with a local display216and keyboard214or the like serving as a local user interface for programming and/or data entry, retrieval, or manipulation purposes. Alternatively, server operations personnel may interact with the computer system200for controlling and/or programming the system from remote terminal devices via the Network212.

The components contained in the computer system200are those typically found in general purpose computer systems used as servers, workstations, personal computers, network terminals, portable devices, and the like. In fact, these components are intended to represent a broad category of such computer components that are well known in the art. Certain aspects of the invention may relate to the software elements, such as the executable code and database for the server functions of the development server126, game server124, administrator104, databases128, and/or clients106and110.

FIG. 3is a functional diagram300of an interactive multiplayer story showing a mapping of multiple events to multiple player character roles according to an illustrative embodiment of the invention. The diagram300includes a vertical axis of roles A through F (302-312) of characters that players can choose to play in a role playing game and/or interactive story. The horizontal axis includes events1-13(314-338) that make up a story line and/or plot of the interactive story where the events happen to and/or are acted out by the player characters in various roles.

Player characters may assume one of the roles302,304,306,308,310, and312(i.e., . . . , roles A-F). The events1-13in the story that happen to or are acted out by the characters may be controlled by various players. Such virtual actors may be referred to as avatars or player characters (PCs). Characters controlled by the story application122may be referred to as non-player characters (NPCs). NPCs in an interactive story and/or movie may also be referred to as virtual actors or “vactors.” Events may happen to individual or multiple avatars. The story application122may wait for avatar proximity or call multiple avatars to an event to initiate the event.

One example or metaphor may be a movie. The camera jumps from place to place and shows one or more players or viewers event happening to the characters in the movie. A two-hour movie can describe a series of events separated by vast amounts of time and space. In the movie, an activity or non-event that happens between events is left out to move the story to a conclusion in ninety minutes. In a virtual adventure run by an interactive multiplayer story application122, the in world time spent by an avatar may include many non-events or activities such as talking to friends, going on dates, playing games, and so on. After some time has passed, the story application122may look for PCs that are destined and/or ready to interact in an event, and then initiate a meeting to act out the event.

The difference between a PC's behavior during an event vs. during a non-event may be that the story application controls an avatar's actions, like a director controls an actor's action while, during a non-event, the player controls their avatar's actions. For example, Jason Bourne springs into Kung-fu action during an event, and then becomes a lonely confused young man searching for his identity.

An avatar may participate in and/or be part of many stories at the same time. In some instances, the stories are independent. However, in other instances some stories may be related in some way. For example, an avatar may be in numerous stories concurrently such as, without limitation, the following:

1) become a great golfer

2) get married and have a family

3) have a wild adventure with a brunette

4) have a wild adventure with a blond

5) be James Bond in a spy story

6) be Indiana Jones in an action story

7) be a Yankees fan in a baseball story

An avatar may participate in multiple non-related stories that are in progress at the same time and/or running concurrently.

Referring again toFIG. 3, a first avatar may assume role A and thus particular in events1,6,10, and13of the interactive story. A second avatar may assume role B and participate in events2,6,11and13. During event1, only the first avatar may participate in the event. However, during event6, both the first and second avatar participate in the event. For example, the story may be Batman where role A is Batman and role B is the Joker. The first avatar may become Batman during event1. During event6, the first avatar, acting in the role of Batman, encounters the second avatar, acting in the role of the Joker, where the event includes a Bank robbery by the Joker.

Because a story may have multiple roles that a player can choose from, a player may repeat the same story with different roles. If a player were to repeat a story using a role different from what previously used to play in the same story, the story application122or adventure engine may generate a new instantiation of the story. The sequence of events and/or total number of events may be the same or different for this new role when compared to the events experienced the previous role. For example, in some events of the Batman story, only Batman and Joker are needed to play an event. However, in other events, only Batman and Rachael Dawes are needed. Because events requiring Rachael Dawes may not require the Joker, the set of events experienced by an avatar in these roles would be different.

The number of events the avatar participates in may also differ as there may be more events that require the Joker role (e.g., role B) as opposed to Rachael Dawes (e.g., role C). Therefore, depending on the selected role, the same avatar or another avatar of a player may experience different sets and/or sequences of events in the same story. Accordingly, because different avatars may assume different roles A-F in a story, two avatars and/or players may not have the same experience in a story. Because what an avatar may experience in a story can be different from what another avatar may experience in the same story, the interactive multiplayer story application122can provide each player of the interactive multiplayer story system with a personalized experience, making the experience more realistic because events occurring to an avatar are unpredictable and dynamically initiated. Furthermore, because the same user may experience different sets of events and/or sequences of events using one or more avatars in different character roles, the interactive multiplayer system advantageously provides users of the system with adventuring possibilities that not provided by existing RPGs.

FIG. 4is a functional diagram showing multiple instantiations404,406, and408of a story402generated by the story application122according to an illustrative embodiment of the invention. In certain instances, the story application122may provide an interactive story402to many players at various times. Thus, there may be many players that want their avatar to act out, for example, role A at the same time. One approach to ensuring that multiple avatars are able to assume a particular role is to provide multiple instantiations or versions404,406, and408of a story whereby a first avatar assumes role A of a story in a first instantiation404, a second avatar assumes role A in a second instantiation406, a third avatar assume role A in a third instantiation408, and so on until the story application122provides each of the players desiring their avatar to assume role A with the opportunity to assume role A in a particular story402.

A player may have multiple avatars and have each avatar assume a different role in an instantiation of a story. Avatars may assume different roles for different events in an instantiation of a story. Using the Batman example, the avatar who assumes the role of Batman in one event of an instantiation may assume the role of the Joker in another event of the same instantiation. Similarly, an avatar may assume different roles in different instantiations. This way, a player can experience the same story or event from multiple perspectives as their avatar or avatars take on multiple character roles, making the virtual world more interesting and dynamic.

To determine whether a new instantiation404needs to be created, the story application122may assess whether one or more trigger conditions exist, such as whether a different set of players are needed to act out an event, whether there exists an opportunity to bring in new players to an event, and/or whether it is more advantageous to first allow players to complete one event over others. Therefore, I1404and I2406may differ at least because different sets of players were brought together to act out one or more events of each instantiation. Instantiations404,406and408may further differ because the series of events of each instantiation of the story402may be played in a different sequence. For example, the story Batman may have been purchased by 1000 players, some of whom wish to be Batman, while others wish to be the Joker or Rachael Dawes. At any moment in time, the story application122may bring together players who are assuming these roles into the story402Batman, and allow these players to act out an event1-13(SeeFIG. 3) of Batman. There may be numerous instantiations404,406, and408of the story402because the story application122may bring together numerous different sets of players to act out events of the story402(e.g. the Batman story). Also, the events of the different instantiations may occur at different times or date depending on when a condition of bring multiple avatars together are satisfied.

In instantiation404for example, a first set of avatars may be brought together to accomplish a first event. These avatars may include PA, Batman, PB, Joker, and PC, Rachael Dawes. Similarly, in I2406, a second set of players may be brought together to accomplish the first event. These players may be PD, Batman, PE, Joker, and PF, Rachael Dawes. Finally, in I3408, a third set of players may be brought together to accomplish the first event. These players may be PG, Batman, PH, Joker, and PI, Rachael Dawes.

The Batman story402may contain, for example, various events1-13for avatars to participate in. The sequence of these events in I1404may also be different from the sequence of events in I2406and may further be different from the sequence of events in I3408. Although some events may only be triggered based on the completion of others (e.g., the event in which the Joker is put in jail has to occur before the event in which the Joker escapes from jail), certain events may be temporally independent from one another (e.g., Rachael Dawes may be investigating the identity of Batman irrespective of when the Joker is put in jail or escapes). Additionally, because some events may not require all avatars assuming the roles of the story402to be available and ready to play, the story application122may first initiate an event in which only two roles are needed (e.g., event6ofFIG. 3) since it may be more feasible to identify two players who want to assume two roles rather than three players who want to assume all three roles.

At least because the story application122of the adventure engine dynamically identifies opportunities for players to be brought together to act out an event, players of a story advantageously no longer have to wait for other players to become available to play an event or chapter or no longer have to play events of a story in a predefined sequence. In some embodiments, players and/or avatars may not be allowed to look ahead at the events left to play as the story application122of the adventure engine dynamically initiates a next event. Accordingly, such unpredictability may enhance a player's virtual world experience while playing an interactive multiplayer story.

In one embodiment, the story application122may create and/or provide instantiations of an event of a story in additional to, or as an alternative, to instantiations of a story. The story application122may track the individual progress of an avatar using an avatar-specific story line.

Additionally, to accommodate multiple players wishing to assume the same role in a story at the same moment in time, the application122can assign the avatars of these players to different instantiations of the story to avoid conflicts. That is, at any particular moment in time, two players may decide to have their avatars assume the role of Batman. To avoid having both avatars playing as Batman in the same event, the application122can prevent such a conflict from happening by initiating a new instantiation so that both avatars can play as Batman simultaneously without interfering with one another. Additionally, if avatars are identified and brought together to act out a particular event or scene in one instantiation, the application122may prevent other avatars from interrupting the event by assigning these other avatars to different instantiations of the same story.

For instance, avatars may simultaneously believe to have made an eye contact with the same avatar in a virtual social setting, such as in a virtual night club. In some instances, the application122can avoid such confusion or a conflict by providing the social interaction opportunity to the first two players, PAand PBthat make eye contact, while preventing a third avatar PCfrom interfering. To prevent PCfrom interfering, the application122can depict on a display a text or graphical bubble above PAand PBto indicate that these players are permitted to participate the social activity. Alternatively, a vactor may approach PCand explain to him that the social opportunity has been given to PAand PB. In other embodiments, PCmay be taken to participate in alternate events or to a different part of the virtual world, or allowed to participate in a different instantiation.

FIG. 5is a diagram showing an avatar-specific story line500associated with a particular avatar including multiple events502,504, and506of a story and activities508and510, according to an illustrative embodiment of the invention. The avatar may have assumed, for example, role A in a story402. In one embodiment, the story application122tracks the progress of an avatar by tracking whether certain events are completed or not.FIG. 5illustrates that the avatar-specific story line500includes at least seven story related events502-506and non-story related events, or activities508and510. The avatar may have completed event502and is ready to act out event504. Event502may have corresponded to event1of instantiation404of story402. However, instead of performing event2of instantiation404, the story application may have avatar participate in event2of instantiation406. There may be numerous reasons why a different instantiation is used. For example, the player for avatar may have not played the interactive story for several days, resulting in event2of instantiation404having been already performed by another avatar. Thus, when the player resumes play with avatar, the story application122provides event2of instantiation404to avatar. Thus, event504of the avatar-specific story line500would correspond to event2of instantiation404.

From the player's perspective, it may not be relevant which instantiation of a story is used to act out a particular event as long as the player or his/her avatar for his player character is able to progress through the events502-506of his/her avatar-specific story line500. In one embodiment, the story application122displays a version of the story line500to a player associated with his/her avatar so that the player is able to monitor the progress of his/her avatar through a particular story line500. The story line500may be displayed in any number of forms including, for example, a sequence of chapters (corresponding to each event502-506). As a player completes an event, an indicator such, for example, closing a chapter cover, may be presented to indicate that a portion and/or event of a story is completed. Other visual, graphical, and/or audio-based indicators may be used to show completion of an event.

In some embodiments, future events or events yet to be performed may be obscured or hidden to enhance the unpredictability of a story line500. The story application122may initiate an event for a player dynamically, or based on the satisfactions of one or more trigger or event conditions. The selection of avatars and/or player characters to participate in an event or instantiation of an event may depend on certain event conditions such as, without limitation: proximity of avatars to one another in a virtual world; whether certain avatar and/or players are “friends” or have designated each other as part of a group, guild, affiliation, or social network; avatar demographics, player demographics (e.g., age, gender, race, ethnicity, and the like), player preferences (e.g., game background), avatar preferences; experience of players and/or avatars in virtual world, and priority of stories that a player wants their avatar to participate in.

In some embodiments, the game application122controls when an event, a portion of an event, and/or certain avatar actions during a non-event is initiated based on upon the occurrence of a trigger condition. With respect toFIG. 3, an avatar may participate in activities (e.g., non-events) that are dynamically facilitated by the game application122while the avatar is not participating in a story-related event. For example, an avatar may visit a virtual meeting place such as a bar to meet other avatars and players. The game application122may assume control of an avatar for certain activities and/or events to enable the avatar to perform in an extraordinary manner and/or in a manner of a character within a story line. For example, an avatar assuming the role of Batman may be controlled, at least temporarily, in a manner to enable the avatar to leap twenty feet from one building to another. Once a particular event, activity, and/or non-event interaction is completed, the game application122may restore control of the avatar the player.

A player may determine when his/her avatar participates a story and/or event of a story. As described in relation toFIG. 7, a player may customize an avatar's virtual world setting. One of such settings may allow the user to pause, cancel, and/or delay an event and/or story line or other activity. In one configuration, a player can decide whether or not the game application122can take control of an avatar to initiate an event of a story. If the story mode is paused, delayed, and/or turned off, the avatar may be free to participate in non-events and activities that are not part of a story even if the game application122determines that the avatar can participate in a story-related event. This feature may advantageously allow an avatar to perform non-events and activities without interruption from the game application122which may be continuously assigning an avatar to various events of one of more story lines. In another configuration, the game application122may allow a player to prioritize certain stories. For example, avatar may be participating in three stories simultaneously. The player of the avatar may designate a first of the three stories as highest priority so that the game application122ensures that the avatar performs events associated with the first story in preference to the second and third stories. In one configuration, the game application may pause the avatar's actions in one story in order to perform an event in a higher priority story. Once the event of the higher priority story is complete, the avatar may be returned to the event of the lower priority story. It may be preferable for a player wishing to complete a particular story as soon as possible and, therefore, want to be interrupted by the game application122to initiate an event of the particular story. In another configuration, the game application122may query a player for authorization before including the player's avatar in a particular story and/or event of a story.

In some instances, a player may purchase the right to pause, delay, and/or turn a story on or off. The game application122may enable a player to choose to pause, skip an event, skip a portion of a story, move forward or back in a story, cancel, and/or restart a story. In other instances, depending on the nature of the interactive story and a player's setting for the story, the game application122may override certain player selections including a player selecting to pause, skip an event, skip a portion of story, move forward or backward in a story, cancel, and/or restart a story.

FIG. 6is a diagram600including two instantiations602and604of a story according to an illustrative embodiment of the invention. The first instantiation602includes a story line having events606,608,610, and612(story events1-4). The second instantiation604includes a story line having events614,616,618, and620(story events1-4). Each event may require that certain character roles be acted out during that event. For example, event1(e.g., event606and614) requires roles R1, R2, and R3. Event2(e.g., events608and616) may require character roles R1and R2. Event3(e.g., events610and618) may require character role R1. Event4(e.g., events612and620) may require character roles R1, R2, and R3.

The story application may assign certain avatars to certain roles in one or both of the instantiations602and604of a story. For instance, the avatar A2may be assigned to event606(event1of instantiation602) to participate in that event in the role R2. However, the story application may then assign avatar A5to the role R2for event608(event2of instantiation602). The story application122may assign the same avatar A1to act out the same role R1for every event of an instantiation602. However, in some instances, the story application122may assign different avatars A4and A7to act out different events of an instantiation604of a story.

The story application122may continuously identify avatars and/or players to assume character roles that are necessary to initiate an event. The temporal sequence of events completed for the instantiation602may be different from the sequence of events completed for instantiation604. This flexibility allows the game application122to identify available players of various avatars at any moment in time so that the system may initiate events for those players at that moment, without requiring the players to wait for other players and their avatars to become available to complete an event. In fact, the story application122may create a new instantiation so that a play may at least be able to play certain events of a story immediately, without having to wait for any other players becoming available. In one embodiment, the story application122can use an NPC to assume a role in an event of a story where an avatar is not available.

In an illustrative situation where, for example, a thousand users have purchased the right to play the story Batman, there may be 50 users signed onto the game server124A and/or124B, and the database128A may currently contain only seven events for the story Batman, though more events may be added later if additional submissions of content are received and approved for sale. More characters may also be added, and therefore, events and/or storylines that are designed to utilize these characters may also be added into the database128A. For example, new characters, such as Harvey Dent, the new district attorney, and Alfred, Batman's advisor, may be added to the Batman story later as new submissions of characters and/or events are published and integrated into the story by the story application122.

Event608may correspond to a scene in the Batman story where Batman rescues Rachael Dawes from Joker. Therefore, to complete this event608, the game application122may check database128A and or128B to search for avatars currently available for playing the event608and identify players who wish to be Batman, Joker and Rachael Dawes. Once the story application122identifies these players, the story application122may automatically bring these players together to act out the various actions of event608. The virtual world environment for event608may largely depend on or be similar to the scenes in the movie Batman, making the story experience more realistic and familiar as most players of the Batman story may have seen the movie.

Other animations and/or graphical designs may also be included in addition to scenes like the movie. The game application122may further automatically generate certain virtual world features for the event608based on each player's user profile or settings, such that the virtual world environment is tailored to each player, making the experience more personalized. For example, if a player indicated in his/her user profile and/or setting that he/she dislikes having a dark background, albeit Gotham from the movie Batman has a dark setting, the story application122may render the background color and/or any other virtual world features associated with Gotham according to the user's preferences. For example, the story application122may create a brighter background for the Batman story (for one player) while other players may still see a darker background for the story. That is, players of the same event, instantiation of a story, and/or story may experience different and personalized virtual world designs.

In response to a player whose avatar is playing the role of Batman and wanting to finish the Batman story, and if the game application122is unable to identify two other players who wish to play the character Joker and Rachael Dawes, the game application122may automatically bring the player to event610as this is a single player event and its occurrence may not be dependent on the completion of other events.

Such mechanism can advantageously reduce the amount of time a player must spend waiting on other players to become available. Alternatively, the game application122may identify one other player who wishes to play the character Joker and bring the two players to, for example, event608because this event only requires one other character. In some instances, a new instantiation, such as instantiation604, is created by the story application122to accommodate a player who wishes to finish a story sooner. The story application122may then track the completed events and determine the remaining events for this instantiation of the Batman story. In the future, the story application122may identify available players to finish the remaining events, such as events614,616,618, and620.

In another example, a player PAmay have completed most of the events for the Batman story and is currently participating in activities or non-events. The story application122may track PA's progress through the story line of instantiation602of Batman and determine that PAhas event612left in the story. The story application122may then actively search for two other players who might be available and wish to play the remaining characters in event612. Once such players are identified, the event/scene generator902of the story application122may generate the necessary graphics and story related features of the virtual world for event612. The bulletin1002for PA, which contains the upcoming events, may include event612and may start flashing on PA's screen to indicate to PAthat event618is ready for him/her to play. Upon PAselecting event618, PAmay exit out of the current activities, or non events, and the story application122may automatically bring in all three players to act out the various actions in event618in roles R1, R2, and R3. After PAfinishes event618, the story line tracker908(SeeFIG. 9A) may receive the appropriate subroutine values and/or parameters so that the story application122can return PAback to an activity or another story prior to participating in event618.

Other conditions or parameters used for initiating a new instantiation of a story may also include new additions of events to a story. For example, while most instantiations of the Batman story have seven events, at some time, a new event may be added to the database128A and/or128B. For some events, a new character, Harvey, may be needed in addition to Batman, Joker and Rachael Dawes. The story application122may generate a new instantiation or version of the Batman story that includes this new event. Players who have either completed the Batman story or have completed various events of the Batman story in various instantiations of the Batman story may also be given the opportunity to participate in this new event of the new instantiation.

FIG. 7is a screen shot700of a virtual environment according to an illustrative embodiment of the invention. Screen shot700includes a male avatar702, a female avatar704, an event selecting window706, a virtual world708and a tool bar710. The screen shot700may be displayed on a monitor, a TV, a cell phone display or on any other visual output devices.

In some embodiments, avatars as depicted in the screen shot700are controlled by new players who have just entered the virtual world. To assist the new players in learning about the various interactions they can control via their input devices, a link to a tutorial may be provided on the tool bar710. Alternatively, or additionally, a vactor can interact with the new players and help them navigate in the virtual world. In other embodiments, a player character, or avatar, is alerted with the opportunity to help a new player. In such instances, a player controlling the player character can teach or help the new player about navigating in the virtual world and its various features. This way, existing players are provided with the social opportunity to interact with new players and to create new friendships as a result. In some instances, the tutorial is designed in a game or story format. The new players can play such tutorial games or stories for free to learn about the various features offered by the virtual world.

The male avatar702and the female avatar704may be displayed using 2D or 3D graphical representations of an avatar and/or player character. An avatar702may be a player-created player character that acts out various scenarios for a player. In one embodiment, an avatar is controlled by and/or represents the interactive multiplayer story. Avatar movements and interactions with other characters may be controlled by an input peripheral device, such as a keyboard, a mouse, a speech-controlled device and a game-specific controller, and/or a graphical user interface (GUI). At certain instances, the male avatar702and/or female avatar704may be temporarily controlled by the story application122to enhance a player's ability to interact socially with other player characters and/or avatars.

An event selecting window706may be positioned in front of the male avatar702and/or the female avatar704. The window706may include a thumbnail window that displays an introductory view of an event that a player can choose. The event selecting window706may include, without limitations, an icon, a door, a text-based message, or any other like forms. The male avatar702and/or female avatar704may choose to participate in an event by selection of the event in the window706.

The virtual world708may include any interactive multiplayer story in which an avatar may play and interact with NPCs, vactors, other player characters, and/or avatars. The designs and imaging of the virtual world708may include graphical representations of a fantasy world, real and/or fictional images of an object, or person, or a combination of these. The virtual world708may then be created by the means of 2D and/or 3D rendering or image stitching. The creators of the virtual world708may include software developers. Various designs of the virtual world708, including objects, adventures, dungeons, characters, and the like, may be developed and/or submitted to the content producer1402(SeeFIG. 14A).

In one embodiment, the screen shot700contains a tool bar710to provide users with additional opportunities for social interactions or exploration, and may be positioned anywhere on a screen. The tool bar710may include buttons, prompts, sliders or any other graphical or auditory elements. In some embodiments, the tool bar710includes a messenger client, an option for changing outfits to adapt to a social scene, a pause button for temporarily stopping play in a game, a music player, and/or other interactive multiplayer story tools.

FIG. 8is a diagram800illustrating story line management of multiple avatar-specific story lines802,804, and806associated with multiple player characters (PA, PB, and PC) by the story application122according to an illustrative embodiment of the invention. The story line802may be associated with the player character PAand include various events812,816,818,820,822, and824(e.g., PAevent #1through PAevent #6). The story line804may be associated with the player character PBand include various events826,816,828,830,822, and832(e.g., PBevent #1through PBevent #5, and PBevent #7). The story line806may be associated with the player character PCand include various events834,836,828,838,822, and840(e.g., PCevent #1through PCevent #6). An event may include a scene, an adventure, a dungeon, short story, subplot, occurrence, an interaction with another player character or vactor, and/or any instance within a story line. Each event within a story line may occur at a particular time (e.g., t1, t2, t3, t4, t5, and t6). The time may be actual time, elapsed time, time relative to a particular player and/or story line, relative game time, and/or time associated with an event. For example, whenever a player logs onto the story application122to play their avatar, the story application122may use a timer or counter to keep track of the time spent by the player character within one or more story lines.

At certain instances, the various avatar-specific story lines802,804, and806may intersect or be linked by the story application122so that different player characters (e.g., avatars) can interact with each other during an event. Events816,828, and822may include linking periods808,810, and812where the various story lines802,804, and806intersect with each other. For example, during the linking instance, window, or period808, the story lines of players PAand PBare joined so that both player characters can participate in event816(PAand PBthe event #2). Event816may, for instance, be a bank robbery. Player character PAmay be a policeman while player character PBmay be a criminal. PAand PBmay interact during the bank robbery where PAattempts to apprehend PB. After shared event816is completed, the story application122ends the linking period808and returns each player PAand PBto their respective story lines802and804. As another example, the story lines802,804, and806are linked together during linking period812so that player characters PA, PB, and PCparticipate in event822(e.g., PA, PB, and PCevent #5). The number of story lines and/or player characters that can be linked via a linking period may be unlimited or limited only by the available avatar positions or slots associated with a particular event.

In one embodiment, event816is triggered based on the time t2such that, regardless of location of an avatar within a particular dungeon or virtual world706, the story application122links the avatar-specific story lines802and804to enable player characters PAand PBto interact and/or concurrently perform activities associated with the same event816.

In another embodiment, event816is triggered based on the completion of one or more prior events, such as event814(PAevent #1) or event826(PBevent #1), within a story line802or804. Thus, the story application122may track the sequence of events associated with a story line, such as story line802, and initiate the next event in the story line802based on the completion of one or more prior events in the story line sequence. The story line802sequence may be linear such that events occur in a particular order. For example, event #1precedes event #2, which precedes event #3, and so on.

The story line802sequence may include a non-linear portion where events are not required to occur in a particular sequence, but can occur in a variety of orders or sequences. For example, the story application122may allow PAto perform event818(event #4of PA) prior to performing event820(event #3of PA). In this case, PAevent #4is not dependent on the occurrence or completion of PAevent #3. Thus, the story application122may have the capability to allow different player characters to encounter the same story line and/or adventure in different sequences, even though the same overall objective and/or outcome of the story line is achieved by both player characters. In other embodiments, different player characters may have story lines with different overall objectives or goals that, nonetheless, intersect at different times and/or for different events. As discussed above, player character PAmay be a policeman within a story line802with the objective to clean up crime within a virtual city. In contrast, player character PBmay be a criminal within story line504with the objective to become the head of a crime syndicate with the virtual city.

In a further embodiment, a player character, such as PA, may be given a notice and/or indicator during play of an opportunity to link with another player character, such as PB. For example, after the completion of event814(PAevent #1) at a time tn, player character PAmay be given an opportunity to participate in the event816during a notice period842before the start of the event816. If the player character PAaccepts the opportunity, the story application122links the story line802with the story line804during the linking period808to enable event816to occur concurrently for both PAand PB. If the player character PAdoes not accept the offer to link, the player character PAmay proceed to another event. In one embodiment, the story application122allows player character PAto perform PAevent #2without linking with another story line and within the802story line using vactors. In certain embodiments, avatar PBmay have purchased one half of a ticket, while avatar PCmay have purchased the other half of the same ticket. Both avatars PBand PCmay be given notice and an opportunity to meet and match the ticket halves at, for example, the linked event828during linking period810.

In some embodiments, the story application122uses a combination of one or more of timing (time-based adventuring), event occurrence (event-based adventuring), and notice (opportunity-based adventuring) to provide players with a more realistic and enjoyable interactive multiplayer story experience. In addition to time, event, and notice based adventuring, the story application122may provide traditional location-based adventuring experiences. However, as a story and/or story line unfolds, a time-based adventure feature may allow players to dynamically encounter different settings and unpredictable scenarios, avoiding the need for avatars to travel to a predefined location to initiate or trigger a particular event or adventure.

While player characters may need to complete the same events or tasks to reach the end of a story line, the specific settings or surroundings of the each event may differ, given that each event may be triggered based on time, as opposed to location, resulting in the same event occurring in different locations for different player characters. For example, the player character PB, acting as a criminal, may be given the opportunity to perform event830, which requires PBto snatch a purse from a pedestrian in the street. The story application122may present event830at any time and/or location within a virtual world706, to enable player character PBto complete the purse snatching event830. The player character PAmay perform the same purse snatching event818at a different time (e.g., PAevent #4) and in a different location with different surroundings.

The story application122may use various time-based parameters such as time-based story line tracking that may enable the story application122to return a player character back to his previous point in a game and/or story line. While the story application122may track the progression of player characters through a story line, the story application122may prevent players from looking ahead in a story line, unless otherwise specified or requested by the players. By withholding information about future events within a story line or story lines, the story application122can enhance the unpredictability of a story line, making the gaming experience much more realistic and exciting.

In certain embodiments, multiple player characters may follow different avatar-specific story lines that only intersect or interact for a particular event, interact during various events, and/or continuously and repeatedly interact as part of a comprehensive story line involving a plurality of story lines. For example, as discussed previously, player characters PAand PBmay be a policeman and criminal respectively, who follow their own independent story lines, but are linked for certain events. However, both independent story lines may be part of, or aspects of, a comprehensive story line about the growth and development of a virtual city.

By linking various story lines of various player characters at select times or for select events, the story application122can advantageous control the allocation of server processing resources. For example, the processing, control, and generation of event816may be performed using server124A which may allow users, even user typically using different game servers, to interact with each other during a particular event816. Existing MMORPGs must distribute subsets of players among different servers that redundantly provide the same dungeons so that a player character using one server cannot interact with a player character using a different server, even though both player characters may be performing in the same dungeon. Thus, the story application122may determine and/or predict which events that certain users are likely to encounter. Based on the determination and/or prediction, the story application122may assign certain players characters to a particular server124A, while other player characters who more likely to encounter other events are assigned to another server124B. In one embodiment, the story application122may dynamically assign and/or transfer an avatar (or multiple avatars) from one server to another server to perform a particular event.

FIG. 9Ais a functional diagram of a system900for managing story lines according to an illustrative embodiment of the invention. The story application122may perform various methods using various functions to enable time, event, and/or opportunity based game play among multiple avatars. The system900may include a scene/event generator that supports multiple players PA, PB, and PCwho experience multiple avatar-specific story lines concurrently and/or support multiple instantiations of a story. Thus, the story application122may use multiple scene event generator routines and/or functions902,904, and906to independently generate events and/or scene related to each of the multiple players PA, PB, and PCand/or events related to multiple stories and/or multiple instantiations of one or more stories. Similarly, the story application122(e.g., system100) may use a story line tracker routine and/or function908that tracks the status910,912, and914of each of the multiple players PA, PB, and PCwithin their independent avatar-specific story lines concurrently or track status of one or more instantiations of one or more stories.

The story line tracker908may include a system of hardware and/or software that can store tracking data related to a player in a database. Tracking data may be recorded and stored in databases122A and/or122B. The tracking data, or recorded data, may include a player's elapsed time, completed activities, dungeons, events and/or availability. Subsequently, the stored data may be used by the scene/event generator PA902to determine the next scene or event for PA. The story line tracker908may also take PAstatus910, PBstatus912and PAstatus914as inputs to create a shared and/or linked event, such as event822(Event #5), to link the story lines of PA, PB, and PCtogether. The system100and/or story application122may provide one or more players with a user interface to configure tracking data used by the story line tracker908.

The system100and/or story application122, via the storyline tracker908, may create, for each player, a tracked or recorded video corresponding to the player's playing history including actions performed by the player. The databases128A and/or128B may store each player's playing history and its associated data. Players may view, pause, sample a portion of, rewind, replay, create copies of, share with another player, sell, and/or modify one or more videos corresponding to their playing history. This way, players can review and analyze their playing history to create better adventuring tactics, for example, for their future adventuring activities. Videos of a player's playing history may be labeled or categorized according to various methods. In some embodiments, each player's playing history comprises a plurality of videos, where each video corresponds to the player's playing history in a particular chapter of a story, book, interactive movie, game, and/or any combination thereof. In certain embodiments, to allow for a more granular categorization of playing history, each video corresponds to the player's playing history in a particular scene within a chapter or event. In some instances, a player's playing history within one story, book, movie, or game is stored as a single video comprising a plurality of segments, where each segment may be similarly labeled or categorized according to the exemplary methods described above.

Furthermore, each video and/or each segment of a video may be indexed in the databases128A and/128B. This way, players can easily search and view other players' playing history, allowing the players to, e.g., share their adventuring tactics. The system100may also enable players to post online image frames corresponding to videos or segments of a video of their playing history, in addition to allowing players to post videos of their playing history.

The scene/event generator PA902, the scene/event generator PB904, and the scene/event generator PC906of their respective story applications may render relevant virtual world objects for a given event. The scene parameter input916may include other player and/or game specific data relevant to generating a new scene/event. Depending on whether story lines are being shared by one or more players, the story application122may generate the same or different scenes for each player character. In one embodiment, the story application122and/or system900may provide users with an interface so that a user select920input enables a player to select a scene and/or event, generated and listed by the scene/event generator PA902, to be played next. In other embodiments, users can also configure the story application122and/or system900so that the event selector routine and/or function918can choose scenes or events for a player. A player may choose to configure the story application122and/or system900before, during, and/or after a playing a story application122.

Once a player chooses a new scene or event, the scene/event generator PA902may choose a new scene or event based upon a predetermined set of rules, the selected story line, selected adventure, or a random selection process. A random scene/event generator used in the scene/event generator902may be based on a random number generator or any pseudorandom number generator such as the Monte Carlo methods. After a scene is chosen, the gaming application122may then generate the objects associated with that scene using the scene/event generator PA902, PBand PC.

FIG. 9Bis a flow diagram of a method950for providing an interactive multiplayer story according to an illustrative embodiment of the invention. The method may be employed by the game servers124A and/or124B to advantageously provide players with interactive multiplayer stories. First, the interactive multiplayer story system100may store game data in a data store such as the databases128A and/or128B. Game data may include story line data associated with a plurality of story lines, where each story line may include event data (Step952). Second, the method950may also allow the interactive multiplayer story system100to store player character data for a plurality of users (Step954). The method may further enable the author clients106A and/or106B and user clients110A,110B and/or110C to interact with the game data stored in databases128A and/or128B.

Next, the scene/event generator902of the story applications122A and/or122B may generate a first story line including a plurality of events based on a portion of the event data (Step956) in response to a trigger condition. In one embodiment, the scene/event generator902can create a story line that is specific to a story and/or player by using the scene parameter input916. In another embodiment, the scene/event generator902can create a linked story line, such as the event816, based on the scene parameter input916to enable PAand PBto participate in the event816together. In some instances, the scene/event generator902generates one or more events related to one or more instantiations of a story so that various avatars are able to be joined to act out their various character roles associated the one or more events.

Then, the story applications122A and/or122B may provide a first interface arranged to enable a first user to control the interactions of a first player character within the first story line (Step958). Examples of a graphical user interface may include the screenshot700,1000, and/or1200. Other examples of an interface may include a mouse, a keyboard, a handheld controller, microphone, speaker, haptic interface, motion sensor, accelerometer, and/or other devices, without limitation, that enable a user to control the interactions of his player character. In one embodiment, an interface presented to one player can be the same as an interface presented to another player, such as, if PAand PBwere to participate in the event516concurrently during a linking period. Players may also customize interfaces based on their personal preferences. In another embodiment, once PAand PBhave completed the event516, the story application122may reconfigure players' respective interfaces to the form presented prior to joining a linked event. Other details about a user interface and the control of a player character are contained in the descriptions with respect toFIGS. 700,1000, and1200.

Further, the scene/event generator902may initiate a first event associated with the first story line in response to a first trigger condition (Step960). The trigger condition may be based on time, elapsed time, the completion of at least one prior event, the availability of at least one player character of the plurality of users to participate in the event. In certain embodiments, the triggers are stored as part of the scene parameter916. A player may also choose which of the triggers should be used by the scene/event generator for creating a new scene.

FIG. 10is a screen shot1000of a virtual environment including an indication of one or more upcoming events according to an illustrative embodiment of the invention. The screen shot1000includes a bulletin1002, a background setting1004and an avatar1006.

Depending on the configuration of a story application122, a player's avatar1006may be presented with the bulletin1002that includes a user interface having, for example, a list of upcoming events, which may be generated by the scene/event generator906. These events may include a scene, an adventure, a dungeon, short story, subplot, occurrence, an interaction with another player character or vactor, and/or any instance within a story line. In one embodiment, the bulletin902contains event828(Event #3) ofFIG. 8where the gaming application122has linked two story lines together for the player characters of players PBand PCto participate in the linked event828. In a second embodiment, the bulletin1002contains a list of events such as event814, event820, and/or event818to enable player PAto make a selection to enable her player character to experience one of the events.

The bulletin1002may be accompanied by an indicator to attract a user's attention, especially when events contained in the bulletin1002may include a linking opportunity for two or more players. An indicator may be a glowing graphical object, a token, a ticket, a message, an alert, an icon, a change in display contrast, a change in display image, a glowing portion of a display, a sound, a counter, a glowing page in a graphical book, and a change in a portion of an interface that is displayed to a user.

The bulletin may be positioned anywhere on the screen shot1000and be oriented in any direction. The events listed on the bulletin1002may be also presented in a pop-up window or contained in a tool bar. Users may further configure the design and location of the bulletin1002based on their preferences.

In one embodiment, events may be listed statistically on the bulletin1002. In another embodiment, the list of events on the bulletin1002can rotate so a user can view all the event descriptions in the case of having a list longer than the length of a bulletin1002. The ordering of events on the bulletin1002may be based on, without limitations, alphabet, correlation score calculated by the quality control unit1410, other player characters' rating, length of time, or any other game-specific and/or player specific ordering metrics. Users may also configure the ordering of events on the bulletin1002before, during or after a game and/or event.

FIG. 11is a block diagram of a gaming application122including a scripting routine and/or function1150according to an illustrative embodiment of the invention. The scripting function1150may be triggered automatically, may be user-enabled, or triggered automatically under certain user-selected conditions. While a player character is performing actions within a story line of a story application122, the story application122may assume full or partial control of a player character to perform a scripted set of actions to assist the player in acting out a part of a story and/or story line and, thereby, assist the player in performing social interactions or other interactions in certain player character situations.

FIG. 12is a screen shot1200of a virtual environment in which a player is prompted to use the scripting function1150according to an illustrative embodiment of the invention. The screen shot1200includes a scripting prompt1202, a virtual scene1206, a male avatar1202, and a female avatar1204. For example, a player may trigger the scripting function to ensure that their male avatar1202says the right things when interacting with a female avatar1204in a virtual bar. The female avatar's reaction may also be prescribed and/or controlled by the story application122if the scripting function1150is turned on by the female player1204.

Players may customize the scripting function1150. In one embodiment, the scripting function1150is configured to automatically provide responses under certain conditions. In a second embodiment, the scripting function1150is configured to be used minimally as a fail-safe at certain critical times, while allowing the player to handle most communications. A player may disable the scripting function or use the interface to enable the scripting function manually. The story application122may not reveal the use of the scripting function1150by one avatar to another avatar.

The design or format of the scripting prompt1208feature may come in various forms. In one embodiment, users can choose the type of the scripting prompt1208at the beginning of a game under the settings option. In a second embodiment, users can be prompted by a pop-up window to choose whether they wish to have the feature turned on or off. For example, the pop-up window may state “would you like to turn scripting on?” while providing “yes” and “no” button. In a third embodiment, the scripting prompt1208is displayed on the display screen along with the virtual scene1206.

FIG. 13is a flow diagram of a method1300for enabling player character interactions in an interactive multiplayer story according to an illustrative embodiment of the invention. First, the story application122may provide a user interface to enable a user to control a player character within the interactive multiplayer story (Step1302). The user interface may include a GUI or other interface that enables a player to control the movement, configuration, actions, and/or interactions of one or more player characters.

The story application122may track the actions of the player character within the interactive multiplayer story using, for example, a story line tracker function908ofFIG. 9A(Step1304). By tracking a player character's progression within a story line, the story application122can monitor the interaction events of a player character to determine whether the story application should take control of the player character using the scripting function1150.

Third, the scripting function may transfer control of the player character from the user to the interactive multiplayer story during an interaction event in response to an interaction condition (Step1306). An interaction condition may include a type of interaction, location of interaction, time of interaction, characteristics of the entity being interacted with, and user acceptance of the interaction condition.

Once an interaction condition is satisfied and/or triggered, the story application122may take control of a player character using the scripting function1150so that the actions of the player character follow a script and/or sequence directed by scripting function1150. In some embodiments, the interaction event includes at least one of a communication, a physical interaction, a mental interaction, a social interaction, a speaking, writing, acting out a part of a story line, performing an action, and performing a sequence of actions. An interaction condition may include a social interaction with a second player and/or player character. An example of such interaction is provided in the description forFIG. 12. Once the scripting function1150of the story application122finishes a scripted control sequence for a player character, the scripting function1150may automatically, and/or in response to a user prompt, transfer control of the player character back to the user.

In certain embodiments, the story application122may function as a training and/or educational application to enable employees and/or student to learn and/or acquire training and/or experience in performing certain tasks. For example, the story application122may provide a virtual representation of a building and/or facility. A security guard may use a player character to perform security functions throughout the virtual facility. The story application122may provide a variety of events and/or scenarios based on certain story-related trigger conditions. In this case, the story and associated story line may be related to providing security for the virtual facility. The user interface may provide any degree of interactivity with the user (e.g., security guard trainee) from providing a 2D interface to a detailed 3D interface (e.g., a virtual holodeck). The story application122may provide various story lines for employees, professionals, personnel, and/or students related to various occupational fields including, without limitation, health care, law enforcement, accounting, law, business, marketing, food services, transportation, entertainment, and/or the military.

FIG. 14Ais a diagram of a content creation platform1400according to an illustrative embodiment of the invention. The platform1400includes a content producer1402, a submission database1404, a marketer1406, a quality control system administrator1408, a quality control1410, a publication database1412, a sale platform1414and a sale application1418.

The content producer1402may be a developer who produces content used in an interactive multiplayer story, such as story applications122. The content producer1402may include one or more authors, novelists, writers of movie scripts, professional video game designers, level designers, music producers, or any other entities capable of producing contents used in an interactive multiplayer story. The content producer1402may produce content used in the entire story or only parts of a story. Similarly, the content producer1402may produce all levels in a game or some levels of a game. In some embodiments, the development server126as shown inFIG. 1may integrate story lines created by various content producers1412into one story. The content producer302may also submit content from various sources, such as the author client106A, to the submission database1404via the network102.

The marketer1406may include a person, group, or business that provides items and/or merchandise to players within a virtual world, provided by, for example, the gaming application122. The marketer306may include a company with a virtual establishment in the virtual world of the gaming application122. The marketer1406may use an advertising agency and/or any other entity to sell and/or market merchandise in a particular interactive multiplayer story or virtual world of the gaming application122. In one embodiment, development server126can be used to create all or portions of the merchandise for the marketers1406. In another embodiment, the marketer1406may outsource the development of their merchandise to another entity. The scene/event generator902,904,906, as described inFIG. 9A, may also tailor the merchandise of the marketer1406to a story and/or a player. All merchandise from the marketers1406may then be submitted into the “gaming submission” database1404through the network102. In one embodiment, the content producer1402and marketer1406collaborate on the development of a story line using the development server126so that merchandise is integrated into a story line before submitting to the database1404. The development server126may be operated by a content producer, a marketer, and/or the game producer. There may also be a plurality of development servers in various locations.

The submission database1404may include a memory and/or computing element that is capable of storing information electronically. The database1404may include one or more databases. The database1404may distribute an entire story or segments of a story across multiple databases. In addition to allowing the content producer1402and the marketer1406to store content into the submission database1404, the content producer1402and or marketer1406may also retrieve and edit their stored data to enable a developer to make future updates. The quality control unit1410may also retrieve data from the submission database1404. Certain communications with the submission database1404may be provided via the network102.

The quality control unit1410may include a system or a plurality of systems of hardware and software, used to determine which submissions in the submission database1404should be published. The quality control unit1410may be automatically initiated, developer enabled, or automatically initiated under certain pre-defined conditions. The quality control unit1410may utilize a computing system, a program, and/or one or more persons to perform quality control functions. A person, acting as an analyst, may be someone with sufficient experience in gaming design such as, for example, a gaming developer. The quality control system administrator1408may monitor the on-going submission process and perform maintenance diagnostics on the systems used in the submission database1404and the quality control1410.

To determine whether a submission should be published, the quality control unit1410may compare a submission against a set of acceptance rules. The acceptance rules may include quality of graphics, quality of image content, quality of theme, quality of actions, difficulty of story line, content rating, amount of offensive content, audio quality, correlation to other story lines, correlation to the interactive multiplayer story, size of the story line, the amount of merchandise included in the content, the amount of advertising in the content, the type of story, the genre of a story, the type of items in a story line, the effect of the story line on other story lines, the effect of story line on the interactive multiplayer story, popularity of the story line, number of votes the story line receives, and ranking of an author of the story line. Users, e.g. an analyst or administrator, may customize the acceptance rules by adding and/or removing additional rules based on preferences. The quality control unit1410may assign a numerical value, “correlation score,” to a submission, based on the number of acceptance rules a submission satisfies. The quality control unit1410may further include a person that reviews a submission via a user interface. Submissions may also be indexed and ordered based on their “correlation score” so that the most relevant submissions may be presented earlier on an interface to a player. The quality control unit1410may also include a correlation algorithm that can decide how relevant a submission is to a story line. A correlation algorithm may include a Bayesian or other types of learning algorithm that can adapt automatically.

In one embodiment, after being reviewed by the quality control unit1410, stories, level designs, merchandise, story applications or any other content submitted to the submission database1404may either be accepted and then stored in the publication database1412, or returned to their respective writers or designers for revision, or refused for publication. Subsequently, the quality control unit1410may review a returned and/or revised submission. In some cases, a submission may never enter the publication database1412.

Certain accepted submissions from the submission database1404may then be stored in the publication database1412. The publication database1412may include a plurality of databases such as the database128A and128B. In some embodiments, the user110A can enable a user to purchase various contents stored in the publication database1412through the sale platform1416.

The sale platform1416may be a system of hardware and software that displays products stored in the publication database1412by providing users with a graphical or textual interface. The sale platform1416may include game server124such that selling and/or marketing of game data to users is performed during, before, or after a user's gaming experience. Once a user has purchased and/or selected the desired content, the sale platform1416may process the request by retrieving the necessary executable computer codes for installing and running the story application122on the game server124A. Users may also install and run part of the story application122on a local machine, offloading work from the game server124A and/or the network102. Alternatively, the story application122may already have the software or code for the purchased gaming data (e.g., story, or item). Thus, the story application can be configured to enable the user to use the purchased gaming data.

While a user is participating in an interactive multiplayer story, the sale platform1416may trigger a scenario or present a scene, adventure, and/or story line for purchase. These scenarios or scene, adventure, and/or story line may at least be triggered by time, player character availability and any other event generating parameters in the scene parameter916. For example, when a male avatar and a female avatar are socializing in a virtual dance club, sale platform and/or application1416may trigger the display of various related items so that a male avatar may purchase an item, such as a martini, to show affection towards a female avatar, and, therefore, enhance the social interactions experienced by the players.

The sale platform1416may include a sale application1418that provides a mechanism for monetizing products purchased by a user. The sale application1418may provide secured communications via a network for monetary transactions and exchanges. It may further provide content producers with the ability to trademark, copyright, or patent their products within a virtual world, and, thereby, protect the rights associated with these contents.

FIG. 14Bis a flow diagram of a method1450for developing story lines for an interactive multiplayer story according to an illustrative embodiment of the invention. The interactive multiplayer story system100may employ the method1450to provide rich interactive multiplayer story related gaming content to a player. First, the story applications122or the development server126may interact with a content producer1402and/or marketer1406by providing an interface to enable the submission of a plurality of story lines (Step1452). An interface may be any graphical, textual, audible or haptic representation that allows a user to interact with a system.

The content creation platform1400may allow the author clients106A and106B to store the plurality of story lines in a data store1404(Step1454). The data store may include the submission database1404to which the content producer1402, the development server126, and the marketer1406may submit their respective content. In one embodiment, the story lines in a data store include an event, a plurality of events and a plurality of story lines. The story lines may include a saga, a dungeon, a quest, a short story, an episode, a scene, an occurrence and/or an interaction among characters. The story lines may include media content associated with a movie, television show, book, story, play, video game, video, and/or song.

The content creation platform1400may define acceptance rules for approving a story line for use in the interactive multiplayer story (Step1456). The acceptance rules may include quality of graphics, quality of image content, quality of theme, quality of actions, difficulty of story line, content rating, amount of offensive content, audio quality, correlation to other story lines, correlation to the interactive multiplayer story, size of the story line, the amount of merchandise included in the content, the amount of advertising in the content, the type of story, the genre of a story, the type of items in the story line, the effect of the story line on other story lines, the effect of the story line on the interactive multiplayer story, approval from a reviewer, popularity of the story line, number of votes the story line receives, and/or ranking of an author of the story line. The quality control unit1410and the quality control system administrator1408may follow the acceptance rules when reviewing content stored in the submission database1404.

Then, the content creation platform1400may review a first story line to determine whether the content of the first story line satisfies the acceptance rules (Step1458). In some embodiments, a story line or merchandise is reviewed by a person based on the acceptance rules, and the content creation platform1400can provide the person with a reviewer interface to enable him to review the content. The reviewer may provide an acceptance or denial of the content and the accepted content may be sent to the publication database1412. For content that satisfies the acceptance rules, the sale platform1416and the sale application1418may prompt the user to purchase the story line via the user interface, whereas the prompt may occur while the user is playing an interactive multiplayer story application122, or before or after the user plays the role-playing story application122. Finally, the sale application1418may integrate at least one item of merchandise into a story line and set intellectual property rules associated with the item in the interactive multiplayer story.

It will be apparent to those of ordinary skill in the art that methods involved in the present invention may be embodied in a computer program product that includes a computer usable and/or readable medium. For example, such a computer usable medium may consist of a read only memory device, such as a CD ROM disk, conventional ROM devices, or a random access memory, a hard drive device or a computer diskette, a flash memory, a DVD, or any like digital memory medium, having a computer readable program code stored thereon.

Persons skilled in the art will appreciate that the various configurations described herein may be combined without departing from the present invention. It will also be recognized that the invention may take many forms other than those disclosed in this specification. Accordingly, it is emphasized that the invention is not limited to the disclosed methods, systems and apparatuses, but is intended to include variations to and modifications thereof as understood by those skilled in the art with respect to the following claims.