这篇文章献给那些想做游戏但是瞻前顾后、一直犹豫不决迟迟不敢动手的朋友们，愿你们能够放下无谓的自尊和完美主义，享受粗糙、野蛮、笨拙但实用的开发技巧！
随性而来的尝试
故事的开始是在4月份，那个时候我跟另外一名独立游戏开发者闲聊，聊到引擎的使用，他说想试试Godot，彼时的我还挣扎在《深渊谜影》跟《传教模拟器》的开发上，并没有认真思考过这个事情，但是那段对话已经在我心里埋下了开新坑的种子。
5月份，因为以上两个项目中的开发者都有事无法推进，我反而稍微闲下来一些，顺便说一下，《深渊谜影》的程序是研究生，要忙毕设，《传教模拟器》的程序是高中生，要忙高考。我突然就回忆起那次对话，于是冒出来个想法：“要不要干脆就用Godot做一款新游戏吧！”
于是5月6号，我开始学习Godot引擎，5月7号开始立项《育苗师》。
说干就干
考虑到这个项目的立项初衷是学习Godot，所以做的游戏不应包含复杂玩法。人性是“欺软怕硬”的，对问题也一样，我们害怕处理复杂问题，但是热衷于解决简单的小问题，把这个思路放在游戏设计里，就要求我们不要在能力不足的情况下开发高难度大体量的游戏，否则会极大地消磨创作热情。
于是，我思考了一下玩法简单的游戏类型，最终决定做一款挂机游戏。这类游戏交互有限，不需要复杂的场景和关卡，没有敌人和状态机，甚至不需要像文字冒险那样写个百八十万字，真的是初学者的理想游戏类型了。
因此，我用一天的时间写好了基础的策划案并制作了原型图，脑海中的玩法循环跑通后，接下来就是上手在引擎中逐步实现功能了。
不需要复杂的功能，所以案子很简单
甚至也没多少界面
引擎的使用
开发一款游戏简单来说就那么几步：
1、有一个想法
2、把想法整理成设计案
3、准备美术资产
4、功能开发
5、跑测
6、上架
7、运营
再次重申，因为这个立项的初衷是为了学习Godot，所以我的主要注意力会放在功能开发上，因此美术资产就没必要浪费自己的时间精力进行绘制，所以我找了一位美术爸爸帮我出图@又三（大家可以在小红书找到他）。
在没有美术资产的时候，我们怎么办呢？难道要一直等到美术提交了素材才开始功能的开发吗？当然不是！
只要随随便便搞一些临时素材，就可以进行功能的开发了，等功能没问题美术资产就位后再进行替换即可，所以美术和程序这两条腿是可以并行的。
故事的开始是一个盆栽
我的第一步是在引擎中制作一个能够装下一个植物并且显示生长进度的花盆。这里涉及到了Controller、TextureRect、ProgressBar、Label这几个节点。在Godot中，所有的游戏内组件都是以节点进行拼接的，类似Unity的Component，Godot贴心的给不同的节点类型标上不同的颜色和图标，非常直观。
像我这样的挂机游戏，因为不涉及到复杂功能，玩家几乎就是纯玩UI，所以我的节点也相当纯粹，几乎只有绿色的Controller类型和子类。（大家如果看过其他Godot开发者的项目，能发现花花绿绿形形色色的节点）
只有绿色也能做游戏！
当我有了一个小花盆，我就可以复制（生成实例）更多的花盆到主场景里，这样做的好处是，只要更改原视小花盆（父类）的状态，所有其他的小花盆（子类）都可以随之变更，当我想新增小花盆的功能时，就会提升很多的效率。
初具人形（bu
随后我加上了计时器和退出游戏的按钮。到这一步，我学会了Timer和Button的使用，学会了把节点实例化。
因为没有正儿八经学过程序（看过一丢丢Py和Js），我的代码主要还是由AI帮我写的，我使用了文心一言和Deepseek，后来才发现Godot有Gemini插件。起初，我以为靠AI的帮助，做这个小玩法应该问题不大，但很快我就意识到，我低估了挂机游戏的实现难度。
最大的挑战在于，AI无法在大量对话后准确记录之前说过的方案，很可能在几十次对话后逐渐忘记之前自己设置的变量、实现的逻辑，转而用新的方案实现同样的功能。这个时候如果直接贴代码，就必然会报错，所以为了更长久的稳定性，我还是决定自己学一下gdscript。
课程是在B站上随便搜的，《Godot100集教程》Up主有口音，但是整体来说不影响观感，其中对于信号的部分讲解跟最新的Godot4版本好像有些出入，大家自己判断一下。
用二倍速迅速过了一下我需要的板块，随后我就开始重新写游戏脚本了，这样主动权在自己，AI负责提供细分功能的实现逻辑，我再去根据实际情况决定采纳还是调整。就这样，5月10号的时候，我开始了现有代码的重构，把已有的逻辑用自己的方式重新写了一遍，大大提升了自己对gdscript的理解。
到5月13号的时候，基本的点击种子选择、随时间积累进度、不同进度切换图片这些功能就都差不多了。
是阳光，我使用了阳光！
为了进一步测试不同类型种子的不同生长阶段，我一晚上准备了全部135个作物的临时素材，那个时候想的是先把引用逻辑都写好，以后可以直接替换素材了，所以吭吃瘪肚画图写逻辑，完全没想到就在半个月后，我学会了使用Luban进行转表，之前的图片引用逻辑全部白写了……
所有类型作物的美术临时素材
代码并没有想象中那么难
在大致掌握了gdscript的情况下，其实主要就是知道一些执行顺序啦，生命周期啦，常见的逻辑判定啦，条件判定啦，就够用了。
知道_ready()里放一些初始化的东西（不用_init()也没关系），知道_process()里是每帧执行的动作，知道==是等于，!=是不等于，知道String、int、float之类的数据类型，其实到这里为止已经可以完成非常多的基础功能了。
那个时候我还不知道Autoload可以自动加载一些全局性的脚本，所以有些跨场景的功能就死活都实现不了，但是问问AI其实也就都知道了，包括让我非常头大的Signal传递，其实也有很多替代方案。
回想一下我曾经对程序的印象是：可以用优雅的代码实现复杂的功能。所以认为学不会那些漂亮高效的实现逻辑就等于不会程序。
但是事实上，我们这些小卡拉米做一些简单的功能压根用不上那些高级的语法和代码优化，我在刚开始写代码的时候，判断全部用if else，特别蠢，但是不会因此卡进度。
请叫我elif的神
你能想象到我敲了几百条elif吗？让那些编程的大佬看到可能会笑我一年吧，但是只要程序能跑，玩家才不care你的实现逻辑是不是优美是不是简洁，所以代码羞耻这种东西，我们一定一定要摒弃掉。
不管多蠢的实现逻辑，只要能跑，就是胜利！！！
包括如果不会用程序生成节点，那就在编辑器里手动创建，笨一点、效率低一点都没有关系，能满足需求就行了，等我们过十天半个月再回头看，可能就知道如何用更高效的方式实现同样的功能了，到那个时候，再优化也不迟。
慢慢就会更多的东西了
比如关于邮件的生成，这部分的脚本相比我刚开始学代码就“高级"很多，我知道如何用代码生成一个新的节点、如何设置节点的属性（大小、位置、颜色、主题）、如何接收信号，如果这些东西不用程序进行生成，那我们就老老实实在检查器里添加就好了。
再一点是，新手程序很容易遇到各种bug但是不知道怎么修，或者更绝望一些，不知道是哪里出了问题，也不会打断点。这个时候就直接祭出大杀器：print()。
不知道哪里出了问题，print就对了
只要不嫌麻烦，每一句代码中间都print就对了，看着自己的log可以非常直观地感受到进度在哪里，是不是符合预期。如果你这么做了，恭喜你，你掌握了小黄鸭调试法。
Godot的log输出面板很好用，包括栈追踪、显存查看、调试器等，一开始不会看没关系，给自己一些时间，每天多熟悉熟悉，很快就掌握了。
调试器真的很好用
对于脚本的学习，我就一句话:
瞎JB写，能跑就行，蠢一点也没关系，没人会笑话你！
转表工具提效
程序的基础框架差不多之后，我面临一个内容完善的问题。因为我的游戏有剧情，虽然不多，但是也涉及到几千字的文本。
因为我之前是正儿八经干过策划的，所以我知道常用的办法就是设计配置表，通过转表导入数据到引擎中。给没有这方面经验的朋友简单介绍一下配表的实现逻辑：
先说问题吧，虽然所有的引擎都有地方让使用者手动输入文本，但通过这种方式无疑是低效且高风险的。万一之后改剧情了，就需要在引擎中找到对应的节点然后修改，特别麻烦。
就像这样
那么通过配置表的思路是如何实现的呢？
首先我需要设计一张Excel表格，把我可能用到的文本都放进去，比如邮件表我就需要邮件id、邮件名称、邮件内容。如果涉及到本地化处理，还可以把其他语言的文本也贴进去。
注意看前两行的字段
之后通过转表工具将Excel表格的内容转化成可以被引擎识别的格式，比如转成csv或者我这里用到的json。转表工具我使用的是Luban，官网在这里大家可以自行去看介绍 | Luban，如果是大厂的话会有自己的定制化转表工具，这里不展开了。
转表之后的数据，看起来像这样：
excel表的字段变成了参数名
这样一来我就可以在脚本中通过调用mail_id, name, content等字段快速查找并引用相关的数据，不论是邮件功能，还是RPG游戏更常见的对话功能，其实都是这么处理的。在配置表中写好说话的NPC、对话内容、对话奖励等等，好的策划是可以合理设计配置表，以方便程序之后进行简单的数据引用的。
《本草计划》我一共设计了3张表，分别是《任务表》、《邮件表》和《作物表》，实际上游戏内引用到的只有后两张表，对于一个大型商业项目，涉及到的配置表是可以轻松突破上千张的。
美术资源合入
随着功能的开发，又三老师基本按照每周一到两次的频率提交美术素材，像刚才说的，我使用了配置表进行数据导入后，只需要在《作物表》中替换美术素材的路径即可实现游戏内的动态调整，非常的方便。
把资源路径填进来就可以了
因为预期的开发周期是两个月，我跟又三老师商量了一下美术的制作周期，原本是要给每个作物画3张图的，但是那样一来开发周期会延后许多，不符合我的期望，因此我们把每个作物的图片删减为两张，到六月中下旬刚好画完。
每波10个作物
原本想着又三老师提交的图是按照作物类型进行区分的，但由于我没有给美术风格做任何的限制，这导致了一个问题是：美术的图片非常漂亮，但是不符合游戏框架下的类型。
在原本的设计中，有一个作物的类型叫“藤蔓类”，我设想的都是细细长长的那种扭曲作物，但是随着美术资源的提交，符合这种形态的作物少之又少。
这个时候有两种办法，一种是让美术爸爸按照既定的分类重新画，另一种是策划调整作物类型的设计。由于这个项目的初衷是学习Godot，所以调整美术资产是完全没有必要的，更聪明的做法是由我这边调节作物的分类以适应美术资产。
因此作物类型从“藤蔓类”变成“树藤类”，可以更多地兼顾又三老师提交的另外一种难以分类的作物。当然，这样做也导致我不得不把所有的作物全部重新分类整理一遍，增加了海量的额外工作，有利有弊吧。
重新排一遍累死我了
准备上架Steam
当功能基本完成，美术资产也基本就位后，就可以准备Steam的上架了。
我这边由于有过上架的经验，所以深知Steam商店也是一个需要大量时间精力进行准备的东西。我在5月31号就已经开始着手steam商店页的素材准备了，那个时候功能也没做完、美术资产也没做完，但是审核需要时间，所以我直接用临时素材搞了一套丢上去。
这部分多提交几次就熟练了
准备好商店页需要的形象图、宣传图、小宣传图、库资产图标、社区图标等，然后准备5张截图和1个宣传视频，就可以提审商店页了。
这是临时宣传图
商店页的审核一般需要3-5天，虽然我已经很熟悉流程了，但还是无法保证可以一次性通过，因此一定要预留足够多的时间，为什么？因为游戏想上架需要商店页开通至少2星期。也就是说如果我希望6月底上架，那么6月中旬商店页一定要开，这也是为什么我5月底就开始准备商店页的素材提审了。
只要审核通过，那么之后再次替换新的素材就无需重新审核，所以我在6月底替换新素材的时候就非常舒服。
风格180°大转变
同理还有游戏包的审核，先准备一个能跑的包提交上去进行审核，即便里边很多东西还不够完善。包体的审核比商店页还要慢，并且这里新踩了一个坑是：如果你在商店页勾选了游戏支持云存档和成就，那么提交的包体必须具备这些功能，否则审核会失败。好的做法是，先不勾选这些额外的功能，等包体审核通过之后再加，这样不会耽误时间。
我是6月12号开通的商店页，那个时候都是临时素材，但这个时候已经可以进行很多后续的宣发工作了。
无止境的优化处理
《本草计划》是在6月30号那天正式上架的，彼时所有的美术资产已经完成，但是功能还有缺陷，并且有一些阻断性的bug存在，因此虽然游戏上架了，作为官方我还是苟着没有发声。
毕竟，虽然立项的初衷是为了学习Godot，但是如果游戏完全没法玩，也确实说不过去，这样的话被玩家骂也是在所难免。
非常真实
所以从6月30号到今天7月7号，我一直在狂修bug，该说不说，这一周对编程的理解比我之前的一个半月还多，非常刺激。
而我也开始顺便学习steam社区的运营和维护，一开始发更新贴都是冰冷的么得感情的，后来逐渐放飞自我，开始角色扮演了（bu）。
逐渐融入运营的角色
到今天为止，刚刚好立项两个月整，这两个月过得非常充实，熟悉我的朋友知道，我白天要上班，下班要带娃，一般做游戏只能是摸鱼的时间或者娃睡了以后，所以能在两个月完成《本草计划》的开发真的要感谢不怕自己猝死连轴转的我和不怕我猝死疯狂提bug的群友们，是我们共同努力才有了这个作品。
善良群友的鼓励
游戏的上架并非游戏开发的终止，上架后的社区运营和bug修复甚至是新功能的开发都是更长维度下我们作为开发者需要考虑的事情。
写在最后
这篇帖子想用我的亲身经历告诉大家，做独立游戏并没有你想象中的那么难，埋下头去，往前冲就是了。
如果用两句话来总结这段经历，那么：
第一，不要有任何完美主义的想法，不要想着设计全新的玩法、设计全新的美术风格、精致优雅的编程能力、文笔卓绝的文案撰写，统统不要想。就记住，我们就是普罗大众中最普通的一员，能上架就可以了，被骂也没有关系，骂你的人不在意你能力如何，能打败你的只有你自己。
第二，坚持长期主义，现在的我很辣鸡，不代表一个月、一年、十年后的我还很辣鸡。每次开新项目，学到一些新知识，都会让以后的我们越来越顺。并且话说回来，即便十年后的我很辣鸡，那又怎样？做游戏难道不快乐吗？只要我自己快乐，我管我自己辣不辣鸡呢？
这里是克系游戏开发者独游凯恩🐙，感谢大家的支持，我下一篇帖子会写这两个月实际上遇到的各种困难，真实情况总是没有看起来那么光鲜亮丽，哈哈哈哈哈哈哈，以上，我们下篇帖子再见！
更多游戏资讯请关注：电玩帮游戏资讯专区
电玩帮图文攻略 www.vgover.com
