TGDC | 腾讯互娱天美杨拓：如何打造动态游戏世界？

GameLook报道/8月14日至8月17日，由腾讯游戏学堂举办的2022腾讯游戏开发者大会（Tencent Game Developers Conference，以下简称TGDC）将正式举行。

大会以Inspire Six Senses为主题，汇聚国内外顶尖游戏从业者以及学界专家学者，以激发游戏的创意力、想象力、洞察力、科技力、影响力和凝聚力，共同拓宽游戏产业的边界与可能性。

在8月15日的艺术专场论坛上，腾讯互娱天美L2工作室技术美术专家杨拓，进行了题为《打造动态游戏世界》的分享。

以下是分享实录

杨拓：各位听众好，我带来的分享议题是《打造动态游戏世界》。我是来自腾讯互娱天美工作室群的专家技术美术师，我的名字叫杨拓。我大概是在2017年加入了天美工作室群，首先是参与了天美L1的《王者荣耀》的项目，接下来参加了天美J3《使命召唤（手游）》的BR玩法的攻坚，最近几年回到了天美L2工作室，主要是负责天美L2工作室几款新项目技术（预研）的工作。

2019年，如果大家有印象的话，当时我是作为天美技术中心的技术美术师，分享的基于程序化生成技术，开发开放世界游戏场景制作的经验。几年过去了，我也是想基于这几年的工作总结和推进，把自己一些工作状态和工作经验做一个分享。

打造动态游戏世界的分享，大概分为三个部分。第一部分，是打造动态游戏世界的动机和想法；第二部分，讲的是如何打造动态世界，所需要做的一些技术准备；第三部分，我们在运行时支持动态游戏世界做的技术储备和实现方法。

下面分享正式开始。首先介绍一下我们为什么要做动态游戏世界的支持，以及在实现想法和设计的一些思路。

打造动态游戏世界的目的是什么呢？大家也清楚我们的核心目标，其实还是希望能够实现一个有沉浸感、可重复游戏的游戏场景，为什么要这么做呢？也是因为当前的大环境下，首先玩家对游戏的品质要求越来越高，而玩家的胃口和眼界放开以后，对每一款游戏保持的耐心其实是很有限的。同时也需要我们提供的游戏有一定的尖叫度，有丰富或经常更新的内容来吸引玩家的关注，这对游戏内容的开发质量和更新频率有一个很高的要求。

在现在降本增效的大环境下，这对于不少天美工作室来说不是现实的。我们的想法是在有限的AAA资源和玩法的基础上，通过一些动态的变化，来实现重复的可玩性。

所谓的动态，我们分为三个特性。首先是支持游戏品质与沉浸感的真实性，其次是重复可玩、有一定随机性，也就是可变形，最后需要有游戏的交互性。

接下来我也基于这三点，简单展开一下我们到底要做哪些事情。从真实性角度讲，作为一个真实的游戏世界，需要有一定的品质和沉浸。这里的“真实”并不是照片真实，而是要符合世界观的真实。

一个真实的世界，从顶到底的大概定义，比如有真实的时间和天气。如果它是一个城市，应该有一套符合世界观的城市搭建的结构，在城市里，有一个真实运作的交通网络和行人系统，这叫一个完整的系统。

而可变性，是这套动态世界的核心，所谓的可变也就是游戏世界的结构是可以变化的。因为大家也清楚一个游戏的可玩点，在于它的游戏体验和基于游戏体验的叙事和任务系统。

叙事和任务最基础的点就是时间、地点、人物，也就是所谓的动态的三个核心。首先在一个可变的时间框架内，不管是场景的结构和表现，还是人类之间的关系和属性，都是可变的。在这些可变的基础上，来实现一个可以重复、可以变化的叙事体验和任务体验。

第三部分也就是游戏性的交互。游戏的交互，我们把它从最直观、最即时反应的一些动作反馈，到和场景物件的交互，以及一些任务系统的触发。

这些任务系统的触发，通常是被动的，而且是延迟反馈的。意思也就是说，平时的移动是所见即所得，当我们的一些移动或行为影响到世界的变化时，更多是隐性的，或者很长一段时间你才会发现自己的行为对整个世界线产生了一定的影响。

定义完动态以后，如何实现动态的方案呢？

我们知道很多游戏都是基于EPIC的UE5引擎开发。包括去年Unreal把它们一款开放城市的Demo，也就是《黑客帝国》的资源完整地开源了。它实现了大量的静态解决方案，从一个城市的搭建到它的车辆、它的行人整套系统都是实现了。

我们如何去实现动态的世界呢？以《黑客帝国》的资源作为实例来讲解一下我们的动态有哪些。

首先整个场景结构，大到建筑的轮廓或街区的变化，小到一个砖块和材质都是可变的。因为整个场景的动态结构可变，连带街道、车辆的行为、走向和交通系统也是可变的。随着车辆的变化，以及场景的变化，街道上的行人规则也会变化。

场景的动态也会使它产生一定的应激反应。我们的动态实际上就是大型场景从表象到结构的动态操作，以及在这种动态操作的基础上，我们车辆和行人的行为，以及他们的反馈是否能随着场景的变化，一直保持逻辑的一致性，其次我们也会从策划和美术角度来规划，我们的动态要解决的问题。

大家知道策划更多的是确保一个游戏的好玩或游戏性，而美术决定了这个场景是否好看，也就是它的表现效果。从策划角度我们总结下来，就是它在动态下的逻辑一致性，而美术表现就是在动态下面表现的一致性，当然这个前提都是在一个高效率，而且逻辑或者表现正确为前提。

基于这些需求，我们知道UE5原生提供了很多基础支持，大家也清楚一个开放世界肯定有一定的LOD或一些分层的渲染，以及逻辑优化的逻辑。

比如UE5原生的World Partition技术，还有AI相关的技术，以及ECS的优化技术。那么在这些优化策略的基础上，它还提供了大量的GI渲染的特性。

有了这些特性，我们的动态是不是完全实现了呢？我们感觉在这个基础上，还要做很多的事情。接下来简单介绍一下我们如何在天美工作室群积累的技术栈下，在UE5基础上对动态游戏世界的支持进行了改造。

我们引入了数字场景的概念，它和之前理解的数字城市是比较近似的。或者元宇宙大家了解的数字孪生技术，这张图从资产的生产、逻辑的维护、玩家体验的反馈，这是一个塔形结构，一级级实现数字场景的表现效果和逻辑效果。

通过这个概念，我们也是基于实例，把《黑客帝国》进行了拆解，它也是分为三层。比如组成场景的建筑资源、车辆资源和行为资源，这些我们会把它叫做资产层。作为一个数字场景，这些资产层都是在数字场景的逻辑和表现层之下进行调度的。

而我们真正要实现的，更倾向于上面的两层，也就是我们的逻辑层和渲染表现层，特别是逻辑层部分，因为它才是数字场景最核心的地方，当我们把逻辑层进行完整实现，并把逻辑解释成表现的时候，最终的动态世界距离我们就越来越近了。

也是因为这点，我们要解答两个核心的技术。我们理解在不同的粒度下，如何保证世界逻辑和功能，以及效果的一致性。这点确定了整个游戏在动的时候，它要能够随时确保它的动态效果是正确和统一的。另外一点，就是让场景更快捷地运作和操作，而且在操作后，可以很快反馈操作结果。

在这两个基础上，我们以一套做游戏的方式，必然是它的编辑状态和运行状态。在编辑状态下，就是要把它的表现、逻辑和优化策略准备好，同时要确定一套编辑状态下，这些技术的管理和呈现的能力。接下来把这些能力平移到运行状态下，确保在运行状态下这些属性也可以很流畅，完整一致性地运行。

上面讲完以后，我们首先要做的是什么呢？是一个动态世界可改变的一个最小单元。为了定义这个最小单元，我们引进了两个概念，和海外的AAA公司，特别是和育碧这些大厂合作中引进了一个叫T.D.G规则，它就是场景资产在设计和摆放上的规则。

核心目的无论什么样的资产，一旦按照T.D.G的规则进行设计以后，它怎么进行组合、怎么进行拆解或移动和摆放，都能满足它的要求，这点就和我们的数字场景里面所讲到的原子化模块功能非常接近。

设计的想法解释清楚以后，就是工程上的想法。工程上我们引入了原子化的设计这个概念，这在网页设计和很多项目设计里都有应用，我们也是把T.D.G规则基于原子化设计做了一个整合，得到的就是最小粒度的原子化模块概念。

这里做一个简单介绍，场景里的每一个砖块和模型资产，它以前只有美术资产。而我们把它赋予原子化的设计以后，它除了美术表现，还赋予了它技术和设计上各方面的规则。特别是在T.D.G规则的加持上，确保了这个资产无论是渲染效果、渲染优化、美术效果，不管这个模块放在哪，都能维持它的功能完整。而且当这些模块进行组合和摆放以后，也能确定一个更大规模、资产功能的完整，和性能、渲染效果的正确。

按照刚刚所说的，我们对整个游戏的动态从局部到整体进行了设计，刚刚讲到了游戏世界以建筑为例，从单个的墙面到一个更大规模的建筑，甚至一个街区都有不同的变化方式。在不同的变化方式下具体怎么变、怎么反馈变化，其实不管在技术上还是表现上都是不一样的。

我们也是基于原子化模块来实现了，不管它是以单个建筑，我们把它叫做站位器或者Place Holder，或者是以建筑为单元、叫Prefab，或者更大的单元叫Zone，无论怎么操作，都能满足整个功能的完整性。

就像在这个空间里，无论是移动一个街道也好，还是一个局部小的范围也好，它的功能无论怎么变，应该都是保证功能和渲染效果的支持。在这个基础上，通过一些更简便的方法把功能进行组合，就得到了一个动态的场景。

如何更简化地修改和改变这个世界呢？大家应该也许比较熟悉。其实，就是我们后面所要讲的程序化生成技术，而我们的程序化生成跟传统程序化生成不同的地方在于，我们可以叫做动态或运行时的程序化生成，它和传统的基于Houdini的程序化生成的差异在哪呢？我觉得有以下几点。

首先，传统程序化生成生成的是美术资产，而我们生成的实际上是满足T.D.G规则的一个带有玩法、带有技术优化，以及美术资产的游戏内容，这是第一点。

第二点，传统的游戏化生成，可能是一个瀑布式从0到1的生成过程，而我们的程序化技术除了生成以外，还要起到管理跟整合的作用，就好像下面的视频，它需要的是把一个、几个简单的Box变化组合成的场景，通过提取它的轮廓线和一些特征属性的方式，最终组合成一个整体的建筑，然后再在这个整体的建筑里面由局部或整体进行改变。当左侧的建筑轮廓属性发生变化，右边的场景效果也会在运行时发生变化。

这样基于程序化生成技术，我们就得到了一个完整的动态游戏系统的设计的思路，这也是我们一个动态游戏系统的设计导图。从下面可以看到我们的顶层，对整个数字场景结构管理，通过一个运行时的程序化生成技术来进行操作的，它根据不同的资源类型，可以是一个挂在服务器上的Houdini，也可以是一个UE4服务器上跑的一个逻辑。

通过数字场景系统的结构，来管理每一个原子化模块，最终确保我们的游戏场景不管如何动态变化，游戏的内容、玩法、特性都能持续保持不变。

第一章的内容大概就是这样，里面介绍了我们想做的一些想法和思路，接下来的两个章节，我会针对性介绍一下，我们是如何准备和搭建这些资产，也就是在编辑状态下，如何设计我们的资源模式，设计我们的原子化模块，以及T.D.G规则。第二部分则是简单介绍了目前的几个做得比较好的例子里面，它是如何在运行时去支持动态效果的。

第二部分，做动态游戏世界所必须的资源与技术储备。

之前介绍了数字场景的概念、动态的概念，资产和技术要怎么准备，才能更好地让他们在运行时支持动态，这里面根据前面的章节，就两个核心问题展开介绍。

首先需要在不同的场景粒度下，都能确保动态的功能一致性；第二，整个场景的动态如何高效地调度、管理和维护。

先讲第一个点，也就是如何确保一致性，如何去设计原子化的模块设计，来展开我们的分享。

左侧是原子化模块的截图效果，它也是基于蓝图的概念，把大量的美术资产按照组件的方式封装成了各种最小的原子项。而右侧是从事程序化生成的方法，把左侧的这些原子化模块进行整体的展示组合和管理的流程。

先介绍一下我们的原子化模块。这里面是我们尝试的一个场景搭建的流程，上面就是一个大型楼房里的资源，每一个资源我们定义为一个最小的原子化模块。它和整个建筑的关系，其实就是一个程序化生成的组合关系，每一个场景，例如这个门有它渲染或技术上的特性。

如果它是一个门，有它远处的剔除方式；而从玩法上讲，有它的物理交互，有它开门的标签设置，以及可攀爬的信息；在美术效果上，有材质、有贴图。根据不同的资产，它所处的场景位置和结构的不同，这些属性肯定有很大的变化，如果是建筑内的场景，它的剔除策略肯定是不一样的。

但是我们现在也有一个问题，就是如果大家用过UE4会发现，刚才讲到所有的设置处于整个场景的各个部分，有些是在它的材质编辑器里面，有的是网格编辑器，有些是优化的设置面板里。这样的话，我们不可能把大量的设置存储于各个地方，所以我们需要有一个载体，它就是蓝图的BP，通过这个蓝图BP里不同的组件，来保存这些设置。

最后得到的构造这一个物件它在整个场景资产上，或者渲染优化上的特性，它在交互、在玩法上的特性，以及它在渲染优化上的特性。

一个墙砖或建筑的墙面有这种特性。我们会把它进一步拓展，例如在上面的图里面，建筑的结构就是一个墙面的效果，还有场景里面的树木，它的逻辑和交互肯定不一样。像天空、河流、地形的T.D.G规则，必然跟建筑的规则也是有差异的。

我们也是根据整个场景结构，在建筑系统的设计基础上，把整个T.D.G做了一定的扩展，来确保整个场景数字的原子化模块都能支持我们程序化的管理，以及这些数字化功能的一致性。

单个模块有了以后，就是怎么对场景大量的模块进行大规模的组织与管理。

首先，我们的原子化模块它的组合，并不像一些游戏里面是随机搭建的。首先还是以建筑为例，建筑的模块它其实有一定的搭建规则，哪些建筑做基底，哪些建筑怎么搭，或者是横向的组合关系还是竖向的组合关系。

就像图里的神殿也好，或者是现代建筑也好，不同的资产有它的组合关系。这些概念也是程序化生成里面很重要的一点，除了组织外，就是空间结构的概念。

利用有些资产，比如室内的建筑，比如我们的灯、椅子依赖于地板、墙面或房顶，它有了这些关系，它跟其他的资源就是一个附加的关系。有了这样大量的关系以后，我们的程序化才能更好地对场景进行一个变化。同时在变化以后能进行快速地解析，确保我们的变化和呈现都是满足性能要求最轻量的方法。

基于这些概念，以下面的例子为例，如果要对一个村庄进行修改的话，通常有以下几个维度，我们改的是一个建筑的结构，也可能改的是一个墙面的材质，甚至因为物理破坏，影响的是某几块砖的材质，我们的改变应该从最低的粒度向最高的粒做转化，应该都能支持才可以。

为了达到这个目的，我们就是要实现一个更高维度、或更全能的场景调控能力。基于这个，我们还是把程序化生成技术进行了一定的优化，以及跟引擎进行了一个内建的管理来进行开发。

大家也知道，整个游戏场景的制作和管理，从传统的手搭到Houdini的PCG ，到最新GPU的PCG，每一种方式有它的优势。手工搭建美术更好搭建，会更灵活，而基于Houdini的程序化，通常由TA或美术主导开发，而基于物联网的CPU和GPU的PCG是由技术人员来搭建，它基于CPU、GPU内建的程序化生成的优化在于刚刚所讲的程序化生成，它生成的不仅仅是美术的资产，它生成的是玩法逻辑，生成的是各种优化的特性，以及各种引擎的底层特性。

考虑到这些因素，我们也是决定后续运行时的动态程序化生成，还是应该由技术人员主导进行开发。

第二点是程序化生成更适合生成哪些。因为Houdini的优势相对来讲更倾向于叫资产的生成，比如用Houdini生成一个完整的场景，而不需要任何美术的参与或者一个开放世界的地形，这些生成的都是一个资产，是把一个场景从0到1的生成过程。

而基于CPU的程序化生成我们叫一个点云方式，点云的方式最大的体现也是在《黑客帝国》的demo里面，特别是在建筑类。因为每一个建筑的资产都是美术预先做好的单元模块，或者在我们的例子里叫模块化的单位。这样真正要生成的是每一个单位它所代表的点，也就是程序化生成里面的点云。

这个点云的信息，比如它的位置信息、属性信息，修改这些点的成本和更新频率，肯定是要比地形低很多。所以我们现在的动态，更多是以点云的方式为基础来进行的。

接下来用一个示例介绍，我们怎么把UE5《黑客帝国》demo里面Houdini的生成，往UE4使用了一些市场资源的CPU城市的点云生成来进行迁移。

这张图是我们之前跟天美某个项目组合作的，试做的一套内建的基于CPU的建筑系统，时间关系，不做很详细地介绍。

首先可以看到，左边这张图里面绿色的点，就是建筑的轮廓，而右边就是整个建筑的搭建规则和拼接方法，整套流程也是从Houdini的方式进行了平移。

除此之外，我们还实现了资产之间的替换规则。首先可以看到，左侧就是我们的数字场景系统，里面的数字场景结构就是一些点线的组合。“点”大家很清楚，它是场景里面每一个资产的属性，不管是它的优化属性，还是可玩的属性以及表现的属性，其实都是存在于这个点里面的。

而“线”则是代表了这些原子画像在场景里面的组织方式，首先属于一条线上的时候，有一个比较强的关联结构。当场景发生变化时，优先以线的方式进行变化，这些和Houdini的程序化生成非常近似，这里不做过多的叙述。

像现在的视频里面，在UE4实现了各种线框的绘制模式，跟Houdini比较类似，通过这些线框把一个建筑的外轮廓确定下来，而一个复杂的建筑是非常多的线框组合，我们的程序化生成可以把一个建筑拆成多个线框的格式，这样就能实现更为复杂的建筑系统。

而且每条线可以单独进行编辑，在编辑以后，场景也可以反馈整个线框里面属性的变化。除此之外，一个建筑的结构，像《黑客帝国》整个楼会分成非常多的层。我们相对简单，只是分了三层，比如底下这一层，中间的楼层里面是两层，中间要加更多层，只需要在节点里面配置更多的节点属性，把它拼接起来也可以实现更多层次的叠加。

剩下的像房顶，除了房周围的边以外，房顶的自动生成也有一定的策略，整体来说我们把《黑马帝国》的这套Houdini的程序化生成转移到了UE4的C++的这套方案里面去。

上面的，就是一个用市场的资源，把整个城市的结构进行一个线框或简模化，再把这些简模化替换成不同主题的建筑。

除了生成以后，我们还有管理的功能，管理是对它的资产和主题进行一定的替换，包括对单个和整体资产的替换都能实现。通过这些能力我们支持了建筑在动态时候的一个程序化的管理替换，还有全局维护和改变的功能。

除了刚刚讲的建筑系统外，我们也做了大量其他的从Houdini往GPU转化的流程。例如上面的图里面，把传统的Houdini地形系统转移到了基于GPU的系统里面去。

但是因为整个计算速度还很难达到实时化，而且除了地形外，河流、植被这些对GPU的依赖很高，会影响到很多游戏的体验。所以也是刚刚提到了，除了点云外，其他的程序化生成方式我们还是保存在了编辑状态下，并没有把它往运行时的实时进行迁移。

第三部分，因为时间关系，我简单挑了几个我们已经实现的点，或者大家比较关注的技术点进行讲解。

这里面最核心的是动态世界如何确保它优化或性能的，其次也是刚刚讲到了很多次的如何在原子化模块基础上，确保角色跟场景的交互的一致性，还有是《黑客帝国》里面的AI，不管是车辆还是行人，是如何动态支持场景，实现它逻辑的一致性的。

在上一章讲到了，我们对整个场景做了大量的准备，或者我们把场景的引擎里面的特性，基于T.D.G和数字场景的概念进行了组合。实际我们基于整个场景的分类，搭建了一套完整的蓝图加组件的模式，这里面每一个蓝图组件除了它的表现以外，更多是它的一些逻辑性、迭代性以及优化策略。

简单来讲，一棵树的渲染策略和一个建筑模块的渲染策略肯定不一样，树和草更多是基于实例化渲染，而建筑会用到一些GPU专用的方式，从做法、规格和剔除策略上，肯定是完全不同的。我们也是在这些组件里面，进行一个设置区别，支持不同的动态效果下如何进行性能的优化。

之前也讲到，其实UE有大量的原生和优化的支持。除了这些原生的技术以外，在IEG也好，在天美工作室群也好，也有大量的优化方法。时间关系，这里不做过多的叙述，我们也是根据上面的原子化的设置，能够通过配置来确定它在动态的时候，组合也好、单个物体也好，都会选择一个最适合它的优化策略来进行。

就像上面这张截图一样，建筑用的是batch的方式，因为它的建筑和整体的轮廓要一直保持，所以它肯定不能被Culling掉。而是稍微远一点以后，通过一些Mesh Merge的方式，类似叫HLOD的方法。

而植被跟树木则不一样，稍微远一点以后，有一些草体可以被剔除掉，来减少Draw call，而小的物件也会根据场景的组织关系，例如建筑内的物件稍微远一点以后，建筑立的东西肯定看不到就可以剔除掉。

建筑外的物件还要更远时，才会根据物件之间的组合关系来决定，它到底应该在什么情况下被剔除，什么情况下被合并。我们的优化就是在一个动态的时候，要有程序化的管理策略，来决定哪些物件用哪些优化的策略。

另外一点也是我们推进方法时遇到的问题，如果这些组件给策划和美术用，学习成本和使用难度很高。我们跟引擎团队配合，实现了一个后置基于蓝盾的程序化生成方法，会把整个场景自动化通过配置转化成一套原子化模块。

当前期策划和美术需要快速验证时，不需要了解和学习这些东西，而只需要我们把它进行转化以后，他们在后期拿到的是一个完整的原子化转化后的资产，样就解耦了两边的开发的矛盾，也能顺利让这个技术进一步进行落地。

除了优化以外，另外一点就是刚刚讲到了场景的交互，这里面我们也是引入了之前跟育碧合作的一个攀爬线的概念。

攀爬线像左图里面，隶属于每一个原子化模块里面的线，我们的玩家也好、AI也好，会根据这些线的属性来确定，当它进行操作时，应用哪些动画反馈它的操作。

这些攀爬线具体如何组合而成，也是用程序化生成的方式，类似这张图，每一个模块有自己的攀爬线，当我把这个模块的攀爬线生成或调整以后，可以通过程序化的技术，把这些攀爬线反馈到整个游戏场景，而不需要每次调整攀爬的规则。

这个是早期的一个实例，可以看到楼里面的每一个模块，它的攀爬线可以通过Houdini生成或人工的方式来配置，这个原子化模块有了攀爬线以后，当程序化生成的整个建筑自然也带有攀爬线的属性。一个模块的攀爬功能实现了，基于T.D.G规则整个建筑的攀爬也就实现了。

除此之外，我们在程序化生成里面，也执行了一些优化的策略。例如T.D.G规则里面，有一些线处于不对的位置，当两个模块在一起时，这条线是不能攀爬的，我们也是根据一些空间算法，把这些多余的攀爬线在运行时或编辑态下进行一定的剔除。

比如图里左侧的红线，说明攀爬线起作用，右侧变成黄线时，也是经过程序化的算法，它是一个不可爬的线，就会剔除掉。

整个场景像左侧可以看到，是有大量的无用的线。当这个场景用程序化生成组合拼接或人工改变以后，我们的算法也会自动把这些错误的线给变灰掉，这样也就确保了整个场景如何动态拼接、动态组合，它的攀爬逻辑都是一致的。

最后讲一下我们怎么让AI更好地支持动态。以道路为例，每个道路车辆是怎么应用道路、行人怎么应用道路，我们都是在道路的原子化模块里面，预先把它的一些功能组件进行设置，这样的话在运行时，只要把这些资产拼接起来，这些道路的信息也会动态进行合并，确保了行人和车辆的完整地适配。

这里没介绍的核心的点，可能还是我的动态场景怎么去适配光照，因为现阶段美术表现是所有游戏最关注的点，而光照的效果就是这个重点里的重点，这也是我之前所讲的资产的管理、世界的逻辑和渲染优化里面唯一没有提到的，因为这块确实有很大的难度，这里面我也会在总结的部分进行一定的阐述。

这次分享并不是一个非常完整的思路或者完整的demo，按介绍的完成度只有50%，或者只完成了资产准备和部分运行时的功能，但为什么还是要把这个东西分享出来呢？有以下两个点。

以前我们听到的各种对外的技术分享，通常是一套完整的方案，例如前些年的各种Houdini的介绍，其实给了大家一种非常美好的印象。实际我这些年应用Houdini，包括把各种程序化技术、工业化技术往项目推进时，还是遇到了大量的问题跟难点。而且里面也有很多的经验教训，我也是感觉从技术分享来讲，不应该只告诉结果，而里面所踩的坑、所遇到的问题和研发过程，其实也是需要为大家分享的。

例如你要推一套完整的工业化方法，我们所面对的问题是先有鸡还是先有蛋的问题，就是先做项目，还是先推工具、先推技术。这里面最大的难点还是在渲染的光照和表现上，如果你没有资产，根本没有机会去验证或研发新的光照技术。所以也是因为这些原因，还是要把这些东西做出来，当做到只差光照时，老板或团队会倾斜更多的资源来支持他。

未来我们的想法，整个的程序化技术应该是在整个动态世界，在一个动态场景、动态角色，甚至动态叙事的基础上，就一个更上层的管理系统。

不管这个更上层的管理系统是玩家的操作，是基于规则的AI，还是更高纬度、深度学习的AI，也就是大家常说的meta-ai技术外，都应该有一个更高级的技术进行一个管理。

所以我们现在做的所有的事情，都是为了能够把底层的基础知识，把它的验证环境搭建好，这样我们的天美工作室群才有机会去引入更多的AI技术，引入更多的外部团队，真正地把这套动态世界解决好。

也正是因为这些原因，我在腾讯内部基于IEG所有工作室群的大家业余的合作或共建的项目里，立项了一个UGC的工程，基于UGC的项目，它就是为了支持和运作一个动态世界需要的所有基础的概念，以及所有的资源。

基于UGC的Take a future，我们会在刚刚所讲的基础，引入更多的技术实验和实例，来说服项目组和IEG，让大家跟家关注这些技术点。

我的分享就到这里，谢谢大家！