Get best of the week

测试Amazon Lumberyard游戏引擎。方法和工具

亚马孙游戏。听起来不寻常？如何为开发人员和游戏玩家测试产品？在对Amazon Lumberyard游戏引擎进行简化测试之后，可以进行手动测试和自动化方法以及项目中使用的工具。



Lumberyard是一个跨平台的游戏引擎，您可以在其中免费为大多数现代平台免费创建游戏：PC，Mac，iOS / Android，所有控制台，包括虚拟现实眼镜。它还与Amazon Web Services和Twitch的游戏广播服务深度集成。

下切-阿尔乔姆Nesiolovsky从报告的视频和成绩单Heisenbug会议。




演讲者简介：毕业于控制论系莫斯科工程物理研究所，从事开发和测试超过8年。他既从事桌面项目，例如GeForce Experience，在线MMORPG Lineage II，也从事移动游戏-Cut the Rope游戏以及Yandex.Images网络项目。他目前是Amazon Lumberyard项目的Amazon自动化工程师。

职位结构


  • 游戏引擎：功能以及测试引擎和测试游戏之间的差异。
  • 手动测试：我们如何尝试通过功能测试来发现项目功能的覆盖范围。
  • 自动化：我们随后填补并处理的错误和颠簸。
  • 我们用来使引擎自动化的工具。
  • 您自己玩游戏时可能遇到的有趣项目错误。


代表讲者的进一步叙述。



亚马逊为什么要玩游戏？2014年，亚马逊像许多科技巨头一样指出，游戏正成为人类第二大最受欢迎的娱乐形式。奇怪的是，第一个是电视，或者说是与视频流有关的所有内容（YouTube，Netflix和其他所有内容）。游戏开发人员也开始更积极地将AWS服务用于其在线游戏。

亚马逊决定在三个支柱上构建生态系统：开放其游戏工作室以创建人们可以在Twitch上观看和观看的游戏。这些游戏还将展示使用AWS Cloud可以实现哪些有趣的游戏构想。

它是如何开始的？


2004年，德国公司Crytek发行了一款名为“ FarCry”的游戏。一段时间后，Crytek开始为其构建游戏的引擎授予许可，以便第三方公司可以使用完成的引擎并开始创建游戏，游戏玩法，并在不花费大量技术投入的情况下为其填充内容。当亚马逊开始玩游戏时，它还立即开设了几家工作室，并开始开发几款游戏。

为了使每个工作室都不会发明自行车-它自己的渲染引擎，动画系统，物理等，Amazon许可了CryEngine版本3，并立即启动了几款游戏的开发。大巡回赛已经在Xbox和PlayStation上发布。正在开发另外两个：MMORPG“新世界”和在线射击游戏“ Crucible”。在这些游戏的开发开始之后，亚马逊开始免费提供开发这些游戏的引擎。由于它与Amazon的云服务高度集成，因此您可以吸引更多人使用AWS。



游戏引擎是一组API，是用于构建未来游戏的游戏引擎。为了使开发人员无需编写自己的游戏系统，您只需采用一组API，即引擎，然后开始编写自己的游戏逻辑，在其中添加内容并进行创造，而不是从头开始开发技术。另外，某些引擎具有编辑器。这是一个桌面程序，您可以在其中创建关卡，即打开关卡并在那里添加内容和游戏逻辑。

有时不用聊很长时间，而是放一个视频：

链接到视频8：33-9：53

这是我们的编辑器及其界面。游戏在其中启动，我们与引擎一起提供。存在“入门游戏”，以便人们可以登录，播放，更改某些内容并弄清楚其工作方式。

通常，可以将3D游戏想象为一组在三维世界中移动并以某种方式彼此交互的三维对象。在此视频中，您可以看到：

  • 具有纹理的静态几何体：土，石头，草，树；
  • 动态几何-角色具有动画效果，对玩家的动作做出反应；
  • 用户界面：任务视图在左上角。

玩家可以遇到敌对角色，游戏逻辑将会出现，并且有可能射击-机器人会做出反应。关于物理：角色将开始在枪管处射击，他们会从与镜头的碰撞以及与角色的交互中移动。您可以随时在编辑器中退出游戏模式并返回到编辑模式，在该模式中，您可以立即更改对象的属性，移动它们，然后该属性会立即出现在游戏中。想象大约有几个地方可能出问题，发生故障并停止正常工作？

如何测试引擎？


测试引擎基于三个要点。首先是测试编辑器和工具：正确的操作，应该打开的工具，没有崩溃的东西，应该正确显示的所有内容，应该正确执行用户脚本，没有附带错误的游戏创建过程。只有游戏创作者才能使用编辑器。第二个是测试引擎本身或引擎API。反过来，游戏引擎是将起作用的部分代码，包括在玩家的计算机上。通过预先创建关卡和游戏来测试项目的这一部分。随后，可以在引擎的每个新版本上测试创建的级别，以确保在一个或另一个级别上使用的所有游戏元素都可以正常工作。第三部分是基础设施和兼容性的测试：可以使用不同的参数配置和构建引擎，可以将游戏部署在各种设备上，并且外观和工作原理几乎在任何地方都相同。
项目

的功能第一个功能-我们支持大多数现有的游戏平台。尽管编辑器本身仅在PC，运行时即可以在Mac，智能手机，游戏机甚至虚拟现实眼镜上构建游戏。

第二个功能-我们的用户-这是两种类型的人，他们的要求完全不同。一方面，他们是将致力于创造游戏的开发人员，程序员，艺术家和设计师。另一方面，这些是游戏玩家，游戏将在其上运行的机器上进行。这两组的要求完全不同。

第三个功能-在这样的程序中，它允许您创建一些新的东西，因此暗含了该应用程序可能的最大范围产品。在我们的引擎上，您可以制作任何游戏，从简单的游戏（例如俄罗斯方块）开始，到以成千上万的人同时玩一个复杂的在线项目结束。

所有这三个功能极大地影响了自定义脚本的数量，每个自定义脚本都需要进行测试。



看一下这个屏幕快照，想象一下您可以为该部分功能编写多少个测试用例？总共，我们在该项目上有超过11000个测试用例，并且该数据库每年以大约3-4 000个测试用例增长。

链接到视频13：20-13：54

我们发现了几个组件相互交互过程中的大多数错误。在此视频中，正常状态的积雪会按原样显示在多维数据集上，但是一旦角色开始与他互动，积雪就开始消失。我们发现的大多数错误都在几个组件合并的地方。

链接到视频14：08-14：41

但是，只有两个条件时，错误并不总是发生。当多个组件同时收敛时，经常会出现错误。在这种情况下，我们正在考虑在正常情况下角色只是站在地面上的错误。值得增加另一种自由度-将角色举到地面上方：当他跌倒时，动画开始播放，并且摄像机接近/移开-纹理开始消失。在这里，三个组件一次相互作用：高度，角色动画和相机距离。不可能事先考虑所有这些选项，并且通常我们只会在临时测试中发现此类错误。

链接到视频15：02-15：49

还有另一个功能-我们有许多不确定的系统。在这些系统中，使用相同的输入，最终结果可能会有所不同。一个简单的例子是系统中存在随机变量。在我们的案例中，这些是物理系统，其中有许多带有浮点数的计算。在不同处理器或编译器上的浮点运算可能会有所不同。因此，最终的功能将始终略有不同。结果，这种系统很难实现自动化，因为很难向机器解释这种情况下的错误，而在这种情况下，这是可以接受的差异。

链接到视频16：03-17：14

在引擎和编辑器本身中有许多非平凡的交​​互。用户经常使用鼠标和键盘在三维空间内进行交互。该视频将具有称为“模拟对象”的功能。穿戴角色时，穿戴在角色上的东西必须根据物理定律运动。例如，衣服或公文包。作为视频中的此类元素-角色之手。当角色移动时，手也开始响应。通常，要测试此类功能，您需要做一些不重要的动作：在UI中进行切换，在三维空间中移动对象，进行拖放，还查看下面的动画图以及实时地进行所有操作。此功能影响自动化的复杂性。

如何确定覆盖范围？


在某个时候，我们意识到我们编写了许多测试用例，但是很难确定我们所覆盖的范围。我们发现大多数关键错误不是在我们的全面回归测试期间，而是在特别测试期间进行的，该测试是在发布周期结束时进行的。我们开始思考：我们拥有一个功能强大的引擎，我们拥有一个可容纳12,000个案例的存储库-如何了解在哪些地方覆盖的范围足够，以及在哪些地方值得添加测试用例？

我们转向测试理论，开始阅读人们如何定义测试范围。一种方法是通过源代码确定。就我们而言，这很难做到。我们有几百万行代码，不可能在短时间内完成此检查。第二种方法是通过需求评估来评估覆盖率。在敏捷过程中，需求通常只存储在人的头上，而不是存储在文档中，因此通过需求进行覆盖评估也是不现实的。结果，我们转向了唯一可行的方法-通过编写模型来定义覆盖率。



我们选择了一个称为ACC的模型-属性，组件，能力。 ACC是最简单的模型之一，在Amazon中用于建模软件非常普遍。该模型建立在三个主要支柱上。首先，这些是组成部分，名词是系统的主要工作部分。对我们来说，这是视口，纹理，游戏本质。以下是功能-动词-这些组件可以做什么。例如，它们可以在屏幕上显示，计算内容，移动内容等。第三部分是属性-与组件及其功能相关的形容词或副词。属性描述功能的参数：快速，安全，可伸缩，安全等。所有这些可以简化为三个问题：谁？他在做什么？如何？

我们将通过一个小示例来分析此模型。以下是一小部分功能的演示：

链接到视频19：59-21：02

视口是编辑器的可见层。视频显示，可以旋转摄像机，在水平面上移动，还可以从游戏对象的本地指挥中添加角色。您可以移动角色，或通过右键单击来创建新的游戏实体，可以选择该级别上的所有当前实体并将它们一起移动。您还可以添加另一个几何元素，并且（如在所有三维编辑器中一样）不仅更改其在空间中的位置，还可以更改其角度并调整其大小。名为“视口”的窗口具有不同的渲染模式。例如，关闭阴影，或者关闭某些后期处理的图形效果。您可以进入游戏模式以立即测试刚刚进行的更改。



让我们看一下ACC模型本身。我们很快意识到，使用Mindmaps创建这些模型非常方便，然后将它们转换为平板电脑或直接转换为TestRail或任何其他测试用例存储库中的结构。主要组件本身在中央的视图中是可见的-视口-并且从红色分支上方可以看到视口功能，该功能使您可以在水平面上移动：可以旋转摄像机，也可以使用“ W”，“ A”，“ S”，“ D”按钮进行飞行。

他的第二个机会（橙色分支）是通过Viewport或从游戏资源管理器中拖放来创建游戏实体。

第三，可以操纵游戏实体：可以区分它们，改变位置，旋转等等。切换渲染模式时，左侧的绿色分支是视口配置。属性在蓝色分支中突出显示，指示视口还应满足某些性能参数。如果放慢速度，那么开发人员将很难做任何事情。

然后将整个树结构传输到TestRail。当我们将测试用例从以前的系统转移到新结构时，立即清楚地知道缺少测试用例的地方-在某些地方出现了空文件夹。



链接到视频23：01-24：10

这些结构增长很快。视口实际上是指编辑器，它只是引擎的一部分。两个主要部分：编辑器本身和游戏引擎本身。在上图的右侧，您可以看到与树无关的几个组件。例如，在渲染或脚本系统中，动画是独立的，因为它们与编辑器和引擎都直接相关。也就是说，渲染系统将在最终设备上运行时运行，但是在编辑器本身中，可以更改一些参数：白天和黑夜的时间，编辑材质，粒子系统。

结果与结论


ACC建模有助于突出受检者所在的领域。填补覆盖范围的空白，在我们完全回归通过之后发现的错误数量减少了约70％。易于构建的ACC模型也被证明是很好的文档来源。参加该项目的新人们对其进行了研究，并很快就对引擎有了一些了解。 ACC模型的创建/更新紧密包含在我们开发新功能的过程中。



我们开始通过用户界面自动化来使引擎自动化。编辑器界面编写在QT库中。这是一个为桌面应用程序编写跨平台UI的库，该库可以在Mac和Windows上运行。我们使用了来自Froglogic的称为Squish的工具，该工具可在与WebDriver相似的系统上工作，并针对桌面环境进行了调整。在此工具中，使用了一种类似于Page Object（来自WebDriver的世界）的方法，即所谓的“复合元素体系结构”。在主要组件（例如“窗口”或“按钮”）上进行选择，并注册可通过这些元素执行的功能。例如，“右键单击”，“左键单击”，“保存”，“关闭”，“退出”。然后将这些元素合并为一个结构，您可以在脚本中访问它们，使用它们，截屏并进行比较。

问题与解决方案


第一个问题是稳定性。我们编写了通过用户界面测试业务逻辑的测试-这是什么问题？当业务逻辑没有改变，但是界面改变了-测试失败时，您需要上传新的屏幕截图。

下一个问题是缺少功能。许多用户案例不仅在于按下按钮，还在于与三维世界互动。该库不允许这样做，需要新的解决方案。

第三个问题是速度。对于任何UI测试，您都需要完全渲染整个引擎。这需要时间，用于这些测试的机器必须足够强大。



该解决方案采用Shiboken库的形式。该库提供了Python中C ++代码的绑定程序，这使得可以直接调用由编辑器或引擎提供的函数，而无需呈现UI编辑器。 Web世界的类似物-无头自动化（类似于PhantomJS）-您可以在不启动浏览器的情况下自动化Web应用程序。在这种情况下，类似的系统仅适用于用C ++编写的桌面应用程序。

在开始对该框架进行投资之后，我们意识到它不仅可以用于自动化测试，还可以用于自动化引擎内部的任何流程。例如，设计师需要连续放置100个光源（例如，他在修路，而您需要放置灯）。无需手动表示所有这些光源，您只需编写一个脚本即可创建游戏实体，并在其中添加点光源，并规定复制以前创建的点光源需要每10米复制一次。通过自动执行日常任务的工具的形式，为我们的用户带来了红利。



解决问题的第二部分。我们很快意识到，要使引擎的各个部分（例如图形和网络部分）自动化，我们需要完全不同的框架。创建一个单一的，可怕的框架来帮助一次自动化所有事情是不可能的。因此，我们开始开发一个名为Lumberyard Test Tools的框架（简称-LyTestTools）。它基于Pytest（很多东西都用Python编写在引擎中）。我们决定使用所谓的即插即用架构-自动化工程师的中心团队编写了框架的主要部分，该框架可以下载，配置引擎，将其部署到各种平台，运行测试和收集日志，将报告上传到我们的数据库或S3并绘制Quicksight中的图形。即插即用是通过测试助手实现的，这些将由开发功能的领域的团队编写。

也就是说，图形开发团队将使用屏幕截图进行测试，而网络交互团队将检查转发的数据包。同时，它们都将连接到我们的通用框架（因为两个团队都开发和测试单个引擎的模块），因此它们都具有用于运行测试和生成报告的相同接口，从而使所有内容或多或少都可以在我们的CI上正常或正确地工作。 /镉。

与伐木场的互动


桌面应用程序的交互/自动化方式有哪些？框架和引擎之间的第一种交互类型-直接从Python，如果应用程序暗示通过命令行启动，则使用Subprocess函数启动该过程。您可以从标准输入/输出输出读取输入/输出，从而进行断言。下一类-通过日志分析进行的交互-您可以读取和分析应用程序剩余的日志。第三是通过网络。在游戏启动器中，有一个名为“远程控制台”的模块。当设备上的某个端口打开时，我们的框架可以发送数据包/特定命令。例如，拍摄屏幕截图或打开某些特定级别。另一种方法是通过比较视觉信息进行交互，即屏幕截图。前面还提到了直接通过产品API调用应用程序功能的方法（在我们的示例中，这是通过Python绑定到C ++编辑器/引擎功能的调用）。

让我们继续介绍使用我们的框架自动化引擎的示例。

看一下这个屏幕截图。



这个站点的细节很高-大量的植被。在现代游戏中，关卡可能需要数十和数百个游戏公里。当然，这些游戏灌木丛都不是手动放置的，否则开发人员只会发疯。对于他们来说，我们的引擎有特殊的工具。

其中之一被称为植被工具。小型演示：

链接到视频32：18-34：06

我们看到了标准的起点。有地形，您可以很快松一口气：在背景中翻山越岭，在中部还突出了一座小山。您可以使用草纹理将地面本身涂成绿色。进一步说明了增加植被（在这种情况下为树木）的过程。几何-树已添加到工具中-突出显示了其中的一个子集，并可以使用这些树绘制任何必要的图形。这是一个非常简单的示例，此工具具有许多可自定义的参数。例如，您不能一次选择一棵树，而是一次选择几棵树，并为其设置一个参数，彼此之间保持一定距离，或者为这些树的大小或旋转设置随机参数。您可以添加游戏角色并立即在关卡中进行测试，您刚刚在自己的游戏花园里种了什么。

现在，我们以几个测试为例，看看如何使用我们的框架自动实现此功能。

链接到视频34：20-34：58

这里有一个标准的地形，并且上面种着许多相同类型的草。这种类型的渲染非常占用处理器资源。如果有很多这样的元素，则可以进行负载测试。这里添加了一个游戏脚本，当启动游戏模式时，该脚本将简单地穿越此关卡。任务是测试此功能并验证游戏启动器是否稳定并且不会崩溃。



这是开发用于生长植被的功能的团队如何编写Test Helper（允许您使用这些功能）的示例。这是使用我们的框架的一个例子。启动器类以绿色突出显示。测试开始时，将部署启动器，并从超时参数开始，然后执行一个断言以验证启动器在一段时间后不会崩溃。然后我们将其关闭。



上面的参数化代码表明，我们可以在不同平台上重用相同的代码。而且，我们可以在不同级别或项目中重复使用相同的代码。例如，平台以红色突出显示：在一种情况下为Windows，在另一种情况下为Mac。该项目以黄色突出显示；名称级别以浅黄色突出显示。

链接到视频36：07-36：47

现在介绍测试-在这种情况下，请通过命令行运行它。将打开一个名为“资产处理器”的程序，该程序是引擎的主要部分之一。该程序将源资产（例如，艺术家创建的模型和纹理）处理为引擎可以理解的格式，并将所有内容写入数据库（SQLite），以便引擎可以在游戏过程中快速导航和加载必要的数据。接下来，启动器启动，游戏模式开始，相机在水平上方飞行几秒钟，测试结束。我们看到一个测试成功，而两个测试被跳过。发生这种情况的原因是，在录制视频期间，测试是在Windows上进行的，在参数化过程中，分别有两个平台在启动过程中被跳过。



还有一个更困难的选择。我们不仅启动完成级别的启动器，而且脚本直接与编辑器交互。蓝色表示将与编辑器一起使用并通过API提取各种命令的单独脚本的名称。



以上是测试级别。在这种情况下，使用预先准备的纹理（蒙版）在标准地形上绘制微笑。有必要确认使用面罩时，仅沿先前选择的轮廓进行喷涂，并且不会超出范围。



与游戏世界合作的团队编写了与Terrane合作的扩展，然后将其插入到我们的框架中。将创建一个新的画笔，该画笔将在“鹅卵石”蒙版上绘制，将画笔设置为红色，并在所选图层上绘制。



继续创建新的画笔，并为其设置不同的强度。不再使用遮罩，并且在循环中，已经在关卡的另一部分中绘制了新元素。

让我们看看这个脚本是如何工作的。

链接到视频38：42-39：35

首先，资产处理器将启动，它将检查资产数据库的状态并在必要时处理新添加的项目。接下来，编辑器启动。该级别将打开并带有微笑，并且脚本将随编辑器一起运行。他在蒙版上绘制了图层，然后创建了一个蓝色圆圈，并开始拍摄屏幕截图。随后，将屏幕截图与参考屏幕截图进行比较，如果一切正常，则测试将完成。

该测试将截取此类屏幕截图以与标准进行比较。在这里，您可以看到图片沿边框清晰显示。

平面艺术


我们还使用我们的框架来测试图形。

链接到视频40：04-40：56

图形-引擎最困难的部分之一，它占用了大部分代码。您可以并且应该检查所有内容-从简单的东西开始，例如几何和纹理，再到更复杂的功能-动态阴影，照明，后处理效果。在右上角的视频中，您可以看到水坑中的倒影-所有这些都可以在我们的引擎上实时运行。当相机在内部飞行时，您可以看到更高级的渲染元素，例如眩光，透明元素（例如玻璃）以及元素（例如金属表面）的显示。如何使用屏幕截图测试此功能？



这是我们的角色Rin。有了它，我们经常测试艺术家管道。艺术家在其编辑器中创建某些内容（例如，角色），然后在其上绘制纹理。资产处理器处理原始数据以将其部署在各种平台上，图形引擎将处理显示内容。



当然，当“纹理未加载”时，您经常遇到错误。实际上，在显示纹理时发生了很多问题。



但是通过比较屏幕截图可以很好地抓住所有这些。在第一个屏幕截图中，您可以看到一个错误-一些材料加载得不好。在这些屏幕截图中，摩托车和照相机在咖啡厅内飞过的高度相同，如先前视频所示。为什么这里的一切看起来很无聊？由于屏幕截图不是在渲染的最后阶段拍摄的，因此图形引擎会分阶段地布置所有效果。首先，仅渲染简单的几何图形和纹理：去除阴影，去除复杂的照明元素。如果您在最后阶段测试所有内容并查看Diff Image，将很难说出到底发生了什么。



如果分阶段执行此操作，则可以大致了解图形引擎的哪个部分出了问题。这是我们比较屏幕截图的算法。



通过比较屏幕截图，您可以测试图形，显示元素，纹理，材质，着色器。

我将举一个例子说明当我们没有此框架时，旧版本引擎的一个错误。

链接到视频43：10-43：44

它与植被系统有关。添加树后，图形部分开始在树下绘制阴影。必须按“ Ctrl + Z”（“取消”），树木消失，阴影仍然存在。如果您在开始时截取屏幕截图，当树站立并且单击“取消”后，与之前和之后的参考屏幕截图相比，在自动模式下很容易捕获到这样的错误。

通过比较屏幕截图，资产管道也得到了很好的测试。当艺术家在3D编辑器（Maya，3dsMax）中创建某些东西时，您需要检查游戏中所有内容的显示方式是否相同，并且没有丢失：鸡有羽毛，所有动物都有毛皮，人有正确的皮肤纹理，其他事情。

链接到视频44：16-44：52

程序的右侧是资产处理器，它监视游戏者画的所有东西在游戏中的显示。他将告诉我们，这些资产一切正常-它们应该起作用。在视频上，您可以看到一些树木变黑了。有些显示正常，有些绿色纹理消失了。自然，您无法以这种形式发布引擎或资产。

并非一切都能被抓住


链接至视频45：03-45：17

仅当多个元素相互交互时，才会形成某种错误。如果将两个Rin模型相互移开，则将正常显示它们，但是如果将它们拉近，则会出现几何问题。不幸的是，即使在自动化之前，也很难捕捉到此类错误。通常，只有当测试人员开始在探索性测试模式下执行某项操作或引擎已经落入客户手中时，它们才会被注意到。



通过比较屏幕截图，您可以测试编辑器本身的界面。

游戏组成




此外，屏幕截图可以测试一些简单的游戏组件。一个简单的示例就是一个简单的关卡，上面有一个门和一个脚本，当您按空格键时，该脚本会启动门的打开和关闭。

您可以在开始和结束时截取屏幕截图。如果一切都匹配，则更改元素位置的脚本将正常工作。

经


我们很快意识到，在不同的平台上，具有相同功能的屏幕截图会有很大差异，在某些情况下，根据视频卡的类型，同一平台上可能会有差异。如何处理，以免存储100500张屏幕截图？Windows Advanced Rasterization Platform是一个工具，它是一个软件渲染器，可让您执行所有图形而无需使用驱动程序和视频卡。使用此工具，您可以驱动大多数功能图形测试，而无需依赖驱动程序和硬件。

性能


最后但并非最不重要的一点是，游戏引擎必须高效！可以使用各种图形分析器（例如PIX）测试GPU。可以在Visual Studio本身中测试RAM。此外，有关如何使用RADTelemetry工具测试处理器性能的更多信息。

知道什么是输入滞后？

链接到视频47：29-48：21

输入滞后-这是玩家按下控制器/键盘键与游戏开始响应按下之间的延迟时间。输入滞后的发生是由于网络上的数据传输，当数据包经过很长时间或服务器长时间响应，在引擎中并且没有使用网络时。当有人弄乱了负责动画的代码时，输​​入滞后可能会变得很高，以至于角色开始响应太迟。大概可以很容易地对其进行测试：打开虚拟键盘并拍摄视频，在该视频上记录按下空格键的时刻和动画开始的时刻。

我们看一下引擎每秒发出多少帧。您可以计算每帧花费了多少毫秒（1000 / FPS）。如果逐帧播放视频，则可以计算自从单击开始到角色开始移动之前经过了多少帧。知道每个帧占用多少毫秒，可以计算出在按下空格和动画开始之间经过了200毫秒。对于标准的100毫秒人类响应，这太慢了，游戏玩家会立即说这样的延迟毫无价值。这种测试方法有其问题。首先，会有错误。例如，虚拟键盘会有延迟。其次，在游戏中，艺术家经常制作动画，以使角色不会立即开始成为主要动作。所谓的期待：在采取主要行动之前，例如，通过跳跃，角色首先弯曲一点，然后才开始跳跃。这可能需要几个框架。我们是如何战斗的？我们开始以更准确的方法测试此部分。

有一个名为RADTelemetry的程序。

链接到视频49：44-50：47

它允许您分析处理器。垂直框架在此处布置：编号629、630-您可以看到每个框架花费了多少时间。如果应用程序是多线程的，则将处理器内核或应用程序执行线程水平放置。如果单击任何线程，则在启动时该线程中所有功能的名称，它们从总执行时间需要花费的时间，执行的次数将显示在左侧。使用此应用程序，您可以准确地了解自游戏注册按键以来到启动“播放动画”功能之前已经经过了多少时间。该程序能够将其日志放入文本文件中，然后使用它们可以在时间分布中绘制不同构建的有用性能图表。

AWS在哪里？


最后，关于AWS的几句话。一方面，我们使用它来驱动我们的测试。我们在EC2和Device Farm中的设备上运行测试。将结果添加到S3中的数据库中，并在Quicksight上显示图形。可以在CloudWatch中查看测试统计信息。由于该引擎与AWS服务高度集成，因此我们也将手动和自动测试这些集成。例如，CloudCanvas是一项服务，允许您无需编程即可为网络游戏创建功能，也就是说，您可以在服务器上简单地配置排行榜，得分表和成就等芯片。对于诸如游戏货币化之类的事情，您无法寻找服务器程序员，而是立即开始使用CloudCanvas。 Amazon GameLift本质上是用于游戏服务器的可扩展系统。与Twitch集成-用户观看两个相互竞争的播放器的广播时。将创建一个Twitch民意调查“您支持哪个球员？” -人们开始在聊天中投票，游戏会读取答案，并且其中一名玩家（如饥饿游戏中的玩家）可能会失去或阻止额外的奖励。

摘要


我们意识到的第一件事是，在如此大型的项目中，没有任何一个可以使一切自动化的灵丹妙药。在我们的案例中，即插即用框架运行良好。我们编写了一个通用框架，并允许其余团队方便地嵌入其解决方案。通过使用屏幕截图和植被比较示例，系统展示了这些框架的工作原理。我希望本文提供的某些应用程序和工业解决方案（例如Microsoft的Software Renderer或RADTelemetry。）对于从事游戏或CAD系统工作的工程师来说是有用的。

最后，链接到报告中显示的所有工具：



我希望我能说出引擎测试与测试游戏有何不同。最近，这一过程已经向前发展了很多-测试游戏引擎并不简单，但是非常有趣。

如果您对测试游戏主题感兴趣，建议您查看其他报告：

More articles:


All Articles