>The audio subsystem 25 may store and render various audio files that may be used during game play that may be triggered for play by the moderator 15. The audio subsystem 25 may include commercially available audio libraries, such as open-source JavaScript audio libraries like the Howler Media server (which also serves as a sound driver), other HTML5 audio libraries like Amplitudejs, Waud, and Soundcloud Audio.js, and/or it may be a library created in-house or by a third party to store various audio files for use in the game. In some embodiments, the audio subsystem 25 may be a sound playback engine.

The graphics rendering subsystem 26 may allow the rendering and display of various graphics files that may be used during game play, and queued and initialized for display by the moderator 15. The graphics rendering subsystem 26 may include commercially or open-source available graphics rendering engines, such as JavaScript graphics rendering engines like Pixi.JS (which may require an MIT license) or may be a graphics rendering engine created in-house or by a third party. In some embodiments, the graphics rendering subsystem 26 may be a browser 2d WebGL rendering engine and may be either open source or proprietary.

Other libraries 27 may include additional audio, visual, both (e.g., video), font, or the like, libraries that include media or other files that can be used to contribute to the look and feel of the game system's aesthetic in combination with the other subsystems above.

The game script 28 may define the features of the game (see, e.g., game features 42 discussed with respect to FIGS. 5-6 below), including the story and the media files that will be visible and/or audible to the players 14 during the game. The game script 28 contains code and declarations that define user interfaces for the game that can be run by the game engine 24. The game script 28 specifies the user interface components used by the moderator user interface 35 and the player user interfaces 34, discussed in more detail below. The order of user interface components in the game script 28, and consequently the moderator user interface 35, controls the order of the events in the game presented by the moderator 15. Changing the game script 28, or creating different game scripts, can create alternate games that can be run by the game engine 24, for example, run on other web sites dedicated to those specific games. In the current embodiment, the game system 10 is run on SavageHall.com.

The game script 28 may be an XML (e.g., XML-based UI markup language) in its native form, so that it can be read by the game engine 24. While it is possible to create the game script directly in XML, it is not ideal because XML is not particularly user-friendly. The game script 28 may be created in a spreadsheet format and converted to XML (e.g., XML-based UI markup language) by, for example, a python script, so that the game software 16 (e.g., the DAT-engine 32, discussed in more detail below) can access and execute the game script 28. The DAT-engine 32 may iterate through all the XML nodes and create the moderator user interface 35, discussed in more detail below. In some embodiments, the data from the spreadsheet may be hardcoded into the game code of the DAT-engine 32, or a program may be used instead of hardcoding. However, the present disclosure is not limited thereto. The game script may be created directly in XML or any other suitable format and may be imported into the game software 16 in any suitable format that can be read by the DAT-engine 32. In some embodiments, the game script 28 may be created by a custom editor that allows the user to input data and drag-and-drop files in a user-friendly manner.

The game script 28 may specify which files, including media files, that the players 14 will see and experience during the game play. The game script 28 may lay out the audio, visual and/or other media files that are uniquely seen by each of the players 14. In the current embodiment, game script is the Savage Hall script. The game script 28 may be loaded by the moderator 15 (e.g., loaded by the moderator instance of the DAT-engine 32 being run on the moderator's browser) and may not be accessible to the players 14.

FIG. 4 is a diagram of a portion of the game script 28, according to one or more embodiments of the present disclosure. In the present embodiment, the game script 28 is in a spreadsheet format (such as an excel or google spreadsheet); however, embodiments of the present disclosure on not limited thereto. The game script 28 may be created in any suitable format, including, but not limited to, a text document and/or any suitable graphical form. In the present embodiment, the game script 28 is a google spreadsheet that is converted by a python script to XML (e.g., an XML-based user interface markup language) used by the game software 16, e.g., the DAT-engine 32 of the game software 16.

The game script 28 may defined in the rows of the spreadsheet, with each row being a game feature (e.g., game features 42 described in more detail below) at a different stage (or step) of the game. Each step may have different audio files and/or image files and the names of the audio files and image files may be embedded as attributes. In other words, the game script 28 is organized as a series of game steps. In the present embodiment, the rows are organized in chronological order based on the order in which the game features 42 (discussed in more detail with respect to FIGS. 5-6 below) should appear in the game, with each row representing a different game feature 42. The DAT-engine 32 iterates through the game features 42 (e.g., the rows) of the moderator user interface 35 to access and initiate each game feature 42 of the game. However, the present disclosure is not limited thereto and the game script 28 may be organized in any suitable format.

In the present embodiment, the header row 41 may include descriptions of what each column contains, and each following row may include a game feature 42 and the media file(s) associated with that game feature 42. The media files linked to the game features 42 may include music or other audio cues, images, videos and/or graphical displays for a specific part of the game (e.g., Act 1, Act, 2, etc.). Hereinafter, music, sounds and other audio will be referred to as audio files and images and other graphical displays will be referred to as visual files. In some embodiments, videos may be treated the same as audio, as video files needed to be played or streamed. In other embodiments, videos are treated as a separate category of file. These media files may be stored on the web server 22 and are loaded and/or streamed from the audio subsystem 25, the graphics rendering subsystem 26, or other libraries 27. The media files may be accessed by the DAT-engine 32 and pushed to the players 14 through the high-level engine 31 (using resource loaders from the audio subsystem 25 and/or the graphics rendering subsystem 26). In other embodiments, the visual files may be stored locally, in the audio subsystem 25, the graphics rendering subsystem 26, and/or in other libraries 27, and may be access and pushed to the players by the DAT-engine 32.

For example, a first row of game features 42 may include artwork (e.g., a visual file) to be shown to the players 14 during the opening “Title” page of the game. In the present embodiment, the artwork shown to the players 14 on the opening “Title” page is the same for all the players 14. However, the artwork may differ for some or all the players 14. For example, in the game feature 42 row for the “Scene Overlay” for “Act 1,” each of the players 14 receives a different visual (e.g., art) file. An overlay represents a visual file that can be superimposed over a player's screen/browser window. It may also include interactive features, such as multiple-choice questions.

As labeled in the header row 41, a type column 50 may be included that provides the type of file for each row (e.g., what type of audio or visual file(s) that row includes as it relates to the game. This type information may be used by the DAT-engine 32 to send messages between the moderator 15 and the players 14, as discussed in more detail with respect to FIG. 7 below. File types in the type column 50 may include types of audio files, such as sounds, music, or long audio streams (e.g., stream), and types of visual files, such as overlays.

A description column 51 may be included that provides a description of the file in each row (e.g., what part of the game the game feature 42 in that row pertains to). A button column 52 may be included to designate the type of button to appear on the moderator user interface 34 for that row (described in more detail with respect to FIGS. 5 and 6 below). A group column 53 may be included that defines the group (e.g., audio or visual) into which the game feature 42 in that row falls into, and the character roles columns 54 may be used to designate the specific files that will be received by each player 14 for each game feature 42. For example, for the “Audio” of “Act 2,” Player 1 will receive the audio file “A21.mp3” stored in the “Audio” folder. Players 2-6 will receive the audio files “A22.mp3”-“A26.mp3,” respectively, also stored in the “Audio” folder. The game script 28 designates which files will be received by which player 14 during each and every part of the game. The game script 28 may be easily accessed and edited to facilitate changes to the game play and/or to easily create new games by simply filling the game features of the new game into the game script form. While the embodiment of FIG. 4 includes type, description, button and group columns 50-54, the present disclosure is not limited thereto. For example, the group column may not be provided and the information regarding whether the media files are audio or visual may be determined based on the information provided in the button column 52 and/or the type column 50. Further, other columns may be included based on needed or desired features for the game.

While FIG. 4 only includes eleven game features 42, the present disclosure is not limited thereto. The game script 28 can include as many or as little game features as needed or desired to represent the game.

In some embodiments, the game script 28 can have a custom layout created by a custom editor in which various files can be uploaded, and/or dragged and dropped into the interface, or otherwise incorporated into the game script 28 for use, display, or playing during the game play and the game script 28 may later be compiled to XML or other suitable format for use by the game engine 24. Rulesets, ordering, and clickable options could also be modified in the moderator's interface so that it would change the sequencing of what the players sees and hears (e.g., the sequencing of game features 42 described in more detail below). The custom layout may be based on a Box, VBox (items arranged vertically), HBox (items arranged horizontally), XGridRow, Spacer or XMLBox nested container systems. The custom layout can be declarative and defined using XML. (e.g., similar to Adobe Flex MXML and React JSX). Additional features may include the capability to display text buttons, sprites, animated sprites or other programmatic animation, and the components can be ordered or have absolute positioning (for example, absolute positioning based on percentages). In such embodiments, the game script may be provided as an external software package (e.g., a web-based app or native desktop app) that will allow an end-user to create the game script via drag and drop operations and/or simple choice-based questions. The software package may have a custom layout and may be built on a high level engine, such as the high-level engine 31 discussed in more detail below.

Referring back to FIGS. 2 and 3, the package manager 29 may allow for automatic installation, compiling and/or management of external libraries, such as those used in the audio subsystem 25, the graphics rendering subsystem 26 and the other libraries 27 above. The package manager 29 may also include a repository of libraries itself. The package manager 29 may be an external tool used to package the code (e.g., all the code) used by the game, including, for example, the game engine 24, the audio subsystem 25, the graphics rendering subsystem 26 and the other libraries 27. The audio subsystem 25, the graphics rendering subsystem 26 and the other libraries 27 can be installed from the package manager 29. For example, open source node.js may be used as the package manager 29 and node.js includes a repository has thousands of 3rd party libraries that can be included into an application in addition to being a package manager. However, the present disclosure is not limited thereto, and any other suitable package manager, open source or proprietary, may be used.

The client side 18 may also include a web browser 30, which will be located on each of the player 14 and moderator 15 computers or mobile devices. The web browser is what each player 14 and the moderator 15 will use to run the game software 16. The web browser 30 used will depend on what the user (i.e., the player 14 or the moderator 15) has on his/her device, and can include web browsers such as Chrome, Microsoft Edge, Safari, Firefox, Opera, and the like. The game software 16 may be developed so that it is compatible with a variety of web browsers. Further, the game software may be developed to have different versions for the players 14 and the moderator 15 that will be run based on whether the moderator or player instance is chosen during installation and launching of the game. For example, there may be a player instance and a moderator instance of the DAT-engine 32 of the game software 16.

In some embodiments, the game software 16 may also include other communication protocols, such as a client side 18 implementation of the multiplayer-enabling server 23 (see, e.g., top right of FIG. 3) to allow the game software 16 to communicate with the game server 11. For example, Smartfox Server 2X includes a client side JS file to allow communication with the Smartfox Server 2X.

The game engine 24 may include a high-level engine 31 for resource loading and graphics rendering. This high-level engine 31 may utilize the graphics rendering subsystem 26 for implementing resource loading and graphics rendering. The high-level engine 31 may also allow organizing of operations, game state management, object life-cycle management, and sequencing of code and animations at a high level. The high-level engine 31 can provide the “glue” that allows a DAT-engine 32 to communicate with the multiplayer-enabling server 23, and may support the user interfaces 35 and 34 of the moderator 15 and players 14, respectively. For example, the DAT-engine 32 may not directly communicate with the multiplayer-enabling server 23, but the high-level engine 31 may have “glue” classes to communicate with the multiplayer-enabling server 23. Having a separate high-level engine 31 may allow for easier switching to a different multiplayer-enabling server, if desired. In some embodiments, the open-source game and application framework Pixi Engine, which uses PixiJS, may be used as the high-level engine 31 (source code for Pixi Engine is available at: https://github.com/wuey99/pixi-engine). Pixi Engine is an open-source game and application framework built on top of PixiJS. Pixi-Engine includes various “glue” classes such as “ConnectionManager.ts,” MessagingManager.ts,” and “SFSManager.ts” to communicate with the multiplayer-enabling server 23 (e.g., SmartFox Server 2X), allowing the DAT-engine 32 to communicate with the SmartFox Server 2X. However, the present disclosure is not limited thereto and any other suitable application framework or high-level engine may be used. In some embodiments, the high-level engine 31 may not be included and the DAT engine 32 may instead perform the features of the high-level engine 31.

The game engine 24 also includes a DAT-engine 32 which converts the XML (e.g., the XML-based UI markup language) of the game script 28 into the moderator user interface 35 and also allows for simultaneous, synchronized distribution of the audio, visual and/or audiovisual cues to each player 14 as designated in the game script 28. The DAT-engine 32 may drive the game system 10 based on the files designated in the game script 28. The DAT-engine 32 may be built on top of the high-level engine 31 to leverage the state management of the high-level engine 31.

The DAT-engine 32 may access and use the game script 28 to control the game flow and audio and visual features designated on the moderator user interface 35 and showed or played on the player user interfaces 34. For example, the DAT-engine controls and outputs the various visuals that create scene changes for each player 14 on that player's user interface 34. In other words, the game script 28 may be fed into the DAT-engine 32 and used to drive the moderator user interface 35 and the player user interfaces 34. The DAT-engine 32 may also handle room creation, logging in and joining rooms.

The DAT-engine 32 is designed so that modifications to the game, or new games can be implemented without the need to re-program the DAT-engine 32. In some embodiments, the game script 28 is embedded/compiled into the DAT-engine 32 directly, while in other embodiments, the game script 28 may be loaded at a particular URL and the moderator 15 can upload the URL of the game script 28 into the DAT-engine 32. In such embodiments, the game script 28 can be changed and the changes will be automatically implemented by the DAT-engine 32 when the game is loaded or re-loaded.

While in the current embodiment the moderator 15 controls when each game feature 42 is displayed for the players 14, control could also be automated to occur directly by the DAT-engine 32. In other words, the DAT-engine 32 could direct the game system to automatically move from one game feature 42 to the next game feature 42 based on actions of the players 14, as opposed to the moderator 15 manually moving to the next game feature 42.

The game software 16, including the DAT-engine 32, allows the moderator 15 to control the specific audio and image streams sent individual players 14. Depending on the game script 28, the audio/image information sent to each player 14 may or may not be different. This allows the creation of different perspectives of the game progression for each player 14. When players 14 are connected via the video conference server 13, they can choose to share information that other players 14 may not have in order to try solve the puzzle of the game.

The moderator user interface 35 is created by the DAT-engine 32 and incorporates the data regarding the game features 42 from the game script 28, thus using the game script 28 to drive the multimedia experience. The moderator user interface 35 directs scene changes, audio commands, etc. to be sent to players 14 via the multiplayer-enabling server 23. The order of events in the game may be defined by the order of the game features 42 in the game script 28.

The moderator user interface 35 may include one or more graphical user interfaces and/or other displays. For example, when starting a game on the game system 10, the moderator user interface 35 can have a graphical user interface or display that allows the moderator 15 to create a ‘game room’. The game room is used to host the players 14 for each instance of a particular game. The moderator 15 may assign a room ID (e.g., a GUID) for a specific game (e.g., a game previously selected by the players 14) that the moderator 15 can provide to the players 14 so that the players 14 can login to the specific game. The moderator 15 can also assign character roles 54 to each of the players 14 (see, e.g., FIGS. 5 and 6 showing a graphical user interface in which the character roles 54 have been assigned). The character roles 54 will determine what audio and visual files each player 14 will receive. In other words, the players 14 will receive the audio and visual cues specific to the character role 54 they are playing the in the game. While the character roles 54 are assigned generic names Player 1, Player 2, Player 3, etc. in FIGS. 5 and 6, the character roles 54 are not limited thereto, and any suitable character role names may be used. For example, in the Savage Hall game, the character roles are named after the characters the players 14 are playing in Savage Hall, namely, Aggie, Calloway, Goodwin, Grace, Isaak and Marcel.

The moderator user interface 35 be a graphical interface, a display, message window, pop-up or any other suitable graphical interface for sending messages (e.g., commands), so that the moderator 15 and communicate with the players 14, as described in more detail below with reference to FIGS. 5 and 6. The moderator 15 can send messages to individual players 14, or may broadcast messages simultaneously to all the players in the room. The player user interface 34 may include a different or distinct graphical interface, a display, message window, pop-up or any other suitable graphical interface for receiving and/or sending messages, so that the players 14 can communicate with the moderator 15. The messages and/or commands between the moderator 15 and the players 14 (e.g., the moderator user interface 35 and the player user interface 34) may be relayed by the multiplayer-enabling server 23.

FIGS. 5 and 6 are examples of a graphical interface the moderator 15 of the game system 10 may use to communicate and/or send commands/messages to the players 14, according to one or more embodiments of the present disclosure. In other words, the graphical user interface of the moderator 15 may be an interactive visual representation of the game script 28 that allows the moderator 15 to initiate the sending of the media files defined by the game script 28 to the players 14. FIGS. 5 and 6 show the same graphical user interface at different points in the game play. As shown in FIGS. and 6, this graphical interface may be a display that is part of (e.g., may be included as part of) the moderator user interface 35. While the graphical interface of FIGS. 5 to 6 will be hereinafter referred to as the moderator user interface 35, the interfaces shown in FIGS. 5 to 6 may only be part of the moderator user interface 35 and other graphical interfaces may be available to the moderator 15. The other graphical interfaces may be available to the moderator 15 on the same screen or the moderator 15 may be able to switch to one or more different screens that includes other graphical interfaces.

The moderator user interface 35 may include rows that contain one or more game features 42. The game features 42 may be linked to one or more media files that pertain to the game as provided by the game script 28.

The first column of the moderator user interface 35 may be a description column 51 that includes the same information as provided in the description column 51 of the game script 28 (see, e.g., FIG. 4). The first and second button columns 61 and 62 may include interactive buttons that can be pressed by the moderator 15 to allow specific media files to be shown to or played for the players 14. For example, when the moderator hits the “Show” button in the first button column 61 for a corresponding game feature 42, one or more pre-loaded (or pre-selected) visual files may be displayed to the players 14. The visual files may be the same, similar and/or unique for each player 14. For example, one or more of the visual files may be the same for one or more of the players 14, respectively, and one or more of the visual files may be different for one or more of the players 14, respectively. In some embodiments, all the visual files for the players 14 may be different (e.g., each player 14 may receive a different visual file for a single game feature 42, such as “Act 1”) or all may be the same (e.g., each player 14 may receive the same visual file for a single game feature 42). Visual files, including files containing images and/or video, may be pushed to the players 14 through the high-level engine 31 in the game engine 24.

For example, when the moderator 15 presses “Show” in the first button column 61 for the game feature 42 labelled “Act 1,” the linked visual files may be displayed to the players 14 on the player user interface 34. The linked visual files may include a scene overlay related to Act I of the game play. These visual files may correspond to the visual files designated for each player 14 in the corresponding row of the game script 28, e.g., the sixth row of game features 42 in FIG. 4 for the Scene Overlay of Act 1. As shown in FIG. 4, each of the players 14 will receive a different visual file in Act 1 that corresponds to the player's character role 54.

After the visual file is shown to the players 14, an indicator 67, such as an “X,” may appear in the row for the selected game feature 42 under each character role 54 column to show that the visual file was received by the player 14 having the character role 54 of that column and shown to the player 14 having that character role 54, as shown, for example, in the third game feature 42 row in FIG. 5. In some embodiments, each player 14 may have more than one indicator, for example, first and second indicators 66 and 67, to indicate different conditions, as described in more detail below. After all the players 14 have received and been shown the visual file as indicated by the second indicator 67, the moderator 15 may press the “Play” button in that row if there is one, or if not, the moderator 15 can press the “OK” button in the third button column 63 to move to the next game feature 42. While in the illustrated embodiment the moderator 15 presses “OK” to move to the next game feature 42, the present disclosure is not limited thereto, and the game may automatically continue to the next game feature 42 after all the players 14 have received and been shown the visual file (or after all the players 14 have received and played the audio file).

When the moderator presses the “Play” button in second button column 62 for a corresponding game feature 42, one or more pre-loaded (or pre-selected) audio files may be played for the players 14. The audio files may be the same, similar and/or unique for each player 14. For example, one or more of the audio files may be the same for one or more of the players 14, respectively, and one or more of the audio files may be different for one or more of the players 14, respectively. In some embodiments, all the audio files for the players 14 may be different (e.g., each player 14 may receive a different audio file for a single game feature 42, such as for “Act 1”) or all may be the same (e.g., each player 14 may receive the same audio file for a single game feature 42). Audio files, including files containing music, sound or other audio, may be pushed to the players 14 through the high-level engine 31 in the game engine 24.

For example, when the moderator presses “Play” in the second button column 62 for the game feature 42 of “Act 1,” each player 14 may be played a unique and distinct audio file audible through the player user interface 34. Each linked audio file may include audio relevant to each player's character role 54 in the game. These audio files may correspond to the audio files designated for each player 14 in the corresponding row of the game script 28, e.g., the seventh row of game features 42 in FIG. 4 for the Audio of Act 1. As shown in FIG. 4, each of the players 14 will receive a different audio file in Act 1 that corresponds to the player's character role 54.

After the “Play” button has been pressed, the word “Play” on the button may change to “Stop.” If the “Stop” button is pressed during the playback of the audio file, the moderator 15 can stop the audio file from continuing to play, at which point the button will return to reading “Play.” If the “Play” button is then pressed (which would be the third time this specific button would have been pressed), the moderator 15 can reinitiate the playing of the audio file.

While the audio file is being played for the players 14, the first indicator 66 may light up in the row for the selected game feature 42 under each character role 54 column to show that the audio file is playing. For example, a yellow light may flash as the first indicator 66 to show that the audio file is playing. If the players 14 are receiving different audio files, the first indicator 66 may be lit up for different lengths of time for each player 14.

After the audio file is finished playing, the first indicator 66 may stop flashing and may turn off or may turn a solid color, such as green, to show that the audio file was received by the player 14 having that character role 54 and was played by the player 14 having that character role 54. In addition, the second indicator 67, which may be represented by an arrow or the like, may appear in the row for the selected game feature 42 in each character role 54 column that was played the audio file. The moderator 15 may press the arrow to then replay the audio file if desired. For example, one of the players 14 may request that the audio file be replayed, and the moderator 14 can then press the second indicator 67 to replay the associated audio file. After all the players 14 have received and played the audio file as indicated by the indicators 66 and 67, the moderator 15 may press the “OK” button in the third button column 63 to move to the next game feature 42. While in the illustrated embodiment the moderator 15 presses “OK” to move to the next game feature 42, the present disclosure is not limited thereto, and the game may automatically continue to the next game feature 42 after all the players 14 have received and played the audio file.

Some game features 42 may require feedback from the players. For example, in the “Object Selection” row of the game features 42, a display including various objects is shown to the players 14. The players 14 must select an object, for example, one of objects A through F. When one of the players 14 has made a selection, the first indicator 66 may indicate that the selection has been made, for example, by a checkmark or the like, and the second indicator 67 may display what the selection was. For example, in FIG. 6, Player 2 has completed his/her selection of object “C” in the “Object Selection” game feature 42. After all the players 14 have made their selections as indicated by the indicators 66 and 67, the moderator 15 may press the “OK” button in the third button column 63 to move to the next game feature 42. While in the illustrated embodiment the moderator 15 presses “OK” to move to the next game feature 42, the present disclosure is not limited thereto, and the game may automatically continue to the next game feature 42 after all the players 14 have made their selections.

In some embodiments, the game feature 42 that is currently active may be highlighted (e.g., highlighted in a different color than the other game feature 42 rows) to facilitate the moderator 15 in controlling game flow. As shown in FIGS. 5 and 6, the game is currently on the “Object Selection” game feature 42. In FIG. 5, the players 14 have been shown the object selection visual file, but have not made a selection. In FIG. 6, one of the players, Player 2, has made a selection.

In the present embodiment, each player 14 has a column with indicators 66, 67 that correspond to the game features 42. However, the present disclosure is not limited thereto and the indicators 66, 67 can be in any suitable format to indicate to the moderator that the specified conditions (e.g., the playing of the visual or audio file, or the selection of an object) have been completed. In other embodiments in which the game system 10 moves automatically from one game feature 42 to the next, indicators may not be used at all, as the system will continue automatically when the conditions are met without the need for a visual indicator.

In addition, the moderator user interface 35 need not be displayed as a table, but could be displayed via any other suitable form, for example as text or another graphical form.

In some embodiments, the moderator may be able to move from one game feature to the next (e.g., from one row to the next) independent of whether the conditions are met. This feature can be valuable if a player 14 requests going back to a prior game feature 42 because they missed reading or viewing an important text or image at a previous game feature 42, for example. Buttons, such as the “−” and “+” buttons shown in FIG. 5, may be used by the moderator 15 to move up and down the game features 42, respectively.

FIG. 7 shows examples of moderator messages 75 and player messages 74 that may be used by the game software 16, e.g., the DAT-engine 32, in embodiments of the present disclosure.

When the moderator clicks one of the buttons on the moderator user interface 35, a moderator message 75 may be initiated and driven by the DAT-engine 32. The moderator messages 75 are sent to (through) the high-level engine 31, which then sends the moderator messages 75 to (through) the multiplayer-enabling server 23, which then sends the moderator messages 75 to the players 14 with the name of the visual or audio file associated with selected game feature 42 and the character role 54 for each particular player 14 so that each player 14 only receives the audio or visual file associated with his/her character role 54. The audio or visual file name gets translated by the client app of the DAT-engine 32 running on each player's browser (i.e., the player instance of the DAT-engine 32) and/or computer to the location (e.g., URL) of the specified audio or visual file for that player 14. The player 14 can then view and/or play the received audio and/or visual file. In addition, in some embodiments, the moderator messages 75 sent via the moderator user interface 35 may be relayed and/or routed by the multiplayer-enabling server 23 to retrieve the media files, such as graphics, video and audio files, from the web server 22. In addition, the audio subsystem 25 (e.g., resource loaders of the audio subsystem 25) may be used to stream audio files from the web server 22 and the graphics rendering subsystem 26 (e.g., resource loaders of the graphics rendering subsystem 26) may be used to retrieve visual files from the web server 22.

FIG. 7 shows various moderator messages 75 that may be sent. For example, when the moderator presses “Show” on the moderator user interface 35 in a row for an overlay game feature 42, the information pertaining to that button is extracted and the message “SHOW_OVERLAY_MESSAGE” may be sent. When the moderator 15 presses the “Play” button of the moderator user interface 35 in a row for a sound or music, the information pertaining to that button is extracted and may be sent as a “PLAY_SOUND_MESSAGE” or “PLAY_MUSIC_MESSAGE,” respectively. When the moderator 15 presses the “Stop” button of the moderator user interface 35 in a row for a sound or music, the information pertaining to that button is extracted and the “STOP_SOUND_MESSAGE” or “STOP_MUSIC_MESSAGE” may be sent, respectively. In other words, the message sent is based on the type of media file (see, e.g., the type column 50 in FIG. 4) and the “Play,” “Stop,” or “Show” button pressed by the moderator on the moderator user interface 35.

The player user interface 34 may be responsive to moderator messages 75 sent from the moderator user interface 35 and the player user interface 34 may not be capable of sending player messages 74 without the message 74 being a response to a moderator message 75 (e.g., the player user interface 34 may be “dumb”). For example, when an overlay has been displayed on the player user interface 34, the DAT-engine 32 run on the player's browser 30 (i.e., the player instance of the DAT-engine 32) may send an “OVERLAY_RESPONSE_MESSAGE” back to the moderator 15 and the second indicator 72 on the moderator user interface 35 may change to indicate that the visual file was displayed (e.g., an “X” may be displayed at the second indicator 72. In some embodiments, a game feature 42 may include text for the players 14 to read, and the visual file may include a button that the player user interface 34 will display and that the player 14 can press when they are finished reading the text to indicate that they are ready to move on. When the player pressed that button, the “READYUP_MESSAGE” may be sent to the moderator 15 to indicate that the player is ready to move on to the next game feature 42.

When an audio file finishes playing for a player 14, a “COMPLETE_MESSAGE” may be sent from the DAT-engine 32 on the player's browser 30 (i.e., the player instance of the DAT-engine 32) to the DAT-engine 32 on the moderator's browser 30 (i.e., the moderator instance of the DAT-engine 32) via the multiplayer-enabling server 23 to tell the moderator 15 that the audio file is finished, as may be shown on the moderator user interface 35 by the first indicator 71 as described in more detail above.

In some embodiments, additional player and/or moderator messages 74/75 may be included. For example, a READYUP_MESSAGE may be sent after the players 14 have all logged into the game and the moderator 15 has assigned the character roles 54. The players 14 may click a button on their player user interface 34 to indicate that they are ready to move forward into the game play. For example, if the log in page for the players contains text and/or other information for the players 14 to read/view to introduce the game, the players 14 may click the button initiating the READYUP_MESSAGE after reading/viewing the introductory information, as discussed regarding the homepage with respect to FIGS. 2 and 3 and in more detail below. This button click may initiate the READYUP_MESSAGE. In response to this player message 74, the moderator message 75 SCENECHANGE_MESSAGE may be sent to initiate a visual (e.g., background art) change to the player user interface 34.

In the current embodiment, the game system 10 takes advantage of the private message capability of the Smartfox Server 2X, which is used as the multiplayer-enabling server 23 in the current embodiment. Moderator messages 35 are relayed using MessagingManager and MessagingSubManager (two classes) in the open-source Pixi-engine, which is used as the high-level engine 31 in the current embodiment, that provides a custom interface to the Smartfox Server 2x's private messaging API calls. MessagingManager and MessagingSubManager implements additional functionality that ensures that messages are actually received by the players 14. The players 14 receive a message containing the audio or visual file name associated with selected game feature 42 and the character role 54 for each particular player 14. The client app of the DAT-engine 32 that the player 14 is running uses the audio subsystem 25 to stream the audio file from the Web Server 22 in the case of an audio file and uses the graphics rendering subsystem 26 to display the visual file from the Web Server 22 in the case of a visual file. Once the audio file finishes playing (or the visual file is displayed), the player 14 sends a “complete” message back to the moderator which the AudioPlayer component receives. The AudioPlayer then updates the UI to signal to the moderator that the participant has received and successfully played back the audio completely.

FIG. 8 is a method for executing a game according to embodiments of the present disclosure.

Prior to the start of the game, a user will complete the game script 28, including the providing (e.g., defining) the game features 42 and the media files to be used during the game features 42 (S800). The game script 28 is then accessed and used by the DAT-engine 32 (S801). In some embodiments, the game script 28 will be converted into a format usable for use by the DAT-engine 32 (e.g., XML). As described able, the game script may be defined as a spreadsheet or other format and converted to a format readable by the DAT-engine, such as an XML version. In some embodiments, the game script can be baked in (e.g., hardcoded or compiled) into the DAT-engine 32 or it may be loaded into the DAT-engine by the moderator 15, from, for example, a URL, e.g., an external URL, when the game begins.

The moderator 15 loads a moderator instance of the DAT-engine 32 into his/her web browser 30 and creates a room (e.g., a ‘game room’) for the game to take place in (S802). In some embodiments, the moderator 15 may load the moderator instance of the DAT-engine 32 and then the game script 28 may be accessed and used by the DAT-engine 32. The moderator instance and a player instance of the DAT-engine may both be contained within the code of the DAT-engine 32. Whether the DAT-engine runs in moderator or player mode (e.g., whether it runs the moderator or player instance of the DAT-engine 32) depends on the mode selected when the DAT-engine is launched.

The moderator 15 may assign a room ID for the game (e.g., a unique GUID) and the room ID may be distributed to all players 14 in the game (S803). In some embodiments, the room ID may be automatically assigned by the DAT-engine 32 and distributed to the players 14. In some embodiments, after the moderator 15 loads the game into his/her web browser, the game script 28 may be loaded by the DAT-engine 32 to run the game. For example, the game script