c451a50349
Claude Code running inside the project's dev container can now build the game, launch a real Godot instance under Xvfb, and drive the automation harness end-to-end — no Windows dependency. Dockerfile adds (as root, before USER node): - X11 / Mesa software GL / audio runtime deps + python3 - .NET SDK 9.0 via upstream dot.net install script -> /usr/local/dotnet - Godot 4.6.2-stable mono Linux x86_64 -> /opt/godot/godot - /usr/local/bin/godot-xvfb wrapper: auto-wraps invocations in xvfb-run -a --server-args="-screen 0 1280x720x24 ..." harness.py picks GODOT_BIN from env, defaults to /opt/godot/godot on Linux, and auto-wraps the subprocess in xvfb-run when DISPLAY is unset. Windows code path unchanged. init-firewall.sh adds api.nuget.org to the allowlist so dotnet restore works post-boot. Godot + .NET SDK are fetched at image build time, before the firewall exists. New docs: - autonomous_plan.md: design rationale, alternatives considered - README.md: launch instructions for Windows terminal / Docker Desktop / VS Code Dev Containers / WSL2 natif - CLAUDE.md already documents the harness (done in previous commit) Validation: docker build succeeds; inside the container, dotnet --version =9.0.313, godot --version=4.6.2.stable.mono, dotnet test=102/102, python3 tools/automation/smoke.py passes end-to-end with 14 non-black 1280x720 PNGs. Mission 1 screenshot is visually identical to the Windows build, and Xvfb determinism is a bonus (det_a.png ≡ det_b.png bytewise).
15 lines
458 B
Bash
15 lines
458 B
Bash
#!/bin/bash
|
|
# Wrap a Godot invocation in a fresh Xvfb 1280x720x24 display so the GL
|
|
# renderer has something to draw into. If DISPLAY is already set (real
|
|
# display / nested X server), skip xvfb-run and exec Godot directly.
|
|
set -euo pipefail
|
|
|
|
: "${GODOT_BIN:=/opt/godot/godot}"
|
|
|
|
if [[ -n "${DISPLAY:-}" ]]; then
|
|
exec "$GODOT_BIN" "$@"
|
|
fi
|
|
|
|
exec xvfb-run -a \
|
|
--server-args="-screen 0 1280x720x24 -ac +extension GLX +render -noreset" \
|
|
"$GODOT_BIN" "$@"
|