Route generation system within the virtual environment of a game application

Abstract

The system and process described herein can provide dynamic and realistic route generation based on actual route data within a game environment. The system allows for the generation of a route database for use with sports simulation game applications. This disclosure also allows for route generation during the runtime of the game application. The route generation system can help solve the problem of generating realistic and lifelike routes based on athletes' real-life movements.

Description

Background Technology

[0001] In video games, game applications can generate routes for in-game characters to move throughout the virtual environment to reach their destinations, such as passing routes in a football game. Typically, in-game routes have a start and an end point. For example, in a football game, each in-game character can follow a defined linear path from the start to the end of an assigned passing route. In more complex games, game applications can be configured to generate routes for many different in-game characters within the game environment. For instance, a video game can generate routes for multiple different characters running different passing routes for a single offensive play. Summary of the Invention

[0002] The systems, methods, and apparatuses disclosed herein each have several innovative aspects, but none of them alone assumes all the desired properties disclosed herein.

[0003] One embodiment discloses a computer-implemented method for generating routes within a game environment of a game application: executing a game application comprising a game environment, the game environment including at least one player-controlled character and multiple non-player-controlled characters, the multiple in-game characters being configured to be controlled by the game application; accessing multiple routes stored in a route database, each of the multiple routes being generated based on data collected from movements performed by real-world people along the route; receiving user input from a user computing system, the user input requesting at least one action to be performed by at least one of the multiple non-player-controlled characters during an in-game event; and responding to the user input... The process involves: determining a first game waypoint path for a first non-player controlled character within the game environment; filtering the plurality of routes using a first route filtering criterion based on characteristics associated with the first route to obtain a first route subset; analyzing the route subset based on route selection characteristics; selecting a first route from the first route subset based on the route selection characteristics; generating a character path for the first non-player controlled character based at least in part on the first route, the character path including a start point and a destination point, the character path including motion data associated with the movement of the first non-player controlled character along the first path; and outputting the first route to be executed by the first non-player controlled character before initiating the game event.

[0004] In some embodiments, the method includes: generating pose data for animation of a first non-player-controlled character based on the motion data; selecting a pose from a pose database based on the pose data, wherein the pose data stored in the pose database is based on motion capture data; and rendering the selected pose within the virtual environment. In some embodiments, the motion data for the first character path includes position, orientation, speed, and acceleration. In some embodiments, the first route filtering criteria include at least one of route type or relative movement angle. In some embodiments, the route selection characteristics include at least one of: distance to the defender, distance to the first down, receiver position, maximum speed, relative movement angle, and character position. In some embodiments, analyzing the route subset based on the route selection characteristics includes: generating a score based on at least one of route length from the path, the path's endpoint relative to the route's end point, character position, or the athlete running the original route. In some embodiments, generating the character path includes: combining the selected route as a segment with a procedurally generated segment to form the character path. In some embodiments, the procedurally generated segment of the character path is generated based on real-world path data. In some implementations, the route selection feature discards routes that do not meet a defined threshold. In some implementations, the role path is a pose trajectory matching path.

[0005] Another embodiment discloses a computing system comprising: a data storage device configured to store computer-readable instructions configured to execute a game application and a route database including a plurality of routes, each of which is generated based on data collected from movements performed by real-world people along the route; a processor configured to execute the game application, the game application being configured to generate a game environment, the game application including a route generation engine configured to: receive user input from a user computing system, the user input requesting at least one action to be performed by at least one of a plurality of non-player-controlled characters during a game event; and respond to the user input... The input determines a first game midpoint path for a first non-player controlled character within the game environment; filters the plurality of routes using a first route filtering criterion based on characteristics associated with the first route to obtain a first route subset; analyzes the route subset based on route selection characteristics; selects a first route from the first route subset based on the route selection characteristics; generates a character path for the first non-player controlled character based at least in part on the first route, the character path including a start point and a destination point, the character path including motion data associated with the movement of the first non-player controlled character along the first path; and outputs the first route for execution by the first non-player controlled character before initiating the game event.

[0006] In some embodiments, the route generation engine is further configured to: generate pose data for animation of the first non-player-controlled character based on the motion data; select a pose from a pose database based on the pose data, wherein the pose data stored in the pose database is based on motion capture data; and render the selected pose within a virtual environment. In some embodiments, the motion data for the first character path includes position, orientation, speed, and acceleration. In some embodiments, the first route filtering criteria include at least one of route type or relative movement angle. In some embodiments, the route selection characteristics include at least one of: distance to the defender, distance to the first attack, receiver position, maximum speed, relative movement angle, and character position. In some embodiments, the route generation engine is further configured to generate a score based on at least one of the following when analyzing the subset of routes based on the route selection characteristics: the length of the route from the path, the end point of the path relative to the route endpoint, the character position, or the athlete running the original route. In some embodiments, the route generation engine is further configured to combine the selected route as a segment with a procedurally generated segment to form the character path when generating the character path. In some embodiments, the procedurally generated segment of the character path is generated based on real-world path data. In some implementations, the route selection feature discards routes that do not meet a defined threshold. In some implementations, the role path is a pose trajectory matching path.

[0007] Although certain embodiments and examples are disclosed herein, the subject matter of the invention extends beyond the examples of the specific disclosed embodiments to other alternative embodiments and / or uses, as well as modifications and equivalents thereof. Attached Figure Description

[0008] Throughout the accompanying drawings, reference numerals are used repeatedly to indicate the correspondence between referenced elements. The drawings are provided to illustrate embodiments of the subject matter described herein, not to limit its scope.

[0009] Figure 1 An implementation example of a computing environment in which one or more implementations of a route generation system can be implemented is given.

[0010] Figures 2A-2C An implementation scheme for the process of generating a route database is illustrated.

[0011] Figure 3 A flowchart illustrating one implementation of the process for generating a route database is provided.

[0012] Figure 4 An example of a route generation implementation within a game environment is shown.

[0013] Figure 5A and Figure 5B An implementation scheme for a route selection feature used when selecting and generating routes within a game environment is illustrated.

[0014] Figure 6 An implementation scheme flowchart of one approach to the route generation process is shown.

[0015] Figure 7 An example of an implementation scheme for a computing device is shown. Detailed Implementation

[0016] Overview

[0017] One of the problems encountered in video games is that the routes run by characters in the game are often not very realistic. For example, characters will move in perfect straight lines and turn at unnaturally precise angles. Characters also often accelerate and move at speeds that are impossible to achieve in reality. This can result in unrealistic or unrealistic movement and animation. In games—such as sports simulations—this can undermine the immersion and realism of the game. Furthermore, much of the locomotion movement and animation used for characters in sports games or simulation games is based on motion capture movement of people performing the same or similar actions. Due to the unnatural movement, speed, and acceleration of characters in the game, the motion capture data used for animation may be difficult to match with the movement of characters in the game, which can further reduce the realism of the simulation produced by the game.

[0018] One solution to this problem is to base the routes of characters in the game on the actual routes taken by athletes in real-life matches. One difficulty in following this approach is capturing data associated with the routes athletes run during a match. One option is to analyze video data to determine the routes athletes run during a match. However, even with video tracking technology, it can be difficult to obtain precise information about an athlete's movement during a match. Another option, which will be described further in this paper, is to use tracking devices positioned on athletes to track their data during the match. For example, athletes can carry tracking chips in their shoes, shoulder pads, gloves, or other match equipment—such as rugby balls, rackets, hockey sticks, bats, or balls. The tracking chips can be used to collect telemetry data for each athlete during the match. This telemetry data can be used to assess the athlete's movement during the match and identify the route the athlete is running. The route can then be analyzed and added to a database of available routes that virtual characters can follow within the game application. The telemetry data can be divided into sections based on defined event intervals—such as an offensive play in a rugby match. Because the length of the event intervals can be indefinite, the telemetry data can include the start and end times of each offensive play.

[0019] Telemetry data for each route may include physical route data that identifies specific movements performed by a player during the route—such as trajectory, speed, acceleration, and position. The telemetry data for each route may have game-related metadata associated with the athlete and the route being run. For example, metadata may identify a specific athlete running a route during a particular attack in the game. The metadata may additionally include information related to other athletes in the game, such as the positions of other athletes on that athlete's team or the opposing team. The metadata can be used as additional contextual data, which can be used to identify and determine routes selected by the game application during the application's runtime.

[0020] Telemetry data can be processed and stored in a database as sub-paths used by the game application during runtime. These sub-paths can be used by the game application to generate more realistic running routes that can be performed by the character during the game application's runtime. This can produce more realistic running routes during gameplay and more realistic animations associated with the game-generated routes. This database can be installed locally on the game application, allowing its use during gameplay.

[0021] During the runtime of the game application, at each event interval, such as before the start of an attack, the user can provide input to the game application to select an attack to be executed within the game application. This execution of the attack by a character can include athletes on the team who are not under the user's control. These characters are controlled by the game application's artificial intelligence (AI) controller, which controls the characters' execution until the user takes control. The game application assigns routes to the characters based on the input provided by the user. For example, an attack selected by the user can assign three different passing routes to characters on the user's team. The game application can then generate waypoint paths for the characters within the virtual environment based on the assigned routes.

[0022] The route generation engine queries the database to identify a subset of all available routes that meet initial gating criteria. These gating criteria can be used to eliminate most routes in the route database that do not meet the route type and / or orientation requirements. For example, the gating criteria could eliminate all routes that are not slant routes. The remaining subset of routes can be scored to identify the best-matching route for an assigned route. Multiple different selection criteria can exist to select the best-matching route.

[0023] After selecting a route from the route database, the route generation engine can generate a Pose Trajectory Matching (PTM) path for the character based on the route data. The PTM path can include the selected path and procedurally generated path data to fill in any missing path data from the selected route. For example, procedurally generated data can extend the path beyond the end of the route data. The PTM path can include motion data used by the animation and rendering system to generate the character's pose at each frame. For example, velocity, position, orientation, and trajectory information can be used to match the character's movement with pose data in the animation database. Because the data associated with the route is based on the athlete's actual movement characteristics, the animation system can better match the motion data with the pose data used for the character. This can produce more realistic and lifelike movement and animation of the character during gameplay.

[0024] The systems and processes described herein can provide dynamic and realistic route generation within a game environment based on actual route data. As will be further described herein, this disclosure relates to a system for generating a route database for use with sports simulation game applications. This disclosure also allows for route generation during the runtime of the game application. The route generation system can help solve the problem of generating realistic and lifelike routes based on the real-life movements of athletes. Although the processes described herein will generally be applied to rugby games, the same systems and processes can be used to generate routes in other sports games or applications where the system controls or animates the movement of characters in the game that mimic real-life actions. For example, the process can be used to control the movement of a group of people rushing into battle or the movement of characters within a group of characters.

[0025] For the purposes of this disclosure, the term "user" can refer to a person operating a computing device to control the operation of a game application. For the purposes of this disclosure, the term "character" can refer to a virtual avatar or role that a user can control within a game application. This character can be a person, vehicle, object, and / or any virtual entity that a user can control within the game application. For the purposes of this disclosure, the term "athlete" refers to a real-world person competing in a sporting event or other real-world activity.

[0026] Overview of the video game environment

[0027] Figure 1 An embodiment of a computing environment 100 for implementing a route generation engine 120 and a route aggregation engine 140 is illustrated. Environment 100 includes a network 108, multiple user computing systems 102, and an interactive computing system 130, which includes an application host system 132 and a route data storage 134. For the sake of simplicity and without limiting the scope of this disclosure, Figure 1 Only one user computing system 102 and one interactive computing system 130 are illustrated, although multiple systems can be used.

[0028] User computing system 102 can communicate with interactive computing system 130 via network 108. Although only one network 108 is illustrated, multiple different and / or distributed networks 108 may exist. Network 108 can include any type of communication network. For example, network 108 can include one or more of a wide area network (WAN), local area network (LAN), cellular network, ad hoc network, satellite network, wired network, wireless network, etc. In some embodiments, network 108 can include the Internet.

[0029] Computing System

[0030] The computing system 102 includes computing resources 104 and application data storage 106. The user computing system 102 can have a wide variety of local computing resources 104, such as a central processing unit and architecture, memory, storage, graphics processing unit, communication network availability and bandwidth, etc. Furthermore, the user computing system 102 can include any type of computing system. For example, the user computing system 102 can be any type of computing device, such as a desktop computer, laptop computer, video game platform / console, set-top box, television (e.g., Internet TV), network-enabled kiosk, car console device, computerized appliance, wearable device (e.g., smartwatches and glasses with computing capabilities), and wireless mobile device (e.g., smartphones, PDAs, tablet computers, etc.), to name just a few. The following section discusses... Figure 7 A more detailed description of one embodiment of the computing system 102 is provided.

[0031] Game applications

[0032] User computing system 102 can execute game application 110 based on software code at least partially stored in application data memory 106. Game application 110 may also be referred to as a video game, game, game code, and / or game program. Game application 110 should be understood to include software code that computing device 102 can use to provide a game for a user to play. Game application 110 may include software code that informs computing device 102 of processor instructions to be executed, but may also include data used while playing the game, such as data relating to constants, graphics, route information, and other data structures. In the illustrated embodiment, game application 110 includes game engine 112, game data 114, game state information 116, and route generation engine 120.

[0033] In some implementations, user computing system 102 is capable of executing game application 110, which can be stored and / or executed in a distributed environment. For example, user computing system 102 can execute one part of a game, and a network-based computing system can execute another part of the game. For example, the game could be a multiplayer sports game, such as rugby, in which multiple users play the game competitively or collaboratively, and the game includes a client portion executed by user computing system 102 and a server portion executed by one or more application host systems 132.

[0034] Game Engine

[0035] The game engine 112 can be configured to execute various aspects of the operation of the game application 110 within the computing device 100. The execution of these aspects of playing the game within the game application can be based at least in part on received user input, game data 114, and game state information 116. Game data 114 may include game rules, pre-recorded motion capture poses / paths, environment settings, constraints, skeleton models, route information, and / or other game application information.

[0036] Game engine 112 can execute gameplay according to game rules. Examples of game rules may include scoring rules, possible inputs, actions / events, movement in response to input, etc. Other components can control what inputs are accepted and how the game proceeds, as well as other aspects of playing the game. Game engine 112 can receive user input and determine in-game events, such as actions, jumps, running, throwing, attacks, and other events applicable to game application 110. During runtime operations, game engine 112 can read game data 114 and game state information 116 to determine appropriate in-game events.

[0037] In one example, after game engine 112 determines a character event, the event can be passed to the motion engine, which can determine the appropriate movement and pose the character should make in response to the event and movement within the virtual environment. The motion engine can use a motion matching process to determine the character's pose. For example, motion characteristics generated by a PTM path can be used to create realistic animation of the character. These motion characteristics can be used to select the character's pose during movement along the PTM path. The character's pose selection process can use a pose matching process to determine the pose to be rendered at each frame. This pose matching process can use the character's motion characteristics at each point along the path to determine the best-matching pose for the character. The pose matching system can match velocity and position information with poses in a pose database to select the appropriate pose. The character's new pose can then be provided to the skinning and rendering engines.

[0038] The skinning and rendering engine can then provide character images to the object combiner to assemble animated, non-animated, and background objects into a complete scene. This complete scene can then be passed to the renderer, which generates new frames for display to the user. This process can be repeated for each frame during the execution of the game application. While this process has been described in the context of the character, it can be applied to any process used for handling events and rendering output for display to the user.

[0039] Game data

[0040] Game data 114 may include game rules, pre-recorded motion capture poses / paths, environment settings, environment objects, constraints, skeleton models, route information, and / or other game application information. At least a portion of game data 114 may be stored in application data storage 106. In some embodiments, a portion of game data 114 may be received and / or stored remotely, such as in route data storage 134, in which case game data may be received during the runtime of the game application.

[0041] Game status information

[0042] During runtime, the game application 110 may store game state information 116, which may include game state, character state, environment state, scene object storage, route information, and / or other information associated with the runtime state of the game application 110. For example, game state information 116 may identify the state of the game application 110 at a specific point in time, such as character position, character orientation, character actions, game level attributes, and other information that contributes to the state of the game application. Game state information may include constantly changing dynamic state information, such as character movement location, and static state information, such as the identification of the game level within the game.

[0043] Route generation engine

[0044] Route generation engine 120 can perform various functions to provide route generation capabilities within game application 110 and can operate during the runtime of game application 110. Route generation engine 120 can perform various route generation functions using route information stored in game data 114 or received from a route aggregation engine, as described herein. In some embodiments, route generation engine 120 can receive route information from interactive computing system 130 before the execution of the game application—such as during an update to the game application. In some embodiments, game application 110 can receive route information from interactive computing system 130 during runtime. In such embodiments, route generation engine 120 can dynamically update the route information within game application 110 based on information received from interactive computing system 130 during runtime. Route generation engine 120 can provide dynamic route information within the game environment. The functionality of route generation engine 120 can include dynamically determining a character's route during the runtime of the game application based on input from the user, as well as other route generation functions within the game environment. Various aspects of the operation of route generation engine 120 are described in further detail below.

[0045] Interactive computing system

[0046] Interactive computing system 130 may include one or more application host systems 132 and route data storage 134. Interactive computing system 130 may include one or more computing systems configured to execute as part of game application 110. In some embodiments, one or more application host systems 132 may include one or more computing devices, such as servers and databases that can host and / or execute as part of one or more instances of game application 110. In some embodiments, instead of or in addition to executing as part of game application 110, application host system 132 may execute another application that may supplement and / or interact with application 110 during the execution of an instance of application 110, such as route aggregation engine 140.

[0047] Application Hosting System

[0048] Interactive computing system 130 enables multiple users or computing systems to access a portion of game application 110 executed or hosted by interactive computing system 130. Interactive computing system 130 may include route aggregation engine 140. In some embodiments, host application system 132 may execute a hosting system for executing various aspects of the game environment. For example, in one embodiment, game application 110 may record the location of characters within the game environment. In some embodiments, game application 110 may be a single-player game in which interactive computing system 130 provides additional functionality when connecting to an instance of game application 110. For example, interactive computing system 130 may provide additional route information to route generation engine 120 based on aggregated information received from multiple users operating the same game application 110. In some embodiments, application host system 132 may provide dedicated hosting services for hosting multiplayer game instances or facilitate the creation of game instances hosted by user computing devices. In some embodiments, host application system 132 may provide users with lobbies or other environments for virtually interacting with each other.

[0049] Route aggregation engine

[0050] Route aggregation engine 140 allows for the generation of a route database to provide route generation functionality for game application 110. Route aggregation engine 140 can be configured to compile and aggregate route information based on telemetry data received from real-world athletes for use in the virtual environment of game application 110. Route information and telemetry data can be collected and aggregated from multiple external systems and data sources. In some implementations, route information can be collected from a third-party system that compiles telemetry data during real-life events—such as sporting events. For example, telemetry data can be generated based on data tracking devices worn by athletes during a rugby game.

[0051] Route aggregation engine 140 can be configured to generate a route database for generating routes within a virtual environment of game application 110. In some implementations, game application 110 may include multiple game environments. Route aggregation engine 140 can store routes for each game environment. Route aggregation engine 140 can be configured to automatically generate routes using telemetry data. Automatically generated routes can be combined with procedurally generated routes to generate PTM paths in the virtual environment. Telemetry data can be manipulated and filtered to remove aspects of routes that do not meet the criteria for use within the game application. For example, received route data may include athlete movements that occur after an attack ends. Aspects of the operation of route aggregation engine 140 are discussed in more detail below.

[0052] Route data storage

[0053] The interactive computing system 130 may include one or more route data storage units 134 configured to store route information associated with a game application 110 hosted by the interactive computing system 130 and / or the application host system 132. The route data storage units 134 may include route information associated with the game application 110, which is generated and aggregated by a route aggregation engine 140. The route information may be filtered and processed to make it available within the game application. The route information may include physical route data and metadata for each route, as well as other information used by the route aggregation engine 140. The physical route data may provide information recorded during a route taken at defined intervals, such as location (e.g., x, y, z, position), orientation on the field, speed, acceleration, events occurring during the game (e.g., passing, tackle, cross-bounds, etc.), and other information recorded as the athlete moves along the path. The metadata may include information associated with the game and the route. For example, metadata may include athlete name, athlete number, athlete ID, match ID, play ID, athlete position, route type, play direction, distance to the first attack, positions of other athletes relative to the athlete, and other information such as route-related information.

[0054] Route generation

[0055] Figures 2A to 2C Examples of implementations of various functions and routines that can be implemented by route aggregation engine 140 to generate route information for use within game application 110 are illustrated. The route aggregation engine can be configured to aggregate, analyze, and process telemetry data generated by athletes during real-life sporting events to generate route information for use within the game application. This route information can be provided by route aggregation engine 140 to route generation engine 120 for use during runtime. Route aggregation engine 140 can be configured to generate route information for installation with game application 110 or after the game application has been installed—such as in a game update.

[0056] Telemetry data

[0057] Telemetry data can be collected from athletes by a third-party collection service during a sporting event and can be provided to the route aggregation engine 140 for processing. During the game, multiple tracking devices deployed on athletes can record telemetry data 220 from them. For example, the tracking devices could be RFID tags placed on athletes and / or objects in the game—such as a ball. The telemetry data can be used to capture real-time location data, velocity, and acceleration of athletes throughout the sports field during each attack. In one example implementation, sensors throughout the stadium track tags placed on athletes' shoulder pads, which can be used to determine individual movement within inches. Examples of telemetry data used for routes are illustrated in [examples of such data]. Figure 2A In the middle. For example, in Figure 2A As illustrated, raw route data 220 is overlaid on a grid 250 within the virtual environment. Telemetry data for each route can include physical route data and route metadata. Physical route data can include information recorded during the route taken at defined intervals (e.g., every 0.1 seconds or other time periods), such as location (e.g., x, y, z, position), orientation on the field, speed, acceleration, events occurring during the game (e.g., passing, tackle, crossing, etc.), and other information recorded as the athlete moves along the path. Metadata can include information associated with the game and the route. For example, metadata can include athlete name, athlete number, athlete ID, game ID, attack ID, athlete position, route type, attack direction, distance to the first attack, positions of other athletes relative to the athlete, and other information such as that associated with the route. Route aggregation engine 140 can aggregate telemetry data received from third parties. Telemetry data can include hundreds of thousands of data points, which are divided into individual routes for each event period, such as each attack in a game.

[0058] Subpath generation

[0059] Figure 2A and Figure 2B This example illustrates how subpath 270 is generated from the original route data 200. Figure 2AAn example of raw telemetry data 200 for a route on grid 250 is illustrated. The illustrated virtual environment is provided for visualization of the route data. The route data includes a starting point 260, athlete trajectory 210, athlete movement speed 220, and line 230—points indicating where data is collected during the route. For example, data may be collected every 0.1 seconds. The route data includes game events 240 generated during the route. For example, pass_forward indicates when the quarterback throws the ball, followed by pass_arrived, pass_outcome_caught, and out_of_bounds. Game events 240 can be used to extract relevant data from the route and remove route data that is not useful for generating routes within the game application.

[0060] As illustrated, the player's position shifts upwards towards the end of the route because the player catches the ball at `pass_outcome_caught` and turns forward to run towards the end zone. The player's speed also decreases as they catch the ball. The player then runs out of bounds at `out_of_bounds`. The player's movement after catching the ball no longer represents their movement along the passing route. Therefore, route data can be processed to remove and discard data irrelevant to the passing route the player is running along. The portion of the route saved for later use can be called a sub-path. Figure 2B The example shows subpath 270 generated after the route data has been filtered and processed. In this case, the subpath is created by discarding the route data after the game event pass_arrived.

[0061] Other routes may include additional available route data after the pass has been thrown and caught. For example, even after the pass has been thrown to another player and caught by another player, the player may continue running along the passing route. The route information for each route received by the route aggregation engine 140 can be analyzed, filtered, and processed before being included in the route database. In some implementations, developers may manually process the route data to ensure that each route utilizes the correct sub-path associated with the passing route. In some implementations, a system may be configured to automatically filter and process the data. For example, the route aggregation engine 140 may utilize an algorithm to process telemetry data 220 to filter and discard data based on analysis of physical route data and metadata—such as, for example, game events, speed, orientation, and trajectory.

[0062] Implementation plan for route database

[0063] Figure 2CAn embodiment is illustrated for selecting a route within a route database after filtering and processing telemetry data. Each row 280 of the route database may correspond to a single sub-path for use by a route generation system within a game application. Sub-path data may include characteristics that can be used to filter route data during runtime route generation. Sub-path characteristics may be obtained directly from the telemetry data or derived from it. For example, telemetry data may be used to determine the maximum speed reached by an athlete during the route. In the illustrated embodiment, columns provide data for sub-path name 290A, athlete position 290B, maximum athlete speed 290C, movement angle 290D, and distance to the first attack 290E. The database may include any number of path characteristics as needed. In some embodiments, the sub-path data includes a subset of the total characteristics included in the original route data, which can reduce the storage space required to store the data and the processing power required to search for sub-path data during runtime. After the database is completed, it may be included in the game application for use during runtime. The route database may be included in the application's game code, provided during game updates, or provided to the game application via a network during runtime.

[0064] Route database generation process

[0065] Figure 3 An embodiment of a flowchart illustrating a process for generating a route database for use within a game application is provided. Process 300 can be implemented by any system capable of aggregating and processing telemetry data for the game application. For example, process 300 can be implemented wholly or partially by a route aggregation engine 140, an interactive computing system 130, an application host system 132, and / or another system. While any number of systems can implement process 300 wholly or partially, for the sake of simplicity, process 300 will be described with respect to a specific system. Furthermore, while embodiments of process 300 can be performed with respect to variations of systems encompassing various game application environments, for the sake of simplicity, process 300 will be described with respect to the interactive computing system 130.

[0066] At block 302, the computing system receives telemetry data. This telemetry data can be collected from athletes by a third-party collection service during a sporting event and can be provided to the system for processing. Multiple tracking devices deployed on athletes can record telemetry data from them during a sporting event.

[0067] At block 304, the system processes each route included in the telemetry data. This telemetry data can be divided into event segments, such as an offensive play in a rugby game. Route data can include physical route data recorded during the event segment, as well as associated metadata. For example, physical route data can include the starting point, athlete trajectory, athlete speed, and game events generated during the route, collected at defined intervals within the event segment. In some implementations, the system can generate a visual representation of the route data for developers to review.

[0068] At block 306, the system can generate a sub-path route data asset from the route data. This sub-path route data asset can be generated by processing the route data to extract route data related to the athlete's passing route. This processing may include discarding route data that is not relevant to the passing route being analyzed. In some implementations, developers may manually process the route data to identify the correct sub-paths associated with the passing route. In some implementations, the system can be configured to automatically filter and process the data. For example, the route aggregation engine 140 may utilize an algorithm to process the telemetry data 220 to filter and discard data based on analysis of physical route data and metadata—such as, for example, game events, speed, orientation, and trajectory.

[0069] At block 308, the system can determine the characteristics of the sub-path route data asset. The system can derive these characteristics based on features included in the telemetry data—such as the athlete's maximum speed on the route.

[0070] At block 310, the system can add sub-path routes to the route database. The route database can be configured to include selection features that can be used to filter route data during runtime route generation. The system can reduce the number of features or data associated with sub-path routes, which can help reduce the storage space of the route database. For example, the system can remove features included in the raw telemetry data that are irrelevant to route selection within the game application.

[0071] Implementation plan for route generation process

[0072] Figure 4An embodiment of a game environment 400 is illustrated, illustrating various aspects of route generation within a game application 110. A route generation engine 120 is configured to generate paths for characters within the game environment based on sub-path route data stored in a route database. The route generation engine 120 can generate routes that are more realistic and resemble the routes run by actual athletes during a competition, based on the sub-path route data. The route generation engine 120 is configured to generate PTM paths for characters by matching waypoint paths assigned to characters with the sub-path route data stored in the route database. The route generation engine 120 is also configured to procedurally generate path data to supplement portions of waypoint routes not included in the selected sub-path route data that matches the waypoint paths.

[0073] Figure 4 An example interface of a virtual game environment 400 is illustrated. A character 410 is located in a first position and has a waypoint path 420. The game environment 400 includes multiple other characters 412 on a game field. Character 410 is configured to move throughout the game environment 400 and generally follow a waypoint path assigned to that character based on user-provided game input. For example, the user can select an attack from an attack book that identifies waypoint paths 420. Each waypoint path has a defined type (e.g., out, slope, corner, etc.) and a relative movement angle (e.g., whether the path is left or right). Waypoint path 420 is constructed from a series of waypoint assignments. Each assignment can identify direction and distance. The waypoint path 420 is then created for the character using positional data within the virtual environment from the waypoint assignments. For example, as illustrated, a waypoint path extending forward and then including a 90-degree left turn across the field is generated.

[0074] The route generation engine 120 can filter available routes based on the characteristics of sub-path routes. The initial filtering criteria, which may be called gating criteria, are used to reduce the number of possible matching routes for the generated waypoint paths. In some implementations, gating criteria may include route type and relative movement angle. When attempting to match a waypoint path with routes in the route database, the route generation engine 120 performs this initial filtering step to eliminate sub-path routes in the database that do not meet the waypoint path type and direction requirements. Figure 5A The text further illustrates an example of a gating criterion used to filter routes.

[0075] refer to Figure 5AInterface 500 illustrates sample gating criteria 510 that can be used for initial querying of the route database. In the illustrated embodiment, the system includes nine different characteristics used as gating criteria. If any of the gating criteria fails, the sub-path route is not considered a feasible match for the waypoint path. As illustrated, a subset of sub-path routes 512 has a score and the following sub-path route 514 has no score. In the illustrated embodiment, the highest score is 255 and zero is considered a failure. In the illustrated interface, sub-path route 514 does not satisfy the last gating criterion 516, which corresponds to the relative movement angle of the sub-path route. Therefore, sub-path 514 has not yet been scored and will not be considered a match for the waypoint path.

[0076] The route generation engine 120 can use a filtering step to quickly identify a subset of the total available sub-path routes that meet the characteristics of the generated waypoint path. This process can eliminate most of the total sub-path routes and significantly reduce the computational cost of scoring each of the remaining routes and selecting a sub-path route.

[0077] Then, a subset of available sub-path routes can be further analyzed based on sub-path characteristics using defined route selection criteria. These criteria can be used to score one or more sub-path characteristics for each sub-path route to determine how closely the sub-path matches the game situation. Figure 4 In the illustrated implementation, route 430 is not selected, while route 440 is selected. An example of the scoring criteria is illustrated in... Figure 5B middle.

[0078] refer to Figure 5B Interface 550 displays a list of potential matches 560. Potential match 562 is selected and displayed as... Figure 4 Line 440 in the middle. Match 564 is... Figure 4 Line 430 in the diagram illustrates a close match. The route generation engine 120 analyzes the physical route data to see which sub-path route most closely matches the waypoint path. In some implementations, the maximum distance of a sub-path route from the waypoint path can be used as a base score, and the base score can then be modified based on the quality of the score generated during the initial filtering step and additional criteria 570—such as whether a player in the game matches an athlete running the original route.

[0079] At this stage, the scoring criteria may include additional thresholds that can be used to further reject routes. For example, a route might be rejected if its sub-path is more than a predetermined threshold distance from the waypoint path. Further reference Figure 4The visual representation of the maximum distance from the sub-path and waypoint paths is illustrated by line 442. A sub-path may also be rejected if one of its legs does not match any of the legs of the waypoint path. In the illustrated implementation, the sub-path with the lowest score is selected as the sub-path. Route selection criteria can further eliminate sub-paths that are not extended far enough or extend too far.

[0080] After selecting a sub-path route, the route generation engine 120 can generate a pose trajectory matching (PTM) path for the character based on the selected sub-path route. For instances where the sub-path route does not extend sufficiently to match the total distance of the waypoint path, the PTM path generated by the route generation engine 120 may include procedurally generated path segments. Segments of procedurally generated PTM paths can be generated using real-world data—such as motion capture data. PTM path generation is completed before initiating an attack. A PTM path can be initiated from the character's stationary position at the start of an attack. The route generation engine 120 generates a PTM path for each character based on the assigned waypoint path and the selected sub-path route.

[0081] The PTM path includes motion characteristics used by the graphics engine to select character poses and generate character motion animations. Motion data included in the PTM can include position, velocity, trajectory, orientation, acceleration, and other motion characteristics. The PTM path can use acceleration curves generated based on real-world data. These acceleration curves can serve as the basis for the character's movement along the PTM path. The PTM path can define the speed at which the character will run, which can be scaled based on the speed of the character assigned to run the PTM path. For different characters in different games, typically, the positional path followed by the character will be the same; however, the speed at which the character moves along points on the path can be scaled based on the character's velocity and / or acceleration characteristics in the game.

[0082] During runtime, motion characteristics generated by the PTM path can be used to create realistic animations of the character. These motion characteristics can be used to select poses for the character as they move along the PTM path. The character's pose selection process uses a pose matching process to determine the pose to be rendered at each frame. This pose matching process uses the character's motion characteristics at each point along the path to determine the best-matching pose for the character. The pose matching system matches velocity and position information against poses in a pose database to select the appropriate pose. Because the PTM path includes realistic velocity and position data, the character's pose data can be better matched with pose data in the pose database. In this way, more realistic movement and animation can be generated during the runtime of the game application.

[0083] Route generation process

[0084] Figure 6 An embodiment of a flowchart illustrating a process for generating routes for a character within a game environment of a game application is provided. Process 600 can be implemented by any system capable of executing and running a game application. For example, process 600 can be implemented wholly or partially by game application 110, game engine 114, route generation engine 130, interactive computing system 130, application host system 132, and / or another system. Although any number of systems can implement process 600 wholly or partially, for the sake of simplicity, process 600 will be described with respect to a specific system. Furthermore, although embodiments of process 600 can be implemented with respect to variations of systems encompassing various game application environments, for the sake of simplicity, process 600 will be described with respect to computing system 102.

[0085] At block 602, the route generation engine receives input from the user's computing system, which selects actions within the virtual environment that require the generation of one or more character routes. For example, the user can select an offensive action that includes a passing route for at least one character on their rugby team.

[0086] Block 603 represents a sub-procedure for generating a PTM path for each of one or more character routes within a virtual environment. This procedure is executed for each waypoint path before initiating an action requested by the user. For example, the sub-procedure could be completed for each character before initiating an attack in a rugby game.

[0087] At block 604, the route generation engine generates waypoint paths for each character in the requested route based on user input. A waypoint path is constructed from a series of waypoint assignments. Each assignment can identify direction and distance. Waypoint paths can be created for characters using waypoint assignments based on location data within the virtual environment.

[0088] At block 606, the route generation engine can filter available sub-path routes stored in the route database based on a first filtering criterion, thereby generating a subset of available sub-path routes. The route generation engine can query the route database to identify potential sub-path routes. The route generation engine can filter available routes based on the characteristics of the sub-path routes. The first filtering criterion may be referred to as a gating criterion and is used to reduce the number of possible matching routes for the generated waypoint paths. In some implementations, the gating criterion may include route type and relative movement angle. If any of the gating criteria fails, the sub-path route is not considered a feasible match for the waypoint path. Sub-path routes considered potentially matching may additionally receive an initial score.

[0089] At block 608, the route generation engine analyzes the subset of available sub-path routes based on route selection criteria. Selection criteria can be used to score one or more sub-path characteristics of each sub-path route to determine how closely the sub-path route matches the situation in the game. In some implementations, the maximum distance of a sub-path route from the waypoint path can be used as a base score, and this base score can then be modified based on the quality of the score generated during the initial filtering step in block 606. This score can also be modified by additional criteria—such as whether a player in the game matches an athlete running the original route. Route selection criteria can include additional thresholds that can be used to further reject routes. For example, a route might be rejected if it has a maximum distance from the waypoint path greater than a defined threshold. A sub-path route might also be rejected if one branch of it does not match any branch of the waypoint path. Scoring criteria can further eliminate sub-paths that do not extend sufficiently or extend too far.

[0090] At block 610, the route generation engine selects a route based on route selection features.

[0091] At block 612, the route generation engine 120 generates a PTM path based on the selected route. The PTM path can be a combination of sub-path segments and procedurally generated segments. The PTM path includes motion characteristics used by the graphics engine to select character poses and generate character motion animations. Motion data included in the PTM path can include position, velocity, trajectory, orientation, acceleration, and other motion characteristics. The PTM path can use acceleration curves generated based on real-world data. These acceleration curves can serve as the basis for the character's movement along the PTM path.

[0092] At block 614, the route generation engine 120 outputs a PTM path for execution within the virtual environment. During runtime, the motion characteristics generated by the PTM path can be used to create realistic animations of the character. These motion characteristics can be used to select poses for the character during its movement along the PTM path. The character's pose selection process uses a pose matching process to determine the pose to be rendered at each frame. This pose matching process uses the character's motion characteristics at each point along the path to determine the best-matching pose for the character.

[0093] Overview of computing devices

[0094] Figure 7An embodiment of computing device 10 according to this disclosure is illustrated. Other variations of computing device 10 may be made instead of the examples explicitly presented herein, such as removing or adding components to computing device 100. Computing device 10 may include gaming devices, smartphones, tablet computers, personal computers, laptop computers, smart TVs, car console displays, servers, etc. As shown, computing device 10 includes a processing unit 20 that interacts with other components of computing device 10 and external components of computing device 10. A media reader 22 is included that communicates with medium 12. Media reader 22 may be an optical disc reader capable of reading optical discs (such as CD-ROMs or DVDs), or any other type of reader capable of receiving and reading data from gaming medium 12. One or more of the computing devices may be used to implement one or more of the systems disclosed herein.

[0095] Computing device 10 may include a separate graphics processor 24. In some cases, graphics processor 24 may be integrated into processing unit 20. In some such cases, graphics processor 24 may share random access memory (RAM) with processing unit 20. Alternatively, or additionally, computing device 10 may include a discrete graphics processor 24 separate from processing unit 20. In some such cases, graphics processor 24 may have RAM separate from processing unit 20. Computing device 10 may be a handheld video game device, a dedicated game console computing system, a general-purpose laptop or desktop computer, a smartphone, a tablet computer, a car console, or other suitable system.

[0096] The computing device 10 also includes various components for enabling input / output, such as I / O 32, user I / O 34, display I / O 36, and network I / O 38. I / O 32 interacts with storage element 40 and with removable storage medium 44 via device 42 to provide storage for the computing device 10. Processing unit 20 can communicate via I / O 32 to store data, such as game state data and any shared data files. In addition to storage device 40 and removable storage medium 44, the computing device 10 also includes ROM (Read-Only Memory) 46 and RAM 48. RAM 48 can be used for frequently accessed data, such as when playing a game or performing fraud detection.

[0097] User I / O 34 is used to send and receive commands between processing unit 20 and user equipment (such as a game controller). In some embodiments, user I / O may include touchscreen input. The touchscreen may be a capacitive touchscreen, a resistive touchscreen, or other types of touchscreen technology configured to receive user input via tactile input from the user. Display I / O 36 provides input / output functionality for displaying images from the game being played. Network I / O 38 is used for network input / output functionality. Network I / O 38 may be used during game execution—such as when playing or accessing the game online.

[0098] The display output signal generated by display I / O 36 includes signals for displaying visual content generated by computing device 10 on a display device, such as graphics, user interface, video, and / or other visual content. Computing device 10 may include one or more integrated displays configured to receive the display output signal generated by display I / O 36. According to some embodiments, the display output signal generated by display I / O 36 may also be output to one or more display devices external to computing device 10, such as display 16.

[0099] The computing device 10 may also include other features that can be used with games, such as a clock 50, flash memory 52, and other components. The audio / video player 56 may also be used to play video sequences, such as movies. It should be understood that other components can be incorporated into the computing device 10, and other variations of the computing device 10 will be understood by those skilled in the art.

[0100] The program code can be stored in ROM 46, RAM 48, or storage device 40 (which may include hard disks, other magnetic storage devices, optical storage devices, other non-volatile storage devices, or combinations or variations thereof). A portion of the program code may be stored in a programmable ROM (ROM, PROM, EPROM, EEPROM, etc.), a portion of the program code may be stored in storage device 40, and / or stored on a removable medium such as game media 12 (which may be a CD-ROM, cassette tape, memory chip, etc., or may be available as needed via a network or other electronic channel). Typically, the program code may be found embedded in a tangible, non-transitory signal-bearing medium.

[0101] Random access memory (RAM) 48 (and possibly other storage devices) can be used to store variables and other game and processor data as needed. RAM is used, and RAM holds data generated during application execution, and portions of RAM may also be reserved for frame buffers, application state information, and / or other data needed or that can be used to interpret user input and generate display output. Typically, RAM 48 is a volatile storage device, and data stored in RAM 48 may be lost when computing device 10 is turned off or loses power.

[0102] When computing device 10 reads medium 12 and provides an application, information can be read from game medium 12 and stored in a memory device (such as RAM 48). Furthermore, data from storage device 40, ROM 46, a server accessed via a network (not shown), or removable storage medium 46 can be read and loaded into RAM 48. Although data is described as being looked up in RAM 48, it should be understood that data does not necessarily have to be stored in RAM 48 and can be stored in other memory accessible to processing unit 20 or distributed among several media (such as medium 12 and storage device 40).

[0103] It should be understood that not all objectives or benefits can be achieved according to any specific implementation described herein. Therefore, for example, those skilled in the art will recognize that certain implementations may be configured to operate in a manner that achieves or optimizes one or a set of benefits as taught herein, without necessarily achieving other objectives or benefits as may be taught or implied herein.

[0104] All processes described herein can be embodied in and fully automated via software code modules executed by a computing system comprising one or more computers or processors. The code modules can be stored on any type of non-transitory computer-readable medium or other computer storage device. Some or all of the described methods can be implemented using dedicated computer hardware.

[0105] Many other variations besides those described herein will become apparent from this disclosure. For example, according to embodiments, certain actions, events, or functions of any of the algorithms described herein may be performed in a different order, may be added, combined, or may be omitted entirely (e.g., not all described actions or events are necessary for the implementation of the algorithm). Furthermore, in some embodiments, actions or events may be performed concurrently, for example, through multithreaded processing, interrupt handling, or simultaneous execution by multiple processors or processor cores, or on other parallel architectures, rather than sequentially. Additionally, different tasks or processes may be performed by different machines and / or computing systems that can run together.

[0106] The various exemplary logic blocks and modules described in conjunction with the embodiments disclosed herein can be implemented or executed by a machine, such as a processing unit or processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The processor may be a microprocessor, but alternatively, it may be a controller, a microcontroller, or a state machine, or a combination thereof. The processor may include a circuit system configured to process computer-executable instructions. In another embodiment, the processor includes an FPGA or other programmable device that performs logical operations without processing computer-executable instructions. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors along with a DSP core, or any other such configuration. Although the processor is described primarily with respect to digital technologies herein, it may also include primarily analog components. For example, some or all of the signal processing algorithms described herein may be implemented in analog circuit systems or mixed analog and digital circuit systems. Computing environments can include any type of computer system, including but not limited to: microprocessor-based computer systems, mainframe computers, digital signal processors, portable computing devices, computing engines within device controllers or appliances, to name just a few.

[0107] Unless otherwise specified, conditional terms such as “can,” “could,” “might,” or “may” should be understood in the context as commonly used to express that some embodiments include certain features, elements, and / or steps, while other embodiments do not include certain features, elements, and / or steps. Therefore, such conditional terms are not generally intended to imply that features, elements, and / or steps are required in any way by one or more embodiments, or that one or more embodiments necessarily include logic for determining—with or without user input or prompts—whether these features, elements, and / or steps are included in any particular embodiment or whether they are to be performed in any particular embodiment.

[0108] Unless otherwise specified, disjunctive terms, such as the phrase “at least one of X, Y, or Z,” should be understood in the context as commonly used to mean that an item, term, etc., can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such disjunctive terms are generally not intended and should not imply that certain embodiments require the presence of at least one X, at least one Y, or at least one Z.

[0109] Any process description, element, or block described herein and / or depicted in the accompanying drawings should be understood as potentially representing a code module, segment, or portion of code including one or more executable instructions for implementing a particular logical function or element in the process. Alternative implementations are included within the scope of the embodiments described herein, in which elements or functions may be omitted, performed not in the order shown or discussed, including substantially simultaneously or in a reverse order, depending on the functions involved, as will be understood by those skilled in the art.

[0110] Unless otherwise explicitly stated, articles such as “a” or “an” should generally be interpreted as including one or more of the described items. Correspondingly, phrases such as “device configured to…” are intended to include one or more of the described devices. Such one or more described devices may also be collectively configured to perform the stated recitations. For example, “processors configured to perform recitations A, B, and C” could include a first processor configured to perform recitation A, which operates in conjunction with a second processor configured to perform recitations B and C.

[0111] It should be emphasized that many variations and modifications can be made to the above implementation scheme, and these variations and modifications should be understood as existing in other acceptable examples. All such variations and modifications are intended to be included within the scope of this disclosure.

Claims

1. A computer-implemented method for generating paths within the game environment of a game application, wherein the game application is a video game: Through a hardware processor configured with computer-executable instructions, Execute a game application that includes a game environment, the game environment including at least one player-controlled character and multiple non-player-controlled characters, the multiple non-player-controlled characters being configured to be controlled by the game application; Access multiple routes stored in a route database, each of which is generated based on data collected from movements performed by real-world people along the route; Receive user input from the user computing system, the user input requesting at least one action to be performed by at least one of the plurality of non-player-controlled characters during a game event; In response to the user input, a first game midpoint path for a first non-player-controlled character is determined within the game environment; The first route filtering criteria are used to filter the multiple routes based on the characteristics associated with the first route, thereby obtaining a subset of the first routes; The first route subset is analyzed based on route selection characteristics; Based on the route selection characteristics, select the first route in the first route subset; At least in part, a character path is generated for the first non-player controlled character based on the first route. The character path includes a start point and a destination point, and the character path includes motion data associated with the movement of the first non-player controlled character along the character path. as well as Before initiating the game event, output the character path to be executed by the first non-player-controlled character.

2. The computer-implemented method according to claim 1, further comprising: Based on the motion data, pose data is generated for the animation of the first non-player-controlled character; A pose is selected from a pose database based on the pose data, wherein the pose data stored in the pose database is based on motion capture data; as well as The selected pose is rendered within the game environment.

3. The computer-implemented method of claim 1, wherein motion data for the character path includes position, orientation, velocity, and acceleration associated with the movement of the first non-player-controlled character.

4. The computer-implemented method according to claim 1, wherein the first route filtering criterion includes at least one of route type or relative movement angle.

5. The computer-implemented method according to claim 1, wherein the route selection characteristics include at least one of the following: distance to the defender, distance to the first attack, receiver position, maximum speed, relative movement angle, and role position.

6. The computer-implemented method according to claim 1, wherein analyzing the first subset of routes based on the route selection characteristics comprises: A score is generated based on at least one of the following: the length of the route from the path, the end point of the path relative to the route's endpoint, the role's position, or the athlete running the original route.

7. The computer-implemented method according to claim 1, wherein generating the role path comprises: The first route is combined as a segment with a program-generated segment to form the role path.

8. The computer-implemented method of claim 7, wherein the program-generated segment of the role path is generated at least in part based on real-world path data.

9. The computer-implemented method according to claim 1, wherein analyzing the first route subset based on the route selection characteristics further comprises: Discard routes that do not meet the specified thresholds.

10. The computer-implemented method of claim 1, wherein the character path is a pose trajectory matching path.

11. A computing system for generating paths within the game environment of a game application, wherein the game application is a video game, the computing system comprising: A data storage device configured to store computer-readable instructions configured to execute a game application and a route database comprising multiple routes, each of which is generated based on data collected from movements performed by real-world people along the route; A processor configured to execute the game application, the game application being configured to generate a game environment, the game application including a route generation engine configured to: Receive user input from the user computing system, the user input requesting at least one action to be performed by at least one of a plurality of non-player-controlled characters during a game event; In response to the user input, a first game midpoint path for a first non-player-controlled character is determined within the game environment; The first route filtering criteria are used to filter the multiple routes based on the characteristics associated with the first route, thereby obtaining a subset of the first routes; The first route subset is analyzed based on route selection characteristics; Based on the route selection characteristics, select the first route in the first route subset; At least in part, a character path is generated for the first non-player controlled character based on the first route. The character path includes a start point and a destination point, and the character path includes motion data associated with the movement of the first non-player controlled character along the character path. as well as Before initiating the game event, output the character path to be executed by the first non-player-controlled character.

12. The system of claim 11, wherein the processor is further configured to: Based on the motion data, pose data is generated for the animation of the first non-player-controlled character; A pose is selected from a pose database based on the pose data, wherein the pose data stored in the pose database is based on motion capture data; as well as The selected pose is rendered within the game environment.

13. The system of claim 11, wherein the motion data for the character path includes position, orientation, velocity, and acceleration associated with the movement of the first non-player-controlled character.

14. The system of claim 11, wherein the first route filtering criterion includes at least one of route type or relative movement angle.

15. The system of claim 11, wherein the route selection feature includes at least one of the following: distance to the defender, distance to the first attack, receiver position, maximum speed, relative movement angle, and role position.

16. The system of claim 11, wherein the processor is further configured to generate a score based on at least one of the following when analyzing the subset of routes based on route selection characteristics: the length of the route from the path, the endpoint of the path relative to the route endpoint, the role position, or the athlete running the original route.

17. The system of claim 11, wherein the processor is further configured to, when generating the role path, combine the first route as a segment with a program-generated segment to form the role path.

18. The system of claim 17, wherein the program-generated segment of the character path is generated at least in part based on real-world path data.

19. The system of claim 11, wherein the processor is further configured to discard routes that do not meet a defined threshold, at least in part, based on the route selection characteristic.

20. The system of claim 11, wherein the character path is a pose trajectory matching path.

Images