你好，各位朋友，我是JulesGlegg，Riot的软件架构师，我是创作符文之地的工程师之一。LOR是一款以Leagueoflegends英雄联盟为背景的战略卡牌游戏——这是自10多年前LOL诞生以来，我们第一款完全自主研发的独立游戏！
一个全新的游戏意味着一堆全新的技术。虽然我们不能一次覆盖所有内容，但我很乐意让你了解一下我们是如何让LOR从无到有的。我将介绍我们是如何一步步让它成型直到我们可以玩，以及我们是如何继续使用我们的美术工具让它看起来像如今这样，再调整它以保持平衡，最后是如何在送给玩家之前通过添加动作和声音来使它变得生动起来的。
首先，关于LOR的一些基础事实:
它是用Unity制作而成的；
它运行于Windows电脑、安卓系统和IOS系统。
几乎所有的代码——包括客户端和服务器端——都是用C#编写的。C#是一种静态类型的语言，它优先考虑正确性和易读性。设计者能够使用Python来创建脚本化的内容，比如卡牌和任务。
我们使用Git和LFS进行版本控制。LFS很重要，因为游戏包含大量的纹理、音频、供应商工具等二进制数据。
就像它的“姐姐”英雄联盟一样，LOR被设置为每两周更新一个补丁。这意味着对我们来说，在维持游戏的主要开发线的稳定前提下，并确保所有具有新特性或新游戏性的高压测试都能在分线同步进行，是非常重要的。
我跟你们讲，成为第二个游戏是有好处的。我们在Roit平台小组的朋友已经投入了巨大的努力，以确保我们所有的“研究和发展”的项目可以充分利用之前为全球玩家开发英雄联盟的基础架构。我们的团队从中免费获得了很多东西，包括新的启动器，它为我们提供了超高效率的补丁、推送通知等等——所有这些都基于英雄联盟客户端架构。
这种强大的基础使得LOR团队能够以许多其他团队都不具备的方式工作。我们甚至在内部使用启动器进行游戏测试！我们的只是看起来多了一点……混乱:
是的——那些都是Git分支。任何开发分支，从最小的bug修正到最大的检修，都可以在我们自己的测试环境中完全得到部署和修补。游戏设计者能够对游戏进行实验性的改变，并在几个小时内以团队规模进行游戏测试——这是游戏的新变革。
一旦我们有了自己的开发环境，就该开始工作了！现在，我们设计团队有的人对游戏应有的特性有一个模糊的概念。他们会说:
“我们真心希望玩家能够感受到被鼓励在LOR中尝试新牌，所以让我们确保他们在玩的时候有稳定的新牌来源来构建他们的新卡组。”
嗯，我们有无数种方法可以实现它。在我们玩之前，我们不会真正知道我们是否选择了正确的途径，所以我们可能要尝试一些不同的方法。我们需要以一种能让我们快速实验的方式来构建游戏。这意味着尽可能多地确保添加特性只涉及到制作与那些特性直接相关的东西。我们在这方面并不完美，但团队在这方面已经取得了重大进展:
图片:核心系统帮助我们快速构建和迭代特性，避免每次都走重复的路。许多这样的系统都是直接从英雄联盟客户端获得的经验！
我们的第一个原型客观上来说是丑陋的，但是功能齐全，这种水平的打磨被团队亲切地称为“开发者艺术”。这是LOR的奖励界面的早期版本，有一些开发工具可以让我们在不同的层次上体验。这个版本的体验被分成了几个章节，并被主题化地呈现为穿越符文之地的旅程:
为了理解这个美丽的、淡雅的开发者艺术原型是如何制作的，我们需要理解四个常见的Unity概念:
Unity游戏中的“世界”是由GameObjects组成的。GameObjects可以包含其他GameObjects，并且可以在世界中定位，但是它们没有自己的任何真实行为。将它们与HTML中的DIV元素进行比较。
GameObjects只在你添加一个或多个组件的时候才会做事情。组件可以把一个GameObjects变成几乎任何东西——一个照相机，一个玩家角色，一张卡片，一个按钮，一个声音发射器，或者任何我们可以想象的东西。组件是用代码编写的，但是它们可以在统一编辑器中分配给游戏对象。
组件可以被赋予属性来定制或配置它们的行为。属性可以是字符串或数字之类的普通值，也可以指向其他Unity对象，从而允许组件之间相互通信。属性是在代码中定义的，但是可以在Unity编辑器中使用拖放来连接。这是工程师为美术设计师提供基础的手段。
游戏对象、组件和属性的排列可以保存为一个预置，允许我们根据需要生成多个实例。你可以把它们想象成模板。
让我们通过这些统一概念的镜头再看一下界面。在这种情况下，一个工程师已经创建了一个名为RewardsScreenController的组件，它负责加载和显示玩家的进度和奖励。为了做到这一点，游戏需要知道哪个游戏对象将包含奖励，哪个预置将用作奖励的模板，哪个文本标签需要更新以显示当前级别，等等。所有这些都显示为组件上的属性，允许我们的美术设计师使用不同的布局和视觉样式——他们所要做的就是将东西拖放到组件上来连接它们:
上面展示的原型水平显然不能交付给玩家，但是它已经足够接近了，团队可以尝试一下，看看我们做的东西是否有趣。假设我们对结果感到满意，我们将尝试一个稍微更完美的版本——如果我们做得好，这可以在代码几乎没有变化的情况下完成。
“奖励”界面中的每个组件都连接到各种文本字段、图像占位符以及填充其内容时应该使用的预设。这是绝对理想的，因为它允许美术设计师在后期大规模地改造屏幕的外观——我们做到了，因为这种设计在当时感觉很好。下面的截图显示了一位美术设计师花了一些时间修复开发人员的作品后的“奖励”界面:
图:奖励界面的早期迭代，这一次是在一个美术设计师修复了一些东西之后。奖励界面的早期迭代，这一次是在一个美术设计师修复了一些东西之后。
我们刚刚概述的实践非常适合我们定制仅限于单个界面的内容，但同样重要的是，我们要赋予美术设计师推动界面之间一致性的能力。令人难以置信的是，一个不合适的字体大小或一个过时的按钮会让游戏感觉没有完成或做得不好。
其中一些可以通过从单个特性中完全去除某些责任来实现，而使用核心系统(如对话框管理)，为每个特性提供相同的一致体验。其余的，包括像文本和按钮格式这样复杂的东西，需要一个更本地化的解决方案。值得庆幸的是，Unity编辑器是非常通用的，并且可以用你的游戏所独有的新用户界面来扩展。我们将其与ScriptableObjects(Unity的轻量级数据容器)相结合，将工具放入编辑器中，帮助美术设计师完成这些常见任务:
左图:按钮样式，指定组成按钮的颜色和纹理。右图:一种文本风格，具有自动应用于中国玩家的覆盖。
为了使文本格式与游戏的其他部分保持一致，美术设计师只需要在任何游戏对象中添加一个“可样式化的文本”组件，并拖动他们想要使用的样式。如果我们以后再来看这个款式，它会自动更新。这里有一个折衷方案——更新一个风格可能需要测试客户端的大块，以确保你没有破坏任何东西。我们发现这种折衷是值得的，以确保我们在游戏中有一个有限的、一致的文本样式集。
您可能已经注意到，文本样式编辑器允许美术设计师在移动平台上选择不同的大小。这对于可访问性来说非常重要，因为许多移动设备较小的屏占面积和较高的分辨率在许多情况下会使文本难以辨认。除了屏幕尺寸的挑战之外，我们还需要对越来越多的利用屏幕形状的设备保持敏感——用浮动摄像头穿透屏幕，或者用摄像头缺口遮掩屏幕的可视区域。为了让美术设计师能够在各种条件下测试他们的作品，我们在Unity中添加了一个模拟器工具，将游戏设置为适合设备的长宽比，并加载到一个凹口图像中，以指示哪些(如果有)内容将在不同的设备方向上被遮挡:
这个模拟器工具配有一个小组件，美术设计师可以把它放在任何用户界面对象上，自动限制它进入“不安全”区域，上面用红色表示。这个工具对速度至关重要，因为它帮助我们(大部分)避免了在物理设备上构建和部署游戏的繁琐的过程，这只是为了测试一个小的布局或格式变化。
代码和艺术创造了功能，但内容创造了游戏。因为我们希望随着时间的推移给玩家提供大量的内容，我们需要给我们的游戏设计者一个坚实的创作工具。幸运的是，英雄联盟的设计师们已经制作和发布内容很多年了，他们已经创造了实现这一目标的工具。
就像英雄联盟一样，我们的游戏使用Roit游戏数据服务器来创作游戏中的每一个内容——从卡牌到任务，从教程到箱子。正如我们从BillClark关于RGDS的帖子中了解到的，这个系统是由一个定义文件提供的，这个文件告诉它游戏中所有不同类型的内容。通过用我们的C#代码生成的文件替换联赛定义文件，Riot编辑器工具很方便地变成了一个LOR内容的编辑器:
您可能想知道为什么，既然我们对如此多的客户端数据使用UnityScriptableObjects，为什么我们不对内容使用它们。这有两个原因——首先，内容需要对客户端和我们的托管服务都可用，所以Unity特定的技术不能满足我们的需求。第二，我们可以使用RGDS的看家本领:层。
层允许我们整齐地划分内容，这样不是所有的内容都可以运行。我们仍在研究的东西不可能被应用到运营游戏中(抱歉，模拟游戏)，但仍然可以在我们的内部环境中进行游戏测试。同样的系统可以用来在特定的环境中对游戏进行冒险的实验性改变(比如说，让漫游女郎SheWhoWanders成为一张1费卡)来进行游戏测试:
有时，游戏内容会有相关的美术内容。卡牌和战利品是很好的例子——每张卡牌都有一个(潜在的巨大的)美术、VFX、动画和音频的捆绑，每件战利品都需要一个3D模型和一组动画来庆祝你收到它。这是一个很难解决的问题，因为它正好位于Unity内置资产管理和我们工作室专用数据工具的交叉点上——我们希望美术设计师能够在编辑器中创作内容，但我们也需要避免运送所有存在于未发布的RGDS图层中与未来内容相关的资产。
这个解决方案当然是一个折中方案，但是它对我们很有帮助——我们扩展了RGDS编辑器来支持直接引用磁盘上的Unity预置(艺术)和ScriptableObjects(数据)的字段。我们的构建过程确保相关层中引用的Unity资产被应用，而未发布层中的内容暂时被隐藏。
图:一个美术设计师创建了一个奖励对象作为两个文件——一个包含3D模型的预置，和一个定义打开、显示或升级对象的动画的脚本对象。
通过将RGDS与我们的可部署Git分支系统相结合，LOR团队中的任何内容或系统设计者都有可能通过他们选择的任何实验性改变来快速部署他们自己的游戏实例——不需要工程师！
到目前为止，我们的功能在一个内部环境中是完全可玩的，它有一些不错的艺术性，在截图中看起来不错，但是仍然缺少一些东西。没有生命，没有运动，没有声音。这意味着是时候让我们的动画美术设计师参与进来了。
就像把一个开发人员的艺术原型转变成一个更容易实现的静态艺术形式的过程一样，这个过程从一个小小的工程工作开始，但是很快转变成一个主要由美术设计师主导的迭代循环。
在尽可能高的级别上，工程师将属性添加到他们的组件中，允许提供某种形式的动画。工程师不知道动画的长度或内容，只知道当特定事件发生时，应该针对特定的一组游戏对象触发它。例如，当玩家导航到一个新界面时，我们会在旧屏幕上播放美术设计师定义的outro动画，在新屏幕上播放intro动画，然后允许进一步的动作发生。为了完成这些事情（此处原文