深入了解 Unity DOTS Sample (一): 代码框架 & 工具 & 开发模式

海田1 · 发表于 2020-12-15 09:53

<< 返回目录
代码框架 & 工具

相比于 FPSSample, DOTS Sample 进行了更加 package 化的更动, 无关乎游戏本体的代码放在了 Unity.Sample.Core 等以 Unity.Sample. 命名的文件夹, 而游戏本体则放在 Assets/Scripts 目录下, 另外, 因为 DOTS 官方鼓吹将运行时和编辑时区别对待, 因此几乎每一个功能都分为Runtime 和 Authrong 两个部分, 比如 Unity.Sample.Core 和 Unity.Sample.Core.Authring, 在编辑器里面用到的东西都能在 xxx.Authring 里找到. 下文中我会将类似 Unity.Sample.Core 和 Unity.Sample.Core.Authroing 这样较为独立的存在称之为一个模块, 而 Assets/Scripts 里面的代码称为游戏代码.
首先简述一下每个模块各自主要都干了些什么.

Core

ConfigVars

Console

DebugDisplay, DebugOverlay, GameDebug

GameTime:

PrefabAssetRegistry:

Game

针对本游戏,

Ability

Animation&Animation Source

Audio:

Effect:

GameBootStrap

Health

HitCollider:

Part

Item & Inventory

Player:

BaseCharacter

Character

Abilities

Terraformer

Editor Tools:

可以看到, 这些近似于 package 的内容使得拿来主义变得更加容易, 甚至不排除未来部分模块将被打造为官方的 package 的可能性.
游戏相关代码(Scripts 目录)
这里包含了游戏相关的代码, 如果你要开发 FPS 游戏, 那么这里的部分内容很容易可以拿来复用, 依然按照目录简述一下主要内容:

Game:

Character

Chat

Core

Frontend:

GameMode:

Movable:

ServerCamera:

Teleporter

Turret:

Main:

Networking:

Generated

V2:

Render:

Utils:

开发模式

这里先预先介绍一下在 DOTS 下开发的常见编程模式, 这样有助于理解项目具体功能的设计过程.
ComponentSystemGroup
Netcode 覆盖了 entities 默认提供的 SystemGroup, 你可以随需取用他们, 不过更好的办法是按照大的逻辑模块来自行定义所需 SystemGroup, 比如 DOTS Sample 里的  Abilities 模块就定义了如下的 SystemGroup 结构:
[DisableAutoCreation]
public class AbilityUpdateSystemGroup : ManualComponentSystemGroup

[UpdateInGroup(typeof(AbilityUpdateSystemGroup))]
[DisableAutoCreation]
public class BehaviourRequestPhase : ManualComponentSystemGroup
[UpdateInGroup(typeof(AbilityUpdateSystemGroup))]
[UpdateAfter(typeof(BehaviourRequestPhase))]
[DisableAutoCreation]
public class MovementUpdatePhase : ManualComponentSystemGroup

[UpdateInGroup(typeof(AbilityUpdateSystemGroup))]
[UpdateAfter(typeof(MovementUpdatePhase))]
[DisableAutoCreation]
public class MovementResolvePhase : ManualComponentSystemGroup

[UpdateInGroup(typeof(AbilityUpdateSystemGroup))]
[UpdateAfter(typeof(MovementResolvePhase))]
[DisableAutoCreation]
public class AbilityPreparePhase : ManualComponentSystemGroup

[UpdateInGroup(typeof(AbilityUpdateSystemGroup))]
[UpdateAfter(typeof(AbilityPreparePhase))]
[DisableAutoCreation]
public class AbilityUpdatePhase : ManualComponentSystemGroup
可以清晰的看到代码执行的顺序, 同时以模块化的方式避免使用传统 Unity 的 Script Execution Order 带来的全局耦合和混乱, [DisableAutoCreation]则让你能精细的控制相关系统执行的环境(比如区别对待client/server)
功能模块
以角色移动功能简化后的代码为例来说明功能模块通常的实现方案, 具体的解释附在注释当中:
// 这里的 class 主要是充当命名空间的功能.
// 一个功能模块通常不止一个 ComponentSystem 或者 Data 结构, 这样就避免了他们的名称过长的问题.
public class AbilityMovement
{

// 通常移动功能会允许设计师在编辑器里调整移动速度等参数, 需要导出到编辑器的 IComponentData 都命名为 Settings 并支持序列化.
[Serializable]
public struct Settings : IComponentData
{
      ...
}
// 将 PredictedState 和 InterpolatedState 区别开来有两个目的
// 1. netcode 的 ghost 默认设置粒度是基于 IComponentData, 这可以免去
// 2. 从名称上可以提示你在实现时要不要增加客户端预测的检测代码.
public struct PredictedState : IComponentData
{
      [GhostDefaultField]
      public LocoState locoState;
      ...
      // 别忘了 C# 里可以自由地在 struct 添加方法
      public bool IsOnGround()
      {
         ...
      }
}

public struct InterpolatedState : IComponentData
{
      ...
}
// 多个 System 在代码里的位置相同, 但是执行顺序则由 Group 来确定.
[UpdateInGroup(typeof(BehaviourRequestPhase))]
// 虽然这里指定了 DisableAutoCreation, 但你在初始化过程并不需要初始化该系统, 而只需要初始化 BehaviourRequestPhase 即可
[DisableAutoCreation]
[AlwaysSynchronizeSystem]
public class IdleUpdate : JobComponentSystem
{
      protected override JobHandle OnUpdate(JobHandle inputDeps)
      {

      }
}

[UpdateInGroup(typeof(MovementUpdatePhase))]
[DisableAutoCreation]
[AlwaysSynchronizeSystem]
public class ActiveUpdate : JobComponentSystem
{
      protected override JobHandle OnUpdate(JobHandle inputDeps)
      {
         inputDeps.Complete();

         var updateJob = new UpdateJob
         {
            time = GetEntityQuery(ComponentType.ReadOnly<GlobalGameTime>()).GetSingleton<GlobalGameTime>().gameTime,
            // 尽可能使用不同的 entity 来&#34;存储&#34;数据, 使用 GetComponentDataFromEntity 来访问 entity 之间的 &#34;关系&#34;, 这样能有效地拆分耦合的代码.
            playerControlledStateFromEntity = GetComponentDataFromEntity<PlayerControlled.State>(true),
            ...
         };
         // 本模块只需要简单声明 Settings, 引用其他模块的数据结构时则需要使用 &#34;全名&#34;
         Entities
            .ForEach((ref Ability.EnabledAbility activeAbility, ref Ability.AbilityStateActive stateActive, ref Settings settings, ref PredictedState predictedState) =>
         {
            ...
         }).Run();

         return default;
      }
}
}
从这个简短的例子就可以看到 ECS 架构的优势所在, 和 MonoBehaviour 相比, 整个过程中, 我完全不用关心我的 GameObject 是谁? 需要如何设置回调函数? 是否有其他代码访问我的类产生副作用? 所有的代码只需要关心两件事: 1. 系统需要读写什么数据 2. 系统的执行顺序是什么
数据的初始化通常交给编辑器端的 GameObject/Prefab, 这和传统的 Unity 开发没什么两样, 这被称为 conversion workflow, 通常你需要编写一个这样的 Authoring Component:
using Unity.Entities;
using UnityEngine;

// 现目前的 SubScene Workflow 还不够完善, 当你无法触发自动 Convert 的时候, 可以尝试更改这里的版本号
[ConverterVersion(&#34;filod&#34;, 20)]
public class AbilityMovementAuthoring : MonoBehaviour, IConvertGameObjectToEntity
{
// 这里你可以预设一些数据
public AbilityMovement.Settings settings = new AbilityMovement.Settings {
      playerSpeed = 5,
      ...
};
public void Convert(Entity entity, EntityManager dstManager, GameObjectConversionSystem conversionSystem)
{
      // GameObject 和 Entity 并非一一对应的关系, 你可以自由设计运行时的 Entity 结构
      // Authoring 组件的设计则主要考量设计师的方便.
      dstManager.AddComponentData(entity, new Ability.AbilityTag { Value = Ability.AbilityTagValue.Movement });
      dstManager.AddComponentData(entity, settings);
      // 这些数据无需暴露给策划
      dstManager.AddComponentData(entity, new AbilityMovement.PredictedState());
      dstManager.AddComponentData(entity, new AbilityMovement.InterpolatedState());
// setName 可以方便在 Entity Debugger 查看和调试, 但是在最终构建中并无用处
#if UNITY_EDITOR
      dstManager.SetName(entity,name);
#endif
}
}
在代码结构上 Authoring 组件和 Runtime 组件是完全分离的, 这是因为在构建后的程序里, 你完全用不上Authoring 组件的 Assembly, 因为这些都被存储在 Entities Cache 里了.
至此, DOTSSample 的整体概念已经介绍完毕, 后续文章里, 我会详细介绍重要的模块的设计和实现过程.

		自动登录	找回密码
密码			立即注册

[笔记] 深入了解 Unity DOTS Sample (一): 代码框架 & 工具 & 开发模式