概念页
资源与场景实例化
Resources & Instancing
Resource 是纯数据容器（纹理、网格、脚本、动画、音频等）；节点消费 Resource。场景实例化是把 PackedScene 当作蓝图复制出运行时节点树——勿与 GPU MultiMesh 硬件实例化混淆。
原理
- Resource：磁盘上几乎一切可加载物；同路径加载返回同一缓存实例（共享），无需也不应无故
duplicate。 - 外部 vs 内嵌：有路径的外部资源 vs 写进
.tscn的 built-in。 - Instancing：
.tscn是蓝图；实例默认同结构，可覆盖导出属性；编辑器隐藏内部，表现像单个节点。 - 代码：
preload/load→instantiate()。
应用
- 子弹、敌人、子弹用场景实例；数值表、对话、存档结构用自定义
Resource子类 +@export。 - 更改共享 Resource 会影响所有引用者——这是特性（享元），改独立副本需
duplicate()。
取舍
- 共享省内存、易统一改；也易「改一处全军覆没」。
- 硬件大批量相同网格用 MultiMesh（性能页），不是场景实例化。
参见
出处
相关页面
游戏开发 · Godot节点与场景Nodes & ScenesGodot 把游戏抽象成「场景树」：节点是最小积木，场景是可复用的节点树蓝图；场景可嵌套实例化，同时扮演其他引擎中 Prefab 与关卡的角色。游戏开发 · Godot文件与数据 IO、存档思路Godot File IO & Persistence官方存档模式：用组标记持久对象 → 序列化（常 JSON 字典或自定义）→ 写入 user://。实践上 GDQuest 更推荐简单结构用 FileAccess.storevar，复杂结构用自定义 Resource + ResourceSaver。游戏开发资源管理器Resource Manager游戏由网格、材质、纹理、着色器、动画、音频、关卡布局、碰撞与物理参数等大量资源（也叫资产、媒体）构成。内存有限，所以引擎要保证每个资源在内存中只有一份（五个网格共用一张纹理时只载入一份）。每个引擎都有某种资源管理器：有的是统一集中的子系统，有的散布在多年间由不同人写的各个子系统中，但职责和要解决的问题是一样的。本页讲运行时部分：职责、文件组织与归档、文件格式、资源 GUID、资源注册表、生命周期（引用计数）和资源的内存管理；交叉引用与加载后初始化见 资源交叉引用与加载后初始化，离线工具链见 资产管线与工具链。游戏开发资源交叉引用与加载后初始化Resource Cross-References & Post-Load Initialization资源之间以任意方式相互引用（网格引用材质，材质引用纹理），整个资源数据库是一张有向依赖图。内存中的指针离开运行中的程序就失去意义，所以存盘时要把引用改写为 GUID 或文件内偏移，加载后再修正 (fix up) 回指针；含非 POD 的 C++ 对象还要用 placement new 调用构造函数；跨文件的外部引用要先加载全部相关文件。加载后通常还需要按资源类型做加载后初始化（以及释放前的拆除）。游戏开发原型模式Prototype Pattern原型模式 (Prototype Pattern) 的核心思想是“一个对象可以生成与自己相似的对象”：生成器持有一个原型实例，通过 clone() 复制出类和状态都相同的新对象。Nystrom 认为这个设计模式本身在现代游戏中很少是最佳答案，更有价值的是“原型委托 (delegation)”用于数据建模，让数据条目继承另一条目的属性，减少重复。游戏开发享元模式Flyweight Pattern享元模式 (Flyweight Pattern) 把对象的数据拆成可共享的“内在状态”和每个实例独有的“外在状态”，让大量对象共用一份内在状态。森林里成千上万棵树共用一份网格和纹理，以及瓦片地图中每格只存一个指向共享地形对象的指针，都是它的典型应用。