Providing Rapid Design Feedback for 3D Obstacle Course Games Using Constrained Solvability Queries

Designers playtest to understand an obstacle's solvability: the set of movement sequences a player can or cannot use to solve it, and the character of those sequences — their difficulty, their strategies, their diversity. Our system lets a designer ask for this directly. A query specifies a starting region and a goal region, plus a set of constraints that limit the behavior a successful playthrough may exhibit:

• Waypoint regions. Regions a successful playthrough must pass through — used when a designer is looking for solutions that take a particular path through the obstacle.
• Avoid regions. Regions a successful playthrough cannot pass through — used to understand how an obstacle can be solved while avoiding a particular path.
• Jump count. A cap on the number of jumps a playthrough may perform — used to ask higher-level questions about play, such as which jumps along a solution path are actually required.
• Time limit. A cap on the number of game time steps to reach the goal — used to view more efficient playthroughs.

Spatial constraints are 3D regions the designer places with standard translate/rotate/scale handles. Multiple waypoints can be chained in sequence, each with its own jump budget. After a query is submitted the system streams partial results back for immediate visualization, plotting both failed and successful attempts as 3D trajectories in the scene — so the designer can see how an attempt succeeded, or why it failed.

To be useful inside a design loop, the query engine has to return playthroughs in seconds and work on the diverse, complex obstacles designers actually build. Two components make that possible.

Policy-guided exploratory search

We first tried training a general obstacle-solving agent on a large collection of procedurally generated obstacles, but the resulting policy often failed on novel human-authored obstacles — human creativity reliably produces out-of-distribution content. Fine-tuning per query was also impractical within a latency budget of tens of seconds. So we build the engine on Go-Explore, a stochastic exploratory search that repeatedly restores a previously visited simulator state (go) and rolls out from it (explore).

We extend it in two ways. Query-dependent binning discretizes state by player XYZ position, elapsed time, jumps taken, and interactable object positions — allocating the highest resolution to the X and Y axes, since obstacle courses demand precise lateral movement, and spending bins on the time, jump, and object dimensions only when the query involves moving objects, limited jumps, or interactables. Bins closer to the goal, or that have satisfied a waypoint, are upweighted during selection.

Go-Explore with Policy Selection (GE-PS) changes how we explore. The first time a bin is selected after being discovered or updated, we roll out our pretrained RL policy for the whole exploration step; every subsequent selection of that bin falls back to default random exploration. This exploits the policy's skills wherever the search meets structures resembling common obstacle course idioms, and degrades gracefully to brute-force random search wherever the policy fails to make progress.

A digital twin running at 800K steps/second

The designer works in a standard game engine editor (Roblox Studio), but playthroughs execute in a separate GPU-accelerated simulator that runs an approximation of the game at over 800K aggregate game steps per second — nearly 14,000× real-time 60 fps gameplay. Query constraints are compiled into the simulation itself: waypoints become blocks that activate the next stage of the chain, avoid regions become damage blocks, and jump and time limits become counters that filter the action space when exhausted.

The designer intends for the player to ride a thin platform, repositioning to fit through gaps in a series of walls. A first query confirms the intended solution exists — but also surfaces a second one: the first barrier can simply be jumped over. That runs counter to intent, so the designer raises the wall and queries again; no solution comes back, so the edit worked. Finally they use avoid and waypoint regions to ask whether the wall can be jumped around. It can — but that route is counterintuitive to a new player and mechanically demanding, so the designer keeps it.

We recruited four external designers — a professional game developer with games research experience, a professional developer with 19 years of design experience, an enthusiast designer specializing in experimental games, and a professional independent developer working on 2D platformers. They used the system to verify desired solutions, discover and prohibit undesired ones, inspire level edits, and acclimate to an unfamiliar 3D creation platform. Two noted that rapid, in-progress trajectory visualizations were crucial to their process.

Designer 1 set out to build a "pixel-perfect platformer." The system showed their initial design was unsolvable because the goal platform sat too high; after an edit made it solvable, a later query revealed an unintended route that skipped their lava ring obstacle entirely. Shrinking the goal and enlarging the ring discouraged it, and a waypoint constraint on the top platform confirmed the intended gameplay end to end. They valued being able to evaluate play on obstacles harder than they could comfortably playtest themselves — and to "press a button and rapidly confirm that a design was still solvable" after each edit.

Six college-age playtesters attempted obstacles built with the system. Each first tried to solve the obstacle; on success they were asked to find a harder solution if one existed. Across three design studies, human players solved the obstacles along the paths the designers intended — so designers can trust that the feedback reflects real human play.

Constrained solvability queries let designers immediately observe how their design decisions shape play. In our studies designers used that feedback to edit the obstacle toward their goals — but knowing the full space of potential solution strategies, or the likely failure modes, could also drive player assistance systems, or breadcrumbs that lead players toward a particular solution.

Because players traverse obstacles segment by segment, complex obstacle course games are usually composed of largely independent obstacle designs. Once the segments exist, the designer faces global questions: obstacle sequencing and difficulty progression, and the visual communication of function — making dangerous things look dangerous, shaping an obstacle so it suggests its own solution. A tool that accelerated that process, especially by automatically evaluating the solution an obstacle suggests to a player on first sight, would be fascinating.

With AI-generated content becoming ubiquitous, we expect an acute need for tools that help designers turn abundant 3D content into compelling experiences. We hope this work encourages more efforts to help creators understand and evaluate how their design decisions affect gameplay.