WALKABLE OR INTERACTIVE VIRTUAL REALITY

FIELD OF TECHNOLOGY

[0001] The present disclosure relates generally to an omnidirectional locomotion system and apparatus that can be used to provide a virtual reality system, and more specifically relates to systems and methods for providing an integrated and automated performance tracking platform.

BACKGROUND

[0002] Virtual reality systems are becoming increasingly popular, offering users an immersive experience that is often accompanied by a 360-degree field of view. This 360-degree field of view can be filled with real-world content such as video or image data that has been captured by one or more cameras, or the 360-degree field of view can be filled with computer-generated content such as animations and other renderings. In some cases, such real-world and/or computer-generated content can be utilized to implement a game or other interactive experience for one or more users of a given virtual reality system. However, these games are often standalone experiences that are unable integrate with the virtual reality system as a whole or measure and track various user and system performance parameters.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] In order to describe the manner in which the features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific examples thereof which are illustrated in the appended drawings. Understanding that these drawings depict only example embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0004] FIG. 1 depicts an example data management and performance tracking system according to an aspect of the present disclosure;

[0005] FIG. 2 depicts an example omnidirectional treadmill according to an aspect of the present disclosure;

[0006] FIGs. 3A-H illustrate example achievements according to an aspect of the present disclosure;

[0007] FIGs. 4A-R illustrate example graphical interfaces according to an aspect of the present disclosure;

[0008] FIG. 5A depicts an example system bus computing system architecture; and

[0009] FIG. 5B depicts an example computer system chipset architecture.

DETAILED DESCRIPTION

[0010] Disclosed herein are systems and methods for data management and performance tracking for a virtual reality environment or platform. In some embodiments, the virtual reality environment and platform can be provided by an omnidirectional locomotion system and/or an omnidirectional treadmill, for example as disclosed in U.S. Patent No. 9,329,681.

[0011] Current virtual reality (VR) systems and platforms are capable of providing one or more virtual reality games or virtual reality experiences for a user (also referred to herein as a “player”) to select and play. Various different ones of these VR games and VR experiences (also referred to herein as“VR content”) can be designed, published, or otherwise made available by game studios and other content creating entities and individuals. However, while all of this VR content is compatible with a given virtual reality system or platform, there is oftentimes little in the way of continuity or direct connection between the different pieces of VR content - each piece exists in isolation and is interacted with by a user in isolation. Additionally, a user’s interactions with such VR content tend to be fleeting in nature, meaning that no history or log is saved indicative of the user’s interactions, that a user never desires to replay a VR game or repeat an interaction with a VR experience, or both.

[0012] Accordingly, it would be desirable to address these limitations of current VR content and provide an integrated and automated solution to track user performance and interaction across games and interactive experiences provided on a virtual reality system.

[0013] Disclosed are system, methods and non-transitory computer readable mediums for performance tracking, which can include an omnidirectional locomotion system (configured with one or more virtual reality games, omnidirectional treadmill and a sensor array), a leaderboard development interface; and a leaderboard creation GUI configured to create a leaderboard GUI. In some instances, the sensor array is attached to a user within the omnidirectional treadmill. In other instances, the sensor array is located on or within the omnidirectional treadmill.

[0014] Further disclosed in the system, methods and non-transitory computer readable mediums is a user progression interface coupled between the sensor array and a central database, the user progression interface ingesting sensor data from the sensor array and transmitting achievement data to the database.

[0015] Further disclosed in the system, methods and non-transitory computer readable mediums is that the achievement data can be used to determine an achievement level of a plurality of achievement levels of a user, the achievement level stored to a user profile. In some instances, each achievement level of the plurality of achievement levels has a threshold level, and the achievement level is determined when the achievement data exceeds or is equal to the threshold level.

[0016] Further disclosed in the system, methods and non-transitory computer readable mediums is that the leaderboard development interface is coupled between the one or more virtual reality games and a database, the leaderboard development interface ingesting in-game data from a given one of the virtual reality games and transmitting scoring data to the database.

[0017] Further disclosed in the system, methods and non-transitory computer readable mediums is a live feed system controller communicatively coupled between the database and the live feed creation GUI, wherein the live feed system controller transmits one or more of the live feed objects for display to one or more users of the omnidirectional locomotion system and updates one or more of the live feed data objects as new scoring data and achievement data are received at the database. In some instances, the leaderboard creation GUI is configured to receive one or more inputs defining parameters of a leaderboard data object and configured to receive one or more inputs defining a set of filters for populating the leaderboard data object with data from a database.

[0018] Further disclosed in the system, methods and non-transitory computer readable mediums is a live feed creation GUI configured to receive one or more inputs defining parameters of a live feed data object, wherein newly created live feed data objects are stored in a database.

[0019] FIG. 1 depicts an example diagram of a data management and performance tracking system 100 according to one or more aspects of the present disclosure. As illustrated, the data management and performance tracking system 100 includes a plurality of Omnidirectional Locomotion Systems 102 (e.g. omnidirectional treadmills, shown in FIG. 2) which are deployed and operated at given Operator Venues 104; a Database 106; a User Profile Controller 110; a Live Feed System Controller 110; an Admin Portal; a User Web Portal 112; and a Live Feed Display 116, each of which are explained in greater depth below. The below explanation of the various components, interactions and transmissions, while described in a system example are not limited as such. For example, the various components, interactions and transmissions can be carried out in one or more methods or non- transitory computer readable mediums.

[0020] Each Omnidirectional Locomotion System 102 is provided with a plurality of VR games 118 (or other VR content and VR experiences) for a user to play. The Sensor Array 120 can serve as input to the VR games 118. The Omnidirectional Locomotion Systems 102 are depicted as being located at an Operator Venue 104 (e.g. an arcade, etc.), although the present disclosure applies equally to a private omnidirectional locomotion system (e.g., player’s house, etc.). Similarly, the Omnidirectional Locomotion Systems 102 are shown as being communicatively coupled to a User Profile Controller 108 for purposes of enabling a user to login and load their personal user profile on a desired omnidirectional locomotion system prior to its use, although the present disclosure also applies to those users who do not opt to login to the omnidirectional locomotion system.

[0021] As the user plays a VR game 118 or interacts with other VR content on the omnidirectional locomotion system, the presently disclosed data management and performance tracking system ingests (into one or more Databases 106) data from both the omnidirectional locomotion system itself (e.g. from a Sensor Array 102 of an omnidirectional treadmill) and further ingests data from within the VR game 118 or other VR content being provided to the user of the omnidirectional treadmill. As shown, only a single database is provided, although it is appreciated that various other database configurations and layouts can be utilized. In some instances, one or more databases can be provided in a distributed or cloud fashion.

[0022] For the purposes of this data ingestion, a User Progression Software Development Kit 122 (SDK) and a Leaderboard Development Kit 124 (LDK) are utilized to implement one or more data interfaces (e.g., user progression interface, leaderboard development interface, etc.) between the Omnidirectional Locomotion System 102 and the Database 106. As illustrated, the User Progression SDK 122 communicates with the Sensor Array 120 of the omnidirectional locomotion system and transmits Achievement Data 126 to the Database 106, while the LDK 124 communicates with the VR game 118 (or other VR content) running on the omnidirectional locomotion system and transmits Scoring Data 128 to the Database 106. It is contemplated that in some embodiments, one or more of the Achievement Data 126 and the Scoring Data 128 may be substantially unprocessed and transmitted to the Database 106 in raw form. In some embodiments, these separate data streams can be correlated or otherwise pre-processed by one or more of the User Progression SDK 122 and the LDK 124 before being transmitted to Database 106 for storage and further use. In other examples, the Achievement Data 126 and the Scoring Data 128 can be transmitted and processed at the Database 106 (e.g., via connected device, database controller, etc.), that is without the use of the User Progression SDK 122 and the LDK 124.

[0023] Achievement Data 126 represent physical interactions between the user and the Omnidirectional Locomotion System 102, independent of any VR game 118 (or other VR content) that is being presented to the user. This Achievement Data 126 can be used to automatically track, calculate, and generate system achievements corresponding to a given user’s usage of the omnidirectional locomotion system. For example, Achievement Data 126 can include data representing the number of overall steps that the user has taken on the Omnidirectional Locomotion System 102, the number of calories the user has burned, the amount of time the user has spent on the Omnidirectional Locomotion System 102, the number of sessions the user has played, etc.

[0024] This Achievement Data 126 is derived, at least in part, from the output of the Sensor Array 120 of the Omnidirectional Locomotion System 102. This sensor array may be integrated with the omnidirectional locomotion system, or may be provided separately for the purposes of providing sensor data to the presently disclosed data management and performance tracking system. In some embodiments, the sensor array can include, but is not limited to, one or more of the following: inertial measurement units (IMUs), capacitance sensors, ambient light sensors, magnetic tracking sensors, acoustic sensors, pressure sensors, optical tracking sensors, Hall Effect sensors, infrared sensors, a VR headset sensor sub-array, a VR base station sensor sub array, a torso/hip orientation sensor, a hand controller sensor sub-array, etc. One or more of the sensors of the sensor array can be removably attached to the user of the omnidirectional locomotion system, can be integrated into an accessory item provided to the user, etc. in some embodiments, one or more of the sensors of the sensor array can stream raw measurement data to an aggregator board.

[0025] Once collected, the sensor data can be transformed into Achievement Data 126 by the User Progression SDK 122, which analyzes the various streams of sensor data from different sensors of the overall sensor array in order to calculate an interaction history or sequence of movements corresponding to the user of the Omnidirectional Locomotion System 102.

[0026] From the Achievement Data 126, various different user achievements can be awarded to the user, or the user’s progress towards accomplishing various achievements can be updated, for example, saved to the User Profile Object or some other location within the Database 106. Each achievement can be associated with a number of different levels, each having a different threshold. FIG. 3A depicts non-limiting example movement achievements that could be provided to a user of the omnidirectional locomotion system. The movement achievements can be awarded as players reach certain milestones with the number of steps they have taken. More milestones can be added to the system as players approach the upper milestones. The overall achievement is a movement achievement, and the different or constituent levels of the overall movement achievement are categorized with uniquely identifying names (e.g.“mobile”,“sure footed”,“strider”, etc.). Each one of these levels has a required threshold for its achievement (e.g. reach 100 steps, 500 steps, 1,000 steps), and grants some number of achievement points (abbreviated as“AP” in the table above).

[0027] As a user obtains achievements, their User Profile Object 130 in the Database 106 can be updated to reflect the fact that a given achievement has been accomplished. The User Profile Object 130 can also be updated with the achievement points (AP) that are granted by the given achievement. In some embodiments, an overall player achievement score can be calculated from the sum of achievement points that the user has earned, e.g. in the lifetime of their account, the prior year, the prior month, etc. Additionally, some achievements may grant a“player title” along with the achievement points, such that a user can select one of their earned player titles to be displayed underneath the user’s profile name within the UI of the omnidirectional treadmill system.

[0028] Returning now to a discussion of the system-level achievements generated via the Achievement Data 126 and the User Progression SDK 122, the Sensor Array 120 can output the desired data or statistic directly to the User Progression SDK 122 (e.g. the output of the sensor array is an integer representing the number of steps taken), or the Sensor Array 120 can output raw data that the User Progression SDK 122 uses to calculate the desired data or statistic (e.g. the output of the sensor array is the signal generated by an accelerometer, which is analyzed by the User Progression SDK 122 in order to determine a step count). [0029] In some embodiments, the Omnidirectional Locomotion System 102 communicates with the User Profile Controller 108 in order to correlate the generated Achievement Data 126 to a User Profile Object 130 that is stored in the Database 106 and corresponds uniquely to the current user of the Omnidirectional Locomotion System 102. In some embodiments, the generated Achievement Data 126 can be tied to a temporary session profile that exists only so long as the user’s current session with the Omnidirectional Locomotion System 102 remains active.

[0030] Scoring Data 128 represents virtual or in-game interactions between the user and the VR game 118 (or VR content) that is being displayed on the Omnidirectional Locomotion System 102. Scoring Data 128 corresponds to user accomplishments and performance in the context of the virtual world of the VR content (e.g. the number of kills a user achieves in one round of a first-person shooter VR game, the lap times in a racing VR game, the completion time in a puzzle VR game, etc.). In certain instances, this Scoring Data 128 can be used to automatically track, calculate, and generate in-game achievements in a similar manner as described above with respect to the use of Achievement Data 126 to generate system achievements.

[0031] The Leaderboard Development Kit (LDK) 124 is utilized to enable developers or VR content creators to implement leaderboard functionality within their VR games or content. In order to do so, the VR game must communicate with the database and overall data management and performance tracking system of the present disclosure. This communication is represented in, for example, FIG. 1 by the LDK 124 interposed between the VR game and the database. In some examples, the LDK 124 can transmit Scoring Data 128, from the VR games 118, to Database 106. This Scoring Data 128 can be used for an online leaderboard (e.g., Live Leaderboard 136, etc.).

[0032] In general, the LDK 124 can define a consistent framework across all VR games that will be played on the omnidirectional treadmill such that the various achievements and achievement points (APs) earned within different games can be combined into the overall player achievement score described above. For example, each game can be assigned a fixed allotment of achievement points to be distributed as desired across the desired achievements that are to be implemented by the VR game developer, e.g. each game might be capped at no more than 1,000 total achievement points to be awarded to the user, regardless of how few or how many different achievements that VR game developer decides to implement. [0033] Broadly, in-game achievements derived from the Scoring Data 128 and the LDK 124 can be divided into three different categories: those that award the first- time experience, those that award the completion of objectives, and those that award the completion of challenges.

[0034] FIG. 3B depicts non-limiting examples of different first-time achievements within a given VR game. FIG. 3B illustrates four separate first-time achievements, each worth 25 Achievement Points (APs), rather than four levels of the same first-time achievement. By its nature, a first-time achievement can only be achieved once, and is generally not compatible with a level-based progression system as is found in other achievements described herein.

[0035] Achievements that award the completion of objectives, also referred to as“objective achievements”, are awarded in response to the user completing different in-game objectives. Progress towards or completion of these in-game objectives can be tracked by the LDK 124, rather than the data management and performance tracking system of the present disclosure, thereby removing the immense computational overhead that would be required in order to perform all calculations in the performance tracking system. FIG. 3C depicts non-limiting examples of different objective achievements for the same VR game used in the example above. The achievements are not all different levels of a single over-arching achievement, although there are some example of paired or leveled achievements, such as“Core Defense Gold”,“Core Defense Platinum”, and“Core Defense Master”.

[0036] A third category of achievements derived from the Scoring Data 128 ingested to the Database 106 via the LDK 124 consists of challenge achievements, which are awarded to players upon the successful completion of a challenge or other difficult/infrequent in-game feature. These challenge achievements therefore reward players who excel at a given VR game and perform well, thereby providing the players with a reason to return to the game and play again when they otherwise would not have. FIG. 3D depicts non-limiting examples of different challenge achievements for the same VR game used in the two examples above. Further examples and details of scoring data and in-game achievements are shown in FIG. 3E-2H.

[0037] Returning now to the discussion of FIG. 1, the aforementioned achievements can be transmitted from the User Profile Controller 108 to the omnidirectional locomotion system for presentation to the user. For example, the user achievements (and other user profile information) can be presented to the user in the context of a virtual reality menu or home screen environment of the omnidirectional locomotion system. Additionally, the user profile controller can transmit user achievements and other user profile information to a User Web Portal 114, which allows a user to login using a computing device of his or her choosing.

[0038] In addition to the achievement functionality discussed above, the data management and performance tracking system of FIG. 1 can additionally provide for a leaderboard functionality. This leaderboard functionality is provided by constructing a plurality of leaderboard data objects from the in-game scoring data that is already stored within the Database 106.

[0039] In general, an administrator uses a Leaderboard Wizard 142 or other helper GUI of an Admin Portal in order to create, view, archive, and delete leaderboard data objects. To create a leaderboard data object, the admin provides definition data for the leaderboard (e.g. title, description, competition type, etc.) and filter parameters that configure the specific scoring data that will be retrieved from the Database 106 and presented within the leaderboard. In some embodiments, the filter parameters can be pointers to specific data locations, types, streams, feeds, inputs etc. within the Database 106.

[0040] The leaderboard data object itself is not presented to the user however - it serves as an organizational and data management structure rather than a user-facing element. In order to serve leaderboards to users and other desired locations, the data management and performance tracking system of FIG. 1 includes a Live Feed System Controller 110 and a plurality of Live Feed Objects 134. These Live Feed Objects 134 include Live Leaderboards 136, Live Images 138, and Live Videos 140. For example, in order to present a leaderboard to a user (or provide it within the virtual reality environment of the Omnidirectional Locomotion System 102), a Leaderboard Data Object 132 is converted into a Live Leaderboard Object 136.

[0041] The Live Image 138 and Live Video objects 140 include largely the same parameters as the live leaderboard object, with the difference being that an image file (or pointer to an image file)/a video file or pointer to a video file is used instead of a leaderboard data object. In some embodiments, the image or video file that is used can be an advertisement. These advertisement files can be stored external to the data management and performance monitoring system of FIG. 1, can be stored in the depicted Database 106, or both.

[0042] The Leaderboard Data Object 132, can include, but is not limited to:

[0043] Leaderboard Title: this variable is the title of the Leaderboard. It can displayed in the backend as well as at the top of the Leaderboard on the showcase.

[0044] Subtitle: this variable provides a short and concise description of what the Leaderboard is displaying.

[0045] Description / Messaging: this variable is a short description that provides any additional information or messaging that needs to be communicated for the Leaderboard. This variable would communicate information such as the prize for the leaderboard, the time that it is ending, and how to enter the leaderboard (e.g., account required, etc.)

[0046] Competition Type: this variable represents the type of competition that is being run with this leaderboard. The admin can select between several different types of competition. Here are some examples of different competition types:“Friendly” competitions which means that there is no prize competition,“Prize Pool” competitions, which means that there is a prize pool that is distributed to multiple winners at the end, and“All-or-nothing” competitions, which means that lst place in the competition gets the full prize.

[0047] Competition Type Option Value: this variable is an option value that provides additional information needed for a competition type. For example, if the competition type is“Prize Pool” then this value is the prize pool amount that is available for the winners of the leaderboard. The title for this value is tied to the competition type and is automatically visible when the competition type is chosen. For example, if the admin chooses the“Prize Pool” competition type, then the title for the competition type option title is automatically set to“Prize Pool Amount (USD)”.

[0048] Display Tiebreaker Column: this Boolean variable signifies whether the leaderboard displays a column for the tiebreaker value. A tiebreaker column can be added to the leaderboard. If it is a short leaderboard and ties are unlikely, then the tiebreaker column can be hidden.

[0049] Leaderboard Filters: the data for the leaderboards can be stored in the database, so the data can be filtered in multiple ways depending on what is stored in the leaderboard data structure.

[0050] Game Title Filter: filters the data based on the title of the game. This is selectable from a game title table in the database that includes the games that can have leaderboards. The CPs (Content Providers) provide the title of their game in the leaderboard data. If leaderboard data is submitted with a new game title that does not exist in the database, the new game title should automatically be added to the list of games selectable in this field. [0051] Game Mode / Level Filter: filters the data based on the specific game mode / level in the game. If a game has multiple leaderboards, this variable must be unique for each leaderboard. This filter is chosen from a Game Mode / Level table in the database that is specific for the selected game. There are different options in this field depending on the game title chosen in the previous field. If leaderboard data is submitted with a new game mode / level that does not exist in the database, the new game mode / level should automatically be added to the list of game modes / levels selectable in this field. In some instances, it should also only be visible if the corresponding game title is selected in the previous field.

[0052] Location Filter: filters the data based on the location that it was created. This field is a hierarchy tree where the admin can select Global / Regions / Countries / Operator Locations for the location of the data to be displayed. The list of countries and operator locations already exist in the database, but a new table for regions will need to be created in the database. Each region can contain a collection of countries that exist within the region.

[0053] User Type: filters the data based on the type of user that creates the data.

[0054] User Accounts Only: filter displays only the data that is created with an User Account. If a leaderboard is set to show only the scoring data for user accounts, then the leaderboards shall only display the top score for each user account. This is possible when the user accounts are required to have a unique name.

[0055] All-Users (User Accounts and Guests): this option does not filter out any data based on user type. All leaderboard scoring data, whether from user accounts or guests, is displayed on this leaderboard. Players without a user account do not have unique names so it is unknown whether players with the same name are the same person. Because of this, if a leaderboard is set to show“All-Users”, the data will include multiple entries for duplicate names. Since players without accounts can have their name on a leaderboard multiple times, players with user accounts can also have their name multiple times on the leaderboards with players without user accounts.

[0056] At least one User Account (Team Play): this filter is useful for team leaderboards where each data entry has more than one player. This filter includes any teams that have at least one user account. So, if 2 players play a co-op leaderboard, and player 1 is signed into a user account, but player 2 is signed into a guest account, the leaderboard scoring data will be on the leaderboard. If both players are signed into a user account, then they will also be on the leaderboard. If both players are signed into guest accounts and not into an user account, then their score will not be on the leaderboard. With this option, the leaderboard does not display duplicate entries for teams that are made up of the same user accounts. If the team contains any players on with a guest name, then the score is displayed on the leaderboard, regardless of whether there is another entry with the same guest name.

[0057] Timing: filter the data based on the date and time that it was created. This field also enables the creation of recurring leaderboards.

[0058] Daily: this option creates a leaderboard that shows only the leaderboard scoring data for a specified day. There are also options available to create a recurring leaderboard so that a new leaderboard does not have to be created every day. The recurring leaderboard can be specified to run every day, or every x number of days.

[0059] Start Time (Time / Time Zone): this filter option specifies the time (including time zone) when the leaderboard begins. For recurring daily leaderboards, this time is the time, each day, that the new leaderboard begins. The leaderboard automatically ends 23 hours and 59 minutes after the start time.

[0060] Recurrence Pattern: every [x] Day(s). If this value is set to 1, then the leaderboard occurs every single day. If the value is set to 2, then it occurs every other day, and so on.

[0061] Recurrence Range: the recurrence range defines how many days the daily leaderboard is active.

[0062] Start Date: the start date is the date that the daily leaderboard becomes active. This allows the creation of leaderboards before the leaderboard competition has begun. The first leaderboard starts at the“Start Time” on the“Start Date”

[0063] End Date: the end date is the date that the daily leaderboard ends and becomes inactive. There are 3 options available to select an end date. 1). No End Date - this option means the leaderboard has no end date, and is set to be recurring forever, or until it is changed/deleted in the backend. 2). End after [x] occurrences - this option means the leaderboard ends after a specified number of occurrences. For example, the leaderboard can be set up to end after 10 occurrences. If it is a daily leaderboard that is happening every day, then it would end after 10 days. 3). End by [Date] - this option means the leaderboard ends on the specified date. The specified date is the last date to run this leaderboard

[0064] Weekly: this option creates a leaderboard that shows the leaderboard scoring data for a specified week. There are also options available to create a recurring leaderboard so that a new leaderboard does not have to be created every week. The recurring leaderboard can be specified to run every week, or every x number of weeks.

[0065] Start Day and Time (Day / Time / Time Zone): this filter option specifies the day and time (including time zone) when the leaderboard begins. For example, Monday at 5:00 AM CST. For recurring weekly leaderboards, this day and time is the day and time, each week, that the new leaderboard begins. The leaderboard automatically ends 6 days, 23 hours and 59 minutes after the start time.

[0066] Recurrence Pattern: every [x] Week(s). If this value is set to 1, then the leaderboard occurs every single week. If the value is set to 2, then it occurs every other week, and so on.

[0067] Recurrence Range: the recurrence range defines how many days the daily leaderboard is active.

[0068] Start Date: the start date is the date that the weekly leaderboard becomes active. This allows the creation of leaderboards before the leaderboard competition has begun. The first leaderboard starts the first time that the“Start Day and Time” occurs on or after the“Start Date”

[0069] End Date: the end date is the date that the daily leaderboard ends and becomes inactive. There are 3 options available to select an end date. 1). No End Date - This option means the leaderboard has no end date, and is set to be recurring forever, or until it is changed/deleted in the backend. 2). End after [x] occurrences - This option means the leaderboard ends after a specified number of occurrences. For example, the leaderboard can be set up to end after 10 occurrences. If it is a weekly leaderboard that is happening every week, then it would end after 10 weeks. If it is happening every other week, then it would end after 20 weeks (still only 10 occurrences). 3). End by [Date] - This option means the leaderboard ends on the specified date. The end date does not end a leaderboard that is currently in progress, but it does not allow another leaderboard to start on or after the specified end date.

[0070] All-Time: this is a preset filter option that does not filter out any data based on time. [0071] Custom Time: this option allows the operator to select a start time for the leaderboard and an end time for the leaderboard. Any data that is outside that range is filtered out. This field is defined by the date and time (Hour / Minute) and time zone for the start and end time.

[0072] The Live Leaderboard Object 136 fully includes the leaderboard data object (or a pointer to the leaderboard data object), and adds a display time (e.g. the number of seconds to display the leaderboard in the live feed before transitioning to the next queued element in the live feed, if there is one), an active/inactive tag, and a display location.

[0073] Database 106 can also include a scoring data structure (for example, formatted Scoring Data 128). The scoring data structure can include, but is not limited to:

[0074] Game Title: this variable is the title of the game.

[0075] Game Mode / Level: this variable is used to distinguish between multiple leaderboards that exist for one game. If a game has multiple leaderboards, this variable must be unique for each leaderboard.

[0076] Player ID#: this variable is a unique ID# generated for the players in this session. This ID# is linked to another table that has player information tied to the ID#. This allows the leaderboard to have multiple players tied to one score for the coop leaderboards. For example, if the Player ID# is 100176, then the database looks at the linked Players table and retrieves all players that have the ID# 100176. There is just one player with that ID# in the Players table if the leaderboard is only single player, but there are multiple players with that ID# if it is a coop leaderboard. If the player is using a user account, then the player name is retrieved from the user data stored in Database 106. If the player is using a guest account, and a custom name has been entered, then the custom name is used for the player name (this name is not a unique name and may have duplicates). If the player is using a guest account and does not have a custom name, then an auto-generated username (i.e. Player- 156) is used in the leaderboard.

[0077] Team Name: this variable is the Team Name that is used for co-op leaderboards. If the players enter a Team Name in the system before playing a coop leaderboard, then this value is displayed on the leaderboard instead of the player usernames.

[0078] Score: this variable is an integer value that is displayed by the player’s name on the leaderboard. This value determines the order of the names on the leaderboard. The score variable is unique to each game and is not comparable to the scores of other games. The CP translates game statistics, such as kills, successful objectives, etc., into one integer value that represents score. For example, Core Defense creates a score based on the number of kills (1000 points per kill) and the remaining health of the power core at the end of each wave (0-10000 remaining health).

[0079] Tiebreaker Title: this variable is the title of the value that determines which player wins in a tie scenario. The tiebreaker value can be displayed in a separate column in the leaderboard. The tiebreaker title is used as the title for the column in the leaderboard. This title communicates to the players why they are lower on the leaderboard than another player with the same score. For example, in Core Defense, this title could be“Performance Rating”, so that players know that even though they have the same score, the other player had a better performance.

[0080] Tiebreaker Value: this variable is that value that is used to determine which player wins in a tie scenario. The tiebreaker value can automatically set to sort in descending value, meaning that if two players are tied, the player with the higher tiebreaker value is ranked higher on the leaderboard. For example, in Core Defense, the CP can add a tiebreaker value to the data that is based on number of kills, accuracy, number of deaths and distance traveled in the game so that even if players have the same score, the player who performed better is higher on the leaderboard. If the CP decides not to use this value, the leaderboard automatically sorts the data based on the date and time that it was created. In a tie, the data that was created first is higher on the leaderboard.

[0081] Device Info: this variable includes the Device Info from the SDK. This includes Shop ID, Shop Name, Region, etc. This variable is used for location information for the device.

[0082] Date / Time: this variable is the date and time that the data was created. This date and time must be taken from the server to prevent cheaters who may change the system time on their computers.

[0083] Ascending / Descending Score Sorting: this variable specifies whether the score data is sorted with the highest values first or the lowest values first. This value is provided by the CP, as they decide if the highest or lowest value wins in their scoring system.

[0084] Leaderboard Version Number: this variable determines the version of the data. This is important in case the scoring in a game is updated, making the previous scores incompatible and invalid. This value is provided by the CP and will be changed whenever the CP makes a change to the scoring system in their game.

[0085] Session ID: this variable is a unique identification number for the session in which this leaderboard data was created. This enables identification needed to display this data in the tablets when the session is over.

[0086] Turning back to FIG. 1, the Admin Portal 112 includes a Live Feed Wizard 114 or other configuration UI in order to assist an administrator in creating, viewing, editing, archiving, and deleting live feed objects. In the process of creating a live feed object, an administrator can use the Live Feed Wizard 144 to define the parameters of the live feed objects as discussed above. The Live Feed Wizard 144 can also be used to upload images and videos to be displayed, to manage the queue of live feed objects to be displayed, to manage current live feeds being displayed, etc.

[0087] In other words, the Live Feed Wizard 144 is used to receive input defining desired changes or behavior of the overall live feed system. In order to actually implement these desired changes, the Live Feed Wizard 144 communicates with a Live Feed System Controller 110, which is responsible for pulling live feed objects from the Database 106 and transmitting them to various locations for actual display or presentation. For example, the Live Feed System Controller 110 might transmit a live leaderboard object (which is updated based on the most current Scoring Data 128 ingested into the Database 106 via the LDK 124) to the user web portal, where it is presented in response to a user query.

[0088] In some examples, the Live Feed System Controller 110 can transmit a live leaderboard object to a live feed display that is located in the same operator venue as the omnidirectional locomotion system. This live feed display may be a standalone display unit or can be integrated with the hardware of the omnidirectional locomotion system itself. In some instances, particularly when the live feed display is located within the operator venue, it can be desirable to configure the live feed display as a passive device, i.e. capable only of displaying the live feed, not accepting inputs or modifications to the live feed. In this manner, users or other patrons at the operator venue will not be able to tamper with or otherwise interfere with the desired display of the live feed as configured in the Live Feed Wizard 144 of the Admin Portal 112.

[0089] In other scenarios, the live feed display may be provided with limited input functionality, e.g. a user or patron at the operator venue may be able to browse or scroll through a display of different leaderboards, or may be able to select a particular live feed to watch (similar to the manner in which one selects a television channel to watch), but the user or patron is unable to provide inputs beyond those to query or navigate through the available live feed elements.

[0090] Similarly, it is contemplated that the live feed and/or live feed objects presented in the User Web Portal 114 will be similarly resistant to tampering or other user modification of any definition parameters of either the live feed or the live feed objects, as this functionality is limited to the Admin Portal 112 and the Live Feed Wizard 114.

[0091] Multiple live feeds and/or live feed objects may be displayed simultaneously, e.g. in a split-screen or other divided screen arrangement. In some embodiments, the Live Feed System Controller 110 can push updates to all active live feeds as soon as the updated data is available, e.g. the live feeds are updated in substantially real-time. In some embodiments, the Live Feed System Controller 110 can transmit updated data to the live feed objects at some fixed, periodic, and/or pre-configured interval. For example, updates might be collected and compiled at the Database 106 or Live Feed System Controller 110 for a period of one minute, at which time the consolidated update package is then broadcast by the Live Feed System Controller 110 to the live feed objects. It is contemplated that the Live Feed System Controller 110 may update all live feed objects simultaneously, e.g., in a broadcast fashion, or that the Live Feed System Controller 110 may update live feed objects with a frequency that is defined during the creation of the live feed object.

[0092] FIGs. 4A-4R illustrates example graphical interfaces of the Leaderboard 136, Admin Portal 112, Leaderboard Wizard 142 and associated components described in FIG. 1.

[0093] FIGs. 4A-B illustrates example leaderboard wizards. The leaderboard wizards can be for the system admin (only accessible by administrators). The leaderboard wizard can enable system admins to create, view, filter, archive, and delete leaderboards. For example, creating a new leaderboard object can include some of the following information from an administrator: leaderboard title, subtitle, description/messaging, competition type, competition type option value, display tiebreaker column, etc. The administrator can also choose one or more filters to determine what data is displayed on the leaderboard. The wizard can also display for“view” the current leaderboards and associated data for selected leaderboards, as shown in FIGs. 4D-F. The wizard can also display data relating to user accounts and ranks, as shown in FIGs. 4G-H. The wizard can also archive leaderboards, as shown in FIGs. 4I-K. Archiving leaderboards is used when a leaderboard is completed, but the history of the leaderboard is going to be maintained in case it needs to be viewed in the future. The wizard can also delete leaderboards, as shown in FIG. L. Deleting leaderboards is used for instances where mistakes are made in the leaderboard manager. Any leaderboards that have been successfully run and completed are archived. If while creating a leaderboard, the admin makes a mistake, they can delete the leaderboard and make a new one. The admin can delete a leaderboard by clicking the “Delete” button next to a leaderboard on the table in the leaderboard manager. If the admin clicks the“Delete” button, a dialog box appears that asks if the admin is sure that they want to delete a leaderboard. If the admin clicks yes, then the leaderboard is deleted from the leaderboard manager. FIG. M illustrates an example leaderboard.

[0094] FIG. 4N-R illustrate example Live Feed Wizard 144. The system admin can create new live feed objects through the Live Feed Wizard 144 as shown in FIG. 4N. When creating an image live feed object (shown in FIG. 40), the admin fills in fields for“Image Title”,“Display Time (seconds)”, and“Active / Inactive”. The admin then uploads the image to be displayed in the live feed. The last step is to select the location for this object to be displayed. This field is a hierarchy tree where the admin can select Global / Regions / Countries / Operator Locations for these objects to be displayed. After all fields are populated, the admin clicks the save button to finish creating the object. When creating a video live feed object (as shown in FIG. 4P), the admin fills in fields for“Video Title”,“Display Time (seconds)”, and“Active / Inactive”. The admin then uploads the video to be displayed in the live feed. The last step is to select the location for this object to be displayed. This field is a hierarchy tree where the admin can select Global / Regions / Countries / Operator Locations for these objects to be displayed. After all fields are populated, the admin clicks the save button to finish creating the object. The administrator can also create a leaderboard live feed object, the admin selects which leaderboard to be displayed (this selects from the table of active leaderboards from the leaderboard manager), then fills in fields for“Display Time (seconds)”, and“Active / Inactive”. The last step is to select the location for this object to be displayed. This field is a hierarchy tree where the admin can select Global / Regions / Countries / Operator Locations for these objects to be displayed. After all fields are populated, the admin clicks the save button to finish creating the object.

[0095] FIGs 4Q and 4R illustrate editing and deleting Live Feed Objects. The system admin can manage the live feed through the live feed admin. For each of the objects in the live feed, the admin can change the order of the objects or edit the individual object itself. The down arrow moves the specified object down in the list, while the up arrow moves the object up in the list. The edit button opens the same window that is used to create a live feed object, but the admin can edit any of the fields and save it again. The system admin can delete live feed objects through the live feed admin. If the admin clicks the delete object next to a live feed object, then a dialog appears that asks if the admin is sure that they want to delete the object. If they select yes, then the object is deleted from the live feed. The live feed can displayed through the live feed interface.

[0096] FIG. 5A and FIG. 5B illustrate example system embodiments. The more appropriate embodiment will be apparent to those of ordinary skill in the art when practicing the present technology. Persons of ordinary skill in the art will also readily appreciate that other system embodiments are possible.

[0097] FIG. 5A illustrates a conventional system bus computing system architecture 500 wherein the components of the system are in electrical communication with each other using a bus 505. Exemplary system 500 includes a processing unit (CPU or processor) 510 and a system bus 505 that couples various system components including the system memory 515, such as read only memory (ROM) 520 and random access memory (RAM) 525, to the processor 510. The system 500 can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor 510. The system 500 can copy data from the memory 515 and/or the storage device 530 to the cache 512 for quick access by the processor 510. In this way, the cache can provide a performance boost that avoids processor 510 delays while waiting for data. These and other modules can control or be configured to control the processor 510 to perform various actions. Other system memory 515 may be available for use as well. The memory 515 can include multiple different types of memory with different performance characteristics. The processor 510 can include any general purpose processor and a hardware module or software module, such as module 1 532, module 2 534, and module 3 536 stored in storage device 530, configured to control the processor 510 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor 510 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric. [0098] To enable user interaction with the computing device 500, an input device 545 can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device 535 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with the computing device 500. The communications interface 540 can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

[0099] Storage device 530 is a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs) 525, read only memory (ROM) 520, and hybrids thereof.

[00100] The storage device 530 can include software modules 532, 534, 536 for controlling the processor 510. Other hardware or software modules are contemplated. The storage device 530 can be connected to the system bus 505. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor 510, bus 505, display 535, and so forth, to carry out the function.

[00101] FIG. 5B illustrates an example computer system 550 having a chipset architecture that can be used in executing the described method and generating and displaying a graphical user interface (GUI). Computer system 550 is an example of computer hardware, software, and firmware that can be used to implement the disclosed technology. System 550 can include a processor 555, representative of any number of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations. Processor 555 can communicate with a chipset 560 that can control input to and output from processor 555. In this example, chipset 560 outputs information to output device 565, such as a display, and can read and write information to storage device 570, which can include magnetic media, and solid state media, for example. Chipset 560 can also read data from and write data to RAM 575. A bridge 580 for interfacing with a variety of user interface components 585 can be provided for interfacing with chipset 560. Such user interface components 585 can include a keyboard, a microphone, touch detection and processing circuitry, a pointing device, such as a mouse, and so on. In general, inputs to system 550 can come from any of a variety of sources, machine generated and/or human generated.

[00102] Chipset 560 can also interface with one or more communication interfaces 590 that can have different physical interfaces. Such communication interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks. Some applications of the methods for generating, displaying, and using the GUI disclosed herein can include receiving ordered datasets over the physical interface or be generated by the machine itself by processor 555 analyzing data stored in storage 570 or 575. Further, the machine can receive inputs from a user via user interface components 585 and execute appropriate functions, such as browsing functions by interpreting these inputs using processor 555. It can be appreciated that example systems 500 and 550 can have more than one processor 510 or be part of a group or cluster of computing devices networked together to provide greater processing capability.

[00103] For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software. In some embodiments the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

[00104] Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.

[00105] Devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, rackmount devices, standalone devices, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.

[00106] The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.

[00107] Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims. Moreover, claim language reciting "at least one of' a set indicates that one member of the set or multiple members of the set satisfy the claim.