Patent Application
20170340962
The present specification relates generally to alternate reality gaming and more specifically relates to a player-director alternate reality game where a director customizes activities within the game based on activity data from a player.
An alternate reality game is an interactive experience that uses a combination of a fictional world and the real world as a platform to tell a story. Alternate reality games require significant user involvement as the storyline is affected by a user's actions, namely, a user's interaction with other users, characters and storyline elements. Alternative reality games can be differentiated from traditional games, which are designed for a user to escape from reality.
With presently available alternate reality games, users experience the narrative collectively at varying rates which can interfere with their individual enjoyment as some users set a faster pace of content consumption. Furthermore, some alternate reality games exist as a single instance with less replay value once they have completed their first run. One method alternate reality games have incorporated to address this is the requirement to interact with a multimedia device, whereby the device communicates the narrative to the user and the user inputs activity data into the device. This allows instances of the alternate reality game to separate users but removes the variability that a puppet master can provide to a dynamic narrative. For educational purposes, some teachers and parents (where the game is targeted at children) may find that there is a lack of interaction and collaboration on their behalf.
Accordingly, there remains a need for improvements in the art.
In accordance with an aspect of the invention, there is provided a system, method and computer program for a customizable player-director alternate reality game where a director customizes activities within the game based on activity data from a player.
According to an embodiment of the invention, the present invention provides a method for a customizable player-director alternate reality game comprising a host server capable of sending and receiving data over a computer communication network, a director using a director computer communication device capable of sending and receiving data over the computer communication network and a player using a player computer communication device capable of sending and receiving data over the computer communication network, the method comprising:
Further, the method may include branches, wherein branches are a sub-type of gate, and branches comprise actions which include a decision by one of the player and the director, wherein the decision results in the selection of one gate from a set of multiple gates, such that the script is subsequently followed along a path defined by the selected gate. Still further, the branch may include instructions to the director enabling the director to modify the script such that the branch contains one or more of: a new gate in addition to existing gates, a new gate replacing an existing gate, a modified gate replacing an existing gate, and fewer gate from deletion of an existing gate, wherein the modifications are sent to the host server from the director computing device and the modifications are limited to the instance of the game.
According to a further embodiment, the present invention provides a system for a player-director alternate reality game, comprising a computer communication network; a director computer for use by a director, wherein the director computer is capable of sending and receiving data over the computer communication network; a player computer for use by a player, wherein the player computer is capable of sending and receiving data over the computer communication network; and a host server capable of sending and receiving data over the computer communication network to and from the director and player computers, wherein the host server comprises a script module for storing one or more scripts wherein the scripts each contain a list of gates to create a corresponding game instance, a game module for initiating an instance of the game for the director and the player, and an interaction module for receiving customization instructions from the director, customization gates for the player based on the customization instructions, sending gates to the director computer and the player computer, and receiving completion indications from the player computer and the director computer.
According to a further embodiment, the present invention provides a computer program product comprising a storage medium configured to store computer-readable instructions; the computer-readable instructions including instructions for,
Other aspects and features according to the present application will become apparent to those ordinarily skilled in the art upon review of the following description of embodiments of the invention in conjunction with the accompanying figures.
Reference will now be made to the accompanying drawings which show, by way of example only, embodiments of the invention, and how they may be carried into effect, and in which:
Like reference numerals indicate like or corresponding elements in the drawings.
In the following, “game” shall be understood to include, without limitation, entertainment activities, educational activities and training activities.
According to an embodiment as shown in
For reference, in the context of the present application, it is noted that the “player” may be a group or two or more players, or multiple groups or one or more players, and groups may be working cooperatively or competitively. Furthermore, groups and cooperative or competitive status may be determined by the script, the director, and/or the actions of the player.
According to an embodiment of the invention, script 110, may be written in an XML-derived language. The script 110 may describe the entirety of the sequence of actions that comprise an activity, and may be used by the system to evaluate incoming data with reference to the activity, as well as to generate output when the activity calls for it. The script 110 may be composed of a sequence of nestable elements. Each element may be a description of an action that a director or a player may perform, a grouping of related child elements, or a system directive. The description of an action may have the following components: a role that may perform the action, a unique name of the action, per-action attributes that may further define expected behavior, and metadata that may be used to describe the action in a director dashboard, such as director dashboard 120. Collectively, the nestable elements are referred to herein as gates, such that the script 110 tracks completion of each gate in reference to progress through the script by the player and the director.
Conceptually, the script 110 defines roles that are assigned to users—the director and the player. Within the script 110, roles are assigned to users according to the gate and the sequence of gates. Therefore, the multiple roles may be assigned to the same user over the course of the script 110, or the same role could be assigned to different users at different gates in the script 110, or other variations thereof.
According to an embodiment of the invention, an execution controller may parse script 110, build a programmatic model of component actions, and connect to available input/output modules. When input arrives via a module, it may be compared to expected actions at a current point in the script 110. If the input matches one of currently available defined actions, the execution controller may advance the script 110. If at any time an available action is meant to be performed by a system role, the execution controller may immediately dispatch it to the appropriate output module and may advance the script 110. The execution controller may be invoked whenever new input arrives to the system via an input module, whenever an action is performed in a director dashboard, such as director dashboard 120, and at regular system-defined intervals of time.
According to an embodiment of the invention, most input and output to and from a system may be implemented by modules, such as modules 145. The module system may be designed to simplify addition of additional modules that implement new functionality. Each module may define one or more of the following: named actions, output handlers, input handlers, and content resolution methods. The name of an action implemented in a module may become a new verb that may be used in a script, such as script 110. To implement an action, the module may provide an action handler function for the execution controller to call when attempting to complete that particular action at the point defined in the script 110. Output handlers are functions that may take arbitrary data and may render it through an output channel, such as output channel 135. While not directly used by the execution controller, action handler functions within this module and other modules may take advantage of output channels 135 for different behavior. Input handlers are functions that may take arbitrary data via a web request and may invoke the execution controller. Each handler may have a chance to process incoming data and may create a customized action record, which may then be passed into the execution controller for processing. From here, one of the modules named action handlers may use the data to implement the necessary behavior within an activity.
According to an embodiment of the invention, a director configures an activity for a player to complete. Events may be collected into a separate application that may be designed ad-hoc for each activity. Each separate application may have its own games and interfaces for an activity. Each separate application may communicate with a main system by way of an API provided by the system. The API may make the following functions available: may authorize the user and may link the user to an activity inside the system via an authorization code generated by a client application module, may authorize the director for administrative actions within the application via the director's standard login, may retrieve a feed of events generated by the client application module, may add an event setup by the director to the feed and may make the event available for the player to complete inside the application, and may mark an event as complete, wherein this form of input is handled by the client application module and may cause an execution controller to progress the activity.
An activity may be composed of a linear sequence of actions whereby each action may be performed by a director or a player. The bulk of an activity may consist of setup actions by a director interleaved with play actions by a player. The nature of the actions may vary widely and input/output module API may allow the capacity for a system to recognize new types of actions. Example actions that may already be recognized by built-in modules may include: filling in web forms, visiting webpages, making phone calls, puzzles, sub-games and physical interactions. For a type of action to be added to the system, the action may be performed with an internet-enabled object or interface.
Actions may be performed by a player or a director using objects with no capability for online communication as part of an intended part of an activity. These actions may not be technically referenced within a script, such as script 110. Alternate instructions may be given to a player that describe such an action, and may ask the player to perform the action. The player or director may confirm completion of the action within an internet-enabled interface. Confirmation of completing the action may be the action technically referenced within the script 110. Actions that must be competed for the script 110 to progress may further include an indication of completion state, which is passed to the host server.
Each action may be described by a scripting language, e.g. XML. The description of an action may contain an identifier indicating the type of the action. When the execution controller processes the script, each action in the script may be represented by a node object in memory. The node object's implementation in code may be provided by a module, which declares the connection between the action identifier in script and the node implementation in code. The behavior and functionality of the action may be provided by implementation of the node's run method.
A key type of action may be the data action provided by the data module, which many other action implementations extend. This action may collect arbitrary data from an HTTP request, store the arbitrary data, and compare the arbitrary data against validation rules defined in the script to determine if the action was successfully completed. This functionality may allow easy implementation of generic “setup” actions, as implementations for these can simply inherit functionality from the data action, and then may perform additional processing on the collected data. There are two particular action/modules that may do so in order to provide additional boilerplate actions: the choice action, that stores a single piece of collected data for examination by other actions; and the confirmation action, that checks a single piece of collected data to ensure it matches an expected value.
In addition to individual actions, scripts may include definitions of branches and threads. A thread may be a collection of actions, branches and sub-threads. The contents of a thread may consist of anything that can appear in a script, including other threads. The entirety of a script is in fact a single implicitly defined main thread. When a thread is activated by the execution controller (as the main thread is when the activity first starts), it may be processed and tracked by the execution controller as a parallel sequence of actions on all subsequent invocations. Input into the system may be handled by all active threads simultaneously, and output may be generated from all active threads simultaneously. When the final action in a thread is completed, the thread may be terminated. Branches may function like threads, but multiple branches may be defined within a single set, and only one branch within a set may become active. Additionally, branches may not be processed in parallel; when the execution controller begins processing within a branch, it may continue exclusively within that branch until the branch ends.
According to an embodiment as shown in
The method may then return one of the following:
According to an embodiment as shown in
According to an embodiment as shown in
According to an embodiment as shown in
According to an embodiment as shown in
According to an embodiment as shown in
According to an embodiment as shown in
According to an embodiment as shown in
One example of a game according to an embodiment of the invention is a scavenger hunt. In this example, the director is a parent and the player is a child, and the director hides physical clues for the player to find. The clues must be combined to solve a puzzle. For example, the clues may be stanzas of a poem which, when read in sequence, presents a riddle to which the solution is the final goal of the scavenger hunt.
The script for this activity would contain two actions. The first is the director's setup, for example represented by an action called “setup scavenger hunt”, and implemented by a scavenger hunt setup node in code. The second is the player's completion, for example represented by an action called “complete scavenger hunt”. These two actions, as well as all the events contained therein, are the gates for the scavenger hunt script.
The setup action is performed by the director using a director dashboard, such as director dashboard 900. To customize the game, the director needs to determine the location for concealing each of the clues, and the actual concealment, as each director will have a personalized layout (e.g. indoor vs. outdoor, number and layout of rooms, etc.). Based on the concealment locations, the director must then compose textual hints, such as textual hints 930, for the player to find the clues, for example, according to the age of the player (e.g. written or visual, difficulty, etc.), and submit these to the host server. Once completed, the director notifies the host server by pressing ready to hunt button 920 and the host server contacts the player to advise them that the scavenger hunt is ready to play, in accordance with the embodiments of the invention as described above.
The notification is sent to the player, for example, as a message through a messaging system received at the player's computing device, preferably a portable device, such as a tablet or phone. The player then engages in the activities (reading hints and searching for clues), and uses their computing device to indicate completion of each activity (finding a clue) and for completion of the game (inputting the final solution into the device). The host server receives these indications, and transmits completion information to the director. Thus, the host server may, according to the game script, present the player with the hints customized by the director as each clue is found, and with the final reward or notification thereof (which may also be customized) on completion of all activities.
The provision for information to pass from the player to the director further enables the director to act to modify the game in progress if necessary. For example, if the time since the last hint was provided appears unduly long, the director can provide an additional hint. Or if the player has found a clue out of order, the sequence of provided hints can be changed. The player remains unaware that the game was changed, and enjoys a seamless experience.
Furthermore, the customization enables the game to be executed for educational as well as entertainment purposes. For example, the hints (and clues) may be presented as mathematical problems, musical arrangements, spatial/geometric puzzles, or combination of different elements in accordance with achieving a desired educational objective.
Another example of a game according to an embodiment of the invention is an online training simulation in communication for medical practitioners. In this example, the director is a program educator, the player is a medical resident and the script presents a medical diagnosis to be communicated e.g. a terminal illness. The activities are represented by information elements that must be presented and received over the course of the game by the player.
In this example, the customization by the director may include player-specific information, such as name, email address and location, which is then implemented into the script into those gates which require communications to be sent to the player. Certain scripts may permit advanced customization, such as to the content of the communications. As the player proceeds through interacting with the online simulation, the host server notifies the director of gate completion, until the simulation is terminated. At certain gates, the player responses may create branches requiring a decision from the director, which is another gate. For example, a player response, once received, could require classification into one of three categories: complete, incomplete and inappropriate, where each category, according to the script, follows a separate path of gates each starting with a request for the next player response, but structured according to the category of the previous response.
The host server also provides the ability for the director to modify the script and activity as the player progresses, for example, enabling early termination of the simulation if specific activities are met or failed. Additionally, the host server may queue player responses such that the director may monitor multiple players, for example, in a classroom setting.
The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Certain adaptations and modifications of the invention will be obvious to those skilled in the art. Therefore, the presently discussed embodiments are considered to be illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than the foregoing description and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
