What you will get from this page: Tips on maintaining a stable and flexible build to save yourself time and money. Get pointers on using version control, utilizing your changelists, clean cheat functionality, bug tracking and more
After years of shipping large titles with even larger teams, typical AAA studios know how to keep their productions on track and maintain a clean and stable build. Sascha Gundlach, from MetalPop Games, highlights how independent game developers can adapt the AAA approach to their own production.
With a clean build, it’s easy to change or add things, as well as maintain and debug features. Overall, you’ll be able to develop your game faster and more efficiently.
简洁构建的优势
从长远来看，通过保持简洁和稳定的游戏构建，您将获得以下好处：
- 让发布的游戏更稳定，错误更少。
- 由于错误更少，代码库更简洁，可以节省制作时间。
- “中断构建”的几率降低。
- 可以更容易地创建演示版本和特殊构建。
并不是所有的 3A 级构建实践都适合独立团队。但是您可以通过多种办法确保构建保持简洁稳定和免费（或实惠），并可被任何规模的团队使用。
即便您是一人运作，以下技巧也能帮助您让游戏构建变得更优异、更稳健。
使用版本控制
即使在今天，尽管有了免费的版本控制系统 (VCS)，仍然有团队使用共享文件夹或 Dropbox 进行协作。没有版本控制的开发有点像开车不系安全带。尽管系安全带可能不会始终感到舒适并对您有些限制，但是一旦高速撞到树上，它却能挽救生命。
不管团队规模大小，您都无法承受作品丢失的后果。即使 Dropbox 帐户被黑或硬盘损坏也不应导致丢失数天或数周的工作。
免费的解决方案还是有很多的。Perforce、Git 和 SVN 均提供免费版本。而且如果在 Unity 中直接集成 Unity Teams，操作也会变得更简单。
利用变更列表
VCS 除了能保障安全外，另一个好处是您可以获得变更列表，让您对变更有全面的了解。上图是显示所有更改的 Perforce 文件夹历史记录。
尽管大多数系统不会强制您提交所做变更的描述，但最好还是清楚地描述变更信息。
此外，对更改使用前缀，创建“补丁说明”及类似文档会变得很简单，例如：
- !B：错误修复。
- !V：视觉效果更改或改进。
- !G：游戏玩法更改。
- !X：补丁说明中应忽略的更改。
如果向 VCS 提交更改并使用前缀描述它们，随后可以对每一个条目运行脚本，并将所有条目整理到一个简洁美观的补丁说明文档中。
以下是一个提交到 VCS 的简洁文件的示例：
“!V 加强粒子的爆炸效果”
“!B 已修复拿起武器时的崩溃问题”
“!G 提高医疗箱中的生命值”
如果您让所有更改保持简洁并对其加以适当描述，当需要时编译补丁说明文档会变得轻松起来。与手动翻找近期更改来确定要在补丁说明中列出的更改相比，这是一种更有效的方法。
保持良好的卫生习惯
让团队中的每个人熟悉良好的构建卫生的基本规定至关重要。以下是保持构建简洁的最重要的五点优秀实践。
- 不应有会造成构建中断的代码
不要签入已知将导致中断的任何代码。如果您负责设计的功能未完成但是需要签入，可以禁用该功能或搁置更改，使它们不会对团队其他人的工作造成任何中断影响。团队其他人员不应因为您签入不能正常工作的代码而受到中断构建的影响。
- 不应使用硬编码的键盘快捷键
对于某些作弊或调试功能而言，添加自定义快捷键会非常方便。“只要将 F12 键设为金钱作弊键就行了，反正没人会按这个键的，对吧？”
但使用这样的键硬编码功能是非常危险的 - 因为容易忘记。您可能不小心将它发布出去，或者测试人员可能无意中激活它并因此污染您的错误报告。
- 标记坏代码和缺失代码
有时必须进行修改。无论您多想避免修改，但终究都会临时修改代码。在添加修改或实施变通方案时，应确认使用容易查找的关键词在代码中进行标记。使用 //HACK 标记修改或使用 //TODO 标记缺失代码。这样做会使以后在所有代码中搜索这些标记变得很容易，您可轻松进行查找和替换。
- 日志垃圾
记录代码问题非常有用，可以帮助跟踪问题。但是，不时清理日志垃圾非常重要，这样重要的警告和错误才不会被淹没。除非您正忙于开发某项功能，否则控制台应尽可能保持简洁干净，以便一旦有问题出现能够立即发现。
- 文件名和命名约定
构建规模最终会增长为数百或数千个文件。保持简洁明了的命名约定至关重要。
在开始新项目时，应花些时间设计对您来说有意义的命名约定，并强制让自己遵守它们。一旦在版本中使用了 texturetestFinal01.png 或 backup22.fbx 之类的名称，情况很快就会变得一团糟。
进行例行检查并清理进入项目的任何脏文件名。
下面是一些简单的技巧：
-
使用描述性的名称
使用 AttackButtonBehavior.cs，而不是 atkBtn.cs -
使用 camelCase 或 PascalCase
notsocleanfilename.cs 的可读性不如 MyCleanFilename.cs -
使用下划线令文件名的含义更明确。
WoodenHouse_Blue、WoodenHouse_Green 等等
保持作弊功能简洁
在游戏开发过程中经常需要进行调试和作弊。您可能希望跳到不同的关卡，给自己额外的现金，让自己变得无敌，生成额外的敌人等等。
您可以根据需要添加这些作弊，并在完成后禁用它们，但最好采用一种简洁的方式关闭和开启这种作弊功能。
即便是小项目也值得多花些时间构建容易使用的调试/作弊菜单。这样的菜单可以让开发者轻松地开启和关闭，并提供对所有常用作弊和调试选项的访问。
这样做可以最大限度降低不小心随同游戏将作弊发布出去的风险。此外，将“作弊代码”放在一个中心位置还可以确保一切稳步运行和易于扩展。
这种做法的另一个好处是让开发作弊变得更快，为日常生产节省大量时间。在便捷的调试窗口中按一个按钮要比在脚本中进行值硬编码快得多。
管理和跟踪错误
游戏中总会有错误存在。每个游戏都有错误，您的游戏也不例外。问题在于如何处理错误。
高效处理错误的工作流程非常简单：您的 QA 部门发现并在错误跟踪系统中输入错误，然后他们将问题分配给开发者，后者随后修复问题并对其进行标记。最后您的 QA 团队确认问题并将其标记为已解决。非常简单的三步流程，对吧？
等一下，什么？您没有专门的 QA 部门？您的测试者也是开发者？
不必担心，因为错误并不难解决。
首先跟踪错误。即使您的团队只有您一个人，也很容易做到这一点。
挑选一款错误跟踪软件（免费和价格低廉的错误跟踪软件有很多）并进行设置。如果这很难做到，可以直接使用 Excel 或桌面上的记事本，这都没有关系。重要的是要有一个集中收集并跟踪问题的地方。在设置好错误跟踪系统后，接下来要制定严格的制度。有错误的构建会降低生产速度，甚至能够带来新问题。
下面介绍几个处理错误的小技巧：
星期五错误修复
星期五错误修复是让构建保持无错误的好办法。每个星期五，不再进行新功能构建，而是只允许每个人处理错误清单中的项目。这种做法可以确保以无错误、稳定的构建开始新的一周。
不要拖太久
一旦发现错误有加重的趋势，最好停止开发新功能，集中精力使构建保持稳定，直至问题恢复正常。
不要总是忙着救火
如果有很多反复出现的错误，应该调查其根本原因。是否关卡构建管线的某个部分总是导致关卡中断？是否从 .xml 文件中解析游戏值的方法三天两头出问题？
一旦发现系统反复造成问题，有必要重新构建系统而不是反复修复它造成的问题。
掌握了所有这些最佳实践与技巧之后，最后就是制定严格的制度与您对构建状态的关注度了。您可以任意组合上述建议并运用到自己的独立作品中。为了让构建保持良好状态而多花一点时间总是值得的。