聊聊我的独游看法

做了一段时间的游戏，来讨论一下独游开发可能会遇到的一些问题和个人看法，不打算说太多游戏设计的东西，更多的是将目光放在现实中需要注意的事情，同时可能以策划角度思考比较多，因为我在团队中干这个。

起初确实信心满满啊，做着做着就会发现很多杂七杂八的问题开始浮现，有预想独游很难，实际上手也感觉到与开始的预期有所偏差，去年是想着写项目总结，不过后来想了想，不如直接把自己尝试做独立游戏的过程感想写出来，于是就有了这篇文章。

写出来是想和大家进行交流，欢迎畅所欲言。

 

关于心态和目标

 

相信很多人一开始都是信心十足，想要做出一款优秀的独立游戏，想着前路虽然未知，但是相信自己有能力去解决。

这种想法确实应该保持，因为在遇到困境的时候要做的是想方设法的去解决，如果一直打退堂鼓那根本不可能做的下去。

保持一个良好的心态是很重要的，正确对待制作过程中遇到的各种困难与失败，不要被击垮。一种方法是做好预案，尽可能的考虑到所有情况和意外，可能会累一些，不过这样在真正遇到的时候也不会自乱阵脚。

在我制作过程中也遇到了不少的问题（之后的部分会详细讲一下），确实，有一段时间内我也感觉有点迷茫，不知道该怎么做，不过比较庆幸的是，在梳理了一遍自己的想法后，还是找到了目标。

如果你想做独立游戏，那说明你肯定是有自己的想法的。保持初心，想明白这个游戏的定位是什么？是为了热卖？为了表达思想？还是想让玩家得到某种体验等等。

总之你需要对自己的游戏有一个定位，我是将想要讨论的思想列出来，让自己不会忘记是想表达什么，然后写出游戏的特征，明确游戏大致是什么样子。

 

看起来很简单，只言片语甚至看不出来什么。不过就像我刚刚说的，其的目的只是让你不会做着做着就陷入迷茫，是给自己看的。这个是关于表达的，其他类型也是按照制作目标写出来，将其作为指路灯用。

有人说玩法应该是最重要的，应该要先考虑玩法。嗯......其实关于玩法和思想，每个人都有自己的看法，在我的看法中，思想要前一步，玩法是在思想确定之后才去辐射开的。不过先定玩法在去定思想的也不是没有。可以说思想也属于包装的一部分，玩法确立后，用独特的思想去包装游戏，也是常见的手法。

也不必去纠结二者前后关系，它们几乎同等重要、缺一不可，看灵感是怎么决定的了（笑）。

“好玩”对于每个人而言都不同，个人觉得不好玩的游戏不一定是烂游戏，只是可能没有理解或不认同作者想要表达的东西，玩游戏其实也是玩家与开发者思想交流的过程。

 

关于人员和团队

 

一般都分两种情况，独斗和团队。如果是六边形战士，那独斗相较于团队更适合，所以这一小节更多的是讨论团队的组建和遇到的问题。

而在团队中，并非所有人都是六边形（要是全是那没话说了...），大家都是各有所长，聚在一起发挥自己的长处，共同朝着一个目标努力，这就是团队的目的。

第一个常见问题就是团队组建，其实召集一群志同道合且各有专精的人进入团队并不是那么难。

招人方面，其实有很多方法，首当其冲的就是形如GameJam、MiniGame等的开发活动，无论线上线下，你都可以看到各个方向的开发者活跃。在这里你可以去和他们聊聊自己的想法，看看有没有想一起将其实现的。一回生二回熟，慢慢的你就能见到很多人也怀揣着大展拳脚的想法，从中寻找志同道合的朋友即可。

当然，身边若有类似的兴趣爱好团体，也是一个好去处。比如我就是线下参加了一个开发社团，与朋友们一起组建的团队。

（这里宣传一下社团公众和b站号，来点关注）

社团的好处就是会有很多机会可以线下交流，大家聚在一起时间长了自然就能明白各自的想法，所以，讲！把想法讲出来，和大家讨论讨论，用不着扭捏，总是觉得自己的想法不好，不讲出来怎么知道其他人的看法呢？

又或者是靠自己的人脉，笼络各种各样的人，出门在外靠朋友嘛。

在组建完团队后，也同样会面临许多的问题，比如团队成员有冲突、有人摆了之类的。这些问题都需要有人去解决，放任不管只会产生不好的影响。

 

这种时候靠的就是交际能力！

如果你是团队领导者，你势必要负起巩固与领导团队的责任，举个例子，假设你队伍中的成员产生了意见不和，而且都是项目的核心开发者，你会怎么做？如果是因为非项目事情闹矛盾呢？

所幸我所在的团队中并没有遇到很激烈的冲突，我们的处理方式就是坐下来一起解决问题，将矛盾说开，大家都讲一下自己的看法与观点，寻取最优解。道理说起来就这么简单，能不能施行下去要下不少工夫。遇到特别强硬的队友会让你感到很头大的，有很大的可能会出现两头受气。（这里希望都不要把互联网的戾气带到现实交流中，不然容易起冲突）

个人感觉线下开发效率会远比线上高得多，线下的面对面使得交流成本大幅降低，减少了信息传递出错的可能性。我在之前打线上minigame时，由于无法及时传递信息，导致开发进度经常停滞或出错（现在想想，自己也有很多地方没做好），而gamejam的线下开发体验就完全不一样：脑暴、迭代、验收、测试都能得到很快回应，所有任务都能得到直接对接。

由于是学生团队，一旦开学后，大家的时间很难调配，即使有线下地点也很难做到每个人都全勤，不过好在团队成员都能合理安排自己的时间，在不能同步的时间各做各的东西，同步时间可以用来对接进度和解决问题。

这也是我比较推荐的工作流，不必追求所有人都到场，只要任务分配下去，按照时间表去做，然后每隔一段时间（上学上班建议一周一次，放假可以三到四天一次）进行对接汇总，让各个成员都能了解其他人做到什么地方，对自己的规划再作调整（很多时候会出现一些功能需要前置功能实现）。

当然有时会出现成员摆烂的情况，如果有明确的DDL，我对此的态度大都是比较强硬，因为在规定时间内不能完成任务，拖慢的可能不止项目进度，还会影响其他人的态度（这是真的，我在实际开发中也遇到了这种情况），所以上面的对接汇总就起到了催工的作用。

所以在一开始定时间表的时候，要保证接受任务的人能够一起商讨，这样讨论出一个合适的工期能够兼顾效率与舒适度，不会出现时间紧任务重，不加商讨就发布任务这种灾难情况出现。

虽然有时计划赶不上变化，只要提前说明白，适当的调整时间也是可行的。不过如果可能，我建议做最坏的打算：出现了紧急事态，导致某个成员临时不能继续完成任务，而且有很大的空档。一般来说是找其他成员顶上，若该成员是无法被替代的，这种事件也无法预知，这就靠随机应变了，延期或者找外援补救等，如果制定计划时就考虑这种情况，应该会预留容错时间。（不直接把开发ddl和实际ddl定在一起）

其实上面的各种问题都是由于人心不齐引发的。理想中的团队：每个人各自发挥自己的专长，齐心协力的向目标前进。实际上这并不简单，人不是机器，都会有自己的想法，一旦人心一散，就约等于解散了。

团队都有一个“主心骨”一样的存在，即使是再扁平的团队也是，主心骨的作用就是了解并引导团队中各个成员的想法，如果没有他，大家各想各的，你会发现每个人都会变得比较盲目散漫，虽说任务仍在推进，但是质量和速度都大不如以前。

这种事情是每个团队都需要重视起来的，苗头可能是一次小摩擦，一些不快，发现端倪就要去了解和开导，不能任其发展。我个人喜欢在团队里面直来直去的说，这样大家都能了解我在想什么，开心就是开心，感觉不对就是不对，不让负面情绪堆积起来。（当然不是所有人都能接受，这就需要主心骨去了解并沟通每个人）

我个人是一直觉得，大家就是一起向着目标努力的朋友，没必要搞的和什么上下级一样，该工作工作，该生活生活，不要给太大压力，红线就是完成任务。

不要害怕失败，团队组建和运营没有想象中那么容易，去总结失败经验，在之后遇到这种问题时就能从容应对，不至于慌了阵脚一错再错。

我的体会就四个字：人心要齐。

 

关于开发与管理

 

和gamejam不同，长线项目要考虑的东西会多得多，可行性、可拓展性和可维护性将会变得十分重要。所以在设计时就需要对整个游戏有个大致的概念：这个游戏长什么样子，大致玩法是什么？

除了上文给策划自己看的特征卡片，策划也要让团队中的其他成员明白，自己想要设计的这个游戏是什么样子，怎么玩的，脑子里有个大致的认知，这样沟通才方便。一个好办法就是用市面上已经有的游戏做例子，方便理解（图文并茂可以让人快速了解你的想法）。

说说我的工作思路：前期设计时，需要一份游戏结构脑图、一份游戏流程图、一份标准策划案。

这三个东西的作用是为后续分配任务拆解需求做铺垫，游戏结构脑图是展现整个游戏的框架结构，帮助梳理游戏中都有什么系统和元素，这个东西主要是给策划自己看的，在后续对设计做改动时不要忘记修改对应的地方。

游戏流程图是展现玩家游玩游戏时，游戏的运行过程，比如在进行某个操作后，游戏会有什么反应，进入到什么阶段等，目的是可以帮助打通游戏流程，使得对游戏运行有个大致的了解，这个图是给策程两个方向的人看的，对流程有认知才能让他们在自己拆分需求时对系统之间的关系有所考量。

标准策划案的内容不用多说，其目的主要是为了在给其他人讲解时做辅助用。这个文档是给所有人看的，要尽量做到没有讲解的情况下能够让参与开发的人明白游戏大概长什么样，让他们能够快速进入开发状态。

这三个文档写完后，策划的准备工作算是做完了。接下来进行的是项目的第一次重要会议。这场会议将会商讨：游戏的结构问题、任务的分配、初期时间表的制定等，一定要保证所有人都要到，方便讲明白谁做哪一部分，汇总每个人的个人时间表，其他人对策划案中的问题也要进行商讨，讲明白为什么这样设计（会出现一些成员不懂策划相关的，提出一些设计上的问题，防止出现团队问题，还是要讲明白）。

在这次会议之后才算是进入项目的准备阶段，在分配下去任务后，接到任务的成员需要对任务拆分。

一般策划不可能说精通所有的领域，所以不可能一次性把需求写的尽善尽美，采用发布-拆分-迭代修改-拆分-......-开始制作的形式更为合理。

程序或美术首先需要思考接到的任务该怎么做，比如需求上是出一个敌人，策划给了状态转换图，还有一些基本属性和技能描述，程序在思考后构思了一套解决方案，但是还需要提供一些信息，一般这些信息都是会和程序设计相关的，需要留什么接口以便拓展功能等等，对这些不熟悉的策划想不到这里，自然无法给出这些要求。

拆解这一步就是各个成员动用自己的专业能力，将策划延伸到游戏的方方面面。拆解也不仅是成员，策划最好也要随时就位，放置拆解过程中出现误解，导致与原有设计理念出现偏差。

在成员拆解完需求后，程序应该有了自己的一套框架体系，美术也敲定了工作流程，项目管理方式也确定下来。进行几次问题迭代后就进入了正式开发阶段。

正式开发阶段主要就是对接跟进度，不过先说一下项目管理这个事情。

 

很重要！一定！要有！良好的！项目管理！我就吃过不少项目管理的亏，从我第一次接触游戏开发，文件管理从QQ群文件到coding网盘，代码管理从打压缩包到git（没错，我最早和程序协同开发是打压缩包互相发，现在想想头皮发麻），经历过好几次因项目管理混乱导致做的一塌糊涂。

项目文件，本地文档，代码都需要找合适的手段管理，项目文件（策划案、文档、素材等）和代码使用线上共享的手段最好，因为是要给所有开发成员使用的。策划需要注重本地资源的管理，最好是做一个项目的完整备份，以备不时之需。

（coding网盘确实不错）

继续讲正式开发，对接和跟进度将会是团队成员的日常（其实这个也是项目管理的一部分），三天一小对，一周一开会，出现问题就及时说，然后想办法解决或者找平替设计。在我开发期间如果闲下来做自己的事情也会处于待命状态，有问题直接@我一下，然后就会凑过去商讨方案。这在线下是很容易实现的（线上的弊端之一），这个过程会持续很长很长的时间，遇到的问题也是千奇百怪，我也没法把情况都罗列出来，只能说一下我的建议。

首先不要怕麻烦，每次出问题都是成长的机会，你可以从这些问题中看出，策划与其他方向的交汇处有哪些不一样，这些思考不当的地方怎么改进。然后就是不要忘记自己最初要表达什么，你的一些需求可能会被其他人否决，遇到这种情况其实就要说明白为什么要这么设计，如果实在因为技术问题做不出来，要优先找平替，其次才是更改设计思路，不然会出现做着做着游戏和初始设计不一致的情况（暴论：技术都是逼出来的，必要时坚持己见）。

资源确实也是个比较常见的问题，很多时候我们知道使用白盒能够帮助迭代，但问题会出在后面细化的时候，包装游戏所需的素材比想象中要的大得多，可能只靠队伍里的美术没有办法解决需求，这就导致游戏看起来完成度很低，达不到想要的效果。

这种情况找外援是最好的解决方案，无论是靠拉新人还是外包，最终目的都是要实现设想中的效果，需要注意的是，要保证游戏的视觉统一性，不要输画风大相径庭的东西塞到同一个画面里面做关卡，会让人感觉很怪异。所以美术一般会有一个主美定风格，剩下的人尽量按照这个风格去做，出成果后主美和策划也要审核把关才行。

剩下的方案实现起来难上加难：自学或者将项目美术需求缩减到力所能及的范围内。如果自觉没有信心还是选择稳妥一点的方式比较好。

在做的过程中程序给我说了一个问题：用现在的眼光去看之前的代码觉得写的很差劲，难以维护。技术在迭代进步是必然的结果，在刚开始做项目的时候写的框架，后续学到新东西后知道能用更简单的方式写出更有效的代码，再想去改又觉得很难受。

如果是有经验的资深大佬，在开工前就能确定一个框架用到结束，即使修改也是小修小补。可惜初出茅庐的新人团队很难做到这种地步，所以这种情况应该也比较常见，遇上了要么不修继续按照之前的思路走，要么就重构，用更先进的方式制作。

这两个路可以说都不好走“我这次重构完，之后学到更好的是不是又白干了？”“啊，看着之前写的垃圾代码我都不想动，折磨自己。”这时候就要做好鼓励师！遇到困难没有人去帮助是很容易产生怠惰心理的，即使代码上帮不上忙，聊天也是能拓宽思路的（最好还是要懂一点代码知识，团队的程序经常会在空闲时间讲点思路，陪着聊聊他有时候就能想通没有解决的问题）。

（安抚程序ing...）

开发是个漫长的过程，什么事情都有可能发生，但是不要害怕失败，每次失败都是经验。可以先定一个月的项目周期试一试，和gamejam差别很大的。

 

关于资金与场地

 

接下来就更现实了，不是说劝各位不要独游，只是把会遇到的问题说出来。

资金，如果你是全职独游，没有其他收入的话，可以说在游戏出成品前都是砸钱的活，而且游戏能不能做出来，做出来之后是否能够回本都要打个问号。如果你还有团队，除非让所有人和你一起用爱发电，不然酬劳也是个问题。

很多时候都是先进厂，然后干一段时间有了技术和资本后跑出来做独游追梦，这确实是稳妥的做法。不过要是想闯一闯，愿意冒险也未尝不可，拥有一定初始资本的话，个人看法是想追梦就追，不要后悔，只要失败成本可以承受，我觉得就可以搏一搏。

找投资也是不错的选择，现在很多游戏开发比赛其实也是亮相的机会，如果你有想找投资的意愿，不如考虑在这些游戏开发比赛中展露头角，路演阶段和大佬或者其他人直接对话能够迅速将你的想法扩散开来，指不定就有人看中了呢？

一些孵化器也是不错的选择，一般是大公司用来筛选人才和养育团队的，他们可以提供的东西更多，例如场地、设备或技术支持等。但是需要注意的就是一些公司可能会有绑定行为，这点具体情况具体分析比较好。

其次是场地，上面也说了，线下开发比线上效率要高得多，怎么搞一个场地呢？如果你是在校生，向学校申请是最佳选择，学校其实能够提供很多资源，虽然一些审核可能比较麻烦，但是这也是成本最小的一种方式。其次是租房，成本有待敲定，不同区域的价格是不一样的，不过选择这个方式，一是要有容纳团队成员和设备的空间，二是需要有舒适的环境，考虑房租水电等等，也是一笔不小的开销。

这两个东西虽然重要，但是能说的地方并不多，有就是有，没有就是没有，天降贵人这种事情可遇不可求，踏踏实实干最重要。

 

关于问题与回答

 

收到一些问题，在这个小节做个回答。这些答案大都是凭借我自己的感悟写的，本意是想进行一次交流，如果有自己的想法欢迎留言或者直接公众号联系作者来交流，欢迎畅所欲言。

Q：独游定价——假设你制作了—款独立游戏，根据你的销量预测需要卖50元才能回本。然而此时市面上有一款内容量，剧情，文本，音乐，玩法全方面超过你的游戏只售卖30元。这时你是否会将自己的游戏降价?理由是什么?

A：定价要考虑很多种因素：市场、玩家受众、对游戏的了解程度等等。具体情况具体分析，如果玩家觉得30那款游戏贵，愿意以更低的价格买你的低配版，不如试试降价。

或者打个折拉个人气，找找有什么特色宣发一下（总不能是被全方面上位替代了，那样的话立项时就是个错误），至少要让你的游戏看起来很不错。

如果想放弃这个游戏，那可以适当提价，利用玩家不了解游戏内容的时候，割完韭菜就跑（想办法拖过退款时间），当然不建议这么搞哈。

 

Q：项目周期管理——对于游戏如何拆解与分配较为合理?例如玩法设计(10%)，开发架构(10%)，素材收集(10%），底层工具设计(20%)，开发（20%)，测试(20%)，宣发(10%)。

A：很难去说到底怎么分配，比如我的宣发实际要看游戏质量，我的测试要看开发完成度，框架工具要看设计难度，每个团队都需要按照实际情况去分析精力和时间分配的问题。而且很多步骤其实可以并行进行，比如素材收集几乎不会作为一个单独的任务去搞，一边进白盒一边推素材是很常见的事情。

很抱歉我没法给出明确的回答，如果各位有想法可以加作者微信（微信公众号：一只在摸鱼的鵺）聊聊看。

 

Q：团队协调——若你成立了独游工作室，但是团队成员质量参差不齐(有工作多年的大佬，也有大—刚学完c语言来兼职的萌新，也有刚毕业边上班边考公的同学且长期存在)，这时会选择分出大佬的精力指导产能较低的成员还是遣散?理由是什么?

A：遣散。讲真，如果是小团队根本没有精力养新人，纯新人能招进来都是问题。独游工作室不是社团，要吃饭要有产出的，不可能说要大佬再去教学。

 

Q：外包分配——哪些游戏资源会选择使用外包进行产出而哪些不会?

A：看团队配置。不同的团队短板是不一样的，我上文也说了，遇到资源缺失的情况怎么办，看情况找外援。外包就是用来补足的，如果团队成员足以撑起所有需求，那自然不用外包。

只有当团队因为各种情况没法完成需求才会去外包，外包的质量把控很难，沟通交流会占有很多精力（毕竟他们没有跟全程，可能无法体会到游戏想要表达什么），而且会增加开发成本。

真要讲起来感觉能聊好久，但是写下来要兼顾逻辑通顺，确实比较折磨。

 

讲到这里也差不多了，欢迎各位畅所欲言，公众号联系作者就能直接找到我啦，如果有想法也欢迎来交流。

（感觉还有很多想说，交流交流说不定就能有下一篇的想法了呢）

总之，这就是大致的想法和体会了，希望各位有想法就不要抛下它，哪怕晚一点也好，做点自己真正想做的事情，免得后悔不是吗。

十分感谢能看到这里，不妨再关注一下作者，未来指不定会出各种各样好玩的东西呢？