Autopilot for a Flappy Bird-Style Game Across Maps with Varying Pipe Gaps

Build an autopilot for a Flappy Bird-style game. The bird flies to the right at a constant speed while gravity pulls it down, and a flap gives it a fixed upward velocity. Pipes hang from the top of the screen and rise from the bottom in pairs, leaving a gap the bird must fly through. Touching a pipe or the ground ends the run. Instead of a player tapping, your code decides on every step whether the bird flaps. The autopilot is graded on several maps it has not seen. The maps differ in the lengths of their pipes, so the gaps sit at different heights, from one pipe to the next and from one map to another. One controller has to clear all of them; flap timings or thresholds tuned to a single map do not count. The assessment allowed 60 minutes, and it was not a standard algorithms or data-structures problem. The assessment's interface was not reported. Assume the following, and adjust it as you clarify: ```python from dataclasses import dataclass @dataclass class Pipe: x_left: float # left edge of the pipe pair x_right: float # right edge of the pipe pair gap_bottom: float # top of the lower pipe gap_top: float # bottom of the upper pipe @dataclass class GameState: x: float # bird's horizontal position (its center) y: float # bird's height above the ground (its center); y grows upward vy: float # vertical velocity per step; positive means rising pipes: list[Pipe] # the pipes the autopilot can see, sorted by x_left def should_flap(state: GameState) -> bool: """Called once per step. Return True to flap on this step.""" ``` ```hint Your code knows the rules The game is deterministic. Before choosing between flapping and not flapping, consider what each choice leads to over the coming steps, not only on the next one. ``` ```hint Test the hard transitions Picture a high gap followed closely by a low one, or a gap barely taller than the bird. Check what your controller does there before trusting it on a gentle map. ``` ### Constraints and Clarifications - Assumed physics, one step at a time: if the bird flaps, its vertical velocity becomes a fixed flap velocity; otherwise it decreases by a constant `g`. Then the height changes by the new velocity, and the bird moves right by a constant `dx`. - Assume gravity, the flap velocity, the horizontal speed, the bird's size and the screen height are the same on every map and known to your code; only the pipes change. - Treat the bird as a box of half-size `r` around its center. It crashes when the box touches the ground or overlaps a pipe outside the gap. - Not reported: the real interface, whether the whole map is visible in advance, whether the gaps also differ in size, whether the top of the screen is lethal, how a map is scored, and any per-step time limit. Ask, or state your assumptions. ### Clarifying Questions - Does the autopilot see every pipe of the map in advance, or only the ones on screen? - Does a flap set the vertical velocity to a fixed value, or add to the current one? - Is reaching the top of the screen a crash, or does the bird just stop there? - Is a map pass/fail, or is the score the distance traveled? - Is there a time limit per call to `should_flap`? - Are the physics constants available to the code, or must they be inferred from the bird's observed motion? ### What a Strong Answer Covers - Pins down the interface, the physics, what the autopilot can see and how maps are scored before coding - A controller that judges each action by the game's own rules of motion, with no flap timings or thresholds fitted to one map - Correct collision handling at pipe edges, the ground and the top of the screen, including movement between steps - Bounded per-step cost, with the trade-off between how far ahead it looks and how long a decision takes - Behavior when no safe move exists, and a testing plan over varied maps: narrow gaps, large height changes between consecutive pipes, pipes close together ### Follow-up Questions - Your model of the physics differs slightly from the game's (update order, rounding). How does the controller cope, and how would you notice? - The constants are hidden, and the game reports only the bird's position each step. How would you estimate gravity and flap strength? - Some maps cannot be finished. How should the autopilot behave on them? - Would a learned controller, such as one trained with reinforcement learning, be a better choice here? When would it be?