【案例设计】权限通行证 设计演变构思与分享（修正版）

开发平台：Unity 2018 以上
编程平台：Visual Studio 2020
 

前言

  交互门是游戏中最为常见的设计。基于交互门类型与实际关卡设计需求，衍生出 密码门、权限门、钥匙门、指纹门等设计（在程序设计上，这些门有着相同点的设计思路）。本文重点对权限通行证与交互门中关于权限级别卡的设计进行构思与分享。
 

基础理论

权限卡的理解：基于持有者职能等级赋予的相关通行许可证明。根据区域划分与机密程度，权限卡级别可由低至高分类多种级别。
应用案例：《Secret Library》、《The Forest》、《Contain Breach》、《Black Mesa》
交互门通信方式：触发器、碰撞器、射线检测
 

设计思路演变

1）最初的设计 - 重复性的糟糕思想

---

  基于Unity引擎的开发基础。在初学者思想中，拟建立多个 MonoBehaviour 脚本进行权限卡级别的设置。以对象作为一个类存在，用于调整权限卡信息。（例如 IDCardLevelOne.cs/IDCardLevelTwo.cs/IDCardLevelThree.cs/…）

public class IDCardLevelOne : MonoBehaviour
{
	public string IDCardName;
	public Dictionary<RoomName, bool> AllowRoom;
}

◼ 问题点：

1. 重复性的代码行内容。对项目整体大小优化无意义。当需要20种或更多时，新建脚本显得不可取。
2. 当 RoomName 对象数量过多情况下，重复的配置其属性信息是繁琐不可取的。
3. 无论是使用何种与门通讯方式，均需GetComponent<T>()获取对象信息。且因为脚本类名不同，在获取方面上显得这种设计不可取。

 

2）优化性设计 - 似乎好起来了

---

  CSharp 提供了枚举类型的设计。针对枚举类数据信息，进行手动配置参数。值得注意的是默认情况下的Enum的声明与使用仅允许一项是选中状态。在枚举权限卡级别上，可采用如下设计：

public enum IDCardLevel
{
	None = 0,
	LevelOne = 1,
	LevelTwo = 2,
	LevelThree = 3,
	...
}

  别忘了Enum也是可以进行复选设计的，在 Unity 引擎中，以 Tag/Layer 等为典型代表的应用存在。如何实现复选枚举项是当前需要攻克的问题难关。幸运的是，已有人为我们负重前行实现了复选模式并提供了程序指导方案。如以下步骤所示：

步骤一：继承PropertyAttibute类，建立可序列化特性。

public class EnumFlagsAttribute : PropertyAttribute { }

• PropertyAttribute：Unity Technology 针对变量特性提供的类对象。继承该父类对象的类可成为属性特性被使用。（可理解为Unity封装的CSharp特性制作方法）例如[SerializeField]序列化特性，对私有变量公开至 Inspector 面板上。亦或是[Tooltip("")]、[Header("")]、[Space]。

步骤二：自定义 Unity 框架下关于EnumFlagsAtrribute（枚举特性）的序列化内容

[CustomPropertyDrawer(typeof(EnumFlagsAttribute))]
public class EnumFlagsAttributeDrawer : PropertyDrawer
{
	public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
	{
		property.intValue = EditorGUI.MaskField(position, label, property.intValue, property.enumNames);
	}
}

• CustomPropertyDrawer：自定义属性内容。用于修改 Inspector 面板的属性内容。
• PropertyDrawer：用于定制属性内容样式的基类。其将继承于PropertyAttribute的特性添加至序列化队列中。并重新进行属性绘制等内容。
• OnGUI()：绘制属性的方法。
• EditorGUI.MaskField()：创建掩码的显示字段。（是实现复选框的核心内容）
  参考 Unity 中文官方文档。

 
◼ 最终效果：
  在该枚举类型下的脚本仅可使用同一类脚本对象进行重复性挂载与参数配置。解决了因权限级别数量过多导致的脚本类数目增多。在调整数据上更加方便与轻松，减少了代码的重复率。提高整体代码质量。即如下所示：

public class IDCardLevel : MonoBehaviour
{
	public enum Level = IDCardLevel.None;
	[EnumFlags] public enum AllowRoom = IDCardAllowRoom.Everything;
}

  在检索是否选中的情况上可使用枚举属性.HasFlag(枚举具体项)的方式进行判断，

---

◼ 问题点：

1. 仍然未解决房间许可数量增多情况下的配置麻烦复杂情况。
2. 若项目工程丢失.meta数据文件，配置数据将丢失。
    

3）持久化设计 - 稳定数据配置

---

  构思：从数量上房间区域通行证在不断的更新中变多。不利于整体的配置选项，不如反着思考。游戏中的权限卡数量是不会超越房间门数目的。修改 以权限卡许可内容中查找与之匹配的信息（原设想）为 门作为个体对象接收与识别等级权限通行证级别信息行为（新设想）。无论未来，添加何种的类型的门通行规则，都无需更变已有的配置信息。则重新设计后应当是：

[CreateAssetMenu(menuName = "ID Card Config/New Permission Object")]
public class Permission : ScriptableObject
{
	public AreaType Area;
	public List<Level> LevelAllow;
	public string Description;
}

[CreateAssetMenu(menuName = "ID Card Config/New Level Object")]
public class Level : ScriptableObject
{
	public int LevelValue;
	public string Description;
}

  ScriptableObject 是 Unity Technology 提供的数据持久化方法，我们可根据数据类型建立 Level文件夹、DoorPermission文件夹，分别存储对应的 ScriptableObject，当我们想新增一类权限级别，或新增一类门的权限许可，将这类权限直接赋予至对应的资产清单中即可完成。玩家仅通过发送自身持有卡信息，交由门对象自行判断是否允许通过。在逻辑层面上，解决了程序逻辑过于集中于玩家自身的问题表现。

public class RoomBase
{
	public Permission DoorPermission;
}

---

可优化点 ：

1. 使用动态加载配置模式，对应的 RoomDoor 以动态加载路径下 ScriptableObject 资源对象。
2. 拓展编辑器，建立基于EditorWindow的配置窗口，该窗口可访问路径下所有ScriptableObject文件，并具备搜索拥有指定Level的数据对象，或访问数据对象上的Level对象，进行增添查改等操作。亦或是创建新ScriptableObject或其他行为。