今年 AI 发展的太迅猛了,很多计算机辅助的工作都能比较好的完成了。好久没古法文章了,水一篇。主要聊聊如何通过 AI 去了解一些计算机相关的产品制作管线,比如:游戏开发、3D 建模等。

感觉现在只要是“仅”通过计算机操作制作的“工艺”,都能很快的通过 AI 辅助去学习了解了。这里我们以游戏制作开发为例:

我们可以挑选任意自己感兴趣的方向去上手制作流程,比如我“曾”经常玩耍的 SRPG 系列游戏:《火焰纹章:封印之剑》,我基于以下的 prompt 让 AI 引导我完成一个关卡的制作流程:

整个 prompt 的设计上,我们应该尽可能的让 AI 帮我们做一些细节上的东西,自己把控下宏观流程,合理设置一些真实可以用的 playground,可视化出来,让整个过程不枯糙:

这里的关键不是让 AI 一次性糊出一个“完整游戏”,而是把学习过程拆成可以验证的小阶段:先让它说明当前阶段目标、涉及概念和会改哪些文件,再要求每个阶段都产出可运行的 playground 和对应文档。这样我们就可以在真实工具里一点点跑起来、看效果、修认知,而不是只停留在概念解释上。

引导式学习 promopt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
你是我的 Godot 游戏开发导师、Claude Code 编程代理、项目文档维护者。

我想用 Godot 4.x 制作一个类似《火焰纹章:封印之剑》风格的 2D 回合制 SRPG 单关 vertical slice。
这个项目的核心目的不是做完整商业游戏,而是通过一个可玩的单关原型,帮我熟悉完整游戏开发管线,以及常见游戏开发概念。

请你同时完成三件事:

1. 写代码,实现一个可玩的 Godot SRPG 单关。
2. 像导师一样解释每个阶段涉及的游戏开发概念。
3. 每个阶段结束后,写一份 Markdown 学习文档,总结这一阶段学到了什么、实现了什么、如何测试、常见坑是什么。

---

# 一、项目总体目标

使用 Godot 4.x 制作一个 2D 网格战棋 SRPG 单关。

最小可玩目标:

* 只做一关。
* 地图大约 16x12 或 20x15。
* 我方 3 个单位。
* 敌方 4 个单位。
* 支持玩家回合和敌方回合。
* 支持移动、攻击、等待。
* 支持单位死亡。
* 支持胜利和失败。
* 胜利条件:击败 Boss 或全灭敌人。
* 失败条件:主角死亡。
* 最后可以导出 Web 或桌面版本。

不要追求美术精致,优先使用占位素材、纯色方块、简单像素图或程序生成的 placeholder。

不要使用任何受版权保护的火焰纹章原版素材。

---

# 二、学习目标

这个项目要刻意覆盖这些游戏开发常见概念,并在对应阶段解释它们:

## 地图与关卡

* TileMap
* TileSet
* TileMapLayer
* 地形数据
* 地图坐标 grid position
* 世界坐标 world position
* local_to_map
* map_to_local

## 碰撞与检测

* 物理碰撞
* 逻辑碰撞
* CharacterBody2D
* StaticBody2D
* Area2D
* CollisionShape2D
* collision layer
* collision mask
* 战棋游戏里的不可通行格子
* 单位阻挡
* 攻击范围检测

## 2D 图像与动画

* Sprite 精灵图
* Sprite Sheet 精灵表
* AnimatedSprite2D
* SpriteFrames
* idle / walk / attack / hurt / death 动画
* 像素图导入设置
* Nearest filter
* AnimationPlayer

## 骨骼动画

* Skeleton2D
* Bone2D
* 骨骼动画和精灵表动画的区别
* Boss cut-in 演出
* 立绘呼吸动画或挥刀动画

## 玩法系统

* 状态机 State Machine
* 回合制 Turn Manager
* BFS 移动范围
* AStarGrid2D 路径寻路
* 战斗计算
* 敌人 AI
* 胜负条件
* 游戏流程闭环

## UI / Audio / Export

* CanvasLayer
* 行动菜单
* 角色面板
* 战斗预览
* 血条
* 音效反馈
* 背景音乐
* 导出发布
* README
* 项目文档

---

# 三、项目结构

请创建并维护类似下面的结构:

res://
playgrounds/
tilemap/
TileMapPlayground.tscn
TileMapPlayground.gd
collision/
CollisionPlayground.tscn
CollisionPlayground.gd
spritesheet/
SpriteSheetPlayground.tscn
SpriteSheetPlayground.gd
skeleton/
SkeletonPlayground.tscn
SkeletonPlayground.gd

game/
scenes/
Main.tscn
Chapter01.tscn
Unit.tscn
Cursor.tscn
UI/
CommandMenu.tscn
UnitInfoPanel.tscn
BattlePreview.tscn
ResultPanel.tscn

scripts/
core/
GameState.gd
TurnManager.gd
Grid.gd
map/
BattleMap.gd
Terrain.gd
MapData.gd
unit/
Unit.gd
UnitStats.gd
combat/
CombatResolver.gd
DamageFormula.gd
ai/
EnemyAI.gd
ui/
CommandMenu.gd
RangeOverlay.gd
UnitInfoPanel.gd
BattlePreview.gd

data/
chapter01.json
units.json
weapons.json
terrain.json

assets/
tiles/
units/
portraits/
boss_parts/
ui/
sfx/
music/

docs/
00_project_overview.md
01_tilemap_playground.md
02_collision_playground.md
03_spritesheet_playground.md
04_skeleton_playground.md
05_chapter01_map_and_cursor.md
06_unit_system.md
07_movement_and_pathfinding.md
08_action_menu_and_combat.md
09_turn_system.md
10_enemy_ai.md
11_win_lose_audio_cutscene.md
12_export_and_wrapup.md
glossary.md
devlog.md
troubleshooting.md

---

# 四、重要开发方式

请严格分阶段推进。

不要一次性生成完整项目。

每个阶段开始前,先输出:

1. 当前阶段名称。
2. 本阶段目标。
3. 本阶段涉及的游戏开发概念。
4. 本阶段将创建或修改的文件。
5. 本阶段完成后应该能看到什么效果。

然后再实现代码。

每个阶段结束后必须停下来,不要自动进入下一阶段。
等待我在 Godot 中运行验证后,再继续下一阶段。

---

# 五、每阶段文档要求

每个阶段结束后,必须在 docs/ 下写一篇 Markdown 文档。

每篇阶段文档必须包含这些部分:

```markdown
# 阶段标题

## 1. 本阶段目标

说明这一阶段要解决什么问题。

## 2. 最终效果

说明运行后应该看到什么。

## 3. 涉及的游戏开发概念

用初学者能理解的方式解释概念。

## 4. 本阶段创建或修改的文件

列出文件路径,并说明每个文件负责什么。

## 5. 核心实现思路

解释实现方案,不要只贴代码。

## 6. 关键代码说明

摘录关键函数或关键逻辑,并解释它们。

## 7. 如何运行和测试

给出 Godot 编辑器里的测试步骤。

## 8. 常见问题和坑

列出本阶段可能遇到的问题,比如坐标错位、碰撞层没设置、像素图发糊、动画不播放等。

## 9. 这一阶段对应真实游戏开发管线的哪一环

例如:关卡编辑、角色导入、动画制作、玩法原型、UI 接入、AI 调试、打包发布等。

## 10. 下一阶段要做什么

说明下一阶段目标。

---

# 六、额外文档要求

除了每阶段文档,还需要维护以下长期文档:

## docs/00_project_overview.md

记录:

* 项目目标
* 最小可玩范围
* 当前完成进度
* 如何运行项目
* 项目结构说明
* 当前已实现功能
* 后续计划

## docs/glossary.md

维护游戏开发术语表。
每次遇到新概念,都追加到这里。

格式:

`markdown
## TileMap

一句话解释:

在本项目中的作用:

Godot 中相关节点或 API:
`

需要记录的术语至少包括:

* TileMap
* TileSet
* TileMapLayer
* Sprite
* Sprite Sheet
* AnimatedSprite2D
* AnimationPlayer
* Skeleton2D
* Bone2D
* Collision
* CharacterBody2D
* StaticBody2D
* Area2D
* CollisionShape2D
* State Machine
* Turn Manager
* BFS
* AStarGrid2D
* UI
* CanvasLayer
* AudioStreamPlayer
* Export

## docs/devlog.md

每阶段结束后追加开发日志。

格式:

`

# Devlog

## 阶段 N:标题

日期:
完成内容:
遇到的问题:
解决方式:
下一步:

## docs/troubleshooting.md

记录开发中遇到的问题和解决方法。

格式:

`
## 问题标题

现象:

原因:

解决方法:

相关文件:
`

---

# 七、阶段计划

请按下面阶段实现。

---

## 阶段 0:项目检查与初始化

目标:

* 检查当前目录是否已有 Godot 项目。
* 如果没有,创建推荐项目结构。
* 创建 docs 目录。
* 创建 00_project_overview.md、glossary.md、devlog.md、troubleshooting.md。
* 确认 Godot 版本。
* 确认项目入口场景。

要解释:

* Godot 项目结构。
* res:// 的含义。
* 场景和脚本的关系。
* 为什么要先建文档。

阶段结束文档:

* docs/00_project_overview.md
* docs/devlog.md
* docs/glossary.md

完成后停下来。

---

## 阶段 1:TileMap Playground

目标:

* 创建 TileMapPlayground。
* 使用 TileMapLayer 创建一张小地图。
* 支持鼠标悬停格子。
* 显示当前格子坐标和地形类型。
* 尝试使用 tile custom data 或代码映射地形数据。

要解释:

* TileMap
* TileSet
* TileMapLayer
* grid 坐标
* world 坐标
* local_to_map
* map_to_local
* 地形数据

阶段结束文档:

* docs/01_tilemap_playground.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 如遇问题,更新 docs/troubleshooting.md

完成后停下来。

---

## 阶段 2:Collision Playground

目标:

* 创建一个 CharacterBody2D 小人。
* 创建 StaticBody2D 墙壁。
* 小人不能穿墙。
* 创建 Area2D 陷阱区域。
* 进入陷阱后显示提示或打印日志。
* 演示 collision layer 和 collision mask 的基本作用。

要解释:

* 物理碰撞
* 逻辑碰撞
* CharacterBody2D
* StaticBody2D
* Area2D
* CollisionShape2D
* collision layer
* collision mask
* 为什么 SRPG 主玩法大多用逻辑碰撞

阶段结束文档:

* docs/02_collision_playground.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 如遇问题,更新 docs/troubleshooting.md

完成后停下来。

---

## 阶段 3:Sprite Sheet Playground

目标:

* 创建 SpriteSheetPlayground。
* 使用 AnimatedSprite2D。
* 创建或导入临时 sprite sheet。
* 支持 idle、walk、attack、hurt、death 动画。
* 使用按键切换动画。
* 如果没有素材,就用程序生成的占位帧或简单色块帧。

要解释:

* Sprite
* Sprite Sheet
* AnimatedSprite2D
* SpriteFrames
* FPS
* 循环动画
* 非循环动画
* 像素图导入设置
* Nearest filter

阶段结束文档:

* docs/03_spritesheet_playground.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 如遇问题,更新 docs/troubleshooting.md

完成后停下来。

---

## 阶段 4:Skeleton Playground

目标:

* 创建 SkeletonPlayground。
* 使用 Skeleton2D、Bone2D、AnimationPlayer。
* 用简单图形或拆分图片模拟 Boss 立绘。
* 做一个待机呼吸动画或挥刀动画。
* 不要求美术好看,只要求理解骨骼动画流程。

要解释:

* Skeleton2D
* Bone2D
* 骨骼动画
* 精灵表动画和骨骼动画的区别
* AnimationPlayer 如何驱动骨骼

阶段结束文档:

* docs/04_skeleton_playground.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 如遇问题,更新 docs/troubleshooting.md

完成后停下来。

---

## 阶段 5:Chapter01 地图与光标

目标:

* 创建主战斗场景 Chapter01。
* 使用 TileMapLayer 制作 16x12 或 20x15 战棋地图。
* 创建 Cursor。
* 支持键盘移动光标。
* 光标移动时显示当前格子的地形信息。
* 引入 terrain.json。

要解释:

* 主玩法场景结构。
* 地图层、单位层、UI 层。
* Cursor 的作用。
* grid_pos 和 world_pos。
* 为什么战棋游戏必须统一坐标系统。

阶段结束文档:

* docs/05_chapter01_map_and_cursor.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 如遇问题,更新 docs/troubleshooting.md

完成后停下来。

---

## 阶段 6:单位系统

目标:

* 创建 Unit.tscn。
* 创建 Unit.gd 和 UnitStats.gd。
* 使用 units.json 配置单位。
* 加载 3 个我方单位和 4 个敌方单位。
* 单位显示在正确格子。
* 选中单位时显示 UnitInfoPanel。
* 单位要保存 grid_pos,不要只依赖 Node2D.position。

要解释:

* 场景实例化。
* 数据驱动。
* 单位数据和单位表现分离。
* Sprite/AnimatedSprite2D 在角色中的作用。
* 为什么 grid_pos 是玩法状态,position 是画面表现。

阶段结束文档:

* docs/06_unit_system.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 如遇问题,更新 docs/troubleshooting.md

完成后停下来。

---

## 阶段 7:移动范围与寻路

目标:

* 选中我方单位后,用 BFS 显示移动范围。
* 根据地形 move_cost 计算移动消耗。
* 墙、水、敌方单位阻挡移动。
* 友方单位不可停留。
* 点击可移动格子后,单位沿路径移动。
* 移动时播放 walk 动画或占位动画。
* 行动后暂时标记为已行动。

要解释:

* BFS。
* AStarGrid2D。
* 移动范围和最短路径的区别。
* 逻辑碰撞。
* 地形移动消耗。
* RangeOverlay。

阶段结束文档:

* docs/07_movement_and_pathfinding.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 如遇问题,更新 docs/troubleshooting.md

完成后停下来。

---

## 阶段 8:行动菜单与战斗

目标:

* 单位移动后弹出行动菜单。
* 菜单选项:攻击 / 等待。
* 如果选择攻击,显示攻击范围。
* 选择敌人后显示 BattlePreview。
* 实现 CombatResolver。
* 使用简单伤害公式:
damage = attacker.str + weapon.might - defender.def
damage 最小为 0
* 执行攻击。
* 播放 attack / hurt / death 动画或占位表现。
* HP 为 0 的单位从场上移除。

要解释:

* 行动菜单。
* 攻击范围。
* 战斗预览。
* CombatResolver。
* 战斗公式和表现分离。
* 动画和规则解耦。

阶段结束文档:

* docs/08_action_menu_and_combat.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 如遇问题,更新 docs/troubleshooting.md

完成后停下来。

---

## 阶段 9:回合系统与状态机

目标:

* 实现玩家回合。
* 实现敌方回合。
* 每个单位一回合只能行动一次。
* 行动后单位变灰。
* 所有我方单位行动后,自动进入敌方回合。
* 敌方行动完后回到玩家回合。
* 创建或完善 GameState.gd 和 TurnManager.gd。

要解释:

* State Machine。
* Turn Manager。
* GameState。
* 玩家选择阶段。
* 移动阶段。
* 行动菜单阶段。
* 攻击阶段。
* 敌方行动阶段。
* 为什么回合制游戏特别需要清晰的状态管理。

阶段结束文档:

* docs/09_turn_system.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 如遇问题,更新 docs/troubleshooting.md

完成后停下来。

---

## 阶段 10:敌人 AI

目标:

* 创建 EnemyAI.gd。
* 敌人寻找最近的我方单位。
* 如果能攻击,直接攻击。
* 如果不能攻击,向目标移动。
* 移动后如果能攻击,则攻击。
* 否则等待。
* Boss 可以设置为 stationary,不主动移动。
* 敌人行动要有简单延迟,方便观察。

要解释:

* 战棋 AI 的基本结构。
* 目标选择。
* 移动决策。
* 攻击决策。
* 为什么 AI 应该独立于 Unit 和 TurnManager。
* 简单 AI 和复杂 AI 的区别。

阶段结束文档:

* docs/10_enemy_ai.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 如遇问题,更新 docs/troubleshooting.md

完成后停下来。

---

## 阶段 11:胜负、音效与 Boss cut-in

目标:

* 主角死亡时失败。
* Boss 死亡或敌人全灭时胜利。
* 添加 ResultPanel。
* 添加选择、移动、攻击、受击、胜利音效。
* Boss 第一次进入战斗前播放 Skeleton2D cut-in 或占位 cut-in。
* 添加简单镜头震动或 UI 动画。

要解释:

* 游戏流程闭环。
* 反馈感。
* 音效在游戏中的作用。
* AnimationPlayer 如何控制 UI、镜头、音效、cut-in。
* 为什么 vertical slice 要包含胜利和失败。

阶段结束文档:

* docs/11_win_lose_audio_cutscene.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 如遇问题,更新 docs/troubleshooting.md

完成后停下来。

---

## 阶段 12:整理、README 与导出

目标:

* 清理无用文件。
* 检查资源路径。
* 创建 README.md。
* 在 README 中说明项目目标、运行方式、已实现功能、学习概念。
* 尝试导出 Web 或桌面版本。
* 记录导出步骤和遇到的问题。
* 最后更新 docs/12_export_and_wrapup.md。

要解释:

* 原型整理。
* 打包发布。
* README 的作用。
* prototype 和 production 的区别。
* 后续如果继续扩展,应该从哪里开始。

阶段结束文档:

* docs/12_export_and_wrapup.md
* 更新 docs/00_project_overview.md
* 更新 docs/glossary.md
* 更新 docs/devlog.md
* 更新 docs/troubleshooting.md
* 创建 README.md

完成后停下来。

---

# 八、代码风格要求

* 使用 Godot 4.x GDScript。
* 代码要清晰直观,不要过度架构。
* 每个脚本顶部写注释,说明它负责什么。
* 关键函数写注释。
* 命名要稳定,不要频繁改名。
* 尽量每阶段结束时项目都能运行。
* 每次修改要说明影响范围。
* 不要一次性引入太多抽象。
* 不要做复杂 ECS、复杂事件总线、复杂存档系统。
* 优先完成可玩的闭环。

---

# 九、素材和版权要求

* 不要使用火焰纹章原版素材。
* 可以使用占位素材。
* 可以用纯色方块表示角色。
* 可以用简单几何图形表示 Boss cut-in。
* 可以后续接入免费素材,但要在 README 中记录素材来源和许可证。
* 如果不确定素材许可证,就不要使用。

---

# 十、Claude Code 执行要求

你在 Claude Code 中执行时,请遵循:

1. 先检查项目目录。
2. 不确定 Godot 版本时,先从 project.godot 或可用命令中判断。
3. 不要破坏已有文件。
4. 每次修改前先简要说明计划。
5. 每阶段完成后必须停止,等待我验证。
6. 每阶段都必须写对应 docs 文档。
7. 每阶段都必须更新 glossary.md 和 devlog.md。
8. 如果遇到错误,先修复;修复不了就写入 troubleshooting.md,并告诉我当前阻塞点。
9. 不要自动跳阶段。
10. 不要使用 copyrighted assets。

---

# 十一、阶段开始口令

现在请从阶段 0 开始。

请先检查当前目录是否已有 Godot 项目。
如果没有,请创建推荐项目结构、docs 目录和基础文档。
完成阶段 0 后停下来,告诉我如何在 Godot 中打开和验证项目初始化是否成功。

这里放一些 AI 辅助实现出来的 playground 效果图。重点不是画面多精致,而是每一步都有一个可以跑、可以看的小实验场:

结合视觉模型,还可以给阶段文档补一些讲解概念图。对小白来说,这类图比单纯看术语解释更容易建立整体印象:

整个学习过程应该是引导式的,AI 可以基于一个小白的角度帮我们思考应该补充了解哪块的知识,我们也可以中途插入让 AI 深入讲解自己某一块不懂的地方,节奏全由自己把控 (以下截取一个片段):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
› RigidBody3D 不是很好理解,中文意思是什么


• RigidBody3D 的中文通常叫:

- 刚体
- 更完整一点叫 三维刚体节点

“刚体”这个词来自物理学,意思是:
这个物体会被当成一个有质量、受力、会碰撞、会运动的实体来模拟。

你可以这样直观理解:

- RigidBody3D = “交给物理引擎驱动的物体”
- CharacterBody3D = “交给游戏逻辑驱动的角色”
- StaticBody3D = “不会动的碰撞体”

所谓“刚”,不是说它一定很硬,而是说它在物理模拟里被当作整体形状不变的实体。
比如一个箱子、石头、桶,被推一下会滑、滚、撞、停,这就是典型 RigidBody3D。

如果放到你这个项目语境里:

- 地上的箱子、可被爆炸掀飞的石块,用 RigidBody3D 合适
- 战棋角色单位,不适合优先用 RigidBody3D
- 地板和墙,用 StaticBody3D

一句话记忆:

- RigidBody3D = 刚体,靠物理模拟运动
- CharacterBody3D = 角色体,靠代码控制运动
- StaticBody3D = 静态体,负责阻挡

如果你愿意,我下一条可以专门用“推箱子、角色、地板”这三个例子,把这三种 Body 的
区别彻底讲明白。


› 不用了,继续
Details
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223

› 我更想了解怎么调整 Camera3D


• 那就讲场景里的 Camera3D,不是编辑器视口。

你现在阶段 2 这个场景里,Camera3D 的调整主要看 4 件事:

- 位置 Position
- 旋转 Rotation
- 朝向目标 look_at()
- 视野 FOV

先结合你当前实现看。PhysicsPlayground.gd 里我写的是:

camera.global_position = Vector3(0.0, 14.0, 18.0)
camera.look_at(Vector3(0.0, 0.5, 0.0), Vector3.UP)
camera.fov = 55.0

这三行分别表示:

1. 相机放在场景上方、稍微往后的位置
2. 镜头看向场景中心附近
3. 视野角设成 55,避免太广导致画面畸变

———

一、最直接的调整方式:在编辑器里手改 Camera3D

选中 Camera3D 节点后,看右侧 Inspector,重点是:

- Transform > Position
- Transform > Rotation Degrees
- Camera3D > FOV
- Current

你可以这样理解:

- Position
决定相机放在哪里

- Rotation Degrees
决定相机朝哪个方向转

- FOV
决定“镜头广角程度”

- Current
决定运行时是不是这台相机在生效

———

二、阶段 2 里最常调的是 Position 和 FOV

对于这种斜俯视实验场,先不要纠结复杂运镜,先抓两个规律:

1. Y 增大
相机更高,俯视感更强

2. Z 增大
相机更远,能看到更多前方内容

比如:

- Position = (0, 10, 12)
更近,更聚焦

- Position = (0, 18, 24)
更高更远,视野更大

———

三、FOV 怎么理解

FOV 是视场角,数值越大,画面越广,但透视畸变也越明显。

常见直觉:

- 35 ~ 45
更像长焦,压缩感强,画面稳,但看得窄

- 50 ~ 60
很常用,比较自然

- 70+
更广,但边缘容易拉伸,战棋镜头通常没必要这么大

对你现在这个 SRPG 原型,我建议:

- 战术视角先用 50 ~ 60
- 你现在的 55 就是一个稳妥值

———

四、为什么我代码里用 look_at()

因为手调旋转角在 3D 里不直观,尤其是俯视斜角时。

camera.look_at(Vector3(0.0, 0.5, 0.0), Vector3.UP)

意思是:

- 相机无论放在哪里
- 都自动朝向场景中心看过去

这比你手算 Rotation Degrees 稳定得多。
对于教学项目和实验场,优先推荐这种写法。

———

五、你在编辑器里如何“把当前视口角度应用给 Camera3D”

这是 Godot 里很好用的一招。

步骤:

1. 在 3D 视口里先把编辑器镜头转到你想要的角度
2. 选中场景树里的 Camera3D
3. 在 3D 视口顶部菜单里找和相机对齐相关的选项
常见是类似:
- Align Transform with View
- 或“将节点对齐到视图”

作用就是:

- 把你当前编辑器看到的角度,直接复制给 Camera3D

这比手输旋转和位置高效很多。

———

六、运行时调 Camera3D,推荐优先改脚本还是 Inspector?

看你的目的:

1. 找感觉
先在编辑器里拖 Position、改 FOV

2. 定结果
把最终值写回脚本

因为你现在脚本里 _ready() 会覆盖相机参数。
也就是说,哪怕你在 Inspector 里改了,运行时还是会被这几行重置:

camera.global_position = Vector3(0.0, 14.0, 18.0)
camera.look_at(Vector3(0.0, 0.5, 0.0), Vector3.UP)
camera.fov = 55.0

所以如果你要保留修改结果,有两个方法:

- 改脚本里的数值
- 或者临时注释掉这些初始化代码,再用 Inspector 微调

———

七、阶段 2 这类镜头,推荐你怎么调

建议你按这个顺序试:

1. 先改 global_position.y
看高低是否合适

2. 再改 global_position.z
看远近是否合适

3. 再改 fov
看画面是否太挤或太广

4. 让 look_at() 继续盯住场景中心
不要一开始就手调旋转

这是最稳的方式。

———

八、给你一组可直接试的镜头参数

更近一点:

camera.global_position = Vector3(0.0, 10.0, 14.0)
camera.look_at(Vector3(0.0, 0.5, 0.0), Vector3.UP)
camera.fov = 50.0

更像标准战术俯视:

camera.global_position = Vector3(0.0, 16.0, 20.0)
camera.look_at(Vector3(0.0, 0.5, 0.0), Vector3.UP)
camera.fov = 55.0

更远,方便总览:

camera.global_position = Vector3(0.0, 22.0, 28.0)
camera.look_at(Vector3(0.0, 0.5, 0.0), Vector3.UP)
camera.fov = 60.0

———

九、你现在最该知道的坑

1. 改了 Inspector,但运行时没变化
原因通常是脚本 _ready() 覆盖了

2. 相机位置对了,但方向不对
直接用 look_at(),不要硬调旋转

3. FOV 太大导致画面怪
战棋项目先别超过 60

4. 看不全场景
先加大 Y 和 Z,不要先猛加 FOV

———

如果你要,我下一条可以直接帮你把 PhysicsPlayground.gd 改成“导出可调参数版”,这
样你就能在 Inspector 里直接调:

- camera_height
- camera_distance
- camera_target
- camera_fov

不需要每次改脚本常量。

通过这样的流程,我们不需要一开始就抠每个实现细节,而是先把注意力放在“流程感”上:地图怎么搭、角色怎么进场、动画怎么接、碰撞和物理怎么验证、最后怎么变成一个可玩的闭环。

真正重要的不是 AI 替我们做完一个游戏,而是它能帮我们快速建立对一条生产管线的整体感。等 AI 能力继续往前走,我们也会更容易指挥 AI(or 不被糊弄)去更快更好地完成自己想要的东西。到时候不一定非要等游戏公司更新进度,自己也可以 DIY 一些进度。(据说有游戏公司开始往 AI UGC 方向靠了~)

了解更多细节:https://github.com/yeshan333/x-gamedev-with-ai/blob/main/README.md