- 创建复合形状
- 每个形状支持多个颜色
- 为每个生成区选择形状工厂
- 追踪形状的初始生产工厂
这是对象管理章节的第八篇教程. 将在上个教程的代码基础上制作. 本篇教程将会加入更多形状工厂, 并生成更为复杂的形状
本教程源码使用Unity2017.4.12f1编写
别问, 酷炫就完事儿了
更多形状种类
我们不仅可以使用立方体, 球体和胶囊体这几种形状, 还可以使用任何导入的Mesh网格. 另外, 形状还可以由多个物体构成. 形状可以拥有自己的组织结构, 使用多个Mesh网格、动画、行为以及其他内容. 接下来要通过组合默认Mesg来创建几种复杂的形状
球体+立方体
第一个复合形状是一个立方体和一个球体的简单组合. 制作步骤如下 :
- 创建一个立方体命名为Cube With Sphere, 创建一个球体, 命名不变. 将球体设置为立方体的子物体
- 两者坐标均设置为(0, 0, 0), 球体的Scale设置为(1.35, 1.35, 1.35)
- 为立方体添加Shape脚本组件
- 将它们整体做成预制体, 然后在场景中删掉它们
复合形状Cube With Sphere
复合胶囊体
将三个胶囊体旋转一定角度组合后可以到更为复杂的形状, 制作步骤如下 :
- 新建三个胶囊体capsule, 分别命名为Composite Capsule 和 Capsule X 以及 Capsule Z, 后面两者设置为第一个胶囊体的子物体
- 三个胶囊体的坐标全部设置为(0, 0, 0),
- Capsule X的Rotation设置为(90, 0, 0), Capsule Z的Rotation设置为(0, 0, 90)
- 为Composite Capsule物体添加Shpae脚本组件
- 将它们整体做成预制体, 然后在场景中删掉它们
复合形状Composite Capsule
复合立方体
最后一个符合形状由三个立方体构成, 制作步骤如下 :
- 新建三个立方体, 分别命名为Composite Cube 和 Cube XY以及Cube YZ, 后两者设置为第一个立方体的子物体.
- 三个立方体的坐标全部设置为(0, 0, 0),
- Cube XY的Rotation设置为(45, 45, 0), Cube YZ的Rotation设置为(0, 45, 45)
- 为Composite Cube物体添加Shape脚本组件
- 将它们整体做成预制体, 然后在场景中删掉它们
复合形状Composite CUbe
产生新形状
要在运行游戏时产生上述制作的复合形状, 只需要将它们的预制体添加到Shape Factory资源的Prefabs列表中 :
将新建的形状预制体添加到Shape Factory资源的Prefabs列表中
完成上述设置后, 运行游戏, 就可以产生新建的复合形状了(友情提示, 上一篇教程对生成区增加了配置选项, 默认都是0, 记得手动配置下非零值, 不然你的形状缩放是0, 看不见)
但是它们现在大部分都是白色, 因为只有父物体添加了Shape脚本组件, 从而可以获得随机的材质与颜色, 子物体并不受影响.
复合形状生成的效果, 大部分面积都是白色
配置要调整的Mesh渲染器
要更改复合形状中所有物体的材质和颜色, Shape脚本需要去操作每一个物体的MeshRenderer组件, 这就需要为Shpae脚本增加一个存储这些组件引用的数组 :
[SerializeField]
//存储脚本要操作的所有MeshRenderer组件的引用
MeshRenderer[] meshRenderers;
现在需要手动的编辑每一个复合形状预制体, 将所有需要被操纵的物体都拖拽到父物体Inspector中的该数组列表内, Unity会自动获取它们的MeshRenderer组件的引用, 设置完成后类似下图所示 :
其中一个复合形状预制体的meshRenderers列表
(记得为之前教程创建的单个形状的预制体也设置下这个列表)
因为有了meshRenderers列表存储每一个渲染器, 因此Shape脚本不再需要在Awake方法中去获取MeshRenderer组件了, 可以将该方法与存储单个渲染器的字段一并删除 :
//现在MeshRenderer组件将手动指定, 不需要该变量去自动获取了
//MeshRenderer meshRenderer;
//现在MeshRenderer组件将手动指定, 不需要Awake方法去自动获取了
//void Awake () {
// meshRenderer = GetComponent<MeshRenderer>();
//}
删除上述代码后, 必须在SetMaterial方法中循环遍历meshRenderers列表中的每一个元素, 并为其设置材质 :
public void SetMaterial (Material material, int materialId) {
//meshRenderer.material = material;
//不再为单个MeshRenderer设置材质, 需要为meshRenderers类别中每一个元素设置材质
for (int i = 0; i < meshRenderers.Length; i++) {
meshRenderers[i].material = material;
}
MaterialId = materialId;
}
对SetColor方法也要进行类似修改 :
public void SetColor (Color color) {
...
//meshRenderer.SetPropertyBlock(sharedPropertyBlock);
//不再为单个MeshRenderer设置材质属性块, 需要为meshRenderers列表中每一个元素设置材质属性块
for (int i = 0; i < meshRenderers.Length; i++) {
meshRenderers[i].SetPropertyBlock(sharedPropertyBlock);
}
}
进行适当的设置后, 复合形状也都被完全染色了
复合颜色
目前, 复合形状中每一个被Shape脚本影响的子物体的颜色都是相同的. 我们可以让它们之间的颜色有所区别.
要让复合生成区支持的多种颜色数据都能被游戏保存, 需要将Shape脚本中存储形状颜色数据的的color字段替换为一个颜色数组. 该数组应该在Awake方法中进行初始化, 长度与meshRenderers数组相同 :
//Color color;
//使用颜色数组代替单一的颜色
Color[] colors;
//新增Awake方法
void Awake () {
//初始化颜色数组, 其长度与meshRenderers数组一致0
colors = new Color[meshRenderers.Length];
}
当通过SetColor方法配置颜色时, 将每一次配置的颜色数据存储到这个数组中
public void SetColor (Color color) {
//color字段已经被colors数组替代 此处代码也应该一并删除
//this.color = color;
if (sharedPropertyBlock == null) {
sharedPropertyBlock = new MaterialPropertyBlock();
}
sharedPropertyBlock.SetColor(colorPropertyId, color);
for (int i = 0; i < meshRenderers.Length; i++) {
//按照索引, 将每一次配置的颜色数据存储colors数组中
colors[i] = color;
meshRenderers[i].SetPropertyBlock(sharedPropertyBlock);
}
}
目前每一个复合形状依然使用相同的颜色. 要让复合形状可以使用多种颜色, 需要为SetColor方法再增加一个变体, 该变体方法额外接受一个代表颜色数组索引的参数, 通过该索引, 每次只配置一个形状的颜色 :
//SetColor的另一个版本, 接受两个参数,
//代码及功能与一个参数的版本只有一个区别 : 它每次只按照index参数设置对应索引的形状颜色
public void SetColor (Color color, int index) {
if (sharedPropertyBlock == null) {
sharedPropertyBlock = new MaterialPropertyBlock();
}
sharedPropertyBlock.SetColor(colorPropertyId, color);
colors[index] = color;
meshRenderers[index].SetPropertyBlock(sharedPropertyBlock);
}
当外部类调用上述新增方法时, 需要知道颜色数组总共有多少个元素, 因此再添加一个公开的ColorCount属性, 用来得到colors数组的长度 :
//用来得到颜色数组长度, 也就是复合形状需要设置不同颜色的形状数量
public int ColorCount {
get {
return colors.Length;
}
}
保存所有颜色数据
目前的代码编译会出错, 因为color字段在前面被我们删除了. 现在我们来修复这个编译错误.
首先, Game脚本中, 将保存文件的版本号增加到5 :
//const int saveVersion = 4;
//版本号升级为5
const int saveVersion = 5;
然后调整Shape.Save方法, 让它保存colors数组中所有的颜色数据, 代替已经被删除的color字段 :
public override void Save (GameDataWriter writer) {
base.Save(writer);
//writer.Write(color);
//color字段被colors数组替代, 现在要遍历colors数组, 保存每一个元素代表的颜色数据
for (int i = 0; i < colors.Length; i++) {
writer.Write(colors[i]);
}
writer.Write(AngularVelocity);
writer.Write(Velocity);
}
当加载游戏时, 如果我们在加载的文件版本号大于等于5, 就需要按照colors数组的长度, 依次读取每一个颜色数据, 并调用SetColor方法设置对应顺序的颜色; 否则如果版本号小于5, 则像之前一样只读取并设置一次颜色 :
public override void Load (GameDataReader reader) {
base.Load(reader);
//版本号大于等于5才支持读取多个颜色数据
if (reader.Version >= 5) {
//按照colors数组的长度, 依次读取每一个颜色数据
for (int i = 0; i < colors.Length; i++) {
//调用SetColor方法设置对应索引的形状颜色
SetColor(reader.ReadColor(), i);
}
}
//如果版本号小于5, 使用旧的颜色读取代码
else {
SetColor(reader.Version > 0 ? reader.ReadColor() : Color.white);
}
AngularVelocity = reader.Version >= 4 ? reader.ReadVector3() : Vector3.zero;
Velocity = reader.Version >= 4 ? reader.ReadVector3() : Vector3.zero;
}
切换配色方式
每个生成区生应该可以决定成的形状使用统一的颜色还是不同的颜色, 因此需要在SpawnZone脚本的SpawnConfiguration结构中增加一个控制配色方式的布尔字段 :
public struct SpawnConfiguration {
//控制生成区对形状的配色方式, false表示对构成形状的每个组成部分使用不同颜色
public bool uniformColor;
接着修改SpawnZone脚本的ConfigureSpawn方法, 当一个生成区需要为形状的每个组成部分使用不同的颜色时, 就为为每一个组成形状的物体分别设置随机颜色 :
public virtual void ConfigureSpawn (Shape shape) {
Transform t = shape.transform;
t.localPosition = SpawnPoint;
t.localRotation = Random.rotation;
t.localScale = Vector3.one * spawnConfig.scale.RandomValueInRange;
//spawnConfig.uniformColor为true表示配置统一的颜色, 则执行之前的颜色设置代码
if (spawnConfig.uniformColor) {
shape.SetColor(spawnConfig.color.RandomInRange);
}
//spawnConfig.uniformColor为false, 表示对构成形状的每个组成部分使用不同颜色
else {
//根据shape.ColorCount属性得到的颜色数量进行循环, 为形状每一个组成部分分别设置随机颜色
for (int i = 0; i < shape.ColorCount; i++) {
//调用两个参数的SetColor方法
shape.SetColor(spawnConfig.color.RandomInRange, i);
}
}
shape.AngularVelocity = Random.onUnitSphere * spawnConfig.angularSpeed.RandomValueInRange;
…
}
如果不勾选uniformColor, 生成的复合形状每个部分的颜色都单独随机设置
能不能为形状设置随机颜色时使用固定的色调(hue)?
是的, 可以. 你可以在为一个形状设置各个部分的随机颜色时, 只随机确定一次颜色的色调(hue), 每个部分只有饱和度(saturation)和明度(value)是不同的. 更进一步, 你可以使用三个开关字段来分别控制色调, 饱和度和明度是否分别随机设置, 还是统一设置. 不过这样也会让你的颜色设置代码变得更加复杂一些.
稳健的保存数据
此时, 我们的游戏已经支持了复合形状, 并且复合形状的每个组成部分都可以配置不同的颜色. 但是在之后我们有可能会更改形状预制体的meshRenderers列表中的元素, 如果我们这样做了, 代表colors数组的长度可能发生了变化, 与存档文件中保存的颜色数据的数量变得不一致. 这样就会因加载时数据不匹配导致游戏加载失败. 为了预防发生这种问题, 需要在Shape脚本保存游戏时额外保存形状包含颜色的总数, 并在加载文件时, 检查加载的颜色总数与当前处理的形状包含的颜色总数是否一致 :
public override void Save (GameDataWriter writer) {
base.Save(writer);
//将形状所包含的颜色总数写入保存文件
writer.Write(colors.Length);
for (int i = 0; i < colors.Length; i++) {
writer.Write(colors[i]);
}
writer.Write(AngularVelocity);
writer.Write(Velocity);
}
对应的, 还要修改Load方法中加载颜色的代码, 为了提高代码的可读性, 将这些要修改的代码放到一个新建的LoadColors方法中, 并在Load方法中调用该方法 :
if (reader.Version >= 5) {
//for (int i = 0; i < colors.Length; i++) {
// SetColor(reader.ReadColor(), i);
//}
//删除上方与颜色加载有关的代码, 调用单独的LoadColors方法处理颜色加载过程
LoadColors(reader);
}
接着摇完成LoadColors方法的代码. 加载颜色数据时, 我们必须先读取形状包含的颜色总数, 之后要使用读取到的颜色总数与当前形状包含的颜色总数中的较小值作为读取的颜色数据次数, 这样就可以保障实际读取颜色的次数不会超过保存的颜色总数 :
//该方法专门用于处理颜色数据加载
void LoadColors (GameDataReader reader) {
//加载保存的颜色总数
int count = reader.ReadInt();
//读取颜色数据的次数取保存的颜色总数与形状所需的颜色总数之间的较小值
int max = count <= colors.Length ? count : colors.Length;
//按照计算出来的次数循环读取颜色数据
//循环控制变量i没有写在循环内, 因为下面马上还要用它循环后的值做其他处理
int i = 0;
for (; i < max; i++) {
SetColor(reader.ReadColor(), i);
}
}
上述代码, 在保存的颜色总数与形状所需的颜色总数一致时, 可以正常工作.
玩意由于某些原因, 导致两者不相等, 就需要处理两者情况, 一种情况是保存的比所需的多, 另一种情况是保存的比所需的少.
第一种情况下, 保存的颜色总数更多, 在为形状设置完颜色后, 也必须读取它们, 以便后续加载流程可以读取到颜色数据后面的其他数据 :
for (; i < max; i++) {
SetColor(reader.ReadColor(), i);
}
//如果保存的颜色总数比形状需要的多, 则需要额外的多余的颜色数据读取出来,
//否则后续应该读取其他保存数据的代码会接着读取剩余的颜色数据, 就出错了
if (count > colors.Length) {
//还需要继续读取颜色数据的次数是(count - i)个
for (; i < count; i++) {
reader.ReadColor();
}
}
第二种情况, 形状所需的颜色数量更多, 这表示即便加载了保存的所有颜色数据, 依然不满足形状设置颜色的需求, 那么就需要为多出来的形状, 设置固定的颜色, 比如白色 :
if (count > colors.Length) {
for (; i < count; i++) {
reader.ReadColor();
}
}
//如果形状需要的颜色总数比保存的多, 则需要为多出来的部分设置固定颜色
//否则如果这个形状用的是回收池里的, 这些多出来的部分就还是销毁前的配色
else if (count < colors.Length) {
//还需要配置固定颜色的部分是(count - i)个
for (; i < colors.Length; i++) {
SetColor(Color.white, i);
}
}
第二个形状工厂
现在游戏使用单个形状工厂, 由于形状的种类很少, 并且也不需要对形状划分更多类别, 所以只使用一个工厂还算合情合理. 不过从现在开始, 要将形状分为两个类别 : 简单形状 和 复合形状. 这种情况下, 为每一个类别的形状使用各自的工厂可以更好地对它们进行区别处理, 并让我们可以对产生的形状进行更多的控制
复合形状工厂
创建一个新的ShpaeFactory资源, 可以直接复制一个之前教程创建的, 在Inspector中为其只保留复合形状的预制体引用, 然后将其更名为Composite Shape Factory.
接着将原有的Shape Factory资源更名为Simple Shape Factory, 并在Inspector中为其只保留单独形状的预制体引用
参考设置如下图所示 :
两个工厂资源的命名与Inspector设置
这样, 就可以通过为Game物体分配不同的工厂, 来决定生成简单形状还是复合形状.
每个生成区的工厂
随着新的工厂类型的假如, 有必要让每个生成区自己决定使用哪一个工厂, 而不是使用游戏的统一设置的工厂. 并且形状不止可以选择一个工厂, 我们将通过在SpawnConfiguration结构中新增一个工厂数组来为生成区配置多个工厂 :
public struct SpawnConfiguration {
//用来为生成区配置要使用的形状工厂
public ShapeFactory[] factories;
保存代码, 回到编辑器, 在Inspector中为每个生成区配置你希望它使用的工厂, 每个生成区至少要配置一个工厂(包括复合生成区). 生成形状时, 将在factories数组中随机选择一个工厂 :
生成区的factories数组配置示意
同一个工厂还可以在数组中设置多个, 这样它就有更大的概率被选择. 比如, 在数组中加入两个Composite Shape Factory和一个Simple Shape Factory, 将会使得前者被随机选择的概率是后者的两倍
复合形状工厂依靠数量优势得到了更高的选择概率
生成区功能扩展
由于每个生成区现在自主的旋转要使用的工厂, 因此Game脚本也就不再需要负责产生新形状了, 这个工作现在已经交给了SpawnZone脚本. 但是Game脚本的其他功能依然需要追踪生成的形状, 因此我们将SpawnZoen.ConfigureSpawn方法改名为SpawnShape, 改名后的方法不再需要参数, 并会返回新产生的形状 :
//public virtual void ConfigureSpawn (Shape shape) {
//ConfigureSpawn方法改名
public virtual Shape SpawnShape () {
//随机获取一个工厂的数组索引
int factoryIndex = Random.Range(0, spawnConfig.factories.Length);
//使用随机索引对应的工厂生产形状
Shape shape = spawnConfig.factories[factoryIndex].GetRandom();
Transform t = shape.transform;
//…
shape.Velocity = direction * spawnConfig.speed.RandomValueInRange;
//返回新生成的形状
return shape;
}
在CompositeSpawnZone脚本中进行同样的修改 :
//public override void ConfigureSpawn (Shape shape) {
//ConfigureSpawn方法改名
public override Shape SpawnShape () {
if (overrideConfig) {
//base.ConfigureSpawn(shape);
//返回父类SpawnShape方法生成的形状
return base.SpawnShape();
}
else {
…
//spawnZones[index].ConfigureSpawn(shape);
//返回指定索引的基本生成区生成的形状
return spawnZones[index].SpawnShape();
}
}
在GameLevel脚本中也要将ConfigureSpawn方法改为SpawnShape方法 :
//public void ConfigureSpawn(Shape shape) {
//ConfigureSpawn方法改名
public Shape SpawnShape () {
//spawnZone.ConfigureSpawn(shape);
//返回生成区产生的形状
return spawnZone.SpawnShape();
}
最后, Game.CreateShape方法中, 只需要将当前关卡生成的形状添加到它用来追踪生成形状的列表中即可 :
void CreateShape () {
//Shape instance = shapeFactory.GetRandom();
//GameLevel.Current.ConfigureSpawn(instance);
//shapes.Add(instance);
//形状生成的任务已经交给了关卡中的生成区,
//Game的CreateShape方法现在只拿到生成的形状并添加到shapes列表中
shapes.Add(GameLevel.Current.SpawnShape());
}
**
Using different factories per zone.
回收形状
因为现在可以同时使用两个形状工厂, 在游戏运行时候就创建用于存放这两个工厂各自生产的形状的场景, 分别与各自对应的工厂资源的名称相同
多个工厂场景示意
看上去工厂生产形状的时候一切正常, 但是在回收销毁的形状时候其实发生了错误. 所有形状最终都会被一个工厂回收, 可能导致再次重用形状时产生的形状与工厂的类型不匹配. 这是因为Game脚本始终使用同一个工厂去回收形状, 无论这个形状到底是哪个工厂产生的.
形状应该只被产生它的工厂所回收. 要做到这一点, 每个形状都应该记录下是哪个工厂生产的自己. 在Shape脚本中添加一个属性OriginFactory, 用来设置和取得生产它的工厂 :
//用来获取生成形状的工厂类型
public ShapeFactory OriginFactory {
//get方法直接返回属性值
get {
return originFactory;
}
//set方法只能被设置一次属性值, 重复设置会显示文字提示
set {
if (originFactory == null) {
originFactory = value;
}
else {
Debug.LogError("不允许篡改形状的生产工厂");
}
}
}
//存储生产该形状的工厂引用
ShapeFactory originFactory;
然后让ShapeFactory在生成每个形状的时候将自身记录为它们的生产工厂 :
public Shape Get (int shapeId = 0, int materialId = 0) {
Shape instance;
if (recycle) {
…
else {
instance = Instantiate(prefabs[shapeId]);
//生产形状后将自身记录为形状的生产工厂, 注意代码位置别加错了
instance.OriginFactory = this;
instance.ShapeId = shapeId;
SceneManager.MoveGameObjectToScene(instance.gameObject, poolScene);
}
}
…
}
这样就可以使用正确的工厂去回收每一个形状了, 另外再向Shape脚本中增加一个方便调用的Recycle方法 :
//方便形状在销毁时调用自身生产工厂的Reclaim方法
public void Recycle () {
OriginFactory.Reclaim(this);
}
在Game.DestroyShape方法中调用上述方法, 取代之前直接调用固定工厂进行回收的代码 :
void DestroyShape () {
if (shapes.Count > 0) {
int index = Random.Range(0, shapes.Count);
//shapeFactory.Reclaim(shapes[index]);
//现在要根据每个形状自身的记录来决定使用哪个工厂对其进行回收
shapes[index].Recycle();
…
}
}
在Game.BeginNewGame方法中也进行同样的修改 :
void BeginNewGame () {
…
for (int i = 0; i < shapes.Count; i++) {
//shapeFactory.Reclaim(shapes[i]);
//现在要根据每个形状自身的记录来决定使用哪个工厂对其进行回收
shapes[i].Recycle();
}
shapes.Clear();
}
在形状工厂中, 每次回收形状前都要检查自身是否有资格回收该形状, 确保不会出现错误的回收调用 :
public void Reclaim (Shape shapeToRecycle) {
//每次回收形状前都要检查自身是否有资格回收该形状
if (shapeToRecycle.OriginFactory != this) {
//如果自身与形状中记录的生成工厂不符, 表示没有资格回收形状, 报错并终止方法
Debug.LogError("当前工厂与形状记录的生产工厂不一致, 无权回收该形状");
return;
}
…
}
保存生产工厂数据
由于支持了多个工厂, 所以保存和加载功能也要做出一些调整, 必须将每个形状记录的生产工厂也写入保存文件, 这就需要为每个工厂分配一个ID代号, 保存的时候将ID写入文件中. 在ShapeFactory脚本中增加新的属性FactoryId. 用于得到当前工厂的ID, 该属性只能被赋值一次, 之后不可以被随意修改. 这只是针对”同一次游戏过程中”这一前提, 由于ShapeFactory类可以在同一次编辑器会话(一次”会话”指的打开编辑器到关闭编辑器之间的时间)内始终保存, 即便退出运行模式. 因此需要通过System.NonSerialized特性, 将记录工厂ID的字段声明为不可序列化的 :
//该属性用于获取和设置工厂ID
public int FactoryId {
get {
return factoryId;
}
set {
//只有工厂id是默认值且不是要为其赋值整型的最小值时才能进行赋值操作
if (factoryId == int.MinValue && value != int.MinValue) {
//满足以上条件, 则表示是对属性初次赋值, 允许执行
factoryId = value;
}
else {
//如果不是默认值以外的值, 表示已经进行过明确的赋值, 不可以再次更改
Debug.Log("工厂Id不能重复设置");
}
}
}
//该特性会使得被指定的字段不会被序列化, 即每次运行游戏都会恢复其代码中的默认值
[System.NonSerialized]
//工厂id字段, 使用指定的默认值
int factoryId = int.MinValue;
为什么必须将字段factoryId变成不可序列化的?
Unity不会保存ScriptableObject类中未标记为可序列化的私有字段. 然而ScriptableObject类的实例会在一次编辑器会话期间暂时实例化其数据, 不因退出运行模式而重置, 这也意味着, 在一次编辑器会话期间, 即便是未标记为可序列化的私有字段的值也会在运行模式之外持久保. 不过只要关闭Unity再打开就会重置这些私有字段.
但是这依然会给我们的编辑工作带来困扰, 试想一下, 你在运行模式之外编辑了工厂的数据, 使其工厂id发生了变化(在下文将介绍工厂ID是如何定义的) , 那么当你再次运行时. 却因为私有字段factoryId依然保持上次运行的值而无法使修改后的工厂Id生效, 因为按照逻辑, factoryId已经在之前的运行模式下被赋值一次了
因此, 为了方便编辑和调试, 我们使用[System.NonSerialized]特性标记它, 则该字段的数据就绝对不会被实例化, 包括上面说到的情况, 即便是临时的实例化也不可以. 这样我们就不需要重启Unity来修改工厂Id了
现在需要定义每个工厂类型的Id是什么. 首先向Game脚本增加一个工厂数组, 这个数组用来存放每一种工厂, 工厂在数组中的索引即代表了它们的工厂Id. 在OnEnable方法中完成工厂Id的赋值 :
//将工厂资源文件拖拽分配给该数组, 数组索引代表了该工厂的Id
//每个工厂资源文件只需要在数组中存在, 因为一个工厂Id只能赋值一次, 分配多次也不会有效果
[SerializeField] ShapeFactory[] shapeFactories;
//新增OnEnable方法
void OnEnable () {
//脚本启用时, 使用数组索引为每个工厂设置其工厂Id
for (int i = 0; i < shapeFactories.Length; i++) {
shapeFactories[i].FactoryId = i;
}
}
我们在之前的教程中, 为了防止玩家的控制指令在加载时关卡场景时导致错误, 加载关卡场景时会禁用Game脚本, 加载完成后则再次启用, 这也会触发Game的OnEnable方法, 不过这时就不需要也不能再次为工厂Id赋值了, 因此合理的做法是, 判断一下工厂Id是否已经赋值过了, 如果是, 则不需要重复赋值 :
void OnEnable () {
//多种情况都可能导致OnEnable方法被触发, 因此先检查工厂Id是否已经赋值过了,
//如果是, 则不需要重复赋值
if (shapeFactories[0].FactoryId != 0) {
for (int i = 0; i < shapeFactories.Length; i++) {
shapeFactories[i].FactoryId = i;
}
}
}
现在, 保存游戏的过程在写入形状数据时, 就可以将形状的生产工厂Id也写入保存文件了, 由于加载游戏时, 产生形状的第一步就应该确定使用哪个工厂, 所以在保存游戏时, 也要最先保存工厂Id :
public override void Save (GameDataWriter writer) {
…
for (int i = 0; i < shapes.Count; i++) {
//加载游戏时, 产生形状的第一步就应该确定使用哪个工厂, 所以在保存游戏时, 也要最先保存工厂Id
writer.Write(shapes[i].OriginFactory.FactoryId);
writer.Write(shapes[i].ShapeId);
writer.Write(shapes[i].MaterialId);
shapes[i].Save(writer);
}
}
加载游戏过程中读取每个形状的数据时, 首先读取形状的生产工厂Id, 然后以此为索引确定要实例化形状的工厂. 要注意的是, 如果保存文件的版本小于5, 说明没有工厂Id数据, 这种情况下使用固定的索引0作为形状的生产工厂Id :
IEnumerator LoadGame (GameDataReader reader) {
//…
for (int i = 0; i < count; i++) {
//读取形状的生产工厂Id, 然后以此为索引确定要实例化形状的工厂.
//如果保存文件的版本小于5, 说明还没有工厂Id数据, 则使用0作为形状的生产工厂Id
int factoryId = version >= 5 ? reader.ReadInt() : 0;
int shapeId = version > 0 ? reader.ReadInt() : 0;
int materialId = version > 0 ? reader.ReadInt() : 0;
//Shape instance = shapeFactory.Get(shapeId, materialId);
//使用工厂Id作为索引确定使用哪个工厂产生形状
Shape instance = shapeFactories[factoryId].Get(shapeId, materialId);
instance.Load(reader);
shapes.Add(instance);
}
}
至此, Game脚本中的ShapeFactory字段已经没有任何用处, 删掉它 :
//已经被工厂数组shapeFactories取代
//[SerializeField] ShapeFactory shapeFactory;
记得, 每一个每一个关卡中用到的不同种类的工厂都应该分配给Game脚本的工厂数组, 并且让Simple Shape Factory位于数组的首位, 这样可以很好地兼容版本号5以下的游戏保存数据. 一旦为Game工厂数组分配好了元素, 如无必要, 不要再更改它们之间的顺序, 保障加载过程可以正确进行.
在Inspector中为Game脚本分配游戏用到的每一类工厂