偷懒！ 运营游戏团队

你想做什么？

您正在尝试制作游戏。 并从中赚钱，以便您可以制作其他游戏。

因此，请采取最短的路径来实现这一目标。

站在巨人的肩膀上

您为游戏带来了独特的东西-无论是背景，艺术风格，叙事，机制还是特定的程序算法。 但是对于其他事情，它可能以前已经做过了，那么为什么要自己做呢？

采用现有的软件，工具和库。 即使他们花了您钱，但从长远来看，它们的花销要比您打算在内部编写的“免费”东西少得多。 （它不是免费的。它会花费您开发，测试，文档，调试，移植和支持时间。）

使用游戏引擎，例如Unity，Unreal，CryEngine，GameMaker，Cocos2D，Torque或其他任何可以让您振作起来的引擎。 使用外部库-Havok，Bullet，FMOD，Wwise。 使用资产商店包装。

通常的反对意见是：

• “但是它们要花钱” -如今，大多数游戏引擎在您开始赚钱之前就不会这样做。 如果您从头开始编写每一行代码，则可能永远无法完成游戏。 否则可能是越野车，没人能为此付出代价。 难道不值得花一点钱吗？
• “但是我的代码会更好/更快” -Carmack先生，您现在可以停止阅读。 对于其他所有人-真的是这样吗？ 比起免费的Bullet物理引擎背后的团队，这些团队是由Sony，MIT，AMD和Google的人员贡献出来的，并且经过数十万人在各种平台和配置上的测试，您是否在编写物理代码方面更好？ 而且即使您的游戏代码更快，您是否还要编写一个关卡编辑器来配合它……？
• “但是我喜欢写代码” -太好了！ 这是很合理的话。 但是，这就是事实—您想编写一个引擎吗？ 还是要创建和发布游戏？
• “但是，如果有错误，您将无法获得源代码” —不再如此。 如果确实需要，主要引擎会提供源代码访问； 其他引擎是完全开源的。 许多库都是开源的。 您真的需要那种访问权吗？ 更多的人将测试该引擎，查找错误，整个团队将致力于在所有平台上修复它们。
• “但是它不能完成我想要的一切” -但是，如果您在开箱即用的引擎之上编写了一些系统，这可能吗？ 或者，如果您下载了一些其他扩展程序？
• “但是没有其他人写过这样的东西” –如果这是真的，那就是您出售游戏的独特之处。 您可能拥有新颖的程序算法或独特的机制集。 但这是否真的意味着您必须从头开始编写所有内容（包括核心循环，渲染器等）？ 还是可以简单地编写自己的独特代码并将其放置在已经存在的代码之上？

编码人员倾向于采取一种态度，即他们需要编写游戏中的每一行代码，以便他们可以完全控制它。 我知道，我本人是编码人员，因此经历了这一阶段。 随着年龄的增长，您意识到您真正需要做的是获得所需结果的最少工作量，否则您可能永远无法获得结果。 偷懒！

内部编写它们有很多很多弊端。 其中最重要的是’ 安娜被公共汽车撞了。 她下个月要住院。 没有人知道此代码的作用，我们有一个错误，该游戏将在下周启动……”

关于工具，无论是体素编辑器，精灵图集创建者还是本地化系统，可能已经存在可以实现您想要实现的功能的工具。 在推出自己的工具之前，请先查找现有工具-您现在可以拥有一些可以正常工作的工具，而无需笨拙的手动滚动界面，这会困扰您整个项目（并花费您时间）。 当然，您可能需要对这些工具进行一些集成以对您的管道进行排序，但是与编写整个工具相比，这是一个相对简单的任务。

但！ 切记先检查工具或库。 确保其他人正在使用它； 最好有很多其他人。 对于Unity Asset Store来说，这尤其重要，因为其中有大量未煮熟的半成品。 买者自负！

建立可以立即使用的东西

忽略花哨的图形，史诗般的故事，一万页的设计文档。 从在屏幕上移动的点开始- 可播放的内容-然后从那里进行迭代。 使您的基本游戏机制掌握并使用临时图形。 好玩 如果现在不好玩，那将永远不会好玩，无论您添加了多少风声。 如果不好玩，请将其丢弃并做其他事情。 与您发现之前写50个级别的设计文档所浪费的时间相比，您浪费了多少时间？

重复。 做一个有趣的事情。 测试一下。 让它变得更有趣。 再次测试。 向其他人展示，看看他们是否觉得有趣。 重复，扩展，添加新的想法，然后在不起作用时将其丢弃。 牢牢把握游戏的核心。

如果要编写完整的设计文档，请确保在编写核心循环和机制之前先进行钉牢。 否则，您的设计文档将被浪费掉，因为“这些技术很烂，我们应该重做吗？”

如果您要开发游戏故事，请在证明自己的技巧之前不要孤立地做。 您希望您的故事支持机制并与他们融为一体。 一定要勾勒出你的故事。 除非您精通游戏的运作方式，否则请不要把它钉牢。

有趣之后，将您的核心游戏扩展到一个垂直的层面-一两个级别，以测试所有核心机制的趣味性，并通过接近最终的图形和声音来测试您预期的外观。 这不仅使您能够在开始对每个级别进行建模之前证明您的概念，而且还为您提供了与发布者，平台所有者或投资者进行对话的有用营销工具。

尝试构建系统 ，而不是关卡。 一旦掌握了核心机制，就希望能够做到这一点。 现在，让我们有趣地将其扩展到50个级别。

始终有一款有效的游戏

永远不要进入一个状态， “是的，到本周结束，我们将完成粒子系统的更换，但是游戏现在不会构建” 。 您的游戏应该始终是可构建的，并且始终是可运行的，理想情况下应该没有错误。 如果一项重大功能需要花费时间，请发送编码器以在另一个分支上执行。 （您正在使用版本控制，对吗？稍后再介绍。）

不要让错误四处散布，以便日后修复，请立即修复。

这是因为：

• 您永远不会知道Biz Dev Guy何时会转身说“我需要一个版本才能在今天晚上向发布商展示！”
• 损坏的版本可能意味着您的艺术团队或声音团队陷入停顿。
• 您不希望错误扩散。 在开发结束时，错误修复阶段总是令人恐惧的-您可以通过控制自己来使其更轻松。
• 每当您的开发团队遇到未修复的错误时，都有可能使它们变慢。 所有的时间加起来。

总是有一个有趣的游戏

永远不要进入那种状态， “是的，现在有点烂，但是如果您忍受了，您会发现下一个乐趣的……”

不好 一直保持乐趣。 这对向其他人展示非常有用，它会让您和您的团队感到兴奋。 首先关注有趣的东西！ 您永远不会知道，也许您永远都不需要关心诸如适当的物理和碰撞检测之类的沉闷内容。 （请参阅： 山羊模拟器 ）

换句话说-不要将鸡蛋放在一个篮子里。

规划和构建可移植性

在发布游戏时（可能比您预期的晚了几年），也许您的目标-令人惊叹的AmstrødJoytopus-7控制台-已经过时了！ 如果对它进行了专门编码，以用光彩的7位浮点寻址Joytopus的7个自定义协处理器，您将怎么办？

或者，如果平台持有人大笔资金说“忘了Joytopus，我们希望您将它作为独家产品放到新的Nøntündo主机上”怎么办？

您需要同时考虑“嘿，它可能不在我想要的平台上”和“嘿，如果成功了，我们可能必须急于将其移植到更多平台上” 。

这并不意味着您需要立即为所有模型编写所有内容。 它的意思是您应该对输入代码之类的东西很聪明-使其变得如此，以便如果您突然需要容纳AmstrødJoytopus-8的新Mind-link控制器，则可以。

输入就是一个很好的例子。 如今，您可能想考虑几种不同的方式来控制游戏-通过触摸，通过键盘，通过控制器，甚至通过运动控件。 因此，请分开输入代码，以防您需要再次撕掉所有输入代码或添加备用代码。

如果您要为所有这些编写自己的代码，则对于任何特定于平台的内容（例如渲染，音频，文件访问，成就等）都相同。 （等等-为什么要为所有这些编写自己的代码？）

规划和构建本地化

这是出于几乎相同的原因-您可能打算仅以英语（国际）发布游戏，但是突然之间，您从一对想要为北极许可（饥饿）的北极熊那里取得了成功。 您现在想说“是的，请不要吃我” ，而不是“哦，呃，我们可能不得不重写一堆核心系统-aargh！”

将资产与行为分开

也许您的游戏注定不会成功，而您需要构建其他东西。 或者，也许它取得了巨大成功，并且您想制作一些DLC。 或者也许是时候开始下一场比赛了。

如果您的机制和行为很容易与资产分开，则可以轻松地添加新关卡，为续集重新设计游戏，或将可爱的平台游戏变成最小惊险的大气恐怖平台游戏。 或从该游戏中窃取一些核心系统，然后将其移至第二游戏。

而如果您的机械手与资产紧密相连，当您用“ 旅行危险：严重动作英雄”代替Fuzzywuzzy独角兽时，游戏就无法正常工作，那么您就有问题了。

但！ 立即构建您所需的东西！

不要构建具有多个面向未来的功能的游戏系统，“如果有人要添加功能X，功能Y或Z，则可以重用它们”。 因为那样的话，您实际上需要功能Q，结果您必须丢弃支持X，Y和Z的代码。

不要听你的编码员。 他们在这一点上是错误的。 他们喜欢编写代码以适应假设的情况。 坐他们 我自己对此感到内times的次数超出了我的计算。 过于复杂的“支持未来功能”的代码在有人添加未来功能时总是会被重写，并且编写时间要长两倍。 尽您所需要的最低要求，以使游戏立即运行。 偷懒！

这是很难达成的平衡。 通常，这与代码封装有关—我上面的输入控制器示例就是一个很好的例子。 不要用一堆通用的触摸代码编写控制台游戏，以防万一我们有一天需要支持触摸。 请将控制器输入代码全部放在同一位置，这样，如果您需要将其全部撕掉并替换掉，则可以。

精简一切。 这需要花一些时间，但是随着开发的进行，您的生活将变得更加轻松。 您可能需要使用编码器或脚本编写器（尽管Photoshop中的操作或Word中的宏也很有用）。 诸如Unreal和Unity之类的编辑器允许相当全面的编辑器内脚本编写和自动化。 Python非常适合将命令行工具粘合在一起或转换数据。

这些东西不需要太复杂-它可以只是一组有用的命令行批处理文件，团队中的每个人都可以访问。

消除摩擦

这里的关键是想想您在进行日常开发过程时会发生什么： “这项任务让您感到很痛苦吗？ ” ？ 如果是这样，那就减轻它的痛苦。

举例来说，您需要将位图导入到引擎中。

最简单的方法是记录文档。 如果要导入位图，则需要查找操作方法（例如，浏览源代码或查看外部工具的命令行选项，或者询问Anna），然后写下操作方法 （在整个团队都知道在哪里找到它的地方），这样您就不必再问安娜了。 （还记得那辆迎面而来的公共汽车吗？）

但是，如果该操作很简单（花了五个步骤），并且您可以肯定需要将更多位图导入到项目中，然后使其自动化！ 编写一个批处理文件，或使用一些导入代码扩展Unity。 一个好的经验法则是“这是我第三次必须这样做吗？”

自动化一切

过程是复杂的还是多步骤的？ 它是否需要在命令行上放置一堆硬接线号码？ 所有位图的质量是否均为90％，并且您必须记住在导入时进行设置？ 自动化！

这是因为：

• 您永远都不知道必须要做多少这些事情。 （ “我们又添加了50个级别！每个级别都有一个位图！”或“我们添加了一个全新的平台！” ）
• 您永远不会知道您将要重做多少这些事情。 （“ 我们已决定将所有级别的质量降低到60％！” ）
• 您永远不知道要让实习生Dave要做多少这些事情。 （ “什么是位图？” ）
• 您可能不记得设置了（ “我们说的是60％还是70％？有人写下来吗？我要检查最后一个还是猜一下？是NøntündoSp00n的内存容量中的75％吗？ ？’ ）

使您的游戏易于运行

如果有人拥有您的可测试游戏的副本，请使其易于运行。 不需要命令行访问，不需要重置屏幕分辨率，也不需要安装特定的驱动程序，也不需要从USB密钥复制过来。 保持它非常非常简单。 记住，您的Biz Dev Guy将会拥有它，并且您知道他的技术水平。 如果需要提前执行大量步骤（驱动程序，复制等），请双击游戏图标以实现此目的。

使您的游戏易于包装

还记得商务开发人员吗？ 他突然需要在明天早晨之前复制具有特定功能的最新版本。 现在是晚上8点。 您是否要开车去办公室并通过检查最新的源代码树，配置所有内容，测试所有内容，然后查找FTP站点详细信息并上传，为他完成任务，请记住该时间将是凌晨1点你什么时候结束？ 或者，您是否想说“我将它设置为现在-完成后会收到电子邮件”，然后单击一个Web链接？

如果可以，请使用某种构建系统（例如Ant，Make，Maven，Incredibuild或一系列脚本文件），并使触发和发布构建非常简单。 不只是为了BDG的利益-您将在发布前每隔几分钟自己做一次。

某些引擎的设置不能很好地完成完整的远程构建，但至少要使其成为一个批处理文件或单个菜单项命令来打包您的构建，更新版本号并将其导出到文件夹。

（当然，理想情况下，您希望能够说“嘿，Biz Dev Guy，通常经过下载的链接已经提供了经过全面测试的最新版本，就像您要求的最后10次一样”）—我们将讨论持续集成稍后。）

使您的游戏易于测试

该游戏的作者鲍勃（Bob）希望在塞舌尔的他的豪宅中下载并测试该游戏，以查看第73级的特定过场动画。

太好了，您已经有了构建和打包系统，因此他拥有了最新的副本。 那很棒。

但是，现在他必须打72个关卡才能达到那种过场动画，而且与83％的游戏编写者一样，他在任何手眼协调下都非常糟糕，所以无法通过1级。亲爱的！

现在，游戏崩溃在一个从未崩溃过的地方。

“发生了什么？”你问鲍勃。

他说： “我用法兰绒打了蜘蛛，然后游戏退出了Windows。”

“什么颜色的绒布？”

“我认为那是蓝色……不……绿色？ 一种蓝绿色。 我不记得了 无论如何……我必须走了，我的服务员把装满香槟的按摩浴池加热到了我需要治愈作家的街区的确切温度。”

您的游戏的开发版本应使其真正容易：

• 跳到任何级别的任何点。
• 允许作弊（例如上帝模式）
• 立即稳固地保存游戏状态的副本，以便可以将其还原或挖掘以进行调试。
• 稳健地加载已保存的游戏状态，因此您可以返回想要测试的内容。 （此外，保存/加载代码通常非常简单，如果将其保留到项目后期，则更容易修改/保存20倍-这意味着它可以更早地工作。）
• 保存游戏日志，理想情况下，保存核心转储或堆栈跟踪（询问编码器）。
• 报告有关主机系统的信息，例如图形和声音驱动程序。
• 允许截图。
• 将所有这些内容报告给您的错误数据库（您确实有一个错误数据库，对吧？）

将所有这些功能全部关闭以使其完全发布应该非常容易。 除非您希望所有玩家都可以进入上帝模式。

（将它隐藏在内部版本中也应该非常容易，但是可以通过某种菜单选项或“特殊按钮”来访问它。您需要能够立即在E3展厅看到此消息，而您的同志却拼命尝试摆弄三台火红的电锯，以使30名失望的顾客排队等候。）

添加更多调试选项

轻松进行更改游戏分辨率，打开/关闭玩家伤害，独立于玩家移动相机，以半速播放所有内容，显示所有物理碰撞，打开记录选项等操作变得非常容易。

鉴于我们“只做您现在需要的事情”的原则，当团队中的某人发现他们需要它时，您才真正需要添加这些东西。 但是要准备在开发过程中继续添加这些东西。

理想情况下，让它在运行时即时更改。 在最坏的情况下，让游戏开始时已经启用了许多这样的选项-一种特定的配置。 您可以在配置文件中指定它们！ 这导致我……

使数据文件可读

在可能的情况下，将可读取的文本用于您的关卡数据之类的东西，而不要使用乱码的二进制文件。 纯文本，XML或结构良好的JSON。 巨大的优势：

• 显然，这是可读的。 您可以查看一个数据文件，然后说“是的，没错”。
• 有什么不对的吗？ 您可以通过打开文本文件并查看来确定您的编辑器工具是否正在产生垃圾数据。 还是如果您的游戏代码有问题。
• 源代码控制系统（是的，我们将介绍这些）在处理文本文件方面要好得多-合并冲突，为您提供一种解决办法，那就是叶夫根尼（Yevgeni）添加了打破所有猫科动物NPC的数据线。
• 您可以轻松地自动执行需要对所有数据文件进行的更改（搜索和替换！）。
• 您可以轻松地编写基于脚本的预处理器来更改文本数据文件，甚至可以从其他类型的数据生成它们（例如，从电子表格中自动导入数据）。
• 您可以轻松地搜索特定数据（ “哪个级别指的是绊倒危险？” ）
• 如果尚未准备好编辑工具，则可以手动编辑文件。

但！ 编码员说…… 这些文件解析太慢，而且磁盘上太大了！

首先，在当今时代，这不太可能。 其次，如果您要这样做，您始终可以编写一个工具来提取文本并将其打包为二进制。 但是，使之自动化。 （并进行测试。很多。）

包括版本号

清楚地在每个版本中显示一个版本号，并在您制作的每个新版本中递增版本号（使其自动！）。 在游戏中的某个地方的菜单上显示它，但也将它包含在磁盘上某个明显文件中的某个位置–好像游戏崩溃了，您无法在菜单屏幕上读取数字，可以吗？

不，不是那种用彩弹射击的游戏……这里有些事情你可以考虑一下，以使团队的生活变得轻松。

备份和版本控制

确保每个人都在使用版本控制。 使用SVN，Git，Perforce或其他任何工具。 如果由于某种原因（使命令行语法讨厌）而过于复杂，则可以使用客户端，或者使用一些批处理文件将其自动化。 使它简单，轻松且自然。 然后，您将获得所有好处-版本跟踪，确定Anna或Yevgeni这次是否破坏了构建的能力，能够在他们破坏构建之前及时返回以便能够继续进行工作的能力以及其他许多功能分支等有用的功能，您应该让编码人员和/或发行工程师关注这些功能。

理想情况下，不要使用您自己的服务器。 因为它会在不方便的时间炸毁。 使用带有大量备份和支持的东西，他们知道他们在做什么。 如果您使用的是自己的服务器，请也将其备份到异地。

实际上，请备份所有内容。 源文件，设计文档，作品，您在自己的计算机或办公室中保留的所有内容。 如果您使用Dropbox或Google云端硬盘来存储内容，那就太好了，那里有内置的冗余功能。 不要将所有核心游戏文件都保存在USB闪存盘上。 不要以为“哦，下周我会备份”。 现在做！

持续集成

您可以考虑使用TeamCity或Jenkins等持续集成（CI）工具。 它不是适合每个团队的东西-对于较大的团队更有用，并且某些开发工具也不适合。 如果设置正确，则理论如下：

• Anna将代码更改签入中央存储库。
• 某处的构建机器会“哦，代码更改”，然后开始对游戏进行完全编译。
• 游戏出现编译错误。 构建机器开始闪烁红色警报，并向Anna邮寄一封粗鲁的消息，说：“ oi，您破坏了构建-修复它！”）
• 安娜对其进行了修复，并检入了修复程序。
• 生成机器重新生成游戏。 这次一切都正常了，因此它开始在游戏上运行一堆简单的自动化测试（即“开始吗”或“是否适合墨盒”等等）。 它突然不适合NøntündoSp00n所需的内存占用，因此构建机器向Anna发送了另一个粗鲁的消息。
• Anna尝试了另一个修复程序，直到它起作用为止，并且构建机器对测试感到满意。 构建机器将成功的构建复制到某处的输出文件夹中，Biz Dev Guy可以在其中下载该文件并将其显示给Nervous Investors。
• 一夜之间，构建机器进行了一次最新的成功构建，并运行了几个小时的测试-稳定性测试，加载和退出每个级别，加载随机级别以及自动按下控制器按钮等等。 在某个时候，构建崩溃。 构建机器将所有日志和屏幕截图发送给Anna，并指责她是新的不稳定因素……昨晚一切正常。
• 安娜再次修复它。 这次，一切正常。

重复直到有游戏为止。

（其中有一些涉及自动化测试的步骤。这是另一篇文章。这可能很难设置，但是如果您有备用机器，则要持续运行稳定性测试是非常宝贵的。尽早进行此操作意味着您需要在发布之前进行平台认证，生活会容易得多。）

问题跟踪和错误跟踪

拥有某种共享数据库，该数据库可以跟踪团队的TODO列表以及测试人员和客户报告的所有错误。 无论如何，您的制作人都应该对此进行介绍，以确保一切按计划进行。 如果他们不这样做，请解雇他们并获得更好的制作人。 使用诸如Jira，Hacknplan或Trello之类的东西。

编码和命名标准

有编码标准。 它们到底是什么并不重要，只要您拥有它们并坚持使用它们即可。 这涵盖了诸如变量，函数，文件的命名，文件的位置之类的东西。 您的目的是，当那辆公共汽车最终撞上安娜时，任何其他编码人员都应该能够查看她的工作并立即了解发生了什么。 （对Anna更加友善-也是这样，当您获得巨大成功的游戏公司雇用了＃75编码器时，他们就可以快速了解其他74个编码器在做什么。或者这样，当您将代码库导出到不良的第三方移植团队时，他们有一个线索……）

文件的命名标准也很重要，因为如果艺术家调用某些文件，例如Sprite-Fred.jpg而其他调用Fred'\\cxx__bucket-jumper-v5.txt.jpg或Untitled-75.jpeg ，则可能很难做到。任何形式的自动化。 甚至只是查看文件并弄清楚它是什么。 保持名称可读。

在代码中命名标准的另一个原因是，您可以使其他内容（例如文档）自动化。

记录东西！

有一个Wiki或一组Google文档-每个人都可以访问，编辑和添加的中央知识库。 保持井井有条。 用它。 不要让信息过时。 如果发现过时的东西，请立即修复。 不，现在。

正如我在谈论消除摩擦时在页面上所说的那样，如果您必须弄清楚如何做其他人必须再次抬头的事情（包括您，忘记了如何做），记录下来。

如果要记录代码，请在代码内部实际记录它，否则将永远不会保持最新状态。 如果要引用它的Web版本，请使用那里的许多自动文档系统（例如Doxygen）之一来生成它。

不要在两个不同的地方写下相同的东西，因为如果这样做，一旦眨眼，其中一个就会与另一个过期。

项目管理系统

敏捷？ 瀑布？ 墙上的便笺纸？ 什么有效？

事实证明，这并不重要。 只要您拥有某种系统，而不是根本没有。

在这篇如今荒谬的文章的第一部分中，我提到使用现成的组件和库来帮助您。

游戏开发的各个方面也是如此。 如果您不是正在尝试做的事情的专家，那么请寻求真正的人的帮助。

这可以是有偿的咨询，也可以是外包商的雇用。 它们要花钱，但是就像买现成的组件一样，它们的成本可能远低于您学习如何做同一件事的成本，并且您可能会做得更糟。

您真的像拥有多年经验的人一样擅长PR吗？ 您是否像QA小组一样擅长QA？ 您是否擅长写作或本地化？ 您在游戏节目的摊位前与公众交谈有多好？

即使您是……您可以将所有这些与您尝试做的所有其他事情混为一谈吗？

但是，即使您不想花钱，也可以与他人交谈。 问问周围。 您可以在论坛上找到建议，也可以通过Web搜索在Twitter上从其他开发人员那里获得建议。 您将要遇到的大多数问题都已被其他人所困扰……您并不孤单。 这导致我：

您可以为您，游戏和工作室做的最好的事情之一就是成为行业的一部分。

参加游戏表演和会议，看看别人在做什么，这会启发您。 （让您的员工也去吧–整个团队买不起吗？办彩票。）

转到“游戏果酱”以及本地讲座和聚会。 加入可以为您提供支持的组织，例如Ukie和BAFTA。

认识人们并与他们交谈。 开放-如果可以的话，请帮助他们，您会发现这种帮助是对的。 谈论你在做什么。 谈论行业。 谈论您对自己的游戏有多兴奋； 激励别人。

炫耀你的游戏。 将控制器放在别人的手中。

他们会发现一个错误。 谢谢他们

然后将其放入错误数据库。 😉

聚苯乙烯

有网络吗？ 首先。 在其他一切之前。 相信我。