您需要 登录 才可以下载或查看，没有账号？注册
x
本帖最后由 chenpan85 于 2022-9-5 11:08 编辑
Dan Sumaili：
My name is Dan Sumaili, and I'm working as a tools programmer at Guerrilla Games, and today I'm sitting down with my colleague Sander Van der Steen to talk about how we retooled the tool pipeline during the development of Horizon: Dawn of Zero.
Before Horizon Zero Dawn, we made Killzone, an FPS game, and when we decided to move from FPS development to an open world game, it posed a major challenge to our company, to our concept, and to the tools we used.
So, today's share will focus on the reasons behind the redesign of the tool, how we implemented it during production, and how it helped the development of the game. If you have a team that uses the same techniques and tools that you left behind and use them on a daily basis, then this might be a good idea for you. 我叫Dan Sumaili，在Guerrilla Games担任工具程序员，今天将与同事Sander van der Steen一起谈谈我们是如何在《地平线：零之曙光》研发过程中重新打造工具管线的。 在《地平线：零之曙光》之前，我们做了FPS游戏《Killzone》，当我们决定从FPS游戏研发转向开放世界游戏的时候，这给我们的公司和研发理念都带来了很大挑战，用到的工具也没有幸免。 所以，今天的分享主要包括我们重新打造工具背后的原因，我们在制作的过程中是如何实现的，以及这给游戏研发带来了什么帮助。如果你的团队也在用之前留下来的技术和工具，并且每天都需要用到，那么今天的内容或许会给你带来一些启发。 The problems encountered in the development of Horizon: Zero Dawn
We'll start by talking about tools left over from previous projects, tools we've rebuilt, the 3D editor and other tools, and then we'll talk about our plans for the future.
Tool problem
When Horizon: Dawn of Zero was first developed, the tools were very fragmented, built around different programming languages and frameworks. With these tools, our iteration times are quite long, such as a game planner trying to make a change to a feature that takes at least 20-30 minutes to complete. Frankly, the team members complain a lot about these tools, compared to the popular tools like Unity or Unreal Engine. So, today's share will focus on the reasons behind the redesign of the tool, how we implemented it during production, and how it helped the development of the game. If you have a team that uses the same techniques and tools that you left behind and use them on a daily basis, then this might be a good idea for you. 《地平线：零之曙光》研发遇到的问题 首先我们会聊聊之前项目遗留的工具，重新打造的工具，还会提到3D编辑器以及其他工具，然后是我们对未来的计划。 工具问题 《地平线：零之曙光》刚开始研发的时候，工具是非常分散的，它们都是基于不同编程语言和框架打造。使用这些工具，我们的迭代时间比较长，比如一名游戏策划想要对某个功能作出调整，至少需要20-30分钟才能完成，坦白的说，团队成员对这些工具的抱怨很大，跟热门的Unity或者虚幻引擎等工具相比，差距很大。 A quick technical note: At Guerrilla Games our Intermediate Plaintext Format uses CoreText, which is used for all game data except texture and audio. Before it is used in the game, We convert it into binary data by means of transformation.
This is the CoreText editor that we used mostly before, and it's pretty old, it turns the content into a 2D image, and the associations between the object file and the comment file are connected by different lines.
We used it to create and configure a lot of game data, but in terms of actual data editing, it was pretty low level, and a lot of it was done during the busy days of developing Killzone. Instead of focusing on the creative process, you spend a lot of time understanding complex data structures.
It's all written in C#, WinForms, and (SONY's) ATF format. All in all, the tool is so complex that even small changes can take a lot of time. As a result, few developers on the team liked the tool. 简单说一下技术方面，在Guerrilla Games我们的intermediate plaintext format都是使用CoreText，它用于除了纹理和音频之外的所有游戏数据，在这些数据被用到游戏之前，我们通过转化的方式将其变为二进制数据。 这是我们之前主要使用的CoreText编辑器，可以看出非常的古老，它把内容变成2D图片，目标文件和注释文件的关联性通过不同的线条连接。 我们用它来创造和配置很多的游戏数据，然而在实际的数据编辑方面，它是非常低等级的，很多都是在研发《Killzone》比较忙碌的时候做出来的。你需要用很多时间去了解复杂的数据结构，而不是聚焦于创意过程。 这些都是用C#、WinForms以及（索尼）ATF格式写的，总而言之，这个工具非常复杂，即便是很小的改变都需要付出很多时间。因此，团队里的开发者几乎没有人喜欢这个工具。 Another tool is Maya, specifically our internal Maya plugin, which imports our data into Maya and exports it to CoreText. This plugin uses the renderer of the internal engine Decima to see what these resources look like in the game. However, it does not run the full Game Loop, which means that some elements that exist in the Game are missing. 另一个工具就是Maya，具体来说就是我们里面的Maya插件，它将我们的数据导入Maya，然后导出到CoreText，这个插件使用了里面引擎Decima的渲染器，以便能够看到这些资源在游戏里的视觉效果是什么。然而，它并不能运行完整的游戏主循环（Game Loop），意味着丢失了一些在游戏里存在的元素。 The last tool is the State Machine Editor, SMED, which is mostly used by level planners. This tool was originally a creative prototype made by the technical planner to explore whether we could generate LUA scripts for a game. Unfortunately, this attempt was not successful and required constant maintenance by a technical planner. The tool was written in Python.
From the above introduction, we can see that these three tools can not be used by many people, and the interaction between each tool is difficult, so the three tool pipelines are not easy to use. 最后一个工具是状态机编辑器（State Machine Editor）SMED，主要是关卡策划们在使用。这个工具最初是技术策划做的创意原型，为了探索我们能否为一款游戏生成LUA脚本，不幸的是这次尝试并没有成功，还需要不断有一名技术策划进行维护，这个工具是用Python写的。 通过以上的介绍，我们可以发现这三个工具能够使用的人并不多，而且每个工具之间的交互也很难做到，因此这三个工具管线并不好用。 We have a number of other tools in use, but due to time constraints, we can't go into all of them.
Because of the tools, we created the Debug UI, an in-game UI framework. It was developed during the production of Killzone: Shadow Fall, and a lot of programmers found this tool useful, and a lot of in-game Debug tools were created based on it. 我们还有大量其他的工具在使用，但由于时间限制，我们没办法一一说明。 因为工具的原因，我们制作了游戏内UI框架Debug UI，它是在《Killzone：Shadow Fall》制作期间研发的，很多程序员觉得这个工具比较好用，并且在此基础上产生了很多的游戏内debug工具。 This is our in-game GPU profiler, so you can see a lot of draw calls for each frame, different samplers, a lot of information, and it also has an external view, where you place the window on a certain part of the scene, and you know that intermediate buffer corresponds to the final frame.
The game itself
In Killzone, including in our previous development, we had never done an RPG, nor had we ever seen an open world game. On Horizon: Zero Dawn, we had to build stuff that we hadn't done before, like quests, interactive dialogue, and Guerrilla Games had a small team of tool programmers -- we only had four to six full-time tool programmers on a team of 220 people -- so we used our time and resources efficiently. In addition to the pipeline tool shortcomings discussed earlier, we decided to start from scratch on the development tool. 这是我们的游戏内GPU分析器（profiler），你可以看到每一帧的很多draw call，不同的采样器等很多信息，它还有一个外部视角，你把窗口放在场景的某个部位，就知道那个intermediate buffer对应最终某一帧。 游戏本身 在《Killzone》包括之前的研发中，我们没有做过RPG，也没见做过开放世界游戏。在《地平线：零之曙光》当中，我们还需要打造一些没做过的内容，比如任务、互动对话等，而且Guerrilla Games的工具程序员团队很小，在一个220人的团队里，我们只有4-6名全职工具程序员，因此必须高效率使用我们的时间和资源。加上之前谈到过的管线工具弊端，我们决定重新开始打造研发工具。 At this point we started to set some tool development goals, hoping to create a framework that would benefit our future tools and give coherence to our tools. Decima is our internal engine, and we want to reuse as much as possible as we build new tools. We also wanted to make the new tool as easy to use as possible so that other teams could accept it and ultimately help more teams.
In terms of editors, we hope to create tools that will fit the needs of our team members, such as Editing Contexts for specific methods and reusable components, so that we can quickly create new tools for other teams when they need them. We also want to simplify tool usage so that all tools remain in one program, which is our current Decima editor. 这时候我们开始制定一些工具研发目标，希望能打造对未来工具有利的框架，让我们的工具之间具有连贯性，Decima是我们的里面引擎，在打造新工具的时候，我们希望尽可能多地实现复用。我们还希望让新工具用起来尽可能简单，以便让其他团队接受，并最终帮助到更多的团队。 编辑器方面，我们希望打造适合团队成员需求的工具，比如针对特定方法打造Editing Contexts，以及可以复用的组件，这样在其他团队需要的时候就可以为他们快速打造新工具。我们还希望简化工具使用方法，让所有工具都保留在一个程序当中，也就是我们现在的Decima编辑器。 Decima is our internal engine, and some of the games we've worked on recently include Killzone: Shadow Fall, Rigs, Horizon: Dawn of Zero, and Kojima Studios' Death Stranded. Unlike most engines, it is divided into many layers, the base layer is the OS designed for different platforms, mainly to make the game easier to port to different platforms, and it is worth noting that we always have the full PC version for R&D purposes.
Next comes the core, which includes rendering, lighting, particles, and so on, followed by the game code to do the different functions. We put the tool framework at the top so that it can reach everything below.
This engine has many advantages, but one of the most important is the highly optimized runtime type recognition (RTTI) that is necessary to build specialized editors. The second advantage is the free code and Decima engine library, which lowers the bar for the rest of the team's programmers to use. Decima是我们的里面引擎，最近用它研发的游戏包括《Killzone：Shadow Fall》、《Rigs》、《地平线：零之曙光》，以及小岛工作室的《死亡搁浅》。与大多数引擎不同的是，它被分为很多层，基础层面是为不同平台设计的OS，主要是为了让游戏更容易移植到不同平台，值得注意的是，出于研发目的，我们始终有完整的PC版本。 接下来是核心部分，包括渲染、光照、粒子等等，随后是用来做不同功能的游戏代码，我们将工具框架放在最顶层，以便它可以触达下方的所有东西。 这个引擎有很多优势，其中一个非常重要的优势就是优化程度很高的运行时类型识别（RTTI），这对于打造专门的编辑器是必要的。第二个优势是免费代码和Decima引擎库，为团队其它程序员降低了使用门槛。
这是我们的Visual Script编辑器 This is the dialog editor
The creation of new editors 这是对话编辑器 新编辑器的打造 By this time, Killzone was already in development, and all but a handful of people who worked on its DLC had moved on to Horizon: Zero Dawn, a project that had already begun production. Despite the inconvenience of the previous tool, it worked, albeit inefficiently, and developers were already familiar with the tools, so although they knew they needed to change, they were less willing.
We don't know what the outcome of building new tools will be, so we need to start small to minimize the risk of development, which means we need to continue to support old tools while building new ones.
For these reasons, we decided to start with the audio team, which meant we had to start with a small team (4 people) that could test the framework from the CoreText editor to Decima editor. 这个时候，《Killzone》已经完成了研发，除了少数为它做DLC的成员之外，所有人都转向了《地平线：零之曙光》，这个项目的制作已经开始。尽管之前的工具有很多不便，但它的确是可行的，虽然效率比较低，研发人员已经熟悉了这些工具，因此尽管明知道需要改变，但他们的意愿并没有那么强烈。 我们并不知道打造新工具的结果如何，所以需要从很小的事情做起，这样才可以最小化研发风险，意味着在研发新工具的同时，还需要继续支持旧工具。 鉴于以上原因，我们决定从音频团队开始，这意味着我们最开始只需要满足小团队使用需求（4个人），而且他们的工作需要能够测试框架从CoreText编辑器到Decima编辑器的可行性。 Our audio team primarily uses NodeGraph, a high-performance Visual Scripting language that generates C++ code to run on target. It was used heavily at the time of Shadow Fall development, meaning that if it was available to the audio team, it could be adopted by other teams. 我们的音频团队主要使用NodeGraph，这是一个高性能Visual Scripting语言，可以生成在目标运行的C++代码，它在《Shadow Fall》研发的时候使用率很高，意味着如果音频团队能够使用，那么其他团队也可以陆续采用。 This is the version we use now, and in fact, we hand it over to the audio team to try every iteration, which is a painful process that goes through a lot of iterations. Every time there was a problem, the tools needed to be changed, but we focused on improving all the features. After a few months of experimentation, we achieved parity, new features that were easy to deploy, and even allowed other programmers to contribute to feature development.
Sander: A New flow of Game Design (3D Editor)
The best way to give your team the confidence to complete a big project is to build them a level editor, which we call a 3D editor. Let's talk about the decisions behind this new editor.
As Dan mentioned, why make a new 3D editor when you're already working on the game? Why not put more effort into the Maya plugin for optimization?
The first reason is that Horizon: Dawn of Zero requires a lot of quest content, which is a new genre for Killzone, so our content production process in Maya is the worst part in terms of practicality, and it's not good for level editing on its own.
Secondly, an editor like Unity or Unreal Engine can help our workflow, without which we wouldn't be able to do a lot of development quickly. Finally, our focus as an editor is easy to implement, as long as the object placement is done to meet the workflow requirements of the planning team, here is how we achieved it: 这是我们现在使用的版本，实际上，我们每次迭代都会交给音频团队尝试，这是个很痛苦的过程，经历了很多次迭代。每当遇到问题的时候，工具就需要做出改变，但我们聚焦于完善所有功能。经过几个月的尝试之后，我们实现了同等特性，新功能可以很容易部署，甚至可以让其它程序员在功能研发方面做出贡献。 Sander：游戏设计新流程（3D编辑器） 给研发团队完成大项目研发信心最好的方式，就是为他们打造一个关卡编辑器，也就是我们说的3D编辑器，接下来说说这个新编辑器背后的决策。 就像Dan提到的那样，在已经开始游戏研发的情况下，为什么还要做新的3D编辑器呢？为什么不是在Maya插件投入更多努力进行优化呢？ 第一个原因是，《地平线：零之曙光》需要大量的任务内容，对于《Killzone》来说是全新内容类型，所以在实用性方面来说，我们在Maya插件里的内容制作流程是最糟糕的一部分，它本身并不适合做关卡编辑。 其次，类似Unity或者Unreal Engine那样的编辑器可以给我们的工作流带来帮助，如果没有这样的编辑器，我们不可能快速完成很多内容的研发。最后，我们做编辑器的焦点很容易实现，只要搞定对象放置就能满足策划团队的工作流需求，接下来说我们是如何实现的： It's purposeful, it's easier to control, and from a research and development point of view, it's more efficient and faster. The downside, however, is that it is difficult to achieve visual or behavioral consistency if new features are introduced later, and the development cycle is longer because more code is required. 它的目的性很强，而且比较容易控制，从研发角度来看，效率和速度都比较快。然而它的弊端在于，如果后续做新功能就很难做到视觉或者行为的一致性，由于需要更多代码，因此研发周期会更长。 If you put the entire game into the editor, you can see all the game features, which means you can make DebugUI freely and change it in the editor as you would a game. The downside of this approach is the high performance overhead. 如果把整个游戏都植入编辑器，你可以看到所有游戏功能，意味着能够自由做DebugUI，而且还可以像玩游戏那样在编辑器改动。这个方式的不利在于性能开销比较高。 If it is within a process, it has the advantage of being quick to set up and easy to debug, since we can directly synchronize data changes within the same process. The downside is that the game crashes directly causing the editor to crash, requiring a lot of work to fix, and over time causing many features in the editor to be diverted to different systems in the game, making code management very difficult. 如果是流程之内，它的优势在于能够快速设置且容易做debug，由于在同一个流程内，我们可以直接同步数据变化。但它的弊端在于游戏崩溃会直接导致编辑器崩溃，需要大量的工作才能搞定，而且随着时间的增加，会导致编辑器里的很多功能导向游戏不同系统，让代码管理非常困难。 The other approach provides higher stability, is easy to recover from crashes because the game is separated from the editor, and the code is cleaner because the editor can't directly modify the game's objectives. Because of the separation of the two, you can quickly see changes in the editor, even if the in-game UI feedback is not as fast. The downside, of course, is that the editor takes a long time to develop, and it can be difficult to debug if the editor and the game flow are out of sync.
Considering project and team constraints, we decided to go with the first option, but at the same time, we wanted to be able to do out-of-process development in the later stages of game development, so we wanted to keep the code separate and not have any data shared between the editor and the game.
Here is an example of research and development: 另一个方法则可以带来比较高的稳定性，由于游戏和编辑器分离，即便游戏崩溃也很容易恢复，而且代码会比较整洁，因为编辑器不能直接修改游戏目标。由于两者分离，哪怕游戏内UI反馈速度不那么快，你也可以在编辑器内快速看到修改结果。当然，它的不利之处在于，编辑器研发时间会比较长，如果编辑器和游戏流程不同步，就会很难做debug。 结合项目和团队限制，我们决定选择第一个方案，但同时希望在游戏研发后期能够做到流程外研发，所以希望做到代码分离，不让编辑器和游戏之间共享任何数据。 这里用一个研发案例来展示： First of all, the level planner can run the game in the editor. When the character arrives at a location and finds that there is a problem with the game level, we enter the editing mode, remove the trees in the way, and add vegetation on both sides of the road. After tackling the terrain with tools, join the enemies you encounter.
Editing content while running the game: A subsystem required by the level editor
This section focuses on how to achieve the separation of editor code and game code. The early problem was that the data in the game was inconsistent with the data on the hard drive, mainly due to the Process Code Conversion mentioned by Dan. While this problem is common, it causes some problems for level editing due to the fact that the information is solid.
Fortunately, as we said, there is no need to directly control game changes through the editor, so the editor and the game use different data formats and cannot be shared between them. 首先关卡策划可以在编辑器运行游戏，角色到了一个地点之后发现游戏关卡出现了问题，这时候我们进入编辑模式，去掉挡路的树木，然后在路两边增加植被。通过工具处理地形之后，再加入遭遇的敌人。 在运行游戏中编辑内容：关卡编辑器需要的子系统 这个部分主要说如何实现编辑器代码和游戏代码的分离。早期遇到的问题是，游戏里的数据与硬盘上的数据并不一致，主要是因为Dan之前提到的Process Code Conversion。虽然这个问题很常见，但由于信息确实，它给关卡编辑带来了一些问题。 幸运的是，我们已经说过，并不需要通过编辑器直接控制游戏改动，因此编辑器和游戏使用的数据格式不同，且两者之间无法共享。 The way to handle Editor and game data, called EditorNode, provides all the editing functionality for a target within the game, without the game target knowing the EditorNode exists. So, this way you can keep your code clean and your game code won't be confused with your editor code.
The second problem with transformed data is hierarchy. Low hierarchies can lead to performance degradation. Although a flat target list is fast and efficient, it is not easy to edit locally.
Therefore, we needed to build in some hierarchical in-game data structures so that when the level planner went into edit mode, it would be easier to see the effects of the changes. 处理编辑器与游戏数据的方法，我们称之为EditorNode，它提供了一个目标在游戏内的所有编辑功能，游戏目标并不知道Editor Node的存在。所以，这种方式可以让代码保持简洁，游戏代码不会和编辑器代码混淆。 转化后数据带来的第二个问题是层次，低层次性会导致性能降低，虽然扁平化的目标列表快速有效，但对于本地化编辑并不容易。 因此，我们需要内置一些有层级的游戏内数据结构，这样关卡策划进入编辑模式的时候，就可以更直观地看到调整效果。 To do this, we made two Editor Node trees that look the same but refer to different data. Once the editor has made the change, it communicates with the game, and this communication is the second part.
Changes to in-game objects
When determining the goal, you'll often need to list what you don't want. In our case, the proxy conflicts and the string-based accessor, editor specific boilerboard files, and the code generation steps in the version are all things we don't want.
We want to go straight to the specific goals we can find in the engine and reuse existing systems and tools to create and transform data. This meant that our game and engine programmers needed to know the editor code, so a pullback system would give them more control and freedom to try out new features. 为此，我们做了两个Editor Node Tree，他们看起来一样，但参照的是不同数据。编辑器做出改变之后，就会与游戏沟通，这部分沟通内容就是第二部分。 游戏内物体的改变 确定目标的时候，你往往需要列出自己不想要的东西，在我们的案例中，proxy representations、基于字符串的accessor、编辑器特定样板文件，以及版本中的代码生成步骤都是我们不希望出现的。 我们希望直接做能够在引擎里找到的具体目标，能够复用现有系统和工具创造和转换数据。意味着我们的游戏以及引擎程序员需要了解编辑器代码，因此，一个回撤系统才能让他们对新功能尝试有更多控制权和自由度。 因此，回撤系统必须简单而且可靠，不需要虚拟的“做”和“撤销”功能，在做新功能的时候不需要回撤新代码。 So our ideal scenario is to have a backoff system that automatically detects changes in targets and knows how to recover them. The compromise we made was to specify the target of the change through the code and then complete the corresponding change.
These are very simple instructions, each representing a change, implemented through the RTTI system and notified in real time on the user interface. 因此我们的理想情况是，做一个能自动检测目标变化并知道如何还原它们的回撤系统。我们做出的妥协是实现通过代码指定被修改目标，然后再完成对应的改变。 这些都是非常简单的指令，每个指令都代表了一个改变，这些改变都通过RTTI系统实现，并且可以在用户界面实时通知。 This approach has many benefits, such as code separation, and means that component changes can come from anywhere, and editor code doesn't need to know much about changes or rollback.
Initially, our approach was to do this manually, but it was time-consuming and did not meet our usability criteria, so our solution was to use DiffUtil to observe the changes that had occurred. Before the change, the programmer uses DiffUtil to keep a snapshot of the target state, and then analyzes the current state against the snapshot after the change. 这种方式有很多好处，比如代码分离，还意味着组件变化可以来自任何地方，编辑器代码不需要知道改变或者回撤的太多信息。 最开始的时候，我们的方法是手动处理，但非常耗时且不符合我们的易用性标准，因此我们的解决方案是用DiffUtil来观察已经发生的变化。改变之前，程序员用DiffUtil保留目标状态快照，改变之后再分析当前状态与快照的对比。 Overall, it's a very reliable and transparent system that allows for complex in-game changes. In the editor code, there is no strict distinction between change and rollback actions, and over the next two or three years, although we made a lot of changes, the code remained relatively stable.
But also some things were not so good, although there are DiffUtil, but it is easy to forget to use programmers, so not all changes may be withdrawn, another problem is that we can't find all the bugs, finally is also very important, it does not support file system operations, which we then need to solve the problem.
Changes in the 3D editor
When a change occurs, the Node Tree in the editor hears and makes the change, and sends the specific change to the game Node Tree, which receives the information and makes the corresponding change. 总的来说，这是一个非常可靠而且透明的系统，能够呈现复杂的游戏内改动。在编辑器代码中，改变和回撤动作没有严格的区分，在随后两三年的时间里，虽然我们做出了很多改变，但代码稳定性一直比较高。 不过，同样有些东西表现不是那么好，虽然有DiffUtil，但程序员们很容易忘记使用，因此并不是所有改动都可以撤回，另外一个问题就是，我们没办法找到所有bug，最后也很重要的事，它并不支持文件系统操作，这也是我们接下来需要解决的问题。 3D编辑器里的变化 当一个改变发生之后，编辑器里的Node Tree听取并做出改变，并且将具体改变发送到游戏Node Tree，游戏里对应的Node Tree接受信息并作出对应改动。 The previous Node Tree illustration might have been simple, but let's go into detail. Suppose MySpotlight is the parent target of the game object MyPrefab, which is the root of the Tree. Every Node change will be applied to the root, and more advanced changes will trigger changes to the terrain. 之前的Node Tree展示图可能会比较简单，接下来我们详细说明，假设MySpotlight是游戏目标MyPrefab的母目标，也就是树木的根，每个node变化都会应用到树根当中，更高级的改变还会触发地形的变化。 This way, however, in the interactive changes to information leakage problems, we found that it is not realistic to reverse the change: first of all, it makes data authorization illegibility, due to the conversion of data loss, reverse change is not possible, in the end, you will also need to prevent the editor changes back into the game. 不过，这种方式在互动改变的时候容易出现信息丢失的问题，我们发现反向做改动是不现实的：首先，这让数据授权变的不清不楚，由于转换当中的数据丢失，反向改动是不可能实现的，最后，你还需要防止编辑器里做的改动回流到游戏当中。 The same goes for the rollback operation.
Game sync
There are some structural changes that we did not take care of. The structural changes of the updated game were implemented through the GameSync function, as shown in the figure below: 回撤操作也是如此。 游戏同步 有一部分结构改变是我们没有管的，更新游戏结构改变是通过GameSync功能实现的，具体流程如下图所示： The advantage of GameSync is that it can accommodate all changes to the editor, and it can even allow users to synchronize their files without having to restart the game. However, the problem is that it is very complicated to analyze the changed code, and it is also prone to performance problems. For some irrelevant systems, it is easy to have incomplete information update, resulting in poor user experience.
Dan: Other tools
As mentioned earlier, we work with teams that use NodeGraph, and one of the most important tools is the NodeGraph Debugger, which provides many powerful capabilities such as variable checking, execution visualization, and debugging information history. GameSync的优势在于，它可以适应编辑器所有的改动，甚至可以在不重启游戏的情况下让用户实现文件同步。不过它的问题在于分析改变的代码会非常复杂，还容易出现性能问题，对于一些不相关的系统，很容易出现不完整的信息更新，导致用户体验较差。 Dan：其他工具 之前提到，我们与使用NodeGraph的团队进行了合作，其中一个非常重要的工具就是NodeGraph Debugger，它提供了很多强大的功能，比如变量检查、执行视觉化以及历史debugging信息。 This tool was very useful during the development of Horizon: Dawn of Zero. The visual Dubugger tool minimized the involvement of the tool team, which was a success for us because it meant that other teams in the company were free to use the tools. 在《地平线：零之曙光》研发过程中，这个工具是非常有用的，这种视觉化的dubugger工具可以让工具团队参与最小化，这对我们来说是成功的，因为这意味着公司里的其他团队可以自由使用这些工具。 This tool was very useful during the development of Horizon: Dawn of Zero. The visual Dubugger tool minimized the involvement of the tool team, which was a success for us because it meant that other teams in the company were free to use the tools. Some things are new to the game, like interactive dialogue. We didn't have any existing tools for this, so we had to build them from scratch, specifically for writers, mission planners, and cutscene artists.
Here's our dialog editor, which clearly shows the dialog, choices, mission objectives, and more. We can show this in a simple in-game dialog: 对这款游戏来说，有些东西是全新的，比如互动对话。对于这方面的内容，我们没有任何现存工具可以解决，因此不得不从头开始打造工具，专门为作家、任务策划以及过场动画美术师们设计新工具。 这是我们的对话编辑器，清晰地展示了对话、选择，任务目标等信息，我们可以通过简单的游戏内对话来展示： What's interesting is that the dialogue is automatically generated, including shot clips, animations, and gestures selected through the rules system, which also generates RovoVoice and facial expression animations, meaning that storytellers only need to enter the dialogue text, and the game can quickly see how the dialogue will play in the game. 比较有趣的是，这段对话是自动生成的，包括镜头剪辑、动画、手势都是通过规则系统选择的，这个系统还会生成RovoVoice和面部表情动画，意味着剧情策划只需要输入对话文本，游戏就可以快速看到对话在游戏里的效果。 The other thing we did was the world map. For an open world game, it's very difficult to show everything that's going on, so we represented the game data through 2D maps, and we showed missions, JIRA bugs, things like that through overlay systems. 我们做的另一件事就是世界地图，对于一个开放世界游戏来说，展示所有发生的事情是非常困难的，为此我们通过2D地图代表游戏数据，并且通过覆盖系统展示任务、JIRA bug等信息。 This is the performance map we made to show the memory, CPU and GPU energy consumption of a certain place. The energy consumption is represented by green and red respectively. However, this is late development of the game, and the performance issues have been solved, so there is no red area. 这是我们做的性能地图，可以展示某个地方的内存、CPU以及GPU能耗，分别通过绿色和红色代表能耗，不过这是游戏研发后期，性能问题已经被解决，所以没有红色区域出现。 The last one is Decima API. Guerrilla programmers wanted to build a C API for the framework so that some of the tools could be used in other languages, such as file loading/storage and object control. We wrote a wrapper in Python. Let artists and planners who have learned Python create scripts that control the content of the game.
With the end of the project research and development, we have more time to look at the tool framework, these tools have been very successful, but we found there are many place to improve, such as allowing more teams use our editor, such as special effects, environmental art, and so on, so, we will also start a different editor, such as the Entity, particle, shaders, etc. Make our editor available to everyone in the company. 最后一个是Decima API，Guerrilla一些程序员希望给这个框架打造C语言API，以便让某些工具可以运用于其他语言，比如文件加载/存储、目标控制等功能，我们还用Python写了一个wrapper，让学过Python的美术师和策划都可以创造控制游戏内容的脚本。 随着项目研发的结束，我们有了更多时间审视工具框架，这些工具是非常成功的，但我们发现还有很多可以提高的地方，比如让更多团队使用我们的编辑器，例如特效、环境美术等等，所以，我们还将开始打造不同的编辑器，比如Entity、粒子、着色器等等，让公司里的每个人都能使用我们的编辑器。 We're also looking to rewrite the GameSync system to take the 3D editor out of the process in order to improve stability, and we've seen a lot of UI and UX improvements in the editor process, so there's a lot of work to be done. 我们还希望重写GameSync系统，把3D编辑器从流程之中剥离出来，以便提升稳定性，在编辑器打造过程中，我们还发现了很多的UI以及UX方面可以提高的地方，所以未来还有很多事情需要做。
|
评分
