维塔士Andy Fong：Switch游戏优化经验分享

在今年腾讯游戏学院举办的第四届腾讯游戏开发者大会（Tencent GameDevelopers Conference，简称 TGDC）上，来自维塔士上海工作室的技术总监Andy Fong，分享了任天堂Switch平台上面游戏的一些优化心得。以下是分享实录：大家好，欢迎来参加TGDC 2020，我是Andy Fong，是维塔士上海工作室的技术总监。今天由我来给大家分享一下任天堂Switch平台上面游戏的一些优化心得。我先来介绍一下自己，本人是在2007年加入维塔士上海工作室，在游戏开发编程领域方面已经有超过13年的从业经验了。近年我参与了一些Switch游戏作品的一些开发，包括《最终幻想12：黄道年代》《黑色洛城》《星链：阿特拉斯之战》《生化奇兵：合集》《幽浮2：典藏合集》等等的一些Switch游戏 。在介绍任天堂Switch方面的一些优化之前，想先介绍一下我自己感受到的任天堂的一些，就是开发这个Switch平台的一些理念，还有它的重点。我认为它是着重于它的创新功能，包括把移动平台跟主机合并在一个游戏机里面，实际上是方便它的玩家可以用同一款游戏，在移动跟主机平台都可以玩这个游戏。实际上主机跟移动平台上面，它操作是没有太大区别的，它很容易就可以适应在两个不同的情况底下去玩游戏，然后它的存档也是可以在两者之间共享的。在手柄方面，它投入了新的HD Rumble。实际上就是让它的振动更有触感，也可以通过红外线去检测玩家的手部的移动、还有形状。在多人游戏方面，它可以允许玩家可以两个人用两个手柄，用同一台主机去进行多人游戏。然后也可以在多台的Switch主机之间连线去进行多人游戏，实际上是吸引到很多喜欢本地多人游戏的一些玩家的。但相对来说在这个年代，它并没有投入到当前最高性能的一些硬件到这个主机上面。实际上如果我们考虑把一些PC或Xbox One或其他的一些主机的游戏移植到Switch的话，实际上内存使用是需要有所降低的。然后在游戏性能方面，如果我们要保持在30 FPS这样的性能，那也需要做一些CPU或GPU上面的一些优化。一般来说，对于我们移植一些其他平台的游戏到Switch平台的话，需要在预生产的那个阶段去进行一些优化计划，然后到后期的时候实现这些计划。这里展示了两张图，左边一张、右边一张实际上就是同一款游戏在不同的两个主机平台。上面的截图，你能看出来这两张图有什么区别吗？实际上这是《生化奇兵合集》的Switch平台上面的游戏跟Xbox One平台的游戏，左边这一张是Switch平台，右边是Xbox One X上面的。其实展示这两张图目的是想说我们公司实际上在尝试去稳定Switch平台上面能够保持30帧这样的目标底下，我们还是希望能够保持这个游戏能有跟原来游戏一样的画质，还有游戏性。其他一些游戏可能它们会采用一些别的方法，比方说牺牲一些画质或者是游戏性这样去达到它的性能目标，但其实在我们来说就是有一些过去的一些客户，他是不容许掉帧的，同时他们也要求画质跟游戏性能够达到跟其他的游戏平台一样的，这样的水平。面对这样的要求，实际上我们是需要更高的去做一些代码的优化，还有算法上的优化，还有就是用到这个平台机器的多核心的功能，然后尽量去优化一些比较次要的一些数据，从而去达到这个性能目标。接下来，我会针对我们过去一些项目的经验去介绍一些我们会采用的优化策略。这一列页就是我这个讲座的一个大致的概览。首先我会介绍上面的内存优化这一方面的做一些调查还有优化，然后就是当我们一款游戏进行内存优化到一定水平之后，实际上我们会展开一些CPU跟GPU方面的一些优化工作。我会先介绍CPU的，然后再介绍一些GPU的优化，最后我会谈谈一些对内存CPU GPU这三方面都有一些帮助的一些工具。首先我们开始讲内存优化。刚才也提到了就是如果我们从PC 、Xbox One、PS4这些游戏平台，尝试把游戏移植到Switch的话，很容易会触碰到Switch的内存上限，一旦超过这个上限之后，游戏就很容易会崩溃。如果我们要顺利开发的话，肯定是需要进行一些内存优化的。接下来我会介绍这些分析的工作，还有优化的工作。这里展示一些不同统计的工具，上面这个是一个日志报告的工具，上下面是一个屏幕统计的工具。屏幕统计工具实际上就是我会通过低层内存的一个分配器，去收集到实际上各个模块，它使用到的内存，然后展示在屏幕上面。日志报告其实也是收集这样的信息，但这是通过QA测试或者是一些自动测试Autotest，就是在测试完之后把一些报告产生出来，事后可以让程序员去分析。还有一些专用工具就是包括引擎或者是SDK，这些方面都会提供一些专用的内存分析工具，可以去查找一些内存泄露。除了上面的屏幕统计、还有日志报告之外，我们还会用这样的工具发现一些更深入的一些问题，然后去查找哪里使用了一些内存。通过这些工具，一般来说我们都能够知道整个游戏运行的时候，它的使用内存的分布，然后我们就会开始从大块的，使用比较多内存的那些模块开始制定开发优化的策略，一步步把内存优化下来。接下来我会介绍一些方法，首先第一个想介绍的是一个优化内存分配器的方法。实际上内存分配器是一个所有游戏一般都会使用的一个系统，它是帮助我们从底层去分配一些内存给不同的系统使用的。实际上内存分配器，它会有一些自己的开销，引擎在管理内存的时候，也有一些额外的开销。实际上两者是有一些重复的，所以我们是更推荐于使用一些底层虚拟内存分配接口，去配合引擎方面的一些或者是第三方内存、页面分配器方面的一些功能，两者结合去控制这方面的开销。同时在VRAM的管理方面，我们可以推荐CPU跟GPU能够共享内存，可以达到动态去控制VRAM的分配，这样可以在需要的时候提高VRAM上面的使用，也就是虚拟内存的使用。如果CPU的内存需要更多的话，也可以动态地去平衡。在VRAM的处理方面，我们是推荐用一开始分配比较大的一个内存池，避免后面如果需要分配内存池的话可能就因为碎片的问题，就分配不出来了。接下来是使用一些关于我们对VRAM使用什么样的缓冲，我们是不太推荐去使用一些环缓冲，还有双缓冲这样的一些结构，我们更推荐使用类似于DX的，就是WriteDiscard或者是WriteNoOverwrite。WriteDiscard就是你如果分配一块大的内存，它就直接把过去的一块内存丢弃了，然后重新分配一块新的。WriteNoOverwrite就是你在一个大块的内存里面一块一块小块的去分配，然后是没有Overwrite，没有表达重写的。这样可以减少一些分配内存上面的一些开销，可以加快它的速度。然后是清除一些冗余的资源。如果我们从其他平台转移这个游戏去Switch平台的话，实际上因为其他平台内存比较足够，所以会有一些冗余的资源包括比方说一些不必要的立体声的音频，还有就是渲染缓冲，有时候也是有一些不必要的，可以尝试去把它省略掉。有一些预加载的关卡，实际上在Switch上面我们推荐会用更激进的一些streaming，就是加载关卡的一些策略，我们会更严谨去选取真正需要的一些关卡去加载，如果是非必要的话，我们尽量争取去把它去掉或者是减少它，达到一个内存平衡。常驻贴图，这里说到就是很可能其他的平台，会选择把一些UI贴图或者是一些低层的一些mipmap，贴图里面比较底层的一些贴图会保留在内存里面一直常驻，在Switch上面很多时候是不允许的，我们会选择性去加载这些贴图，只保留当前需要用的一些贴图。关于着色器的二进制文件，我们发现用着色器的编译器去编译之后，在不同的着色器它有可能产生一样的二进制文件。我们在调查里面会争取找到这些重复的二进制文件，确保它的唯一性。还有在打包着色器，二进制文件的时候也希望能够尽量在游戏开始的时候就已经把这些二进制文件打包在一起，然后一起加载。因为如果我们是分布的在不同情况加载这些二进制文件，也有机会产生一些更多的额外开销，我们也是希望减少这些开销的。接下来就是当我们清除掉一些冗余的数据之后，实际上剩下的都是真正游戏需要用的。但这些我们也是争取需要减少它们，包括贴图，一般都是游戏里面占用比较大内存的一个部分，我们会采用ASTC压缩格式，这个格式实际上是你可以看到，最右边的这张贴图就是ASTC的相对于其他的格式，实际上它能够比较好的去保护原来贴图的一些画质、一些细节，实际上也可以允许去调整不同的参数，去对这个贴图进行压缩。可以在保护它的画质的同时，可以达到比较好的一个压缩率。对于一些mipmap，贴图的不同等级，我们会调整最高的mipmap的等级，因为实际上在Switch上面，它的屏幕分辨率已经有所降低了，实际上并不需要去时刻地去保持，最高分辨率的mipmap，我们可以限制它的最高mipmap的使用。后边就是一些其他的一些内存块，包括渲染缓冲，我们可以检查GBuffer的，就是延迟渲染里面使用的GBuffer，就是一个大的缓冲。它的布局是怎么样的，很可能里面是有一些效果是不必要的，可以把一些渲染缓冲给节省掉。动画我们也进行一些压缩，实际上很多引擎都支持动画的压缩，它可以使用一些更激进的一些压缩方法，让这个动画的数据更加小一点。模型我们会检查不同的LOD，有可能有一些LOD实际上是不需要的，我们就直接把它去掉了。我们也碰到很多关卡使用内存过大的问题，其中一个方法我们会拆分，就是把大的关卡，再拆分成两个、三个、更小的关卡，只有当你处于特定的关卡的时候，就加载那个关卡，这样也可以大大的节省使用的内存。上面就大致讲完了几个，我们会做内存优化的方向。一般来说做过这些优化之后，游戏是能够跑起来了，但是有可能还没达到30帧。我们会在GPU跟CPU方面，进行一些优化工作。实际上两方面，他们的工作都需要在33.3毫秒里面完成，面对不同游戏的差异，有时候CPU的工作会多一点，有时候GPU会多一点。接下来我会先分享一些CPU的分析，还有优化的方法。这里就列出了一些CPU性能的分析工具。首先我们会选择采用一些引擎专用的工具，包括双引擎4里面的一个Stat的命令。这里展示的就是一个UE4里面的Stat的命令，列出的一些参数，实际上是罗列了一个CPU里面，各个模块使用的一些时间。我们也会用一些第三方工具比方说Frame Pro，它是沿着时间线的把不同的函数给罗列出来，不同函数使用的时间，也能够很清晰的看出来。实际上Switch平台，它也有提供自己的CPU研究的工具，但这个是受到它的NDA的保护，如果有任天堂开发者帐号的话，可以去了解这方面的工具了。说到CPU的问题，实际上很多时候，我们会联想到draw call太多的问题，这样会产生一个问题就是渲染线程上面投入的时间太长。接下来我会介绍一个优化的方法。在过去开发的经验里面，我们会使用到一个多线程渲染，之前我们开发过一个开放世界的一个游戏项目，因为开放世界看到很宽阔的一个场景，所以drawcall很高。在那个时候，我们也分析了其他的核心，实际上其他核心的使用率是不高的，所以我们考虑采用一个多线程渲染的这样的一个方法。首先就是先考虑单线程。单线程的情况下，实际上CPU负责去产生一些命令缓冲，就是产生一些命令投入到一个命令缓冲里面，最后提交给GPU去进行渲染。改变到多线程会怎么样呢？其实就是我们会研究过Switch平台，它的图形接口实际上是能接受多线程渲染的，我们会给各个线程去产生它独立的命令缓冲。实际上难点是在于一个Setup，就是图片里面有提到Setup，就是设置的部分。在我们渲染每一个draw之前，我们都需要通过一个Setup的步骤，当我们把这些draw分派给所有不同的线程的时候，我们要确保每个线程，每个draw call，它都能有一个正确的设置。所以你可以看到，我们分摊到多个线程的时候，实际上多了一些Setup，就是设置的工作。最后我们需要确保所有这些缓冲，能够顺序的提交到GPU里面，在单线程的情况是一个渲染缓冲，依次提交给GPU。虽然我们多线程，就有很多的渲染缓冲，我们还是要确保它们按顺序的排列，最后依次再提交到GPU那边。这里再提到的一些例子，实际上从单线程去到多线程，其中一个很大的难点就是拆分队列，在单线程里面，实际上在Setup就是设置这个部分，它可以做到一个局部的设置，并不需要全部的参数都刷一遍，它可以局部的去刷。在多线程的时候，因为它拆分了所有的队列之后，有机会它会需要去刷更多的一些参数的。我们可以看看左边的这个例子，实际上你可以看到在它渲染第二个draw的时候，如果把这个draw分摊给另外一个线程去工作的话，在这个draw之前是需要一个Full Setup的。因为实际上它没有准备好，它还是需要做一些设置这些参数的设定。再看看右边这个例子，实际上在第二个、第三个draw之前，有一个叫Partial Setup，就是局部的设定。如果我们把第二个、第三个Draw，把它分派到另外一个线程，我们也是需要做一个全局，就是全部的一个设定。因为很可能这些，如果只做一个部分设定的话，它很可能还是会漏掉一些设定的，这是其中一个困难。我们在开发这个方法的时候，实际上碰到很多问题就是很多状态都没有设置对，就产生了很多显示的问题。后来设置对了，但我们发现这个设置本身，它也带来很多额外的开销。所以后面我们就采用了一个方法，就是我们尝试争取用不同的渲染步骤，去拆分这些任务，去到多线程那边减少一些设置。到最后当我们完成了这个多线程渲染之后，实际上在准备命令缓冲的时间，就从20毫秒减到6毫秒。实际上也是一个很不错的一个提升。后边就进入到另外一个优化，叫图形脚本的原生化。实际上，图形脚本它更多是在主线程那边去执行的。现在越来越多引擎会使用一个图形脚本去进行它的游戏逻辑，包括UE4的蓝图，这些脚本很容易上手，游戏策划也可以去使用。但如果是重度使用的话，很可能会对主线程的性能产生一些压力，因为它调用的函数会比较多，调用栈也比较深。一般来说，我们会采用一些原生化的方法，去把脚本转换成C++代码。也有两种方法，一种是部分原生化，一个是深度原生化。部分原生化就是我们会自己去检查，哪一些脚本是它的性能损耗是比较高的，去选择性的把局部的一些脚本转换成C++代码。深度原生化就是我们会更多的开始去自己实现一些工具，去把图形脚本转换成C++代码。这个当然会达到更高的提升，当然也是会投入更多的一些时间，去开发这样的工具了，在过去的项目，我们曾经有经验能达到10%到20%这样的提升。后边是一个关于声音的优化，实际上声音在现在新时代的游戏，都是很重要的一个方面。我们会先采用一些第三方，就是如果是用第三方去播放声音的话，我们会用第三方的声音库里面提供的专用工具去进行一些性能检查，然后在Switch上面，我们很多时候会使用一些压缩的方法，就是OPUS还有ADPCM。那OPUS这个格式的话，它好的地方是有很好的压缩率，它解压缩的速度也是挺快的，但是有一个问题是声道比较有限。如果声音声道比较多的话，会转移采用ADPCM去播放它们。其实还有另外一些问题，就是关于DSP音效的播放，这些效果实际上是需要采用CPU去进行一些运算的，我们推荐就是把这些效果烘焙到一些声道上面，让它去直接播放，节省一些运算的效率。保护一些关键声音的一些实例，把一些比较次要低优先值的一些声音实例给去掉。或者是把它的频率给降低，就是让它去不要那么频繁地去播放，也可以节省一些运算的时间。对于距离远的一些3D声音的话，可以考虑把它放到虚部。把它放成一个虚部声音的话，可以减少一些运算，只有当它靠近比较明显的时候，才开始去计算它们。上面提到的就是大致我们一些比较很常用的一些CPU的优化，实际上这里还有更多的CPU优化，如果以后有机会，我们可以再多交流这方面。接下来我会介绍GPU方面的一些性能分析的方法，还有优化的方法。GPU性能一般会跟着色器的效率有关，也会跟每个渲染命令所填充的像素会有一定关系。对于Switch的主机模式，还有掌机模式的话，它的主机我们一般会推荐使用1080p这样的分辨率，掌机会使用720p（分辨率）。也是考虑到它在这两个模式底下的GPU的性能这样去定义的，确保它去能够在不同的模式都能达到30帧这样一个稳定的帧率。接下来就谈一下一些分析的工具。一般来说，我们会采用SDK提供的一些API去获取GPU里面不同步骤的渲染的时间，把它罗列在屏幕上面，就像这个截图上面一样，也会采用SDK提供的专门的工具去研究GPU上的问题。这个方面也是，如果有任天堂开发者帐号的话，是可以去多了解这个工具的。我们对这两方面收集起来的数据，我们进行一下对比去确认最终的GPU问题在哪里，有时候我们也会采用个别去把某一些效果关掉、打开，这样去对比耗用的时间，这样可以确认某一些效果它所耗用的时间。接下来是一些优化，一般来说我们会考虑去除分支对于着色器的程序，会去除一些分支。实际上分支语句是对于无论是CPU或者GPU，都是一些难点。因为你没有办法去判断程序的流向，着色器上面的一些分支它会被平坦化，意思就是说，它分支的两边都会执行，最后会选择其中一个结果，但是如果它们的工作量不平衡的话，也会影响到它在GPU上面执行的并行性。所以我们推荐还是尽量争取去移除掉这些分支。这个页面，我们展示了一些方法。首先第一个是一个替换写法，就是使用一些特殊语句，比方说叫saturate还有lerp这样的一些语句，可以很好地去替代原来的一些分支的语句。也可以使用一种条件编译，就是把不同分支的代码，把它组织成不同的着色器二进制文件，然后在C++那边去进行判断。当你可以能够判断每一个draw call，它实际上只用到某一个分支代码的时候，你就可以这样去做。在C++那边就已经判断出来，使用某个特定的着色器的二进制文件，执行二进制文件，避免你每一个像数都需要去判断。做这个分支的语句，这样对性能会有相对比较好的提升。下一个是一个叫图块缓冲的一个优化方法，这个是属于Tegra GPU的一个，自己有的一个功能，GPU可以接受把一些绘制的请求收集起来，再把渲染缓冲划分成很多的图块，一个一个图块的这样去播放这些渲染的请求，这样的好处就是当你在一个图块上面去渲染的时候，实际上它在访问一些帧缓冲的时候，命中cache的机会会大大提高的.当你能够去从cache里面，就是缓冲里面去获得这些数据的时候，它能够大大地加快你的访问速度。这个使用场景是什么呢？就是当你有很多大面积的粒子，实际上这个图展示的就是一个很多的粒子效果。这些粒子效果，都需要去访问帧缓冲。一般来说，我们尝试过把PS2的游戏移植到Switch，实际上PS2上面VRAM的带宽还是比较高的，去到Switch上面我们需要一些优化，我们发现这个图块缓冲是不错的一个选择。在一些情况，我们会达到一个五毫秒的提高。但需要注意的是这里面有一个收集渲染命令，还有播放的一个步骤，就是当如果是我们去渲染的一些单元，它使用比较大量的顶点属性，还有频繁地切换这些属性的话，建议还是不要太多去使用，因为可能会在收集跟播放会增加一些开销。接下来是关于美术数据，美术资源的一些优化一般来说，我们会在所有的GPU的手段都没有太大的效果，包括动态分辨率或者是刚才说的图形缓冲、图块缓冲，这些都没有太多的帮助的情况下，我们会考虑对美术资源进行一些优化。这里有一张截图，是《幽浮2》的一个基地的截图，实际上它展示了很多不同的小房间，在最开始的时候，所有的小房间都是充满了很高精度的细节的。实际上我们发现，当镜头拉得比较远的时候，并不需要对所有房间都能够提供这么高的细节。我们就对每个房间都创建了LOD的模型，实际上就是一个不同层值、不同精度的一些模型，可以在拉远的时候，我们实际上可以采用一个相对精度比较低的模型，实质上在Switch的屏幕上面是不太能看出这个区别的。除了这个模型之外，就是关于粒子效果，我们也是有一些游戏会采用粒子的LOD去渲染粒子，也是得到一些不错的优化。其他方面还有就是，对于一些比较不明显的地方，我们可以选择，选择性一些对象就不去做投影，或者是降低它的密度，这些都可以去节省一些GPU的开销。这些就是我想分享的一些GPU方面的优化，还有过去的一些有用的优化。接下来就是想讲一些帮助我们优化的工具，上面的一些工具是能够帮助我们的GPU、CPU，还有内存的优化都能够产生一些帮助的。包括检查掉帧的一些工具，就是当你游戏跑到某一个位置，突然有一个比较严重的掉帧了，它会在屏幕展示一个警告，像warning frame-drop这样的一个显示，很容易就被QA或者是开发人员给检测出来，马上就开展一个调查去了解为什么会掉帧了，也会去专门给某些特定敌人或者是技巧去做一些功能，就是专门去处罚这些敌人，还有技巧，方便我们去重现一些特殊的一些掉帧问题。对于模型的话，我们会采用一些第三方的一些软件，比方说Simplygon还有Houdini，这样去制作一些低模的LOD模型去替换那些高模模型。自动测试，我们很多时候，晚上都会让编译机器去自动去跑游戏，然后收集一些内存，还有性能的一些信息，这样可以让开发人员去调查这些问题，节省QA的一些测试的成本。以上其实就大致是我想在这个讲座介绍的一些内容了。做一个简单的总结，实际上讲这些分享，我想表达的一个核心的目标，其实就是我们是希望能够在保护原来游戏的画质，还有游戏性的情形底下，我们还是能够对Switch游戏能够达到一个稳定的帧数，能够加强提高玩家的一个体验。然后怎么做到呢？就包括三方面，首先就是内存我们需要优化到位，包括一个分配器我们要时刻关注它额外的开销。对于一些冗余数据，我们会检查是不是有一些渲染缓冲可以节省的。常驻的贴图是不是有一些可以变成非常驻了。对于一些大的数据资源包括贴图，我们采用了像ASTC这样好的一个压缩的技术。对于CPU方面的优化，就是多线程渲染可以帮助减轻渲染线程的压力，在主线程我们会对图形脚本进行一个原生化把它转换成C++代码。声音方面，我们推荐使用一个叫OPUS这样的一个压缩格式。对于GPU的话就是，我们对着色器会进行一个去除分支的这样的一个操作，比方说用lerp这样的一些语句去取代原来的一些分支，这样的一个语句对于图块、图块缓冲可以很有效的去优化。一些粒子效果，特别是大面积的一些粒子效果，到最后我们会对美术数据进行一些选择性的这样的优化，包括采用一些LOD或者是关闭一些投影效果，这样去达到一个降低GPU消耗这样的目的。我们也会采用一些工具包括检测掉帧的工具、自动测试的工具，去尽量给开发人员提供一些有用的信息，去加快他们的一个优化工作。好，以上就是我想介绍的这次演讲的内容。Q&A环节1、从技术层面来说跨平台适配的难点在哪里？如何应对？答：实际上跨平台适配来说，我们会遇到很多可能。第一方面是底层系统的一些适配，包括内存I/O 输入输出，还有它的一些渲染器的适应。因为其实不同平台，它对底层的一些接口会有自己的一套实现。渲染器，渲染的接口也是不一样，我们要进行一些适配，就是参考原来的它是有用到哪些功能了，然后在新平台需要怎么去实现这些功能。第二点，实际上就是优化。这个演讲其实我们讲了很多优化，其实不同平台它的性能的水平是不一样的，很可能我们在移植适配到另外一个平台都是会需要进行一些优化，其实就是处理的方法，就是我们提早的去定义一个优化的策略，提早去对原来的游戏进行一些分析，哪些地方会成为一个优化的难点，我们预早去进行一个计划怎么去达到优化的效果。还有其实就是一些平台独有的要求，实际上不同平台它对一个游戏发布在它的平台是有独有要求的，比方说有一些平台对多人游戏它的安全性是有独有的要求，这样的话我们需要越早去安排一些工作，去对服务器端或者是客户端都要进行一些调整，这样去能够符合到他们专门的一些要求。这些就是关于跨平台适配上会遇到的一些难点。2、一个图形脚本原生化，PPT里面有提到的实际上是一个不错的CPU优化，想问就是你们在做这个原生化的时候，会遇到哪一些困难？答：其实原生化它能带来很高的、很好的一个性能优化，但确实是有一些困难。首先是一个工具的适应性，因为一般来说它工具并不能完全百分百的，能够对所有的不同类型的脚本都能够适应的，很可能是需要一步一步去调整，包括脚本方面可能要调整，工具方面也可能要有一些调整，可以说是一个磨合，慢慢会达到一个完全适应，就可以全面的去把这些脚本都转化成另外一种类型。但还有一个转化正确性的问题，就是我们每当转变了一些图形脚本到C++，做了一个原生化，其实都会需要去验证，这样的脚本它的逻辑是正确的，有时候因为一些时间点的问题，它是按时间去触发某些事件的，因为时间可能会变化，因为你转移到C++上面去执行它，可能那个时间点就不一样了，也会产生一些问题，我们需要去适应这些问题。还有第三点，就是一个脚本方面会更改的问题，因为有时候我们会并行开发，客户也是不停地在更改脚本，每次更改脚本之后，我们原来可能能原生化的，然后后边又产生问题了。我们又要去验证一遍，确保它都能够很好的原生化变成C++的代码。基本上这些就是这方面会遇到的一些难点了。3、内存 CPU GPU方面，Switch游戏如果我们从其他平台移植到Switch的话，还会需要做哪些方面的优化呢？答：第一点，就是一些极端情况。虽然我们会实现一些比较通用的优化，在大部分的情况游戏都能够在30帧上面去运行。但还是会有不少的极端情况，就是特别多的VFX、特效。特别多的场景、物件。实际上就是针对各种各样的极端情况，我们需要更深度地去研究个别的case，制定更激进的一些优化策略。实际上很多情况都是需要更多的精力去优化，才能有可能达到性能的目标。还有一点就是加载时间，实际上加载时间就不单指在Switch了，在各个平台都会需要有一定的优化，因为我们都在跟时间竞争，所有的玩家都希望能够瞬间就进入到游戏里面。这方面的话，一般来说我们要分析加载的过程里面会加载了哪些数据，也要看有没有一些调整的方法。有时候我们调整一些加载的顺序，也可能会有提高或者是把一些资源变成常驻的，也是有可能有提高。还有就是选择性的去优化部分的数据来提高加载的速度，其实安装包还有下载包这些，一般来说发行商会希望追求能够减少的，因为这个会牵涉到比方说Switch上面有卡带，那我用哪一个尺寸的卡带呢？还有就是如果要下载的话，要下载多少数据到它的Switch的机器上面，其实也是对各种这些包，我们会进行一些分析。比方说像一些视频，在游戏包里面很多时候有一些视频，我们可以选择考虑改变它的分辨率或者是去降低它的比特率，这些都有机会去很好的掌握它的大小，控制这个安装包或者下载包的大小。其实这些就是一般来说我们都会除了CPU GPU，就会考虑做这些类型的优化。