18个月做了17款游戏后他们才明白独立开发最难的不是开始而是收摊

在独立游戏圈，几个朋友在Game Jam上认识，然后决定一起做游戏，几乎是最常见的创业故事开头。

只不过，大多数故事也就停在开头了。项目文件夹还在，群聊还在，但游戏没了下文。

最近Reddit上有个帖子倒是挺特别，发帖的是一个来自比利时布鲁塞尔的四人小团队。他们在2024年布鲁塞尔Game Jam上认识，彼此聊得来，又都喜欢独立游戏，于是定了一个有点莽的目标——每个月发布一款游戏。

18个月过去，他们做出了17款月度游戏，还顺手做了几个额外的小作品。游戏主要发在Itch，后来也上了Steam。作品几乎全免费，收入可以忽略不计。

但他们说，这一年半学到的东西，可能比之前空想几年都有用。

这不是一个“草根团队逆袭”的故事，更像是一份很朴素的开发笔记：几个新手真的开始做游戏、真的把游戏发出去之后，才发现那些听起来像废话的经验，原来每一条都要拿工期和心态去换。

·第一个坑：想做的永远比能做的多

他们最先提到的，是控制规模。

这句话独立开发者应该都听过。但问题在于，新手往往不是不知道要做小，而是不知道什么叫“小”。

一个简单的谜题机制，后面可能跟着教程、关卡、反馈、失败处理；一个顺手加的功能，可能要牵动UI、存档、数值等一大堆边缘情况。脑子里想的时候，它只是一个点子，落到项目里就成工作量。

这个团队也承认，最早的几个项目都做得太大。明明经验不多，却很容易在讨论时越聊越兴奋：要不要加点剧情？要不要做几种结局？是不是可以再来一个成长系统？

这就是老生常谈的话题——很多独立游戏不是死在没创意，而是死在创意太多。每个人都想给游戏多添一块肉，最后变成了一锅不知道该怎么收拾的东西。

针对这个问题，他们给出的建议非常简单：做小一点。

做完，发布，然后做下一个就好。因为“完成一款游戏”本身就是一种能力，而且是最容易被低估的能力。你只有经历过收尾，才知道什么功能该砍，什么问题可以暂时放过。

不会收尾的人，项目永远都处在“快好了”的阶段。

·玩家看不懂，不是玩家的问题

他们提到的第二个教训，是玩家经常看不懂开发者觉得显而易见的东西。

这是所有游戏测试里最让人崩溃的场面：地编摆了一个视觉引导，玩家没看见；QA觉得某个按钮闪得已经够明显了，玩家绕着它走了三圈；策划设计了一个自认为很自然的教学关卡，玩家在第一步就卡住。

很多开发者的第一反应是：“这还看不懂吗？”

但问题恰恰在这里。你看得懂，是因为你知道这东西为什么存在。玩家不知道，是因为他第一次进入这个空间时，看到的只是一个陌生场景，以及一堆还没建立意义的物件。

所以他们后来学会了给信息“加保险”。

一个重要提示，不要只交给一种表达方式。环境可以引导，声音可以提示，关卡布局可以把玩家往正确方向推。不同渠道反复指向同一件事，玩家才更可能在自己的节奏里理解它。

但他们也补充了一点：尽量别用强制弹窗。

很多新手一遇到玩家看不懂，就想弹个窗口，把话讲明白。但弹窗往往是最粗暴的办法。它当然有效，可也容易打断体验。相比之下，告示牌、浮动文字、NPC对话、场景里的重复元素，往往更像游戏世界的一部分。

真正好的教学，是让玩家误以为自己是聪明人。

·Itch很自由，但流量全在Steam

他们一开始大部分游戏都发在Itch上，因为Itch适合小实验，上传方便，氛围也更像独立开发者社区。而且不用每个月掏Steam那笔100美元的上架费。

毕竟对一个“月更免费游戏”的小团队来说，每款游戏100美元不是小数。何况他们本来也没打算靠这些作品赚钱。

但后来，他们把最近两款游戏也放上了Steam，结果很明显——玩家变多了。

所以他们总结，Itch像一个创作者集市，适合试验、交流和快速发布；Steam则是一个更大的消费场。它更商业，抽成更高，门槛也更麻烦，但确实能让作品碰到更多普通玩家。

对于这个团队来说，上Steam不纯是为了变现，也是为了获得更大的反馈池。作品放在不同平台，面对的人群会完全不同。Itch上的玩家可能更包容，也更懂开发者处境；Steam上的玩家更接近普通消费者。他们不会因为你是小团队就自动降低预期。

这两种反馈都重要。前者帮你继续做下去，后者提醒你外面的世界长什么样。

·四个人一起做，最怕各自脑补一款游戏

在问答里，有人问他们团队是怎么分工的。

他们的回答是：四个人基本都是全能型，没有严格专精。大家都能写一点代码，做一点设计，哪里缺人往哪里顶。这样的好处是灵活，坏处是很容易每个人脑子里都有一款不同的游戏。

他们提到，团队合作必须经常对齐想法。如果沟通不够，每个人都会按自己的理解往前做。程序以为这只是临时玩法，美术已经按正式版本画了一套资源；有人觉得游戏应该轻松一点，另一个人却在做硬核关卡。

很多小团队其实是被沉默拖垮的。大家都很客气，都以为别人懂了，最后项目拼起来才发现不是一个东西。

所以他们后来形成了一个很简单的脑暴方法：不讨论“整个游戏怎么变好”，只讨论具体问题。

比如，这个机制不好玩，或者这个反馈不清楚。这时大家先离开电脑，各自拿纸想十分钟，再回来讲自己的方案。哪怕没有人能直接提出完整答案，但几种半成品想法碰在一起，也有机会慢慢收敛出一个可执行的解法。

因为电脑前的非正式讨论，太容易变成“先改一下试试”，最后团队被实现细节带着跑。纸和笔反而能让人先想清楚问题到底是什么。

评论区还有个问题是，他们每个月做新游戏，会不会复用之前的东西？

他们的回答是：没有特别规划，但需要的时候，就回旧项目里拿，或者问当初做那部分的人。

一开始做游戏，很多人迷恋“从零开始”。好像只有每次重新搭一套流程，才显得纯粹。可做得多了就会发现，真正需要原创的是玩法体验和设计判断，不是每次都手搓一遍功能。

能复用，说明团队开始有积累了。对月更团队来说，这种积累尤其重要。相比大厂的工业管线，这更像手艺人的工具箱。锤子用顺了，下次就不用再拿石头砸钉子。

·他们最后学会的，是不要把每款游戏都当遗作

这个团队一开始对“每月一款”比较严格，后来逐渐放松了。他们说，这个集体的初衷还是为了学习做游戏，而不是给自己立KPI。

现在他们的模式也变了：不再总是四个人一起选一个项目，而是每个人做自己的游戏，其他人给意见和帮助。每周日尽量线下碰面，工作之外继续推进。他们也发过自己觉得不好的游戏，第一个项目后来甚至下架了。

这点反而让整个故事更可信。能长期做下去的创作习惯，通常不是靠硬撑，而是找到一个不至于把人压垮的节奏。

独立游戏圈有太多人卡在“我的梦想之作”里。第一款游戏就想做人生代表作，想把所有喜欢的东西都塞进去，想一次证明自己。结果几年过去，项目越做越重，人越来越累，游戏还是没能来到玩家面前。

这支比利时小团队的经历揭示了一件很实际的事——你不一定要先成为一个成熟开发者，才有资格发布游戏。

很多时候，恰恰是因为你不断发布、搞砸、复盘、再开始，才慢慢变成了开发者。