这篇文章献给那些头脑发热打算辍学、贷款、卖房梭哈做独立游戏的朋友们。欢迎你们来做独游，但请先对你们要做的事业有一个基础认知。独立游戏欢迎有想法有能力的兄弟追梦，妄图投机一日暴富的人有多远滚多远，谢谢。
全文字数较多，不建议蹲坑的时候阅读，容易腿麻。
一、立项部分
初心：一切的起点
首先，不建议所有初学者以赚钱为第一目标进行独立游戏的立项，我是真的见过有兄弟一上来就贴脸开大：我做独游就是为了赚钱！
可不可以把赚钱当做做独游的目标？可以！
但这意味着你选择了最难的“又当又立”路线。喜欢独立游戏的玩家首先会关注游戏有没有独特之处，是不是好玩是不是有趣、世界观新颖吗、美术风格独特吗，如果满足玩家的期待，玩家肯定是会愿意掏钱包的。那么你们有能力做出满足玩家心愿的游戏吗？如果没有足够的能力，就老老实实从基础开始补足能力短板，用时间积累逐步换取认可。
所以立项的时候，这个“初心”非常关键，它直接决定了这个项目在后续开发过程中遇到大大小小几百上千个问题时该如何选择。我会用本草计划的例子给大家讲解立项初衷是如何决定项目走势的。
说回我们，《本草计划·桌面实验室》的立项初衷非常简单，就是我想学一下Godot，所以我的核心目标就是能够掌握基础的Godot引擎使用以及Gdscript这门编程语言。也就是说，项目能不能上架、赚不赚钱、有没有人喜欢这都是其次的，我通过一个新的项目掌握了我需要的技能这才是最优先的。
DDL：辅助决策的利器
很多的开发者或者说创作者都喜欢走一步看一步、想到哪做到哪。对于有的人来说，没有明确的截止日期可能这确实可以让他在创作过程中产生源源不断的灵感，但更多的时候，这只会成为拖延的一个冠冕堂皇的借口。
DDL，deadline，死线，这并非导致开发者焦虑的原因，恰恰相反这是一个非常好用的项目管理工具。对于习惯了拖延找借口的人来说，有没有ddl他项目都做不完，但是对于主观能动性更强的人来说，掌握了ddl，你就掌握了提效利器，能够大幅度提升项目的落地成功率。
DDL主要的功效有二，第一是帮我们规划项目排期，第二是帮我们避免无效设计。想要让DDL发挥全部功效，还得结合我反复提及的“杜绝完美主义”一起使用，我会在下文给出大量实操案例。
结合我的实际情况，之所以我有了可以学习Godot的时间，是因为我的其他项目都暂时无法推进，《深渊谜影》的程序要忙研究生毕设，《传教模拟器》的程序在忙高考，因此我的窗口期有差不多两个月的时间，从5月初开始算，我的DDL就是7月初。
项目类型：挑一个能hold住的
我需要学习Godot，这是我的初心，那么Godot引擎适合做什么不适合做什么，我得有一个大致的认知，比如比起3D项目，2D项目就更适合Godot开发。（虽然Godot也可以做3D游戏）
并且我得对自己的能力有一定的认知，让我一个人做2D横版动作RPG也不现实，纯纯开着手电上茅坑——找屎，所以我需要选一个相对简单的玩法类型。
由于我做过《珍珠梦》，这是一个文字冒险类游戏，我不想再开一个同样类型的项目，加上最近几个月挂机游戏很火，如果我做完了上架保不准还能蹭一波“时代的红利”，因此最终我选择了放置挂机这个玩法类型。
满足我的初心+满足我的能力+满足我的排期，甚至有额外附加优势，就这么愉快地决定了！
项目题材：挑一个你感兴趣的
我就不用说了，我喜欢克苏鲁。
项目题材是一个非常关键的指标，但我发现很多时候独游开发者朋友们对这块好像没有特别敏感。
我们常常讲玩法融合，怎么就没什么人讲题材融合，是因为题材相比可见玩法更加抽象，但我认为对题材的把控可以让你更容易做出差异化和属于自己风格的作品（尤其当你是策划而不是美术的时候），选一个自己感兴趣也比较熟悉的题材是百利无一害的。
反面教材是《耶兰多的低语》，我尝试做克苏鲁x俄国内战题材的融合，我以为我对二者都很熟悉，但实际上找资料的过程中困难重重，所以大家要理性选择适合自己的题材。
项目风格：问你的美术爸爸
除非你真的有自己想要明确表达的风格，这里再举《耶兰多的低语》这个例子，我就是非常想做分层纸雕，我觉得这个美术风格太棒了我想尝试，所以我带着大量这个风格的参考图去找美术。
当你不知道什么风格合适的时候，就放权给你的主美，让美术主导表现风格的确立。如果是独立游戏人，没有美术或者想自己尝试，那么风格选择的角度就应该是：我自己能画的，或者以低成本可以处理的。
为什么市面上像素风格的作品这么多，是因为玩家都好这口吗？不是的，是因为像素风格的作品做起来成本比很多其他风格的作品低，从开发者的角度来说成本更可控。
《本草计划》这里，我是因为早早就确认了合作的画师，并且我个人有个特点是，我希望在合作过程中充分发挥各方的主观能动性，对于艺术创作者来说，当他有一个非常强烈的想要表达的风格时，那种热情是打钱都找不来的，所以我把美术风格的确认交给了又三老师，在他出风格测试前，我并不知道他会带来什么样的植物。从最后的结果来看，他创作了让他满意的作品，我收获了足量的精美的美术资产，玩家看到了让人眼前一黑（）的可爱作物，共赢的局面，皆大欢喜。
立项总结
我需要在两个月内使用Godot开发一款克苏鲁题材的放置挂机类游戏。
二、设计案部分
策划案：跨工种合作的基础
一般来说，我们出案子之前，甚至在立项之前，还可以有一个头脑风暴的阶段，帮我们拓展游戏的创意和玩法边界。但《本草计划》是一个学习Godot的副产品，没有脑暴的必要，所以这一步直接省略了。
对于功能的策划案，我的理解是，程序员可以通过阅读你的文档直接把代码框架定下来并且几乎不需要返工。
换言之，策划案不是写给策划看的，所有的策划案根据目标不同，都是写给其他工种看的。功能策划案是写给程序看的，美术需求策划案是写给美术看的，世界观策划案是写给美术或者任务策划看的，总之，在涉及到多人合作的情况下，策划案永远不是写给你自己看的，请各位策划同学务必注意。
对于独狼选手，你的案子对于执行另一个工作的你自己来说是不是清晰，如人饮水冷暖自知。
还有一个误区需要澄清，很多新人策划会纠结我该用word写案子还是用excel，其实工具不重要，重要的是你能不能把想法准确传达出去。对于有些商业项目，他们会有自己的策划案模版，等你进去之后跟着模版走就行，除此以外，怎么方便怎么写。我现在也经常用xmind来写策划案，都可以的。
写案子的时候如果不知道从哪里上手，可以按照游戏流程的顺序来写，实际上更好的角度是按照程序的实现逻辑先后来写，但那个对于初学者来说不太好理解，先不展开了。
游戏流程顺序怎么理解，我们随便打开一个游戏，会有登录界面，登陆以后会有创建角色界面，之后进入游戏场景还会有各种功能，我们就按照这个顺序来设计登录功能、创角功能、核心玩法功能等等，这个方式是所见即所得的，只要玩儿过游戏就可以扒功能拆解，就可以照葫芦画瓢学习写案子了。
我这里其实案子很粗糙，毕竟这个项目里我自己就是程序我能理解就行。大家可以看到，我在表格中有个红字备注“美术素材去掉了开花期”，这是一个DDL使用的例子，即当我的需求无法满足DDL且不影响核心诉求时，那么转变甚至砍掉需求就是一个更好的选择。
同样的，案子里对于作物的变异，我设计了普通类型作物有概率转化为古老种的设计，但是实际上手的时候这个设计导致我程序那边会有很大的不稳定性，所以我把这个需求也给去掉了，仅在我开发到后期才尝试着加了一个变异作物，就这么一个变异作物还给我带来了巨量的bug。
另一个案例是，在我原本的设计中，我对于古老种是有很多想法的。我不希望挂机很单调，想给玩家带来一些surprise，所以大家可以看我之前设想的古老种其实都非常有意思，每一个植物都有独特的功能。
我超喜欢那个发出尖锐笑声的还有满地乱爬的，那么最后为什么没做呢？是因为我不想吗？当然不是，是因为我的编程能力不足以让我实现这些特殊的功能。我在之前的贴子里也反复强调过了，落不了地的想法P都不是。对于这种暂时无法实现的需求，如果我们时间充裕或者团队有其他程序，是可以尝试花时间进行学习然后开发的，但我们的DDL只有两个月，是必然无法实现的，因此我把这些功能都砍掉了。
原型图：看得见的交互
当我们有了文字版的策划案，我们还必须准备一个“可视化的策划案”，也就是原型图。
说到原型图又有一个误区是，对于策划来说很多时候我们做的其实是线框图，因为真正的原型设计会比较精致并且往往包含交互，那种一般是美术来做的。
那么策划的原型应该满足什么要求呢？简单来说，需要让UI老师知道我的界面包含哪些素材、布局如何，需要让程序老师知道我的功能是如何跟用户行为交互的。毕竟UI原本就是指user interface，是用户跟程序进行互动的桥梁，所以好的原型图要让程序知道我的用户会进行哪些交互、入口在哪、反馈在哪。
我这里使用的原型工具是Figma，因为之前在国外上学的时候我们学的就是这个。现在国内也有非常非常多的原型制作工具，摩客，墨刀，MasterGo，用什么都可以。
一开始其实没有右边的图鉴和邮件界面，只有左边的培养皿和自动化界面，因为我一开始压根就没敢设计这两个功能，我担心DDL之内无法搓出来。后来之所以有了，是因为我的进度比预期快，所以才尝试着新增了这两个功能。
以单个培养皿的原型来说，这个界面包含上下两部分。上半部分我需要他包含展示图片的区域以及背景区域，下半部分是操作台，里边还有培育按钮、采摘按钮、作物名称、自动化标记、倒计时显示（后来去掉了）、阶段提示灯以及培育进度条。那么对应这里的每一个元素，理论上来说，在策划案中都要有非常明确的设计。
就拿作物名称这个文本显示区域来说，我在作物的哪个阶段要展示什么名字？要不要展示全称？展示全称的话英文本地化名字太长了怎么办？采摘后名字应该显示成什么……等等。这还是玩家不可交互的部分，对于可交互的按钮，实际情况要复杂更多。而这，也不过是UI层面的交互设计，如果是动作游戏或者MMO那种大型多人互动游戏，各个功能之间的耦合会让人炸掉的，所以策划真的是应该是非常细心的人，好的案子应该尽可能多地考虑到各种情况。
流程图：看得见的代码
《本草计划》没有用到流程图，因为我的时间精力有限不足以专门给每个功能出流程，所以这部分的设计我是直接在敲代码的同时进行的。这边拿一个《传教模拟器》的流程示意。
流程图就是把代码的实现逻辑可视化了，有的时候利用流程图在开工之前就可以提前锁定一些容易出问题的逻辑判定或者并行处理。跟程序对接的时候有流程图对方也更容易理解你要什么，比策划案看起来更直观。
《本草计划》中我在脚本的注释这里写了很多帮助我理顺流程的东西，还是那句话，自己是程序的话很多工作省略掉只要自己能看懂就行，但如果是跟别人合作，那么必要的工作是不建议省略的。因为沟通成本有的时候会占据一个项目开发成本的绝对大头。
三、功能实现
引擎：积木的来源
我使用的引擎是Godot，这是一款轻便的开发工具，给我的感受特别像Blender，网上下载了直接就是exe可执行文件，啥安装都省了。甚至网上还有内置SteamAPI的编译包，连自己装addons的步骤都省了，非常方便。
AI：良师益友
遥想三年前学RM的时候，全网找不到几个靠谱的好用的RM脚本编程教程，硬着头皮学还得从JS入手，并且学了也不代表你能直接用在引擎中。一切看起来都困难重重，阻力满满，因为敲代码就像做数学题，会就是会，不会就是不会。
但是在几年后的今天，境况已经发生了天翻地覆的变化，AI的到来让我们有了步入新领域的可能。如果在今天还有人跟我们说AI不行、AI做的东西不能用、用了AI的人都是投机取巧、AI会害人抢我们工作岗位这些言论，直接理都不要理，他们不用咱们用！
当我靠着AI提供的代码第一次实现了我的小盆栽，那种喜悦和兴奋远超我之后在Steam后台点击发布游戏时的感觉。我重新找到了“创造世界”的可能。
小学的时候，写小说，当我会写字，我就可以在书本上创造世界；后来，画漫画，当我会用手绘板，我就可以在屏幕中创造世界；如今，做游戏，发现会写故事会画画，好像都差了些什么，我的故事我的图片怎么都动不起来呢？这时我们才发现，对于电子游戏来说，编程才是那个最底层的能够创造世界的技术。
而AI的发展让编程的门槛大大降低了，他最直观的帮助其实不是提供现成的代码，而是让创作者获得了“安全感”，当他知道自己的某些设想不再是天马行空，这种“我能创造我想创造的世界”的信心，是非常可贵的。
我在《本草计划》的开发中使用的AI编程软件是文心一言和Deepseek，大家根据自身的情况选择合适的即可，能满足自身需求就行不要非得ChatGPT或者Copilot。为什么选择两个AI，是因为如果他们使用的是不同的语料，那或许我可以看到对于同一种问题的不同解题思路，在实际的体验中，遇到简单的问题我会直接丢给文心一言，什么都不勾选；遇到复杂的问题我会丢给DS，主要是看他在深度思考中说的内容（这部分有时比给出的答案还要有用）。
提问的时候我会说明我使用的工具，想要达成的目的，提供一下示例，详细说明问题，重申我的诉求（有时我会再给一个我认为的解答思路，看看DS怎么说）。一般这一套下来基本上AI也就理解我要做什么了。关于提问，我们应该尽可能缩小提问的“颗粒度”，如果一上来就给AI说“帮我做一个存档系统”，这跟“我要一个五彩斑斓的黑”也没什么区别。应该详细拆分你的需求（在策划案阶段都写好的），然后用程序实现时的最小结构来提问，比如图示的部分实际上就是我已经把游戏数据存储为json格式之后，想要进行“导入”这个行为时遇到的问题，至于导入之后如何复现游戏进度，那都是下一步的事情，不应该放在一起提问。
AI帮助我进行了前期的功能实现，但随着沟通次数的增加，AI无法保持前后统一或者无法继续提供解答，虽然我尝试过用一些取巧的手段尽可能延长AI的记忆长度，但最终还是因为不可控所以决定自己学一下gdscript。
UI：积木的地基
前文也提到过，UI是交互界面，是用户跟程序进行互动的桥梁。《本草计划》是一个主要通过UI进行游戏的产品，不像常见的2D或者3D游戏会有关卡之类的美术资产，这里所有的玩法都通过UI组件完成，在Godot中被称为Control Nodes。
在我们有了UI之前是否可以直接开始脚本的编辑？答案是可以的。对于数据的处理、游戏的流程这种脱离游戏表现的部分的确可以直接新建脚本然后开工。
但我还是建议可以先在引擎中把主要的界面内容拼好再进行脚本的编辑。这样做第一可以让我们在脚本编辑时有一个更加直观的参考，第二可以辅助我们进行功能开发优先级的判定，第三可以查漏补缺帮我们寻找逻辑漏洞。
如果没有完整的游戏资产，也可以用临时的资源先把UI框架搭出来，还记得原型图吗，直接把那里边的黑白灰图形导出使用即可，我们需要的主要是UI结构层级（上图中画面左侧的部分）而不是实际的美术表现（画面右侧的部分）。
很多时候，拼界面的同时，我们就能发现功能设计上的漏洞了，拼接的过程就是我们在脑海中复盘实现逻辑的过程。
最一开始如果不熟悉引擎的UI功能，我们可以用几个基础的Node完成所有界面的组装，比如所有文本都用Label，所有可点击的都用Button，所有图片显示都用TextureRect。当我们对Node比较熟悉之后，可以再用一些高级点的Node整理界面，比如把相关联的Buttons放在同一个VBoxContainer里，明确从属关系也方便优化美术表现。
记得给自己的UI节点重命名，英文还是拼音无所谓，但一定别是默认的命名，不利于后期进行定位。一个好的名称能让我们快速找到节点，变量和函数同理。不要嫌麻烦，磨刀不误砍柴工。
Godot非常贴心的一点是，他们给Node提前封装好了现成的信号。《本草计划》中我的按钮使用过的信号主要是“点击时”、“鼠标进入时”和“鼠标离开时”（模拟hover效果）。如果我们注意观察可以发现，信号根据Node的从属关系，从Object对象开始，到Node对象→CanvasItem对象→Control对象→BaseButton对象，这个父子级就像Unity的继承。面向对象编程的“封装继承多态”Godot这边其实都差不多。
脚本：看似代码，实为言灵
对于脚本的撰写，通过《本草计划》的开发我现在确实是祛魅了。一句话总结写脚本的本质：用代码形式把游戏的流程复述一遍。
所以与其担心什么脚本逻辑什么数据处理，还不如先学会“程序思维”，当我们能用程序思维把需求说明白，距离能亲自上手也不远了。
众所周知，程序员对数据进行的操作无非增删改查，让我们从这个角度来审视一个功能，看看程序思维是如何描述的。
还是上文那个图鉴系统，现在我需要实现“点击右侧的向下翻页按钮，显示新的作物图片和资料”这个功能，用程序思维是这么描述的：
1、点击按钮时，触发点击信号
2、调用点击信号绑定的函数
3、函数功能是把页码+1（如果大于27就不变）
4、更新作物的名称
5、图片1显示下一个页码编号的作物成熟期图片（如果作物没解锁则隐藏）
6、图片2显示下一个页码编号的作物生长期图片（如果作物没解锁则隐藏）
7、文本框1显示下一个页码编号的作物培育信息（如果作物没解锁则显示解锁按钮，如果金币不足以解锁，则按钮置灰）
8、文本框2显示下一个页码编号的作物特性（如果作物没解锁则显示解锁按钮，如果金币不足以解锁，则按钮置灰）
每一个“如果”都是一个if判定，我们发现5、6和7、8中间有很多描述是重复性的，这意味着代码也是重复性的，到时候可以复制粘贴。所以按照这个思路把每句话都翻译成代码，这个功能的基础内容就做好了。（下图中关于红点的部分是后加的新功能）
根据我们的梳理，可以获得如上的函数。但是这里很多逻辑还是通过引用其他的函数来实现的，比如上文的第4点更新作物名称，这个功能的实现上我们还得1、先获得作物的id，2、获得显示名称用的label节点，3、获得对应id作物在配置表中的name参数的值，4、赋值给label节点。这4步没有直接写在点击按钮的函数下，而是新建了一个update_plant_name函数，一方面是让点击按钮的函数看起来更简洁，另一方面是其他按钮也会利用到相同的功能，那么单独整理一个函数方便在其他地方复用。
上图是更新作物名称的update_plant_name函数代码部分，是不是跟我们刚才描述的逻辑是一样一样的？我那个时候对本地化的判定都是if 中文，elif 英文，elif日语这种简单粗暴的方案。
后来学会了match，那么中间的语言判定部分就可以换一种更好看的写法，是不是逻辑看起来更清晰更简洁？但如果不这么做也完全不会影响功能的实现。所以请一定不要有代码羞耻，写得笨一点也没有关系。
综上，这一部分想讲的是，写代码其实语法不是重点难点，重点难点反而是我们能不能把功能需求用足够详细的逻辑给描述出来。当我们能把实现逻辑说出来的时候，功能已经完成了，就像言灵一样，言出法随。语法通过AI或者上网查教程可以很快掌握，但是无法清晰描述功能需求反而是一个非常致命的缺点。如果不能把一个功能拆分成原子化的描述，那么在开发中就势必会遇到各种各样的问题，尤其是在策划这边很容易见到“我觉得这个功能不难呀，这不是很好理解吗”这种想当然的表述，但实际上程序在开发的过程中会遇到的问题并非表面上看起来的那样直接。这就要求策划对程序的实现逻辑有一个基本的认知。
四、美术制作
概念图：风格的先导者
不论是角色概念还是场景概念，都可以帮助我们快速定义游戏美术风格的主基调。一般来说，主美在确定风格方向的时候肯定是会跟制作人沟通的，制作人最好对自己的项目表现风格有一个明确的方向，如果实在没有，那就只能由美术来牵头了。
如果策划这边想要向美术传达一个方向，我们该怎么办？找参考对吧。对于具体的美术表现风格来说，参考图比较容易找到。那如何传达更抽象的“体验风格”呢？这边我推荐一个工具叫情绪板moodboard。我翻了好像只有工作项目有用到情绪板，那这里就不拿自己举例了，我上网找个图。
使用情绪板我们除了可以把项目的主视觉（色彩、冷暖、质感等）大致框定之外，还可以额外传达一种更加抽象的感受。情绪板的内容往往可以彼此之间毫不相关，但当他们拼凑在一起时想要传达的感觉是统一的，比如上图就包含了复古、梦境、青春、回忆等情绪。当你不知道怎么跟美术表达你想要的风格，或许掏出几个情绪板就好啦。
《本草计划》是一个小项目，我也并没有限定游戏的表现风格，所以概念图就看美术怎么出我就怎么用。所以又三老师提交了第一版植物后，我们都没觉得有问题，于是后续的所有美术资产都会根据这个方向进行产出。
UI：尽量跟主视觉保持统一
在开发《本草计划》的过程中，我一共绘制了3次UI资产。
第一次是在刚刚拼凑出最基础的游戏界面后，决定用一些稍微修饰过的美术资产做一个简单的替换，让我在后续的开发过程中感觉游戏是在“逐渐完善”的，算是给自己一个心理预期。
因为我游戏的世界观是科学修仙的方向，所以一开始想把UI往体现实验室的冰冷、科技感、简洁的方向做。于是我出了一个以灰白色为主的UI，并用这一版提交的Steam的商店页审核。鉴于我的初衷是学习Godot，所以关于UI风格我也没做太多处理，基本心态就是有就行。
但是随着作物资产的丰富，以及内测玩家们的反馈，大家都表示这个UI风格跟植物完全不搭，于是我根据又三老师在小红书上发的宣传图重新绘制了第三版UI。这一版用了更多的手绘风格，色调转向深绿，用橘红的线条搭配，强化了质感，最终上架也是使用了这一版的UI。
单看第二版UI其实也不能说难看，但确实跟游戏整体风格有点割裂，玩家不满意也是很正常的，好在游戏体量不大，UI的重绘没有占用太多时间，这也是通过评估在DDL内可以实现的优化点，如果最后评估说没时间做新的UI，那我可能就真的用第二版上架了。
在Godot里可以通过新增主题tres文件快速更换素材风格。以按钮主题为例，通过修改默认、点击时、悬浮时、禁用时等不同按钮的配色或者图片就可以让游戏内使用了同主题的所有按钮一键更新。
五、剧情撰写
世界观设计
《本草计划》使用了一个我已经构思好的世界观，所以在设计上没有花多长时间。有一个世界观可以让很多的剧情展开更加顺畅自然，并且可以让一些矛盾冲突更加独特，比如《灵笼》的世界观下，人类是选择拥抱情感活在危险中还是选择抛弃情感活在安全中，这就是一个很好的核心矛盾，并且值得人们思考。《本草计划》也有一个比较明确的底层设计，现在先不剧透，会随着后续的项目一点一点展示给大家的。
剧本大纲
我习惯先梳理一个完整的故事线，然后再拆分任务环进行配置，这也是之前在工作中常用的流程。关于故事主线，当我们成为创作者后我相信大家一定有一个同感就是我们可以进行创作的角度特别多，特别自由，反而是该选择用哪一个角度进行叙事成为了困难。对同一个概念，我可以从这个角度写，也可以从那个角度写，这个选择的过程往往让人纠结从而浪费大量的时间。
就是这个挂机小游戏，当我回过神来，我才发现自己竟然写了4版大纲，因为每一版都有一些自己的叙事主题和设计亮点，但每一版都好像有一些故事讲不通，所以一直在纠结在删改。最后，在DDL的帮助下，我没有再进行更多版本的优化，使用了第四版的大纲进行故事的拆解和文本的撰写。
文本撰写
在《本草计划》中，游戏的所有可阅读内容都是通过邮件的形式展现给玩家的，所以我需要以不同的身份给玩家发邮件，然后用不同人的口吻把剧情大纲中敲定的部分一点一点剥给玩家。
在开始撰写前，我需要先设计配置表，这一点在上一篇帖子中也有过说明。我使用的转表工具是Luban，所以我的字段就要符合Luban的格式要求，因此我设置了mail_id, title, content,以及本地化的字段。这样当我用中文写好了所有邮件之后，再用AI进行翻译就可以快速把其他语言的邮件都生成好并且在游戏内也可以直接查看。
目前的邮件一共有56封，字数8500，包含了两段主要的剧情线和一些游戏引导内容。游戏上架后的补偿也是通过邮件的形式发给玩家的，在大纲确认后邮件的撰写其实就比较省心了。我本来想再多写一些内容，但是由于我需要在程序中进行邮件的发送判定和其他的功能处理，导致我在写邮件的时候必须要考虑后期的敲代码的工作量，还是在DDL的帮助下，我忍住了创作冲动，保持了当前的文本量规模。
六、准备上架
Steam开发者账号
首先我们需要有一个steam开发者的身份，关于注册的教程B站有很多，小黑盒也有这里就不讲了。注册账号只有一条硬指标，那就是你得有一个能收外汇的银行卡，别的都是跟着教程走就能完成的。第一次注册的时候会收取100刀，相当于强制让你购买了一个steam direct费，你可以获得一个上架产品的名额。
Steam商店页准备
steam商店页一般需要注意的点主要是游戏的本地化名称记得填，如果不知道怎么填可以发邮件给客服。steam的客服特别可爱，真的很好沟通，大家不要怕不好意思，遇到真的没法解决的就发邮件。
一般来说我们需要处理这5个页签的内容，当然了，最主要的是图像资产和宣传片。
图像资产中包括商店资产、截图资产、库资产和直播资产。其中商店资产包括形象图片、小宣传图、主宣传图、竖向宣传图和页面背景；截图资产要提供至少5张游戏内的实机截图；库资产包括库宣传图、库形象图片、库主页图片和库徽标。每一个图像steam都给了需要的尺寸，根据要求制作并提交即可。这部分不难，但是资产数量比较大，所以一定要预留足够的时间。
（因为审核时用的是灰白风格的UI，实际上架是深色风格的UI，所以steam商店页这部分的资产我做了两遍）
Steam辅助功能
现在的steam游戏，最好要有云存档和成就，这也是steam官方鼓励研发在游戏中加入的功能。实际的操作来说，Godot有两种方案，一种是在插件里搜索godotsteam这个addon，另一种是在网上直接下载pre-compile包，就是一个内置了steamAPI的godot引擎。我个人推荐后者（因为前者没整明白），只要使用这个预编译包进行项目开发，那么在写脚本的时候直接调用steamAPI的初始化脚本就行，非常方便。
如果有不明白的地方，可以通过查询steam文档找到接入API的详细教程，或者大家来这个网站查资料下资源也行。
七、宣发
现在这个年代，独立游戏不宣发纯靠自然量基本等于暴毙，除非项目自带热点，比如非常能整活的那种游戏，否则多少还是请各位开发者去推一推，哪怕不找发行自己至少也得搞几个社媒账号运营一下。
B站
B站是一个视频平台，虽然也能发图文贴，但流量相当有限。所以如果大家有游戏宣传视频或者实机演示，都可以在B站上发，鉴于steam商店页需要我们提交宣传视频，所以B站上每一个独立游戏应该至少都会有这个宣传视频。目前B站上的用户群体对游戏开发或者独立游戏的兴趣总得来说还不是特别高的那一档，所以如果在B站发视频，最好还是要有足够多的内容展示才会有比较好的效果。
前一阵有一个游戏宣传视频叫《天沦落九霄》，是一个很有意思的案例。那个游戏只有一个开发者+两个营销人员，通过使用UE商城资产、定序器动画、AI配音和音效，制作了一个完成度看起来相当不错的demo演示，获得了40w的播放量和3000多条评论。这个案例告诉我们，即便游戏刚刚起步，但只要看起来有效果，B站用户是会买账的。
目前我在B站一共上传了3个视频，最底下的那个是一开始提交steam商店页审核的视频，用的是旧的UI；中间的视频是我尝试蹭《灵笼》的流量做的视频，效果非常一般，但我觉得能蹭还是蹭吧，不寒碜；最上边的视频是替换了新UI后的宣传视频，也是目前播放量最高的，截止写稿5800。这些视频没有购买流量，能有这个播放其实已经超出预期了。
小黑盒
这个平台是宝藏平台，我在以前完全没接触过，后来是一个台湾开发者朋友（@FilterGame阿胜）跟我们说，可以试着注册一下去做做宣传，所以我在年初那阵就搞了一个小黑盒账号。经过这半年的使用体验，我的一个最明显的感受是，小黑盒是一个玩家浓度相当高的图文平台。单论玩家纯度，是超过B站的。
另一个小黑盒的好处是，它的后台会接入steam后台数据，也就是说，只要你认证了steam开发者，就可以在小黑盒以开发者官方的身份跟玩家互动，而玩家在小黑盒上对你游戏的关注也可以转化到steam上，比如“一键添加愿望单”的功能，这让小黑盒的玩家转化非常容易。
目前在小黑盒上，关于《本草计划》的推广我只写了一篇帖子，也就是这篇的前置文章《做独游真的很容易|如何在两个月从零上架一款游戏》。当时游戏刚上架一周，把要命的bug处理了之后就火速开始了宣发工作。那个帖子写了很多游戏开发过程中的事情，并且UC头条了一下，在标题中构建了一个“快速”“独立”“有能力”的开发者形象来获得流量。
文章截止撰稿时有2w8的阅读量，应该是起到了很不错的宣发效果了，我看了一下小黑盒上《本草计划》的关注数量有336，还不错，看看能不能努力让关注数量破1000。
写手和鉴赏家
这次我联系了大约二十名左右的写手和鉴赏家朋友来给《本草计划》做宣传，就我的个人观感来看，他们相当敬业，这一点大家可以去翻一下游戏的steam评价，正常玩家绝对写不出那么多长篇大论的评价的hh。
因为这个游戏的立项初衷是学习Godot，所以关于销量我是没有预期的，因此评价我也没必要追求好评，跟写手朋友们说的都是正常评价客观评价，不过他们基本也都还是出于人道主义关怀给打了好评，感谢他们的善良。
这里有一点需要开发者朋友们额外留心，就是steam的评价数只统计自费购买了游戏的玩家评分，通过key或者其他方式获取的评价不纳入打分统计，因此即便我这边有几十条好评，但实际的玩家评论数量寥寥无几。因此如果想给steam刷好评，就得用一些别的方式了。（当然了，我不推荐也不建议刻意刷好评的行为，这对付费玩家极度不公平，刻意刷差评我也不建议，三国杀那种已经成为文化的不算）
最后
好的以上就是这次开发《本草计划》的两个月我做的事情，实际上会更琐碎，也有很多技能都是融在了某些环节中不好单独提取出来进行展开的。所以做游戏简单吗？其实很难很枯燥，需要开发者掌握的技能真的很多，做游戏绝对不是一个轻松愉快的事情。
那些广告说什么0基础十天半个月就能学会开发游戏纯纯Funny Mud Pee，不说全流程全工种，单拎出来一个策划、程序、美术、音乐，哪个不得学大量的基础知识进行大量的实操才能慢慢掌握，也就是策划这个岗位比较特殊，很多技能不体现在明面上，所以水货也很多。
如果大家看了帖子有学到一些东西，那是最好的。如果看了帖子觉得做游戏好复杂，不想自己做了，也是很好的。创作的形式有很多种，自我表达的方式也有很多种，为什么非得选这个最复杂最痛苦技术门槛最高的呢？
如果意识到做游戏这么困难，还想来参合一脚，头铁想要选这种形式来证明些什么，那就不要有任何自我怀疑，只需要稳步向前，学习、练习、学习、练习。独游开发者的榜样我觉得可以选做了7款游戏的流贾君或者做了18款游戏的半桶水战士，向他们学习。“Talk is cheap，show me your game”，不要再来拿做游戏当赚取流量的手段，掏出你的作品，狠狠甩在玩家、资本的脸上，告诉他们我这个好玩，来买，来投钱！我希望未来的独游开发者都有这样的觉悟，与大家共勉。
独游凯恩IndieCain 