虚拟实验室-UE版本开发方案调查表
<table>
<thead>
<tr>
<th>作者</th>
<th>QFord</th>
</tr>
</thead>
<tbody>
<tr>
<td>更新时间</td>
<td>2024-7-22</td>
</tr>
<tr>
<td>版本</td>
<td>V0.0.1</td>
</tr>
</tbody>
</table>
<h1>背景</h1>
<p>先前项目负责人召开会议宣布全面转UE，同时在DJ的心签到中也提到了<strong>放弃Unity3d引擎（或准备暂时放弃Unity引擎）</strong>
<img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=4388ac88cc9e193fe25d413ae0c0dae2&amp;file=file.png" alt="" /></p>
<ol>
<li>虚拟实验室的版本的客户端是基于Untiy3D开发的，历时长达8年之久（截止2024年），业务规模十分庞大，故转换为UE版本也需要巨大的开发成本。
转换工时的初步统计（仅包含原有组件的预估工时，不含器材开发工时）：<a href="https://www.kdocs.cn/l/clkLL5AOrpyX">https://www.kdocs.cn/l/clkLL5AOrpyX</a>
> 对于上述的工时评估，我们从现有UE颗粒开发经验来评估觉得是远远不够的。
综合UE的开发成本溢价（相较于Unity来说，更别提美术对UE的陌生了）、开发人员对业务的熟悉度等，预计投入的工时需要再乘以2-4倍。</li>
</ol>
<h1>需求</h1>
<ol>
<li>项目负责人提出，UE版本的器材开发需要兼容Unity版本，并使用<strong>用品编辑器</strong>生产器材。</li>
</ol>
<h1>开发方案</h1>
<h2>1. 兼容Unity版本/用品编辑器</h2>
<p>UnLua和xLua都是用于不同引擎（Unreal和Unity）的Lua脚本解决方案。为了实现兼容性，需要考虑以下几点：</p>
<ul>
<li>API差异：UnLua和xLua在API上有一些差异，需要通过抽象层来屏蔽这些差异。</li>
<li>引擎特性：Unreal和Unity在引擎特性上有很大不同，需要在Lua代码中进行适当的封装。</li>
<li>模块化设计：将引擎相关的逻辑和通用逻辑分开，确保通用逻辑可以在两个引擎中复用。</li>
</ul>
<h3>不利因素</h3>
<ol>
<li>器材的业务开发不能使用蓝图，等于抛弃了UE的一大便捷的特性。</li>
<li>Unity器材的节点是支持重名的，而Unreal是不支持的，会导致依赖节点路径访问的业务出现异常。
因此，Unity端必须改造命名为唯一，在美术原始资源生产阶段就需要修改，预制和代码也需要更新。</li>
<li>需要额外开发抽象层/中间层，解决引擎间的差异性。</li>
<li>器材开发和维护需要考虑双引擎端的多个平台，工作量大幅增加。</li>
</ol>
<h3>总结</h3>
<p>一般说来，考虑公司会恢复Unity引擎技术栈的情况下，上述方案才有价值。
同时，如果Unity版本只是处于维护状态，那么兼容Unity版本就没意义了。</p>
<h2>2. 不兼容Unity版本/用品编辑器</h2>
<p>器材直接使用蓝图+Unlua开发</p>
<h3>有利因素</h3>
<ol>
<li>开发效率最高，符合UE开发的最佳实践。</li>
<li>能够更快的输出UE版本，有更多时间专注于提升表现品相的研发。</li>
</ol>