個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證製作者的介紹僅有上面的一句話。 更多詳情請閱讀儲存庫 README。 儲存庫 README ↗
正在載入完整 README。
檢視完整 README ↗A cozy survival game on a dead desert moon. Working title.
Docs first: docs/vision.md says what the game is, each system has a PRD
in docs/prd/, and docs/README.md maps the full documentation set.
docs/skeleton-plan.md records the original build order.
Sand Game, the prototype this replaces, lives on the
archive branch.
.godot-version. Open the project in the editor and run
it. The dev overlay shows every number the game publishes; the game lists its keys,
which are defaults set in game/core/controls.gd.game/tuning.tres. Change numbers there, never in code.probes/. Run them with
scripts/probe.sh; it needs a godot binary on your PATH, or set GODOT.
scripts/probe.sh selftest proves the runner itself can fail. It runs in bash 3.2 and
up, so in macOS's own and in Git Bash on Windows too. CI runs both on every push, on
Linux; master and tags also run the native macOS and Windows checks.Probe, put the body in run(), and call check(). Probes
run on a fixed seed and never find nodes by name.Work in a sibling worktree. Copy scripts/verify.sh outside the checkout, then run
that copy from the worktree with <name>, or <name> --land after merging current
origin/master. It pushes verify-<name>, waits for that commit's run and prints what
failed; failures block landing. Docs-only changes skip CI, and dashboard-only changes
run only the dashboard's checks. Branch pushes run the Linux groups; master and tags
also run native macOS/Windows probes and build smoke checks (.github/workflows/probes.yml
owns the groups). While master's latest macOS/Windows run is red, --land names the
failing probe and lands no game change but its fix (FIXES_PLATFORMS=1).
scripts/probe.sh's header describes its scheduling markers.
Versions follow the version policy; milestones and their gates are in the Alpha roadmap.
The version lives in one place, application/config/version in project.godot, and
shows in the main menu's corner alongside application/config/release_name.
The release name also appears in the GitHub release title. scripts/export.sh exports the Linux, Windows and
macOS builds (export_presets.cfg) and zips each as desert-<version>-<os>.zip; it
needs the pinned export templates installed. CI runs it on every push, then launches
each build on its own OS for a smoke test (scripts/probe.sh smoke <game>).
gh workflow run release.yml --ref <branch>. The zips are the run's
artifacts; nothing is published.project.godot, give it a ## <version>
section in RELEASE_NOTES.md, merge to master, then tag that commit v<version> and push the tag. The Release
workflow builds and smoke-tests it again and publishes a GitHub pre-release with the
zips and that version's notes (plus How to start and Known issues) only after that tag's full Probes run succeeds. A failed,
cancelled or missing probe run blocks publication. A tag that doesn't match
the version publishes nothing.game/ the game, one folder per system
probes/ headless probes, one folder per PRD (lib/ is the framework)
look/ look-tests, judged by eye
assets/ only what's in use, copied from the archive branch
docs/ vision and PRDs, with world references and supporting briefs grouped by topic
launcher/ the standalone desktop app for published releases and local source worktrees
The separate desktop launcher installs and runs published game releases or opens a
checked-out source worktree in Godot. See launcher/README.md and
the launcher PRD. Its cross-platform builds publish from
launcher-v* tags independently of the game version.
The GitHub Pages dashboard refreshes after completed master Probes and Release workflows, including failures. It shows probe/retry costs, job and build steps, artifact sizes and opt-in game measurements. It consumes existing evidence; it never reruns the suite or gates a game release. Real-frame metrics are Linux-only and headless, so they do not measure GPU cost.
Refresh manually with gh workflow run performance-pages.yml. The site requires
GitHub Pages configured to use GitHub Actions. It keeps a bounded run history and
backfills recent runs if its cache is lost. Source and
checks live in site/ and scripts/ci_dashboard/; requirements and measured results
live in Probes and builds.