mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 09:58:36 +00:00
DonchitosandClaude Opus 5.5
be8993bbc5
Fix release for 1.1.2: the 14 longest skills keep their later phases after a compaction, a question nobody answered is never taken as an answer, settings read the same from a subfolder, the commit check works for a project in a subfolder of a larger repository, every skill opens with a title, and the shipped allow rules no longer approve deleting a branch or writing files without asking. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.2 → v1.1.3). Refs #83 Refs #133 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185en4t76fPn7315q4c3nko
87 lines
3.8 KiB
Markdown
87 lines
3.8 KiB
Markdown
# /setup-engine — Section 7.5: Scaffold the Engine Project
|
|
|
|
> Part of `/setup-engine`. `SKILL.md` names when to read this file; the settings it
|
|
> resolved and the rules under its later headings still apply here.
|
|
|
|
## 7.5 Scaffold the Engine Project
|
|
|
|
**Without this step the framework produces source files no engine can open.**
|
|
`/dev-story` writes `.gd`/`.cs`/`.cpp` under the resolved code root, and the `minimal` path
|
|
advertises "four steps to running code" — but nothing anywhere created a project
|
|
for the engine to load. Verified by grep across every skill: no `project.godot`,
|
|
no Unity project, no `.uproject` was ever written. The files were real and
|
|
orphaned.
|
|
|
|
### Godot — write `project.godot` if one is absent
|
|
|
|
**Never overwrite an existing `project.godot`.** If the file is already there,
|
|
say so and skip to Section 8 — the developer has a project and its settings are
|
|
theirs.
|
|
|
|
Show the proposed file, then ask: *"May I create `project.godot` at the repo
|
|
root?"* On approval, write:
|
|
|
|
```ini
|
|
config_version=5
|
|
|
|
[application]
|
|
|
|
config/name="<project name>"
|
|
config/features=PackedStringArray("<major.minor>", "<renderer feature>")
|
|
|
|
[rendering]
|
|
|
|
renderer/rendering_method="<rendering method>"
|
|
```
|
|
|
|
Fill it from decisions already made — do not ask again:
|
|
|
|
| Field | Source |
|
|
|-------|--------|
|
|
| `config/name` | the brief's working title, else the repo directory name |
|
|
| `<major.minor>` | `engine.version` from Section 3, major and minor only (`4.7.2` → `4.7`) |
|
|
| `<renderer feature>` / `<rendering method>` | the `rendering` value chosen in Section 5.5.1 — Compatibility → `"GL Compatibility"` / `gl_compatibility`; Forward+ → `"Forward Plus"` / `forward_plus`; Mobile → `"Mobile"` / `mobile` |
|
|
|
|
**Leave `run/main_scene` unset.** There is no scene yet at engine-setup time.
|
|
Add a comment saying `/dev-story` or the developer sets it once a scene exists;
|
|
an empty project with no main scene opens fine in the editor.
|
|
|
|
**Then verify, and report what the verification actually was.** If the engine
|
|
binary was found in Section 3, run its headless import
|
|
(`godot --headless --path . --import`) and report the result — read the output
|
|
for `ERROR`, because the import exits 0 even when something in the project
|
|
fails to load. If the binary was
|
|
not found, or its version differs from the pinned one, write
|
|
**`project.godot NOT VERIFIED — <reason>`**. The `config_version` and feature
|
|
strings are stable across Godot 4.x, but "stable in the versions I know" is not
|
|
the same as "checked against the version you pinned", and only the run
|
|
establishes the latter.
|
|
|
|
### Unity and Unreal — instruct, do not fabricate
|
|
|
|
A Unity project and an `.uproject` are editor-generated and span many files,
|
|
several of them binary or machine-specific. This repo cannot source their
|
|
correct contents, and a hand-written scaffold would be the exact failure
|
|
Section 7's sourcing rule forbids — something that looks finished and is quietly
|
|
wrong.
|
|
|
|
Tell the user, in one short block, that CCGS does not create the project for
|
|
these engines and they should create it first:
|
|
|
|
- **Unity** — create the project in Unity Hub at the repo root, choosing the
|
|
template matching the 2D/3D answer from Section 2, then re-run `/setup-engine`.
|
|
- **Unreal** — create the project in the Epic launcher or via `UnrealEditor`,
|
|
then re-run.
|
|
|
|
Report the outcome in the Section 12 summary either way — created, already
|
|
present, or "not created, engine requires the editor" — so the user leaves this
|
|
skill knowing whether a runnable project exists.
|
|
|
|
> **Deliberately not a `project.yaml` key.** An `engine.project_scaffolded` flag
|
|
> would be written here and read by nothing, which is a dead setting — the same
|
|
> writer-without-reader defect the config gates exist to catch. The filesystem is
|
|
> the source of truth: any skill that needs to know globs for `project.godot`,
|
|
> `*.uproject`, or `ProjectSettings/ProjectVersion.txt`.
|
|
|
|
---
|