虚拟实验室-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>