1.引子

游戏的灵感萌生于2015年，当时只有一些概念性的设计图。

后来我利用资源商店的素材搭建了最早的原型。

游戏的最终画面：

早期以D.P作为代号进行开发，来源于两个单词的缩写 Devil Prototype。

去年秋季我离开了当时的公司开始全职开发这款游戏，鉴于游戏的体量和一定的情怀原因，我选择了线上开发的形式招募一些队友

在群内发了一些信息以及一阵子磨合后，最终拉拢了3名小伙伴入伙，总共4人。

期间遇到了许许多多的难题，以及若干未解决的问题。但最终仍然发布到了steam商店上(即将解锁)：

http://store.steampowered.com/app/716060/Purgatory_Ashes/

并不算是合格的作品，但有许多内容可以写一下。

2.关于合作

我本身有一定的C4D基础，可完成一定的美术资源。甚至有一些偏执，例如之前开发的C2U工具。

众所周知，线上合作的问题是不能及时给予反馈。但这个问题在这款游戏的合作中并不是很突出。

最多隔一个上午或者下午就可以得到回复，真正最大的问题是拉不到合适的人。

所以这次合作的成员中，除了美术是专业美术以外，其他人则都是'野路子'。这一直是一个伴随开发非常头疼的问题。

到了后期基本上是我一个人在做，变成了其他人帮忙的形式。不过还算好，开发这款游戏所花费的时间尚能接受。

而在网络上不断地组队发广告又是一件非常拉嘲讽的事情。双刃剑吧。

2.踩过的坑

2.1 游戏设计方面

传统关卡制模式的弊端

我觉得对于独立游戏而言，做这类长关卡制的游戏实在有点吃力不讨好。只能说是这样做情怀的比重更大一些。

与其做传统模式的游戏，不如把战斗节奏的把控，出怪间隙调整好，来设计一个纯血宫,Rougelike模式的游戏要来的好。

关卡场景的比例问题

关卡设计上有个比较大的问题是大小比例问题，很容易造成场景过大角色过小的情况。控制好比例需要合理的场景摆件/物件

特别是高度到角色脚部，腿部，肩部这几个地方的参照物物件。摆放得当才显合理。

特殊的建筑风格

一些古建筑其实比较难做，棱角边数等都有讲究，特别是哥特的穹顶。

而要塞类或者一些现代建筑要好做一些。不要无意识的踩了这个坑。

室内室外空间的来回切换

尽量避开这类复杂的空间结构，游戏中经常要用到一些本来就不合理的结构填充到关卡中去(比如凭空出现的跳台,传送台)。

2.2 技术方面

优先考虑用混合树 而不是 Layer

很多问题用同步层可以解决，但用混合树也可以解决，而且更灵活。只需要指定一个float变量当成bool用即可。

例如变身的处理，变身后的招式以及动画状态和变身前其实是有较大变化的，这时候用混合树就更为合适。

手柄适配

统一键位的手柄适配使用InControl，这款插件能保证xbox,ps4,北通等手柄都是同样的键位

但使用时需要勾选XInput支持，否则北通手柄无效。另外对于不支持InControl的手柄需要自行自定义键位来处理。

使用InControl还有一个锅，就是PS4手柄没有震动，但作者说这不是他的问题，这需要一个支持ps4震动的dll。

如果只上steam的话，可以模拟成steam控制器来解决震动问题。若是其他平台则需要另想办法了。

敌人AI的简化

Unity这一块比较常规的做法是用Behavior Designer来设计AI。建议是一上来不要设计太复杂的敌兵AI，特别是涉及需要'黑板'这种小队逻辑的

否则会衍生出非常多的bug。所以不一定非得设计出强AI敌人，有很多变通的方法，例如通过一些特殊的技能来增加可玩性，一些弹幕类技能的释放等等。

3.取舍还是死磕

如果你做ARPG你就要强化剧情部分，养成部分。如果你做ACT你就要强化战斗部分。

独立游戏想要把整体给做好，就需要在核心模块上下文章，其余则做减法。

拿ACT来说，战斗部分又有以下4点可取舍：

1.可以弱化AI逻辑，强化AI技能。避开小队AI这样难以调试容易出bug的内容。

2.敌人模型复用。例如身着盔甲的敌人，通过换武器变为法师，战士，枪兵等。

3.优先考虑人形敌人，半身怪，漂浮怪物。这类角色在美术制作上会节省时间，且人形敌人的动画可以复用。

4.通过改变不同敌人的组合让战斗不至于枯燥。

其他部分，则有这几点可取舍：

1.用文字对话配合程序驱动的演出来代替过场动画。

2.考虑好关卡中的场景复用，一个场景来回跑。而不是堆量。还有角色也是。

3.一些部分的处理逻辑少不了HardCode，改成节点或者配表反而没HardCode来的简练。

4.结语

终于把这个坑给填上了。也算结束一事，有始有终吧。

以后也是往这个方向去做新的游戏，不过什么时候开始谁知道呢。