Update nexus wiki content
This commit is contained in:
@@ -1,79 +1,59 @@
|
||||
---
|
||||
title: "Godot Gameplay Scripter Agent Personality"
|
||||
type: source
|
||||
tags: ["godot", "gdscript", "game-development", "agent-personality"]
|
||||
date: 2026-04-26
|
||||
tags: [game-development, godot, agent-personality, gdscript, gdscript-2.0, signal-architecture, type-safety, composition]
|
||||
date: 2026-05-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/agency-agents/game-development/godot/godot-gameplay-scripter.md]]
|
||||
- [[Agent/agency-agents/game-development/godot/godot-gameplay-scripter.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Godot 4 游戏逻辑脚本专家 Agent 人格定义，强调以软件架构师的纪律性构建游戏系统
|
||||
- 问题域：如何用 GDScript 2.0 和 C# 构建类型安全、信号驱动、可组合的游戏玩法系统
|
||||
- 方法/机制：严格静态类型 + 信号架构 + 组合优于继承 + 正确的 Autoload 使用模式 + GDScript/C# 互操作规范
|
||||
- 结论/价值：提供了一套完整的 Godot 4 游戏开发规范，包括命名约定、代码模式、工作流程和性能指标
|
||||
- 核心主题：Godot 4 游戏玩法脚本专家 AI Agent 人格规范，专注于用 GDScript 2.0 和 C# 构建类型安全、信号驱动的游戏系统
|
||||
- 问题域：游戏开发中如何避免 GDScript 动态类型的运行时错误、实现系统间松耦合通信、保持场景树可维护性
|
||||
- 方法/机制：静态类型强制 + 强类型信号架构 + 组合优于继承 + Autoload 事件总线
|
||||
- 结论/价值：提供一套完整的 Godot 4 游戏玩法系统开发规范，使代码在大型项目中仍可维护和测试
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- GodotGameplayScripter Agent 以软件架构师的纪律性和独立游戏开发者的务实精神构建游戏玩法系统
|
||||
- GDScript 信号必须使用 snake_case 且携带类型化参数，C# 信号使用 PascalCase + EventHandler 后缀
|
||||
- 所有变量、函数参数和返回值必须显式类型化，禁止在生产代码中使用无类型 var
|
||||
- 组合优于继承：通过子节点附加组件（如 HealthComponent）优于创建继承层级
|
||||
- Autoload 仅用于真正的跨场景全局状态，不得包含游戏逻辑
|
||||
- 场景必须可独立实例化，不得假设父节点类型或兄弟节点存在
|
||||
- GDScript 信号必须使用 `snake_case` 且携带类型化参数——携带 Variant 的未类型化信号是运行时错误的根源
|
||||
- GDScript 2.0 中每个变量、函数参数和返回值必须显式类型声明——生产代码中出现未类型化的 `var` 会导致难以追踪的 bug
|
||||
- 场景组合优于继承：向节点附加 `HealthComponent` 比 `CharacterWithHealth` 基类更灵活且更可测试
|
||||
- Autoload 仅用于真正的全局状态（设置/存档/事件总线）——将游戏逻辑放入 Autoload 会导致无法独立实例化和垃圾回收
|
||||
- 场景必须可独立运行（按 F6）——假设父节点上下文的场景在集成时会产生级联错误
|
||||
|
||||
## Key Quotes
|
||||
> "Everything is a node — behavior is composed by adding nodes, not by multiplying inheritance depth"
|
||||
> 核心哲学：一切皆为节点，行为通过添加节点组合，而非增加继承深度
|
||||
|
||||
> "Adding the type here catches this bug at parse time instead of 3 hours into playtesting"
|
||||
> 类型安全即功能：在解析时捕获 bug，而非在测试 3 小时后发现
|
||||
|
||||
> "Don't add this to Player — make a component, attach it, wire the signal"
|
||||
> 通信风格：组合优于捷径，永远不要把逻辑直接加到 Player 上，而是创建组件
|
||||
|
||||
> "GDScript signals use snake_case; if you're in C#, it's PascalCase with EventHandler"
|
||||
> 语言感知：在 GDScript 中信号用 snake_case；在 C# 中用 PascalCase 加 EventHandler 后缀
|
||||
> "Signals must carry typed parameters — never emit untyped Variant unless interfacing with legacy code." — 信号类型安全原则
|
||||
> "Prefer composition over inheritance: a HealthComponent node attached as a child is better than a CharacterWithHealth base class." — 节点组合哲学
|
||||
> "Autoloads are singletons — use them only for genuine cross-scene global state: settings, save data, event buses, input maps." — Autoload 使用规范
|
||||
> "Test every scene in isolation by running it directly (F6) — it must not crash without a parent context." — 场景隔离测试原则
|
||||
|
||||
## Key Concepts
|
||||
- [[Signal-Driven Architecture]]：信号驱动架构——通过信号解耦系统，避免直接方法调用，信号必须携带类型化参数
|
||||
- [[Static Typing in GDScript 2.0]]：GDScript 2.0 静态类型——所有变量、参数、返回值必须显式类型化，使用 typed arrays
|
||||
- [[Composition Over Inheritance]]：组合优于继承——通过附加子节点组件实现行为，而非创建继承层级
|
||||
- [[Event Bus Autoload]]：事件总线 Autoload——跨场景解耦通信的全局信号总线，只用于真正跨场景的事件
|
||||
- [[Type-Safe Signal Design]]：类型安全信号设计——信号命名遵循语言约定，参数必须类型化，连接时验证方法存在性
|
||||
- [[GDScript C# Interoperability]]：GDScript/C# 互操作——跨语言信号连接模式，类型转换和连接命名规范
|
||||
- [[GDScript-2.0]]：Godot 4 的脚本语言，支持静态类型声明、类型推断（`:=`）、强类型数组（`Array[Type]`）
|
||||
- [[TypedSignals]]：携带显式类型参数的信号（`signal health_changed(new_health: float)`），而非 Variant 类型
|
||||
- [[CompositionOverInheritance]]：通过组合节点（HealthComponent/MovementComponent）实现行为，而非继承层次
|
||||
- [[EventBus]]：Autoload 事件总线（EventBus.gd），用于跨场景解耦通信，避免直接节点引用
|
||||
- [[StaticTyping]]：GDScript 2.0 强制显式类型声明，消除运行时类型错误
|
||||
- [[GDExtension]]：使用 C++ 编写性能关键系统并暴露给 GDScript 的原生扩展机制
|
||||
- [[RenderingServer]]：Godot 低层渲染 API，用于绕过场景树开销实现高效 2D/3D 渲染
|
||||
- [[SceneTreeLifecycle]]：`_ready()` 初始化、`_exit_tree()` 清理、`queue_free()` 安全删除的节点生命周期管理规范
|
||||
|
||||
## Key Entities
|
||||
- [[GDScript 2.0]]：Godot 4 默认脚本语言，支持静态类型、装饰器、改进的信号系统
|
||||
- [[C# (Godot)]]：Godot 4 支持的 .NET 脚本语言，通过 GodotSharp bindings 与引擎交互
|
||||
- [[GDExtension]]：Godot 4 原生扩展机制，允许用 C++ 编写性能关键系统并暴露给 GDScript
|
||||
- [[HealthComponent]]：健康组件示例——展示类型化信号声明、@export 属性、伤害/治疗逻辑的标准模式
|
||||
- [[EventBus]]：事件总线 Autoload——全局跨场景信号发射器，用于解耦通信
|
||||
- [[GodotGameplayScripter]]：本 Agent 身份——Godot 4 游戏玩法脚本专家，强调类型安全、信号完整性和组合架构
|
||||
- [[GodotEngine]]：Godot 4 游戏引擎，支持 GDScript 2.0、C#、GDExtension 多语言生态
|
||||
- [[GDScript]]：Godot 官方脚本语言，GDScript 2.0 引入静态类型支持
|
||||
- [[CSharpGodot]]：Godot 的 C# 集成，使用 `[Signal]` 委托模式和 `EmitSignal(SignalName.X, ...)` 调用
|
||||
|
||||
## Connections
|
||||
- [[GDScript 2.0]] ← uses ← [[Static Typing in GDScript 2.0]]
|
||||
- [[GDScript 2.0]] ← uses ← [[Type-Safe Signal Design]]
|
||||
- [[C# (Godot)]] ← uses ← [[Type-Safe Signal Design]]
|
||||
- [[EventBus]] ← implements ← [[Signal-Driven Architecture]]
|
||||
- [[HealthComponent]] ← demonstrates ← [[Composition Over Inheritance]]
|
||||
- [[GDExtension]] ← extends ← [[C# (Godot)]]
|
||||
- [[GodotGameplayScripter]] ← builds_with ← [[GDScript-2.0]]
|
||||
- [[GodotGameplayScripter]] ← builds_with ← [[CSharpGodot]]
|
||||
- [[TypedSignals]] ← enables ← [[EventBus]]
|
||||
- [[CompositionOverInheritance]] ← enables ← [[TypedSignals]]
|
||||
- [[StaticTyping]] ← enforces ← [[GDScript-2.0]]
|
||||
- [[GodotGameplayScripter]] ← complements ← [[GodotShaderDeveloper]]
|
||||
- [[GodotGameplayScripter]] ← complements ← [[GodotMultiplayerEngineer]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
|
||||
## Technical Deliverables Summary
|
||||
|
||||
### 核心代码模式
|
||||
- **Typed Signal (GDScript)**：`signal health_changed(new_health: float)` + `died.emit()`
|
||||
- **Signal Bus Autoload**：`signal player_died` + `signal score_changed(new_score: int)`
|
||||
- **Typed Signal (C#)**：`[Signal] public delegate void HealthChangedEventHandler(float newHealth)`
|
||||
- **Composition Pattern**：`@onready var health: HealthComponent = $HealthComponent`
|
||||
- **Typed Array**：`var _active_enemies: Array[EnemyBase] = []`
|
||||
- **GDScript/C# Interop**：`health_component.HealthChanged.connect(_on_health_changed)`（PascalCase）
|
||||
|
||||
### 质量指标
|
||||
- 生产代码零无类型 var 声明
|
||||
- 所有信号参数显式类型化，无 Variant
|
||||
- 零运行时路径查找（所有 get_node 仅在 _ready 中通过 @onready）
|
||||
- 组件节点 < 200 行，每个处理一个游戏关注点
|
||||
- 所有场景可独立运行（F6 测试通过）
|
||||
- 与 [[UnrealSystemsEngineer]] 冲突：
|
||||
- 冲突点：游戏逻辑放置位置（Autoload vs Actor/C++ 类）
|
||||
- 当前观点：游戏逻辑不得放入 Autoload，应封装在可实例化的节点组件中
|
||||
- 对方观点：Unreal 中游戏逻辑倾向于放置在 Actor/Component 层次，Autoload 在 Godot 中仅作服务定位器使用
|
||||
|
||||
Reference in New Issue
Block a user