游戏设计师似乎没有意识到这一点，但是他们可以使用的工具却很差。 游戏设计的过程充满了困难和障碍。 我不是在将游戏视为软件开发，而是在将游戏视为规则集设计。 软件开发人员的需求和欲望与游戏设计师的需求和欲望完全分开，但是两者都使用许多相同的工具。 游戏规则集设计人员想要突破媒体的界限，就需要更好的工具。
当我说游戏规则集设计师时，我指的是主要关注规则集和交互式系统的游戏设计师：我谈论的是棋盘游戏或策略游戏，而较少涉及步行模拟器或繁重的执行游戏。 后者的体验与软件密不可分，而基于规则的游戏则并非如此。 例如，国际象棋可以在海滩上的岩石上玩，而StreetFighter只能在可以运行StreetFighter的计算机上玩。
当前的典型流程
游戏设计过程始于设计者的想法，然后设计师通常将这些想法写到设计文档中，从而创建更具体的规则集。 为了证明这些想法的质量，设计师有两种选择。 他们可以制作纸质原型，也可以将游戏编程为可玩的软件。 两种选择本质上都是有问题的，并且会浪费设计过程。
一种选择是从设计文档过渡到将规则编程为软件。 这里最大的问题是，这要求设计人员知道如何编写代码。 这是一个巨大的时间投入：获得快速迭代游戏设计所需的编程知识可能需要数年时间。 即使被收购，游戏编程也与游戏设计完全不同，并且需要不同的顶部空间。 不应要求游戏设计师也必须是程序员。
游戏设计师通常不使用自己的游戏引擎进行编程，因为这会花费更多的时间，而是使用Unity或UnrealEngine等现成的软件包。 但是，这使设计依赖于另一个软件包：如果不进行维护，游戏设计将在几年内损坏并且无法播放。
如果设计人员决定他们不想花多年的时间成为一名程序员，那么他们将决定使用纸做原型。 尽管纸张原型有其自身的主要问题。
创建纸质原型是挑剔而烦人的。 设计人员必须切出特定形状的纸张并将其粘贴到其他纸张或纸板形状上，有时打印出网格甚至绘制网格，然后才能玩游戏，设计师必须同时运行游戏和玩游戏。 理想情况下，设计师应该只在玩游戏，而规则应该在管理自己。 此外，在纸制原型中进行模拟非常令人讨厌。 设计人员必须管理游戏机制要求的每种不同类型的随机性。
更糟糕的是，有些规则集无法用纸笔写成原型。 传统的战争迷雾就是一个很好的例子。 每个人都知道什么是战争迷雾，但是用纸来管理它是不可能的，因为玩家无法知道战争迷雾所隐藏的东西。 这使设计师不愿从事某些力学工作，这显然是一个巨大的问题。
纸质原型的真正破坏者是游戏测试中的困难。 设计人员必须与游戏测试人员位于同一房间。 这完全破坏了设计迭代和改进中固有的反馈回路。
尽管纸制原型存在独特的问题，但两种原型解决方案的确存在一些类似的问题。 由于编写软件或剪纸所需的技能与设计游戏所需的技能不同，因此它们都使设计师摆脱了设计的顶峰空间。 这使设计人员脱离了实际的设计本身，而开始考虑剪切，粘合或编码。 理想的工具集使设计师可以完全专注于设计。
当前所有的原型制作工具完全缺乏归档能力。 理想情况下，游戏原型可以可靠地存档。 设计师必须能够探索一个想法，将其保存下来，并在数月或数年后重新激发他们的兴趣时回来。 两种系统都无法达到该目标。 纸质原型需要完整的随附规则手册才能发挥作用。 由于规则不是由媒体强制执行的，因此错误地播放纸质原型非常容易，尤其是在一段时间后返回原型时。 同样，软件会随着时间的流逝而腐烂：如果没有持续的维护，程序的寿命充其量只有几年。
这些问题是游戏设计所特有的。 没有其他艺术媒介会允许这些类型的流失过程进行。 作家和画家可以写作和绘画。 在创建之前，他们不必学习完全独立的技能。 几分钟之内，音乐家就可以创作出完整的听觉作品。 游戏设计师充其量只能在几天后完全测试他们的想法。
你为什么要在意
我认为这是游戏设计中的一个巨大问题。 游戏设计的媒介因流程不良而停滞不前。 设计师无法快速，高效地迭代其想法，从而使整个过程的创造力和动力无法发挥作用。
而且，这些过程问题吓跑了潜在的优秀游戏设计师。 不难想象有人充满想法，但缺乏实现这些想法所必需的技术编程技能。 这是一场悲剧，它将继续减缓游戏设计的进度，直到修正它。
另外，缺乏强有力的过程减缓了博弈论的发展。 我经常阅读游戏设计文章，声称游戏应该这样做，或者游戏不应该这样做。 但是他们几乎从不引用当前的游戏。 这是因为设计师很难证明自己的理论。 我可能需要花费数年的时间才能开发出一款能体现您想法的游戏。 同样，这会使整个介质变慢。 如果我们想提高游戏媒介的改进速度，则游戏设计师需要更快的迭代过程。
可能的解决方案
我们发现了一个问题。 我们将如何解决？ 这是一些有潜力的解决方案。 这些解决方案有助于简化策略设计过程，但要以游戏作为软件生产为代价。 因此，这些解决方案很乐意牺牲典型的软件质量指标来提高设计的表现力和迭代速度。 这些解决方案的目标不是可交付的软件，而是一些不同的东西。
我在下面概述了这些目标。 这些指标是理想的。 使用一种工具来实现其中的每一项都是一项艰巨的任务，但是重要的是要弄清楚我们从工具中想要什么。 我认为这是三个最重要的指标。
- 可存档
设计人员必须能够存档他们创建的内容。 他们必须测试一个想法，将其保留数月或数年，然后再次打开以恢复工作。 他们必须能够以最少的时间成本做到这一点。 这意味着该工具必须是面向未来的。 这些工具中创建的任何内容都必须能够永久存在于未来（这听起来并不困难）。 - 富有表现力的
工具必须轻巧，简单但功能强大。 设计人员需要能够快速简单地表达复杂性的想法。 这意味着很少的“锅炉板”工作。 - 光
该工具应允许设计人员以探索性方式创建游戏：测试，修改和删除操作需要快速，轻松地完成。 这意味着该软件必须快速简便。 设计人员永远不应等待该工具执行某些操作。 该工具应始终在等待设计人员。
好的，我们有一些理想的指标，并且我们知道当前工具的问题。 让我们看一些可能的解决方案。 作为警告，以下解决方案是非常技术性的。 我会尽力以任何人都能理解的方式来解释它们。 由于复杂性，我也省略了进一步的深入解释。
大库O码
一种解决方案是简单地编写和打包最常用的代码。 这将加快设计过程，因为设计人员将减少编写代码。 理想情况下，设计人员将拥有一个可视化的编辑器，使他们可以将该库的不同部分连接到有意义的东西中。 这将类似于Unity，只是明确地专注于设计迭代过程，而忽略了可交付软件的生产。
这是最直接的解决方案，但远非完美。 该解决方案不能解决任何归档问题，因为设计必须依赖于其产生的库。 棺材里的钉子就是缺乏表现力。 您的设计只能包括已经考虑和实现的功能。 该解决方案可以加快设计过程，但会扼杀设计师的创造力，从而产生许多非常相似的游戏。
GDL
另一个有希望的途径是游戏描述语言（GDL）。 GDL是一种可以对任何规则集进行严格编码的语言。 它被开发为以人工智能可以玩的方式完全封装游戏。 以下是用GDL-II编写的Monty Hall门游戏的示例。
GDL具有许多优点。 由于其数学根源，它已被证明可以表达所有可能的游戏。 这提供了扎实的理论基础，真正释放了设计师的创造力。 语言非常简单，这使入学成本低廉。
重要的是，GDL对运行游戏所需的计算完全不感兴趣。 它仅声明游戏规则，而不声明如何在计算机上实现规则。 运行游戏取决于完全不同的软件。 这意味着GDL完全可以面向未来并且可以完美归档。 设计人员只需要保留GDL规则，游戏就可以在将来的任何时候玩。
GDL有一个大问题：它太小了。 即使创建很小的东西也需要大量的编写工作-即使使用GDL设计基本的棋盘游戏也非常困难。 语言太冗长和太严格。 可以通过使用通用设计模式扩展语言来解决此问题，但我认为这一差距太大：需要许多新功能，结果实际上只能是另一种语言。
ASP和事件演算
答案集编程（ASP）是另一种可能的解决方案，其背后有很多有前途的研究。 简而言之，ASP是一种编程范例，专注于以其他程序可以解决的方式在逻辑上声明问题。 然后，在此基础上建立事件演算，并允许这些问题随时间而改变。 所有这些都是非常复杂的，不幸的是，使用这种原型工具将需要了解这些并发症。
该解决方案具有与GDL相同的许多问题，尽管程度不同。 但是，用ASP表达游戏可以很容易（尽管不如我所愿）。 没有为游戏设计的ASP语言，因此它们都有许多不必要的烦恼。 例如，语言没有时间或转弯的概念，因此程序的每一行都有一个烦人的变量来管理时间的流逝。 ASP是朝着正确方向迈出的一步，但它还不完全正确。
新语言
当前，没有好的解决方案。 尽管这并不奇怪，因为在设计游戏规则集迭代时没有设计任何东西。 我认为最好的解决方案是设计一种既有优点也有缺点的新语言。 显然，这说起来容易做起来难。 总是会出现并发症。 这似乎是有可能的。
这种新语言将专门为策略游戏规则集开发而设计。 它将具有AnsProlog（如语义和语法），但会删除许多不相关的内容，而是采用对设计人员有用的功能。 最后，这种新语言将是声明性的，因此也可以归档。 我很高兴地说我处于设计这种语言的早期阶段。 我还没有任何可证明的东西，但是我正在根据上述目标和方向取得进展。
处理
创建一种新的编程语言听起来是最好的解决方案，这是因为我已经定义了它。 没有用于策略游戏规则集设计的好的工具。 当前所有的解决方案都充满了问题，没有一个解决方案接近于实现我上面概述的指标。 部分原因是因为没有人专门解决此问题。 当前所有的解决方案都过于抽象和笼统-游戏设计人员需要专门针对解决问题的解决方案。
我认为这是行业的一个大问题，但还没有得到足够的讨论。 游戏设计师迫切需要改进的设计工具。 这样的工具将使游戏设计师，他们的想法以及整个行业都得到授权。
