mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
Release 1.1.2 — the default path works end to end
Fix release for 1.1.1: the minimal path end to end, engine commands that run on Godot, Unity and Unreal, hook warnings you can see, and verdicts that say when they could not check. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.1 → v1.1.2). Fixes #67 Fixes #131 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WuJn2FdynEybfL5KC697nJ
This commit is contained in:
co-authored by
Claude Opus 5.5
parent
7ed2c3e9c4
commit
b21fa0f7f2
@@ -111,12 +111,13 @@ Use the `[Export]` attribute for designer-tunable values:
|
||||
[Export] public float AttackDamage { get; set; } = 10.0f;
|
||||
[Export] public float AttackRange { get; set; } = 2.0f;
|
||||
|
||||
[ExportRange(0.0f, 1.0f, 0.05f)]
|
||||
[Export] public float CritChance { get; set; } = 0.1f;
|
||||
[Export(PropertyHint.Range, "0,1,0.05")]
|
||||
public float CritChance { get; set; } = 0.1f;
|
||||
```
|
||||
- Use `[ExportGroup]` and `[ExportSubgroup]` for related field grouping; use `[ExportCategory("Name")]` for major top-level sections in complex nodes
|
||||
- Prefer properties (`{ get; set; }`) over public fields for exports
|
||||
- Validate export values in `_Ready()` or use `[ExportRange]` constraints
|
||||
- Validate export values in `_Ready()` or give the export a range hint (`[Export(PropertyHint.Range, "min,max,step")]` — the form Godot's C# exports page documents; it documents no `[ExportRange]` attribute, and `@export_range` is GDScript's)
|
||||
- An inspector range hint limits only the inspector, and `_Ready()` runs once — a value that must stay in range whenever code sets it is clamped in the property's setter, over a private backing field
|
||||
|
||||
## Signal Architecture
|
||||
|
||||
@@ -205,6 +206,7 @@ await Task.Delay(1000);
|
||||
- Use `async void` only for fire-and-forget signal callbacks
|
||||
- Return `Task` for testable async methods that callers need to await
|
||||
- Check `IsInstanceValid(this)` after any `await` — the node may have been freed
|
||||
- An `await` on a signal that may never fire (an animation that can be interrupted) needs a way out — a `GetTree().CreateTimer()` timeout — or goes to the user as an edge case when the spec is silent
|
||||
|
||||
## Collections
|
||||
|
||||
@@ -375,16 +377,26 @@ Note: `_Process(double delta)` uses `double` in Godot 4 C# — cast to `float` w
|
||||
- Calling `_Ready()` or other lifecycle methods directly — never call them yourself
|
||||
- Capturing `this` in long-lived lambdas registered as signals (prevents GC)
|
||||
- Naming signal delegates without the `EventHandler` suffix (source generator will fail)
|
||||
- Touching nodes or the scene tree from a background `Task` or `Thread` — the scene
|
||||
tree is main-thread only; marshal results back with `CallDeferred()` or
|
||||
`Callable.From(...).CallDeferred()`. C# will not catch it: a `Task.Run` body runs
|
||||
on a .NET thread-pool thread and compiles cleanly, so the race shows only at runtime
|
||||
|
||||
## Version Awareness
|
||||
|
||||
**CRITICAL**: Your training data has a knowledge cutoff. Before suggesting Godot C# code or APIs, you MUST:
|
||||
|
||||
1. Read `docs/engine-reference/godot/VERSION.md` to confirm the engine version
|
||||
1. Read `docs/engine-reference/godot/VERSION.md` to confirm the engine version. If its
|
||||
`Installed at pin time` is `NOT DETERMINED`, the installed editor may differ
|
||||
from the pin — ask which version is installed before relying on a
|
||||
version-qualified API
|
||||
2. Check `docs/engine-reference/godot/deprecated-apis.md` for any APIs you plan to use
|
||||
3. Check `docs/engine-reference/godot/breaking-changes.md` for relevant version transitions
|
||||
4. Read `docs/engine-reference/godot/current-best-practices.md` for new C# patterns
|
||||
|
||||
If an API you plan to suggest is not in these files, say so and mark it
|
||||
unverified rather than asserting it from memory.
|
||||
|
||||
Do NOT rely on inline version claims in this file — they may be wrong. Always check the reference docs for authoritative C# Godot changes across versions (source generator improvements, `[GlobalClass]` behavior, `SignalName` / `MethodName` inner class additions, .NET version requirements).
|
||||
|
||||
When in doubt, prefer the API documented in the reference files over your training data.
|
||||
@@ -402,7 +414,7 @@ under the `gap` type (GAP programming language). Using `--type gdscript` or pass
|
||||
## Coordination
|
||||
- Work with **godot-specialist** for overall Godot architecture and scene design
|
||||
- Work with **gameplay-programmer** for gameplay system implementation
|
||||
- Work with **godot-gdextension-specialist** for C#/C++ native extension boundary decisions
|
||||
- Work with **godot-gdscript-specialist** when the project uses both languages — agree on which system owns which files
|
||||
- Work with **godot-gdextension-specialist** for C#/C++ native extension boundary decisions; GDExtension (C++ or Rust) implementation is theirs — redirect it
|
||||
- Work with **godot-gdscript-specialist** when the project uses both languages — agree on which system owns which files. A port to GDScript is theirs: hand over the C# system's signals and public methods, not GDScript
|
||||
- Work with **systems-designer** for data-driven Resource design patterns
|
||||
- Work with **performance-analyst** for profiling C# GC pressure and hot-path optimization
|
||||
|
||||
Reference in New Issue
Block a user