1. 尽早确定您的核心机制，然后迭代、迭代、再迭代
我从大量项目开发经验中学到的一件事情是在没有打下扎实的基础之前建造房屋是毫无意义的。 换句话说，要在您真正进入美术制作和关卡开发之前使您的游戏性机制有趣并且玩起来很有意思。 这样的声明可能看起是傻瓜都知道的问题，但是实际上总是抑制不住就要直接跳到最重要的整体内容开发上，最后导致忘记了要先打基础。 如果在开始制作成本高的资源之前，您不但能够准确把握您想要创建的游戏类型（例如，至少是一个设计剧本大纲），而且可以确定游戏会因为这一点而非常具有可玩性（不一定意味着没有 bug 或者视觉效果扣人心弦），那么将会为您免去一堆麻烦。
此外，越早确定您的游戏性机制，您就可以有更多的时间进行迭代，它意味着通过反复步骤进行完善。 迭代可以在您的整个开发周期大部分时间发生，但是如果您可以在您的预制作/概念原型阶段中塞进越多迭代，越好。
当然，正如我前面所提到的，虚幻有一些可以支持快速迭代的重要工具。 它们中包括远程控制（用于实时更改值），原型（用于具有必需由数据控制而不是硬代码编写的值）以及在编辑器中播放（用于在您在相同的应用程序实例中动态修改的关卡中游戏）。 使用每个以及它们中的每一个，真正的同步（例如，您可以在 PIE 中打开 Remote Control），然后将会比您召唤它快 3 倍。 您的游戏性将会从中得益。
2. 使用占位符资源设计出您的游戏性原型
3D 美术建造一个角色模型，技术美术对它进行组装，然后动画师创建一系列动画，做这些只是为了找出是否有适合于您的游戏性实际需求的媒介设备？ 不是吗？ 那么恭喜您。 之前我已经翻过这样的错误，毋庸讳言： 美术不喜欢这样。 为什么要他们做这些？ 程序和策划需要确保在将最终美术作品放入到制作通道之前，他们要准确把握为游戏性目的考虑应该要构建怎样的美术作品，同时还要与相关美术人员沟通相关事宜。 我发现解决这个问题最好的方法是使用 PLACEHOLDER 资源，也就是所说的简单通用版本，一个类人生物角色或一个武器，可以使用它们代表最终资源。
理想情况下，占位符资源的尺寸、形状以及骨骼结构（如果是骨架网格物体）与最终资源大致相同，但是具体情况由机制（可能并不是必需的）的复杂度决定。不但要占位符资源，重点是，允许您‘尽早确定您的核心机制’（参见 Rule #1），而且它还允许您的美术人员在开始制作最终媒介之前了解游戏中的计划操作运行状况；占位符执行函数应该是效率最高的通讯方法。 此外，美术人员自己通常可以直接将占位符资源换出为最终资源，也就是他们可以在实际的游戏环境中遍历视觉效果，而不是只局限于抽象的空间。 幸运的是，虚幻可以轻松地使用最终资源换出临时资源： 只需在 Archetype 或在 DefaultProperties 中更改一些引用（网格物体、动画集等等）（不要直接在代码行中引用！），这样就可以了。
参照 Endeth Commandment #2。3. 按照虚幻方法进行操作
通常通过使用虚幻有很多很多方法可以实现游戏性结果，但是往往都不太理想。 这些‘虚幻方法’通常包括充分利用 UnrealScript 界面提供给您的功能，这些功能已经大大超出基础编程语言（例如，C++ 或 Java）范围之外。 随机举例…
[*]想要出现延迟或者随着时间变化出现吗？ 使用隐性状态功能（例如 Sleep 或 MoveTo）或 Timer。 如果状态在 Tick 中，那么不要进行一系列基于时间的处理! [*]想要找出在您的玩家周围的特定 Actor 吗？ 不要进行 AllActor，分别在世界中检查与每个 Actor 之间的距离，使用 OverlappingActor，并将您的半径赋给它。 [*]想要在您的玩家角色身上到处设置装备配件吗？ 不要为每个都创建一个 Actor，动态创建并向您的 Pawn 附加新的网格物体组件（或者甚至是一个自定义组件类）！
[*]想要制作一系列只因一个贴图而异的 Material（材质）吗？ 不要为每个都创建独特的基础材质，使用可以共享一个父代材质的材质实例常量，只需换出一个 Diffuse Texture Parameter（散射贴图参数）。 [*]未经核实，千万不要自认为结构体是通过引用进行传递的。 默认情况下，通常对它们进行深层复制，除非您在您的函数参数中使用“out”关键字。 在您的逻辑规则假定结构体变量是非唯一引用的情况下，深层复制结构体不一定速度慢，内存独占并生成潜在 bug。 Epic 致力于使用全部 UDN 主题解释这个问题。
?:)通过特定方法创建 UnrealScript 和引擎框架可以使游戏实现从 straight C++ 工作中得到更丰富的体验（像很多我已经在这里进行的操作）。 在您使用虚幻开发游戏的过程中，您将会发现内在功能比您之前可以预想的更多。 如果您正在努力使用虚幻实现一些功能，那么您可能还不了解已经在引擎中存在的一些好用功能，在不确定的时候，通常都是这种情况。 阅读 Epic 的代码。查看它们的样本，储存感兴趣的 UDN 文章，甚至可以查看 Dungeon Defense（并不是说它是完美的），您会轻而易举地辨认出可以使这种方法充分利用功能超级强大的框架。
它直接将我们带入…4. 搜索 Epic 的代码库！
UnrealScript 引擎框架代码库非常大。 此外它保存得很好，但是要查明开始的地方通常是非常困难的，从头到尾“阅读”它并不是特别明智，除非您可以经常提供一个与 I.V. 连接的 Red Bull（但是我会至少建议您从熟悉 Actor.uc & Object.uc 开始）。
最后，将一个非常大的代码库转换为一个积极应答的知识暴客全书是最好的方法吗？ “Find All in Files（在文件中查找全部）"，Code IDE 的一个搜索功能，就像 Visual Studio 一样（它由一个免费版本，Visual Studio Express），或者其他文本编辑程序。 通过搜索所有或一些 Epic 代码文件内的关键字，诸如“Cursor”、“Force”（或您通常正在寻找的内容），您通常将会了解 Epic 已经提供处理所有常见游戏需求的相关功能。 一个好的经验法则是： 在您决定“自己动手”之前，搜索
Epic 的代码库检查我们是否已经为您“进行这项操作”！ 您可能会惊奇于它们已经搜索您正在寻找的内容的频率… 然后再次，如果您玩过战争机器，应该就不会觉得意外了。5. 使用 nFringe。 周期。
是的，我不得不佩服 PixelMine 的那些家伙： nFringe 反常摇摆。 它的‘Intellisense’和代码解析通常都准确无误，而它的语法检查同时也可以大大降低大傻冒 bug（刚好与愚蠢的 bug 形成对比）。 使用 nFringe 将会大大提高您的编码效率（或者至少在我的实例中可以提高），而且它还可以帮助您更加快速探索 Epic 的代码库（以及您自己的代码库）。 通过 Intellisense 和成员列表，您将有望在类周围方便快速地检查它们的变量、函数和状态。
我无法充分强调它： 如果您刚开始使用虚幻编程，那么 nFringe 将会帮助您更快速地帮助您加快进度。 目前就有一个问题： 虚幻有一个功能强大的调试器，但是 nFringe 被锁定不可以进行访问，除非您从 PixelMine 购买了商业 nFringe 许可，它目前只供专业开发人员使用。 C’mon PixelMine 使并不神圣非常棒的工具完全面向人民大众，那么他们会将您供奉为（不神圣的）神！ 或者诸如此类的东西。 不过是呀，现在下载 nFringe（+ Visual Studio Express，在您没有它的情况下），然后就好像您从来没有进行编码一样开始编码！
6. 根据您的需要使用所有调试方法
有或者没有 nFringe，这里始终都有很多通过使用虚幻框架调试您的游戏的方法，而您应该使用所有不同的技术达到最好效果。 在这些方法中，我偏爱的方法是：
[*]调试绘制（球体、线、框等等）： 这些可以帮助您可视化 3D 空间中所发生的事件，在您需要看到一个经过精确计算的 3D 转换的结果或者只是要知道大小的时候等等情况下有效。 [*]记录声明： Ahhh 记录： 滥发消息，但是可以提供很多信息。 尤其是在 nFringe 调试器不工作的时候！ 好吧，通过记录，您可以立即将很多任何数据类型输出到输出窗口（您可以使用控制台命令 showlog 调出这个窗口），然后使用“@”符号合并多个字符串，这样您就可以使最大信息在一个单独行上。 小心一点，不要将它们放在您的
Tick 函数中，然后将它们留在那里（滥发记录将会降低游戏速度）。 事实上，最好是只在您的 Actor 类具有“bDebug”切换设置的情况下使记录处于激活状态，“bDebug”是一个提出需求后您可以在运行时切换的可编辑变量。 [*]无光照模式，线框模式： 在您忙于一些图片上的处理但是关卡照明坏了的情况下，只需按下 F2 更改无光照模式。 或者如果您需要看穿墙壁（秘技！），那么按下 F1 进入线框模式。 这样可以出乎意料地帮助您，使您可以看到敌人 AI 正在做什么，而敌人却看不到您（偷窥！）。 [*]“Show
Collision”控制台命令将会使世界中的所有碰撞可见，它适用于您遇到与碰撞相关的问题的情况。 现在还无法理解吗？ 可能它不是一个游戏 bug，可能您的关卡设计师会在入口道路前面放置一个大的可见封锁网格物体，然后将其隐藏起来… 只是为了刁难你。 ‘Show Collision’将会显示所有这些碰撞！ （再说具体一些，它非常有利于看到您的 Pawn 的碰撞大小） [*]使用远程控制上的 Time Dilation（时间缩放）设置按字面意思降低游戏中的时间（不是在真实生活中… 可能会棒极了但是虚幻功能还没有那么强大）。
它对看到微小游戏细节中的视觉效果和动画具体发生了什么来检测任何诡异现象非常有帮助。 有助于解决与计时相关的问题。 [*]远程控制还可以在您点击 Actor 列表上的“Clock（时钟）”图标的情况下显示在与游戏过程中所生成的所有动态 Actor。 它可以用于复核应该被销毁的 Actor 没有活着（例如，您的射弹在发生碰撞之后会到处闲荡？等等）。 [*]所有 Kismet 操作都有一个“Output Comment To Screen（将备注输出到屏幕）”选项，启用它后，它会将它们的备注输出到游戏中控制台显示器。
它可以用于了解被触发的操作，以及触发时间。 或者，对于专业的 Kismet 大师，可以使用控制台命令 Kismet 操作（比方说），与我的连接字符串操作相结合输出任何您想要的 Kismet 变量
通过使用其中的这些调试方法，我们希望有一天大家就可以喜欢 nFringe 调试器，您将会成为一个非同寻常的平定 bug 的能手。 这是一件好事。
7. 使用 Kismet 是明智之举，但是...
Kismet，我们是有多爱你？ 您使得关卡设计师能够实现游戏性，同时使得游戏设计师能够快速设计原型。 您赐予… 然后您再要回来。 Kismet 是一个非常出色无与伦比的关卡交互性工具，甚至可以用于设计特定面向关卡游戏性机制的原型。 但是，它有它的局限性： 它不是专门面向对象/可继承，它不包括 UnrealScript，而且不具有 UnrealScript 的任何调试功能。
因此，尝试通过 Kismet 进行所有操作并不是构建大多数游戏最终版本的可行方法。 如果您愿意可以使用任何方法，在可能的情况下使用 Kismet 设计您的游戏性（它肯定可以做很多），但是请记住您将有可能必须为您的最终产品重新编写其中的大部分内容。 如果您发现自己正在费力地通过 Kismet 进行一些操作，那么我认为您应该考虑通过 UnrealScript 进行这项操作（或者，考虑编写新的 Kismet 操作进一步扩展它的功能）。
我的通用规则如下： 如果它是发生在关卡的固定设计中一些操作，那么通过 Kismet 进行这项操作。 如果它是必须动态生成并且与动态对象而不是关卡本身的行为相关的操作，那么最好通过 UnrealScript 进行。 这个观点是由很多使用 Kismet 的经验得来的，我非常喜欢这种做法，而且到处都可以使用。 不要弄错： 从理论上讲，您可以使用动态生成的 Prefab 编写一个完整的游戏，但是经过某个点，我认为它会阻止您继续操作。 但是不要担心，亲爱的读者们，ut don’t worry dear readers,
我对 Kismet 的迷恋将永远不会终止： 在 Dungeon Defense 中，我就是通过它控制整个高级游戏性逻辑规则的。8. 它就是趣味性
各位，我们是独立开发者（除非你是 Cliffy B，如果您正在阅读这篇博客，那么您现在是一位重量级名人！） 总的说来，这意味着我们专注于趣味性而不是如何安排几百万美元的预算。 当然，它可能是我们大多数人的目标（每个人知道自己的职责所在），对您来说是更大的动力，虚幻将会提供使您可以达到目标的功能。
但是永远不要忘记在您准备向世界证明您的游戏是多么美妙以及它值得大家花时间玩的时候，您的游戏画面优美程度（虽然有一些帮助），或者您们所获得游戏时间长短（哦，Oblivion（遗忘法师），吞噬人们的时间）或者您的主要角色乳房部位的多边形数目，这些都无关紧要。 真正重要的是玩家是否参与互动性体验，这些体验可以为他们提供很好的反馈并会以令人满意的方式奖励他们。
很讽刺的是，有时奋战中的设计师通常因为一天天面对游戏而无法对它进行最好的判断。 所以在关键时刻让您的朋友、家人、同事和宠物狗一起来玩您的游戏，这样他们可以告诉您/向您叫他们对于它的处理过程的反馈。 它不可能十全十美，有时建设性的批评可能会让人难以接受，但是您和您的游戏将会因为它而更趋于完善。 虚幻的确是世界上功能最强大的游戏创建技术，但是您如何使用它，您是要制作一个平衡性很好的趣味性游戏还是其他… 嗯… Monster Madness（怪物也疯狂） – 全部取决于您！
大家保重，同时不断进行开发，让梦想成真
-Jeremy Stieglitz