在跳入代码之前是否值得计划？

我一直认为规划对于游戏很重要。但是我不知道在哪一点。有些人告诉我编写代码而不是计划，但是我觉得它仍然很重要，因为当您进入代码中时，您会更轻松地知道下一步该做什么。我目前正在开发一款内容丰富的游戏，因此我决定创建一份介绍这些内容的设计文档，并且从侧面看，我正在做概念证明，以检查是否可以完成。然后，每个概念证明的部分内容都可以稍后在实际游戏中使用。

编辑：我正在这个项目上独自工作。

所以我的问题是：在跳入代码之前是否值得计划？我仍然很想知道其他人对此有何评论。因为我仍然有些人说我应该编码而不是思考..那么您对此有何看法？

您在问题中说了两点聪明的话：

1. “用代码代替思考”-有一种完整的哲学来描述：http : //gettingreal.37signals.com/toc.php
2. “检查是否可以完成的概念证明”-我已经看到并提出了许多想法，当它们几乎完成时，这些想法变得不可能或极其困难。有时您只是无法预测，因为它是您的编程环境（语言，库，硬件性能）的限制。

这就是为什么我说：

• 设计，但是如果您不希望寻找合作者或投资者，则不要制作大量的设计文档，除非您觉得这很有趣，并且您认为这是编程的一种休息。
• 始终牢记您想要实现的目标；每个模块都应具有设计的输入和输出；这样，您可以轻松测试模块，而不会在雾中徘徊。
• 请记住，无论如何，您大部分时间都在设计，因为键入代码仅花费您大约5％的时间（至少键入最终代码）；
• 编程不是一门理论科学，您可以检查并尝试一下，而不是检查是否可以在纸上工作。最终产品主要是使用户输入变得万无一失，使GUI看起来不错并处理特殊情况-可以立即对想法进行肮脏的测试；
• 如果您害怕忘记自己的想法，请创建一个待办事项清单
• 与您的朋友讨论您的想法，因为他们的热情会降低，并且可能在某个领域有更多经验；曾经有一个想法（在战略游戏中）将单位参数保密，但我的朋友告诉我，这是一个坏主意，因为他玩过这样的游戏，而且用户体验非常糟糕。

是的，但只有一点点。

对于游戏编程，尤其是游戏编程，在编写任何代码之前拥有一个良好的用例至关重要。例如，玩家应该做什么，应该去哪里以及如何与世界互动，等等。这可以是画在纸上的故事板，也可以是与同伴讨论的结果。是游戏设计的一部分，而开始编写代码却没有一个关于如何玩游戏的粗略想法，这是愚蠢的。

但是游戏必须迭代创建。您不能为自己的游戏创建庞大的规格，并希望它会很有趣。您需要定期进行游戏测试，以找出哪些有效，哪些无效，并不断进行迭代。可执行文件运行得最快，可以测试最快的游戏设计，最后获得最好的游戏。因此，从一种非常非正式的游戏设计开始，最好尽快开始编码，看看有什么结果，然后继续进行下去。

可以肯定的一件事是，由于您仅在编码，因此不需要任何精美的软件设计文档或方法，而源代码就是设计。

有人说您应该编码而不是思考？要进行编码，您需要知道要创建的内容，要知道要创建的内容，首先需要考虑一下要拥有的东西，因此，您需要在编写代码之前先思考一下；）。

认真的说，您可能一开始就不需要详细的计划，但是制定大纲和/或里程碑始终是有益的-同样对于您的态度，当您完成工作时，会鼓励您做更多的事情工作。

编码和计划都需要。首先计划，然后编码，但不要立即计划所有事情。计划一个核心，对其进行编码，根据需要更新您的计划，然后计划可增加可玩性，图形，声音，精灵等特征的功能，这将使您正在创建的游戏看起来更好，整体感觉更好。显然，您可以多次运行这样的循环，我建议您在需要时做出支持升级的决策。

在编写代码之前，您必须知道要去哪里，而编写/绘图可能是实现您想要实现的好方法。我说绘图是因为绘图，草图等也可能对您有很大帮助。您不需要制作用Word或其他任何东西制作的精美文档，只需用铅笔和一张纸（几张纸？）作图，然后写下您可能会想到的所有内容。

对我来说，这是使用铅笔和纸的好习惯，它有助于实现您的想法，还可以设置要去的地方，以防止走到任何地方，实现目标。它适用于所有需要反思的事物。在许多领域中，在进行实际工作之前先写下来很明显。

做任何对您有用的事情。就我个人而言，我会在某种程度上进行规划，但是在开始编写任何代码之前，没有设计文档是非常详细的计划。做对您来说最有成效的事情，尤其是因为您一个人工作。

（我认为这个问题是从代码设计/体系结构的角度提出的，而不是从游戏设计的角度提出的，尽管答案至少在某种程度上适用于两者。）

如前所述，您既需要又需要平衡。对您的代码流/结构进行过度设计和设计不足都会导致问题。很难说出正确的平衡点是什么，但是总的来说，我发现我至少需要模糊地知道其余代码如何与我目前正在编程的内容结合起来，并思考可能的问题，否则，我倾向于“将自己编码为死胡同”-进入一种情况，即我意识到“好吧，现在由于我解决了这个问题，我创建了一个新问题，使整个以前的解决方案成为可能（甚至在最坏的情况下，甚至更多） ）徒劳”。

通常，我认为，您可以通过考虑“如果...以后”（当我以后使用（当一切都以与我现在使用的相似的方式完全实现时））中的“假设条件”场景来大致判断您是否具有适当的平衡那部分A的工作需要略有不同，这意味着我必须完全修改与它相适应的部分B来适应这些变化吗？”。如果某一部分的体系结构更改不需要您更改一个或两个以上其他部分，并且这些更改不会级联（这意味着您还必须更改连接到B部分的下一部分，然后再更改连接到B部分的部分）。它们等等），代码以相对良好的方式划分。

但是，实际上，这是您在获得一些经验之后会体会到的。这就是部分原因的原因，每个人都向游戏初学者提供建议，使其首先编写已知且简单的内容（Breakout / Tetris / Snake），并通过所有菜单，声音，效果以及使其完全完成游戏的所有内容完全完成它-更好搞定较小的项目，并执行它（无论是好是坏）将完全帮助您了解各种体系结构决策的影响范围。