海姆达尔：用三年来讲述一个故事
来源：Cocos 论坛
作者：liuxiaoyi135
版权归原作者所有！
《海姆达尔》是一款多结局单机RPG游戏。玩家在游戏中扮演黑客杰森，调查一起十五年前的离奇命案。游戏通过解谜和跑酷两种玩法，传递我们对于现代社会和人性的些许思考。
这款付费单机游戏自 7 月 6 日上线之后，在 TapTap 获得超优秀的评分成绩 9.5 分，收获玩家评价 2857 条。
从创意到成品，这款游戏前后竟然花了三年的时间，换言之，三年了，这款单机游戏竟然还能够成功上线并斩获如此战绩。近日，该游戏的开发者在 Cocos 论坛中发表了一篇《写在海姆达尔完成时》的帖子，讲述这三年里的“事故与故事”。
《写在海姆达尔完成时》
2018 年 7 月 6 日，《海姆达尔》在 App Store 和 TapTap 同步上线，又经过了一个星期的优化和 BUG 修复，现在包体基本稳定，可以说整个游戏的开发终于告一段落。回顾三年时光，感受颇多，收拾一番心情，决定从程序的角度给这个项目做一个总结，于是有了这篇文章。
为什么做了三年？
我想这是很多人想问的第一个问题。其实答案很简单：因为我们犯了很多错误。立项初期，我们只是想做一个讲故事的游戏，对游戏的想法也很简单。随着开发的深入，我们加入了跑酷、解谜、收集等游戏要素，游戏的复杂度不断提升，最终到达了一个一度让我们无法驾驭的程度。在那段时间里项目的推进速度变得非常慢，慢到甚至一个月都无法完成一个关卡的制作。与此同时，团队的规模却已经从开始的 4 人扩张到了 9 人。当我们意识到项目正向着不可控制的方向越走越远的时候，我们痛下决心，裁掉了项目组大部分人，留下了 5 个人，并将游戏的规模砍到了我们能够控制的程度，而此时已经是 2016 年底，可以说从那时起项目组才进入正轨，并在后来的大约一年半的时间里完成游戏所有内容的开发。
为什么使用 cocos2d-x？
这个问题也是不止一次的被人问起。在我看来，不管选择什么引擎，只要能让我快速的实现需要的功能，完成项目开发即可。正如上面所说，项目在立项初期，并没有想做成现在大家看到的这个样子，当时整个游戏的功能需求很简单，cocos 引擎足够应付，再加上引擎体量较小、开源便于修改，所以也没怎么多想，便确定用 cocos 进行开发。
开发过程中踩了哪些坑？
总的来说还是踩了不少坑，这里就简单的提几个我印象比较深刻的吧。
工具链的缺失
这应该是我遇到的头号大坑。众所周知在 creator 出现前 cocos 的工具链是惨不忍睹的，而游戏的跑酷和剧情两大核心模块都需要策划能够直接编写关卡内容，给策划提供所见即所得的编辑工具是整个项目开发的首要任务。我参考了 github 上的几个仓库：Jennal/cocos2dx-3.2-qt，imeteora/cocos2d-x-3.x-Qt，使用QT，将 cocos 的窗口嵌入到 QT 的 GLWidget 中，当然我最终的实现比他们更复杂，并定制了很多功能，编辑器支持剧情场景构建和实时运行、Lua 实时调试、打印，支持跑酷的场景构造、运行调试，我还重写了鼠标和键盘事件，支持搜索、多选、拖拽、复制粘贴等功能。
剧情编辑器
跑酷编辑器
随着项目内容的开发，编辑器的开发也在同步进行，直到游戏上线。可以说跑酷和剧情编辑器的实现是程序工作中最为重要的一块。有了编辑器，策划可以完全脱离程序，自行创建游戏内容，并实时的运行调试，完成关卡制作。
Lua嵌入
项目开始使用的是 c++ 版本，进行了一段时间后，策划提出游戏的剧情关卡需要程序提供脚本接口，让他们去编写整个剧情关卡的全部内容。策划有过《仙剑五》的开发经验，并给我看了他们当时写的脚本，基本上就是程序提供接口，他们编写关卡内容，包括 NPC 逻辑、摄像机运镜、任务等。当时我有两个选择，一是重新使用 cocos-lua 版，二是在 c++ 版本上自己接入 Lua 环境。我选择了后者，主要有这么几个原因：首先提出这个需求时程序已经做完了基本的框架设计，用 Lua 再来一遍有点浪费时间。其次当时正值 cocos-lua 和 quick 版合并，lua版本的接口和文档可以说是一塌糊涂，难以上手。最后在看过仙剑的脚本，并在和策划沟通后确认了他们只需要面向过程的接口，并不需要做 lua-binding 。综合这几点，最后我参考了 cocos-lua 版的源文件，自己接入了 Lua，提供接口给策划使用。
物理引擎
游戏的跑酷部分使用了物理引擎。最开始的时候是打算用 cocos3.x 自带的 physic 系统实现，看完源码后放弃了这个想法，cocos 内部封装的是 chipmunk ，当时chipmunk 没有解决 bullet 穿透问题，而且 cocos 的 physic 系统是直接挂在 Scene 下实现的，满足不了项目需求。我干脆自己封装了 Box2D 实现，隐藏了物理和像素的转换，提供了更简单的接口，完全满足了跑酷部分的开发。
继承还是组合
项目一开始规模很小，再加上 cocos 本身是以继承方式实现的引擎，项目代码里充斥着各种继承多态。然而自己挖的坑，始终是要填的。新功能越来越难添加，开发陷入瓶颈，我不得不花了一周时间，彻底重写了底层实现，利用 cocos 已有的那个薄弱的 Component 组件，将 gameplay 部分的所有功能转为组件化实现，至此整个游戏框架才算最终成型，我能够非常容易地给跑酷和剧情添加各种新的功能，并同步到编辑器，而且完全不会影响到已有模块的实现。
剧情部分共有80多个组件
后处理效果
单机游戏必不可少的要做各种后处理特效，然而 cocos 的渲染管道比较简单，而且 RenderTexture 不支持嵌套。我首先简单修改了下 RenderTexture 源码，使其能支持嵌套使用，然后实现了一个 PostRender 节点，在场景中添加该节点后，可以在节点上添加删除各种后处理组件，动态地实现节点上所有内容的后处理效果，比如常见的高斯模糊、动态模糊、全局饱和度亮度调整、蒙版等。
AudioEngine 闪退
这个是游戏即将上架时遇到的最致命问题，cocos 新的音效模块在部分 ios 设备上会引发闪退，github 上的讨论在这里（https://github.com/cocos2d/cocos2d-x/issues/18597#event-1726873190），这个 issue 在 17 年 12 月建立，我遇到这个问题的时候是 18 年 5 月底，当时我的内心是崩溃的，唯一的想法就是“完了，游戏没法上线了！”。尝试了几天仍然没有解决问题，最后靠着公司大老板的私人关系，紧急联系了王哲大大，加急解决了这个问题。在这里也十分感谢引擎组的朋友这么快就解决了问题，让我们游戏能够顺利上架。
程序的内容就先说这么多吧，有想到其他想要聊的我再重新编辑补充吧，下面聊一聊一些其他的东西。
关于美术风格
我并不是美术，关于美术风格这块我只能简单的说一说。全手绘的想法是在项目一开始就确定的，当时是想走美漫的风格，大概类似于《晶体管》那种类型，也以此为基础招了擅长该风格的主美。刚开始的时候美术制作出的素材质量是很高的，非常的风格化，可惜的是美术和策划的配合在之后出现了严重的问题，结果是策划总觉得美术产出的素材不是他们想要的，美术却又觉得策划对他们限制了太多，影响了他们的创作，美术风格越走越偏，最后已经不再是美漫风，而是一种难以言表的掺杂着各种风格元素的混杂风。最终主美也觉得难以继续而离开了团队。
在最终的五人团队形成后，我们也不再坚持什么美漫风，而是完全根据团队成员个人的特点，选择他们更加擅长的风格。现在游戏上架了，我个人觉得整个游戏的美术风格可以说更偏向于日漫风。
关于苹果推荐
一个不得不面对的现实是，个人或是独立开发者想要拿到首页的各种推荐：大图、编辑推荐、新游和预约几乎是不可能的。实际上 App Store 的首页各种推荐位已经被国内外各家游戏巨头牢牢占据。我们游戏也是靠着心动网络的强大公关能力拿到了 App Store 首页推荐和 TapTap 推荐，想要出人头地的各位独立开发者，请果断地去抱大腿吧。
结语
一个单机手游项目做了三年，还上线了，放眼国内现在的手游大环境，应该算是个奇迹了吧。在这里想感谢的人很多，首先要感谢项目组的同事，三年的时光让我们早已经超越了同事的感情，大家充满了韧劲，不离不弃，一起完成了属于我们自己的游戏。其次要感谢黄一孟黄老板，说真的，项目组经历了好几次非常困难的时期，甚至可以说是生死存亡的时期，黄老板完全可以拍个板项目组就解散了，我们心里也很清楚，项目中后期整个管理层大概也只有黄老板仍在支持我们。如果没有他的坚持，项目组真的活不到游戏上架那天。我还要感谢公司测试和推广的同事，研发只是游戏做完的第一步，测试和推广也是游戏开发重要的一环，没有你们的工作也不会有项目的最终上架。最后我要感谢所有购买我们游戏的玩家，游戏上架后我们在 TapTap上 看到了很多很多玩家打通游戏并留下了评论，有赞美的、有吐槽的，每一个评论都让我们受益良多。你们的评论让我们觉得三年的努力是值得的，开发中的一切痛苦在这一刻都烟消云散，正因为有了你们，我们才能坚持在游戏开发的道路上越走越远。
（转载结束）
做一款独立创意的游戏，并不是一个容易的决定；考虑到从无到有的艰辛，以及小团队必然遇到的许多障碍，即使是从开始走到终点，也需要过人的勇气。
不过，他们还是走过来了。
《海姆达尔》诉说的，更是一些普通的逐梦人在失败后如何前行，如何对未来做出选择的故事。与其说故事吸引人，不如说是人选择了去读一些故事。这款不错的国产单机独立游戏，剧情饱满，态度真诚，欢迎各位开发者下载体验！点击【阅读原文】可至作者原贴！