在开始项目之前，您的游戏设计文件的详细程度和/或完整性如何？

我想知道的是，在开始实施项目之前，您的设计文档通常有多完善？我在这里谈论的是由一个非常小的团队组成的中小型项目，即使完全充实整个文档也可能只有几十页。

您是否从一个粗糙的框架开始，并在实施开始的同时充实细节？

您是否在开始实施之前就完全充实了每个部分？如果是这样，在实施开始后您看到了多少百分比变化？

如果您有我概述的两种情况之一的经验，那么我很乐意听取您关于该特定路线的哪些问题引起的意见以及您认为它可以帮助您避免的障碍。

如果游戏想法在很大程度上基于一些不寻常的游戏概念，我的原型，就从头开始，使用以前的项目作为模板。95％的时间导致人们意识到它并不像我想象的那样有趣，而使其变得有趣将需要更多的资源，而不是值得的。

如果同时我在做另一个项目，我会花点时间做些涂鸦，以了解原型的外观（尽量不要被素描艺术分散注意力）。然后，我与朋友分享该信息，部分是看他们是否有任何投入，但主要是让我自己想到那些并不立即可见的事物（总会有很多事物，即使是最聪明的人思考最简单的想法）。像这样几个小时之后，我将写下一些必须包含在体系结构中的关键概念，大约20个字。有空的时候我可以建立一个原型。

目前，我的游戏设计在开始之前已经足够详细。

我将充实大多数重要的课程，绘制一些模型（图纸通常很恐怖），对游戏进行描述。

尽管这主要是由于通勤时间长，没有其他事情可做。我宁愿花更少的时间做这些事情，而花更多的时间进行编程，因为充实最有可能改变的类似乎是过分的。

我在小型游戏的小型团队（小型休闲游戏的单人团队）中工作，我从“繁重的设计”过渡到“快速的设计”。我发现迭代式开发（两个星期专注于一个目标，例如核心游戏玩法）有助于充实设计，并为您提供一些帮助，这意味着您不会改变主意并使90％的设计无效在纸上看起来不错，但在游戏中却不行。

话虽这么说，我确实将大部分设计时间都花在了核心游戏玩法和机制上（主要游戏的运作方式），并且很少有太大变化-它会进行调整，有时我会采纳新想法或放弃旧想法；但是没有一个可行的原型，一切都没有。

在技​​术方面，在使代码真实之前，任何事情都应该经过至少几分钟的思考。但是，您以后总是可以重构。

设计文档的维护成本；随着情况的变化，您必须返回并重新阅读和更新任何现有文档。因此，减少可维护文档的数量应该是生产目标，因为这将使实际制作游戏所花费的时间最大化。

从那里开始，您就不需要提前设计所有细节，因为您完全了解其中的一半会发生变化，因此您将浪费大量时间。做开始制作核心游戏所需的最小设计。完成后，根据需要进行迭代，然后为每个新功能重复该过程。