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

Zander Majercik1,2, Sharon Zhang1,2, William Wang1, Tejan Karmali1, Fangjun Zhou1, Yucheng Yuan1, Jean-Peic Chou1, Maneesh Agrawala1,2, Kayvon Fatahalian1,2
1Stanford University, 2Roblox
SIGGRAPH Asia 2026
Paper Supplement Video Code (coming soon)
A designer edits a 3D obstacle course while the system visualizes solution trajectories through it.

Our system shows designers how their obstacle can actually be played — as they edit it.

Starting regions are green, goal regions blue, and surfaces that damage the player red. Parts of an obstacle may move or rotate to create timing challenges. Here the player must traverse a series of platforms while dodging deadly obstacles, and push a yellow block up to a tall wall in order to jump over it. A solution trajectory found automatically by our system is drawn in green and white. Because this feedback arrives seconds after each edit, designers can iterate rapidly toward the experience they intend.

14,000×
faster than real-time
60 fps gameplay
800K+
aggregate game steps
per second on one GPU
seconds
to answer most
solvability queries
4
external designers
in our design study

Abstract

We present a system that aids the design of 3D obstacle course games by providing designers with rapid feedback on how obstacles can be solved. Our core contribution is a system for querying for solutions (sequences of player actions) to an obstacle that adhere to designer-specified constraints (e.g., avoid a region, travel through a given waypoint, only perform two jumps, etc.).

To solve a wide range of obstacle designs quickly, we author a high-performance implementation of the GoExplore algorithm for exploratory search, and guide search with an obstacle solving agent trained offline using reinforcement learning (RL). To further accelerate search, the system carries out exploration using a custom GPU-accelerated obstacle course game simulator that generates playthrough experience at nearly 14,000× real time, 60-fps gameplay.

Through design studies, we demonstrate that the use of constrained solvability queries in a rapid design loop is sufficiently expressive to help designers understand ways an obstacle can be solved or why it cannot be solved. We also show how the tool can let designers answer higher-level questions such as identifying undesirable solution paths and assessing the difficulty of solutions. This allows them to pursue new design directions they did not originally anticipate. Human playtesting of obstacles designed using our system confirms that human players indeed play the obstacles in the manner the designers intended.

Solvability Queries

Designers playtest to understand an obstacle's solvability: the set of movement sequences a player can or cannot use to solve it. Our system lets a designer ask for that directly. A query names a starting region and a goal region, together with constraints that limit the behavior a successful playthrough may exhibit.

The waypoint region is the clearest of those constraints: a 3D region that every successful playthrough must pass through. The designer places it with the same translate, rotate and scale handles they use to build the obstacle, and can chain several in sequence. They reach for it when they want to know whether the obstacle can be solved along one particular path — the route they had in mind while building it. Results stream back as 3D trajectories drawn directly on the obstacle, so the designer sees how an attempt succeeded, or why it failed.

A solution trajectory routed through a yellow waypoint region, from the green start to the blue goal.

A waypoint query. The designer constrains solutions to pass through the yellow waypoint region. Our system returns a playthrough that leaves the green start, drops through the waypoint underneath the sweeping red obstacle, and reaches the blue goal. The trajectory is drawn on the obstacle itself and can be replayed in sync with the motion of the level.

Designing With Solvability Feedback

Controlling the solution space

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.

Three-stage design study: an unintended jump-over solution is found, removed by raising the wall, and an alternate route is verified.

Design study. Solvability feedback helps the designer identify and remove an undesirable solution. (a) The initial design supports a solution that jumps over the wall instead of passing through its gap. (b) The designer raises the wall so it cannot be jumped over. (c) The designer verifies an alternate solution — jumping around the wall — for experienced players.

External designer study

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.

Five-stage sequence of an external designer's session, from unsolvable design to verified intended solution.

External Designer 1. Our system allowed this designer to (a) see why their design was unsolvable, (b) make an edit resulting in a solvable obstacle, (c) see an alternate solution they did not know was possible, (d) make an edit discouraging that solution, and (e) verify that their final design supported their intended solution.

Do humans play it the way the designer intended?

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.

Designer-intended trajectories on the top row, matching human playtester trajectories on the bottom row.

Human playtesting. Across three design studies, feedback from our system allowed a designer to create obstacle courses that supported their desired solutions (top row): a solution passing through the wall gaps and one jumping around the wall (left), a design with multiple solution paths (center), and a design where players time jumps between platforms to balance the difficulty of the preceding section (right). All of these solutions were reproduced by human playtesters (bottom row). On the rightmost obstacle, playtesters agreed the second section was much easier than the first — exactly as the designer intended based on trajectory feedback.

Query Performance

Mean time to first solution for five search methods across short, medium, and long queries.

Query performance. Mean time to solve (with inter-quartile range) for five methods across 56 solvability queries logged from our design studies, grouped into tertiles by Go-Explore's time to first solution. On long queries our policy-selection strategy (GE-PS) solves more queries than baseline Go-Explore (GE), a >15 s reduction in average solve time, at minimal overhead on short and medium queries. Both GE and GE-PS outperform Cell-Free Latent Go-Explore (CFLGE), Policy-Based Go-Explore (PBGE), and a pure RL policy rollout (RL). Queries exceeding the 90 s budget are terminated and counted as 90 s.

Obstacles Built With the System

BibTeX

@article{majercik2026solvability,
  author  = {Majercik, Zander and Zhang, Sharon and Wang, William and
             Karmali, Tejan and Zhou, Fangjun and Yuan, Yucheng and
             Chou, Jean-Peic and Agrawala, Maneesh and Fatahalian, Kayvon},
  title   = {Providing Rapid Design Feedback for 3D Obstacle Course Games
             Using Constrained Solvability Queries},
  year    = {2026},
}