看书里说，开发游戏时应该先写下大体规划，做出Demo，看看有没有游玩的潜力（有没有趣味），然后逐步开发各个系统，验证技术角度是否可行，在开发各个系统的时候边开发边写设计文档，最终开发完成的时候进行汇总，形成一份详实的设计文档。总的来说，并不是一条路走到黑，一开始就写下一个事无巨细的设计文档，而是边走边看，随时调整。

文档很有必要，初期没有规划好就开搞多半走不远

一个人开发的话，有自己能看懂的草稿案就够了，太正式的没必要

要整理文档，且不仅包含如何设计，更重要的是为什么如此设计，还否定过哪些方案，为什么被否定。

有了点子，在经过简单的头脑风暴做点笔记后，就直接开始乱写代码，怎么爽怎么来
但是（重要），只要代码思路被卡住，那就考虑立马停下来的可能，转头开始去写文档（数据流图、数据结构、变量名、策划案思维导图、代办列表之类的东西，具体看自己的开发习惯和需要），以帮助自己重新整理思路，和用于验证自己是否真的想清楚了策划案、是否有足够能力完成对应的代码工作
除去文档工具不熟手这方面的因素外，假如连写简单的文档这一步骤都觉得麻烦困难，那就有很大概率，自己其实并没有把一些应该先想清楚的问题给想清楚。如果保持这种迷茫的状态，贸然继续写代码，那结果大概率也只会遭遇更大的麻烦和困难，看似步骤少了，但也只不过是把文档步骤留下的坑延迟到写代码步骤罢了（最终变成逼迫自己边写代码边整理思路的低效模式）

需求文档、功能设计文档等一定要写，如果是个人开发、经验丰富、体量小的情况不写开发相关的文档，其他情况要写全

1，一句话介绍，什么类型，题材
2，核心玩法，为了通关要干啥，有什么体验。
3，围绕核心玩法有哪些系统，战斗，建造等等。
4，背景设定，人物设定，剧本等等。

先有大框架 按框架思路去敲代码

还是建议先写文档，不然写了代码改动更大

独立游戏的话，我觉得可以先写不用急着框架什么的，先把玩法测试ok了 确定不会推翻重写了再说