gamedev@v2
Engine-flavored programming - gameplay mechanics, game-loop bug fixes, pathfinding and procedural generation built in a workspace and checked by compiling and running what the agent left behind, plus judge-scored design and optimization tasks.
Table stakes. Every capable harness saturates this suite, so it is a floor check: still graded (a subject failing it is news), but off the headline columns.
scoring
hybrid
repeats
1
judge
grok-cli-grok-4-5
Grade bands
| Grade | Capability ≥ |
|---|---|
| A | 0.9 |
| B | 0.75 |
| C | 0.55 |
| D | 0.35 |
| F | below D |
Sample task
Published in full, exactly as the models see it. All other tasks in the suite stay private.
You are working in an empty Go workspace: it holds a `go.mod` (module `gamedev`) and nothing else. Write a program that solves grid pathfinding for a tile-based game. Leave it in the workspace as `package main` in `main.go` at the workspace root. The program reads from standard input: - A first line with two integers `W H` (grid width and height), separated by a space. - Then `H` lines, each a string of exactly `W` characters. `.` is an open tile the player can stand on; `#` is a wall. The player starts at the top-left tile (column 0, row 0) and wants to reach the bottom-right tile (column `W-1`, row `H-1`). Movement is 4-directional (up, down, left, right) between open tiles only; diagonal moves are not allowed. It prints a single integer: the minimum number of moves on a shortest path from start to goal. It prints `-1` if the goal is unreachable, or if the start or goal tile is a wall. That integer is the whole output. You can compile and run it yourself: `go build ./...` builds the workspace, and `go run . < input` runs it against an input you write. When `main.go` builds and behaves as specified, you are done.