Runtime Evaluation of Procedural Content Generation in an Endless Runner Game Using Autonomous Agents

The [SerializeField] variables (script fields exposed to the Unity editor while remaining private to other code) are exposed to the Unity Inspector (the editor panel that displays and edits a game object's properties at design time) and attached to the attached to the player runner prefab. These values allow the player movement behaviour to be tuned directly from the editor without changing the script every time. The main exposed fields are:

The scene script starts with the Start() function calling the component initialisation logic. At this point, the Rigidbody configuration is applied so that the player does not rotate incorrectly during movement. Rotation is locked across the X and Z directions, linear damping is applied with $c\; =\; 2f$, and interpolation is enabled to give smoother motion. The safe spawn position is also stored for later re-spawn, so that the player can be teleported back after falling below the valid playable area. The initial boolean flags are then set as isGrounded = 1 and isJumping = 0.

The frame loop is separated according to Unity's execution model. The Update() function (called once per rendered frame) is used for input, animation and ground checks, while FixedUpdate() (called at a fixed physics interval, independent of frame rate) is used for the physics update where the linear velocity is overwritten and the model tilt is corrected.

Holding W sets the player into the running state for the movement logic and animation controller. Holding A or D provides a discrete horizontal value for side movement. Tapping Space while the player is grounded sets the isJumping flag to true. This keeps the control scheme simple and matches the endless-runner structure of the game.

Ground detection is handled using ray casting (projecting an invisible line from a point in a chosen direction and reporting the first surface it intersects). A short ray of 0.3 metres is fired from the feet of the player. If this ray hits the groundMask layer, then isGrounded becomes true and the landing state is cleared. This check is required before applying the jump logic, because the player should not be allowed to repeatedly jump while already in the air.

Forward velocity is not applied as an instantaneous change. The script uses linear interpolation [14] so that the current forward velocity advances gradually towards the target, producing a smooth transition rather than a step:

where

When the player is running and grounded, $v\_z$ is assigned runSpeed directly. The interpolation in equation (1) applies only when the player decelerates to zero.

For small $\backslash Delta\; t$, the recurrence approximates exponential approach,

so the controller accelerates and decelerates with a time constant of approximately 0.1 s. Here, runSpeed is the configured running speed, $v\_z$ the current forward velocity, $\backslash Delta\; t$ the physics timestep, and the factor 10 controls the rate at which the velocity approaches its target.

Lateral motion is computed from the discrete horizontal input:

where $h\; \backslash in\; \backslash \{-1,\; 0,\; +1\backslash \}$, with $h\; =\; -1$ for left, $h\; =\; +1$ for right, and $h\; =\; 0$ when no lateral key is pressed. The jump action overwrites the vertical component using the configured jump force,

and, when the player is already running, an additional forward impulse is applied along the Z-axis,

where $\backslash mathbb\{I\}\_\{\backslash text\{running\}\}$ equals 1 when the player is in the running state and 0 otherwise. After lift-off, the vertical position follows the standard kinematic equation,

with $y\_0$ the vertical position at the start of the jump, $y(t)$ the position at time $t$, and $v\_y$ the vertical velocity immediately after lift-off. A linear damping coefficient of $c\; =\; 2\; \backslash text\{\; s\}^\{-1\}$ is applied through the Rigidbody, so that any unforced velocity decays as $v(t)\; =\; v\_0\; e^\{-2t\}$. This prevents residual drift after input release without producing an abrupt stop. If the player falls below $y\; =\; -8\; \backslash text\{\; m\}$, the controller triggers a respawn that teleports the character back to the configured spawn point and resets the velocity. Up to nine respawns are permitted per run before the game-over state is entered. This safeguard is required because the procedural ground occasionally contains transient gaps between tile boundaries during navigation rebakes.

The terrain generation script is controlled through the following core parameters:

Tiles are spawned according to two conditions. The first is a temporal trigger: a new tile is generated when the elapsed time since the previous spawn exceeds the active interval,

The interval itself contracts as the player's speed increases,

with the player's instantaneous speed estimated from successive forward positions,

The scaling constant is $\backslash gamma\; =\; 0.01$, and the clamp [15] bounds the interval within $[\backslash Delta\; t\_\{\backslash min\},\; \backslash Delta\; t\_\{\backslash max\}]$ for any input.

The second condition is a proximity check. When the most recently generated tile is sufficiently far ahead of the player, spawning is suspended,

so that the system does not extend the world beyond the range that any agent or the player will reach in the near term. The parameters above denote: $t$ the current time; $t\_\{\backslash text\{lastSpawn\}\}$ the time of the previous spawn; $\backslash Delta\; t\_\{\backslash text\{spawn\}\}$ the active spawn interval; $v\_p(t)$ the player's instantaneous speed; $z\_p(t)$ the player's forward position; $z\_g$ the forward position of the most recent tile; $\backslash gamma$ the speed-to-interval coupling constant; and $\backslash delta\; t$ the sampling step used to estimate $v\_p$.

When a new ground tile is spawned, its Z-axis position is calculated as:

where $z\_g$ is the Z-axis position of the last tile which has been spawned. All the tiles spawned are instantiated as child objects of the game object called GroundContainer to organise the hierarchy. After the instantiation, the environment objects are spawned via the object spawn manager.

The navigation surface, also called the NavMesh (a simplified walkable map that Unity automatically generates from scene geometry so AI characters can pathfind across it), is the substrate on which the AI agents move [16]. It can be understood as a runtime traversability map that defines where an agent may walk, jump, or stop. Because the ground is generated dynamically, the navigation surface must also be updated during runtime; a single bake at scene load is not viable.

Three triggers initiate a re-bake:

The baked region is re-centered on the player at every rebuild,

so that its coverage is the interval $[z\_p\; -\; d\_\{\backslash text\{behind\}\},\; z\_p\; +\; d\_\{\backslash text\{ahead\}\}]$, with $d\_\{\backslash text\{ahead\}\}\; =\; 600$ m and $d\_\{\backslash text\{behind\}\}\; =\; 50$ m.

The navigation rebake (re-computing the walkable map from the current geometry) is performed asynchronously (off the main thread, so the game does not freeze while it runs) to avoid frame drops (single rendered frames that take noticeably longer than the budget and produce a visible stutter). An earlier synchronous implementation produced visible stalls [17] because the engine halted the main thread at every rebuild while it walked the colliders, surfaced the mesh, and uploaded it. The current implementation issues the rebuild as a non-blocking job, summarised in Algorithm 1, so that the navigation surface remains current without forcing the main loop to halt during a bake.

For smooth performance and optimal use of memory, every generated ground tile checks the player's current position and destroys itself after the player has safely moved ahead. This is required because the terrain is generated continuously, and keeping every old tile in the scene would slowly increase the number of active objects without adding anything useful to the current gameplay.

Let $z\_\{\backslash text\{tile\}\}$ be the Z-axis position of the tile and $z\_p$ be the coordinate of the player on the Z-axis. For every single tile, a threshold is set as:

The moment the player moves 400 units beyond this value, the tile is scheduled to delete itself:

The implementation uses a delayed destruction call:

Destroy(this.gameObject, 5.0f)

The 5-second delay works as a small safety buffer for remaining references before Unity removes the object from the scene. This keeps the older procedural terrain from staying in memory once it is no longer part of active gameplay, without making the ground disappear too aggressively.

Each generated ground tile is divided across the X-axis into a one-dimensional grid. This grid is used to decide the possible positions where environmental objects can be placed. The width of the available spawning region is first calculated as:

The number of cells for the tile is then taken as the maximum between the rounded-up width and a minimum value of 12:

This same calculation is implemented in the script as:

float width = xAxisRange.y - xAxisRange.x;
int cells = Mathf.Max(Mathf.CeilToInt(width), 12);

For every tile, the number of spawning attempts is calculated from the spawn-density percentage. This makes the amount of generated objects dependent on the configured spawn rate, while still keeping it bounded by the number of available grid cells:

Here, $p\_\{\backslash text\{spawn\}\}$ represents the density percentage used for object spawning. The ground agent lane is also preserved using clearHalfwidth, so that the grid does not place objects directly inside the main path required by the player. This makes the spawning process controlled enough to avoid obvious blockage, but still random enough to keep the generated environment unpredictable.

The placement stage starts after the grid cells and the number of spawning attempts have already been calculated. The cells are randomly chosen, but the selection is not completely left open. Once a cell is selected, its neighbouring cells ($i\; -\; 1,\; i\; +\; 1$) are marked as occupied. This prevents objects from clustering too closely on the same ground tile and keeps the placement more distributed across the available width.

The X-coordinate of the object is fixed from the selected grid cell. The Z-axis position is given a small jitter so that objects are not spawned in a perfectly straight line:

After this position is calculated, a ray cast is performed towards the ground. The purpose of this ray cast is to confirm that valid ground exists at the selected position. If the ray cast does not find a valid ground hit, that object is skipped. This prevents objects from being instantiated in empty space or outside the playable ground area.

The correct prefab is then selected from the current skybox variant. Every skybox variant has multiple prefabs associated with it, so the visual objects spawned in the environment remain connected with the active skybox theme. The prefab is selected randomly from the available objects of that variant.

Once the ray cast returns a valid ground hit, the object is instantiated at that point. Snapping to ground is performed through SnapToGround(), where the boundary of the object is used to align the base with the terrain. Some specific objects with complex geometry at their base are forced down into the Y-axis. These objects mainly involve variants of trees and a rock cliff. This workaround is necessary because these assets do not always have a stable lower base after spawning. Certain objects are also allowed to float above the ground where the visual effect is intentional.

The generated objects are removed using a separate despawning rule from the ground tiles. This is required because the environmental objects do not need to remain in the scene once the player has already passed them. If they are kept for too long, they continue to occupy memory and physics resources without contributing to the current game state.

For each spawned object, the system compares the Z-axis position of the player with the Z-axis position of the object. The object is removed when the player moves more than 50 units ahead of it:

This threshold is deliberately smaller than the terrain clean-up threshold. Objects are therefore deleted before the ground tile itself is removed. This ordering is important because if the ground disappears first, the remaining objects may fall through the environment, accelerate due to gravity and remain active as unnecessary physics bodies.

The despawning mechanism therefore keeps the generated scene bounded around the active play area. It allows the game to continue producing new objects ahead of the player while removing old objects behind the player before they become an avoidable runtime cost.

At each frame, the aerial agent calculates a target position ahead of the player. Since $\backslash Delta\_z$ represents a fixed forward offset, the target Z-position is calculated by adding this offset to the player's current Z-axis position and then clamping it to the farthest generated ground position:

Here, $z\_p$ is the player's position on the Z-axis, $\backslash Delta\_z$ is the fixed forward offset used by the aerial agent, and $z\_\{\backslash text\{ground,last\}\}$ is the position of the farthest recently spawned ground tile. The minimum operation prevents the aerial agent from moving into empty space beyond the generated terrain.

The full target position is represented as:

where $x\_p$ is the player's X-axis position, $\backslash Delta\_x$ is the lateral offset, and $h\_f$ is the fixed altitude maintained by the aerial agent. The aerial agent is kept independent from the engine's gravity and normal physics response because its role is to inspect the upcoming generated path, not to behave as another physically simulated character.

The position of the aerial agent is updated using a smoothed-velocity interpolation routine. Instead of placing the aerial agent directly at the target position, the method moves it towards the target through a smoothed velocity update:

Here, $p\_f(t)$ is the current aerial agent position, $p\_\{\backslash text\{aerial,target\}\}$ is the target position calculated ahead of the player, $v\_f$ is the current velocity reference used by the smoothing function, $T\_s$ is the smoothing time, and $v\_\{\backslash text\{max\}\}$ is the maximum speed allowed for the aerial agent.

This keeps the agent responsive, but prevents sudden jumps in its movement. The aerial agent follows the generated path ahead of the player while remaining constrained by the smoothing and maximum-speed parameters. This is important because the agent is used for evaluation, so unstable or abrupt motion would make the scanning process less reliable.

The area ahead of the aerial agent is divided into tile-like segments along the Z-axis. Each segment is scanned using horizontal probe rows, with multiple ray origins distributed across the width of the ground. From each origin, a ray is fired downward towards the generated terrain:

Here, $x$ varies across the width of the ground, $y\_\{\backslash text\{scan\}\}$ is the height from which the ray is cast, and $z\_\{\backslash text\{row\}\}$ is the Z-axis position of the row currently being examined.

A row is considered passable only when it contains a continuous clear interval of sufficient width for the player to move through:

In this condition, $[a,\; b]$ represents a continuous interval across the scanned row, $w\_\{\backslash text\{clear\}\}$ is the minimum required clear width, and $C(x)\; =\; 0$ indicates that no blocking collider is detected at the sampled position. If no such interval exists, the row is treated as unsafe.

This formulation evaluates the path as a traversable corridor rather than as isolated ground hits. A generated section is therefore accepted only when there is enough uninterrupted space for the player to pass through. The volumetric checks described in the next subsection extend this test by detecting physical collider volume that may not be fully captured by individual rays.

Ray casting provides a narrow, line-based view of the generated corridor. This is useful for sampling the ground and checking whether a clear passage exists, but it does not fully describe the physical volume occupied by irregular objects. For this reason, the scanner supplements the ray probes with Physics.OverlapBox checks (queries that ask the physics engine which colliders intersect a defined 3D box, rather than only what a single line hits).

The overlap-box test is centred on the tile being inspected and covers the traversable corridor window. Any collider intersecting this volume is captured as part of the scan result. This makes the evaluation less dependent on whether a thin ray happens to strike the exact obstructing part of an object. It is particularly relevant for prefabs with uneven geometry, extended branches, wide bases, or collider shapes that do not align neatly with the visual mesh.

In this form, the ray probes and volumetric sweeps serve different purposes. The rays estimate whether a continuous path exists across the scanned row, while the overlap-box check verifies whether the same corridor is physically occupied by colliders. The two checks together give a more reliable assessment of whether the generated region is actually usable by the player.

Objects detected through the ray probes or overlap-box checks are recorded using their collider information and the name of the corresponding root object. This keeps the blockage report tied to the actual generated prefab rather than only to an anonymous physics hit. The reported data therefore remains useful for later analysis, because the problematic object can be traced back to the spawned environment asset.

When the automatic-removal option is enabled, the scanner can destroy objects that block the corridor before the player reaches that section. This behaviour is kept as part of the evaluation mechanism because the generated world is produced at runtime, and some invalid object placements may need to be handled immediately rather than only reported after failure.

Even when an object is removed, the blockage is still recorded with its relevant details, including object identity, size and layer information. The removal step therefore does not hide the generation problem. It only prevents the detected blockage from becoming an immediate obstacle for the player, while preserving the evidence needed to study why that object placement was unsafe.

The ground agent validates the generated terrain from a ground-navigation perspective. The aerial agent can inspect the corridor from above, but an overhead scan does not confirm that the same region is navigable through the baked NavMesh. The ground agent therefore acts as a second evaluator by attempting to move through the generated path using the runtime navigation system.

The target position of the ground agent is calculated ahead of the player:

Here, $x\_p$ is the player’s X-axis position, $y\_\{\backslash text\{navMesh\}\}$ is the valid height sampled from the navigation mesh, and $D\_\{\backslash text\{lookAhead\}\}$ is the forward distance used to keep the ground agent ahead of the player. The target is therefore tied to the navigable surface rather than being an arbitrary point in world space.

The ground agent speed is adjusted according to the player’s forward velocity:

The lower bound of 10 ensures that the ground agent continues moving even when the player’s forward velocity is low. The additional boost keeps the ground agent separated from the player, allowing navigation problems to be detected before they become immediate gameplay failures.

A practical issue observed during runtime was that the ground agent could become stuck around overlapping NavMesh regions between procedurally generated ground tiles. This failure is different from an ordinary obstacle blockage. The path may appear open in the scene, but small discontinuities or boundary artefacts in the baked navigation surface can prevent the agent from progressing.

The stuck condition is evaluated using both movement progress and NavMesh velocity. The ground agent is treated as stuck when its Z-axis position changes by less than the configured threshold while its NavMesh velocity is nearly zero. Using both conditions reduces false positives, since the agent may briefly slow down or adjust its direction without actually being trapped.

When this condition is detected, the recovery mechanism moves the ground agent forward by the configured step, places it on the nearest valid NavMesh position, resets the current path, and applies a cooldown before another recovery attempt can occur. The cooldown prevents repeated recovery actions during a short navigation disturbance.

This recovery mechanism does not remove the underlying generation issue. Its purpose is to keep the evaluator active when the failure is caused by minor NavMesh overlap or tile-boundary artefacts, so that the system can continue inspecting the generated path ahead.

The ground agent also performs corridor scanning and obstacle detection, but from a ground-navigation perspective. While the aerial agent scans the generated region from above, the ground agent checks whether the same region can be approached through the baked NavMesh surface.

This gives the evaluation system a second form of evidence. A section may pass the overhead scan because there is visible ground and some clear space, but the ground agent may still fail if the navigable surface is broken, blocked, or not connected properly across generated tiles. The ground agent scan therefore focuses less on visual openness and more on practical traversability.

Detected problems are treated as part of the runtime evaluation report. In this way, the ground agent acts as a ground-level validator for the procedural generation system, complementing the aerial agent rather than replacing it.

The ground agent applies obstacle detection through a dedicated obstacle layer rather than treating every collider in the scene as a possible blockage. The agent’s obstacleMask (a bit mask telling the physics queries which Unity layers count as obstacles and which to ignore) is configured to the Obstacles layer in the Unity Inspector, and the obstacle prefabs used by the procedural generator are marked with this layer. This keeps the scan focused on objects that can actually interfere with traversal, instead of mixing terrain, decorative objects, agent colliders and unrelated scene elements into the same detection process.

The ground agent uses the same general scanning idea as the aerial agent, but its interpretation is different. The aerial agent can remove blocking objects when automatic removal is enabled, whereas the ground agent does not modify the generated scene. Its role is diagnostic. It performs ray-based checks

and supplements them with Physics.OverlapBox sweeps for irregularly shaped objects, then records the detected obstacle colliders and the corresponding tile position.

This distinction is useful for evaluation. If the ground agent reports a blockage, the result represents a ground-navigation failure rather than an automatically corrected generation issue. The blockage data is then passed to the reporting pipeline, where it can be preserved for later inspection instead of being lost during runtime.

When an impassable tile is detected, the blockage information is sent through the BlockageReporter class. Each report is stored as a serialisable data object (a plain data record that Unity can convert into bytes so it survives a scene change or can be written to disk), so that the failure state can be carried across scenes and later rendered in the exit-report view. The collected reports are stored in a static cache, which allows the detected blockage information to survive the transition from the running game scene to the report scene.

The captured fields are summarised in Table 4.

This structure keeps the report close to the actual generation process. The object name identifies the spawned prefab involved in the blockage, while the scanner and generation parameters show the procedural conditions under which the blockage was detected.

The exit-report scene renders the stored blockage data using TextMeshPro. The BlockageReportDisplay component converts the cached blockage records into a readable report, with formatting and margins suitable for viewing inside the game. The scene therefore acts as a bridge between runtime detection and human inspection.

If no blockage data is available, the scene does not remain blank. A fallback message is displayed instead, indicating that no reports are present and giving possible reasons such as no detected blockages, data loss or cache reset. This makes the report scene useful both when failures are detected and when the evaluation run completes without recorded blockage data.

The PDF export mechanism provides a persistent version of the crash report outside the Unity scene. The PdfExporter script collects the report text and writes it into a readable PDF document. The exporter handles line wrapping, pagination, margins and report formatting, which is necessary because blockage reports can vary in length depending on the number of detected objects and scanner entries.

The implementation writes the PDF structure directly, including pages, font objects and text streams [19]. The resulting document can be saved locally in a stand-alone build. This makes the crash report usable beyond the immediate game session and allows the detected procedural failures to be reviewed after execution.

Three structural properties of the system are determined entirely by the constants in the spawner and scanner scripts and require no runtime measurement.

F1 — Spawner saturation bound (supports H2). With the X-range $[-7.1,\; 10.55]$ giving $W\; =\; 17.65$ m and $N\; =\; \backslash max(\backslash lceil\; W\; \backslash rceil,\; 12)\; =\; 18$ cells, a clear half-width of 2 m excludes the four cells whose centres satisfy , leaving 14 candidate cells. Because each successful placement marks both itself and its two neighbours as occupied (Section 4.5.2), the maximum number of objects that can ever coexist on a single tile is the size of a maximum independent set on the path of 14 available cells, which is 8. Solving $\backslash lceil\; N\; \backslash cdot\; p\_\{\backslash text\{spawn\}\}/100\; \backslash rceil\; =\; 8$ gives a saturation threshold $p\_\{\backslash text\{spawn\}\}^*\; \backslash approx\; 44\backslash \%$. The spawn-density slider therefore exposes a controllability ceiling that is structural: requesting 50%, 75%, or 100% cannot place more objects than requesting $\backslash approx\; 44\backslash \%$, and any extra demand is dissipated as failed re-roll attempts under the safety counter attempts < cells * 5.

F2 — Per-segment scan cost (supports H3). A single call to FlyerCorridorScanner.ScanCorridor performs $\backslash lceil\; L\_\{\backslash text\{seg\}\}/g\_z\; \backslash rceil\; +\; 1\; =\; 21$ horizontal probe rows over a segment of length $L\_\{\backslash text\{seg\}\}\; =\; 10$ m with row gap $g\_z\; =\; 0.5$ m. Each row sweeps the corridor with X-step 0.05 m across a width of 2.15 m, giving up to $\backslash lceil\; 2.15/0.05\; \backslash rceil\; +\; 1\; =\; 44$ rays in the worst case (no early-exit on a sufficiently large clear gap). The per-segment ray budget is therefore bounded above by $21\; \backslash times\; 44\; =\; 924$ rays, plus a single Physics.OverlapBox call. Because the scanner is gated by tileZ <= _lastScannedTileZAxis, this work is performed at most once per $L\_\{\backslash text\{seg\}\}$ of forward travel, irrespective of frame rate. The ground tile length is 96 m, so each ground tile incurs $\backslash lceil\; 96/10\; \backslash rceil\; =\; 10$ scanner segments. Note that the scanner segment length (10 m) is not the same as the ground tile length (96 m); the two operate at different granularities, and conflating them overestimates per-tile work by an order of magnitude.

F3 — NavMesh coverage relative to look-ahead (supports H4). The aerial agent maintains a forward offset of $\backslash Delta\; z\; =\; 200$ m, while the ground agent uses a NavMesh look-ahead of $D\_\{\backslash text\{lookAhead\}\}\; =\; 300$ m, both within the baked region of $[z\_p\; -\; 50,\; z\_p\; +\; 600]$ m (Section 4.4.4). The ground agent therefore evaluates a larger forward window than the aerial agent under default settings, so the two agents do not in general cover the same set of tiles even when both are active.

Together, F1 establishes that the spawn-density slider has a controllability ceiling at $p\_\{\backslash text\{spawn\}\}^*\; \backslash approx\; 44\backslash \%$, F2 establishes that scanner cost is constant per metre travelled rather than per frame and is bounded above by 924 ray probes plus one Physics.OverlapBox call, and F3 establishes that the two agents inspect non-coincident forward windows under default settings. These are the claims that follow directly from the implementation; the corresponding empirical quantities ($\backslash rho\_\{\backslash text\{spawn\}\}$, mean frame time and its violation rates, $J(A,\; G)$) require a runtime-measurement batch and are not reported here.

The structural results F1–F3 follow from the code constants and therefore generalise only to the parameter set used in the released build; changing $W$, $N$, the clear half-width, the row gap, or the X-step changes both the saturation point and the ray budget. The remaining metrics defined in Section 3.1 require runtime instrumentation and are not reported in this paper; their empirical instantiation on the released build is left as future work, together with the player study that would be required to extend the analysis from technical playability to human enjoyment. Ground-truth labels for false positives and false negatives are not directly observable at runtime and would rely on manual review of logged replays, which would introduce an annotator dependency. Commercial titles such as No Man’s Sky [1] and Caves of Qud [2, 3] are retained only as qualitative inspiration for automated probing of generated content, not as numerical baselines, because their scale, asset budget, and production goals differ substantially from a single-author research prototype and a side-by-side comparison would not be meaningful.

The framework in Section 3.1 instantiates three of the four axes identified by Cook et al. [9] for procedural-level-generation systems: playability via $R\_\{\backslash text\{block\}\}$ and $R\_\{\backslash text\{remove\}\}$; controllability via the spawn-density response in conjunction with the structural bound F1; and performance via the frame-time distribution against Unity’s documented budgets [12, 13]. Diversity is approached by the prefab entropy $H\_\{\backslash text\{prefab\}\}^\{\backslash text\{norm\}\}$. Of these, the present work delivers the structural component of controllability (F1) and the structural component of performance (F2) as derivable numbers; the remaining instantiations are framework-level and await runtime measurement.