1.引子
游戏的灵感萌生于2015年,当时只有一些概念性的设计图。
后来我利用资源商店的素材搭建了最早的原型。
游戏的最终画面:
早期以D.P作为代号进行开发,来源于两个单词的缩写 Devil Prototype。
去年秋季我离开了当时的公司开始全职开发这款游戏,鉴于游戏的体量和一定的情怀原因,我选择了线上开发的形式招募一些队友
在群内发了一些信息以及一阵子磨合后,最终拉拢了3名小伙伴入伙,总共4人。
期间遇到了许许多多的难题,以及若干未解决的问题。但最终仍然发布到了steam商店上
开发时间7个月左右。4月份解锁:
http://store.steampowered.com/app/716060/Purgatory_Ashes/
并不算是合格的作品,但有许多内容可以写一下。
2.关于合作
我本身有一定的C4D基础,可完成一定的美术资源。甚至有一些偏执,例如之前开发的C2U工具。
众所周知,线上合作的问题是不能及时给予反馈。但这个问题在这款游戏的合作中并不是很突出。
最多隔一个上午或者下午就可以得到回复,真正最大的问题是拉不到合适的人。
所以这次合作的成员中,除了美术是专业美术以外,其他人则都是‘野路子‘。这一直是一个伴随开发非常头疼的问题。
到了后期基本上是我一个人在做,变成了其他人帮忙的形式。不过还算好,开发这款游戏所花费的时间尚能接受。
而在网络上不断地组队发广告又是一件非常拉嘲讽的事情。双刃剑吧。
2.一些坑
2.1 游戏设计方面
传统模式的弊端
我觉得对于独立游戏而言,做这类长关卡制的游戏其实有点吃力不讨好。只能说是这样做情怀的比重更多一些。
与其做传统模式的游戏,不如把战斗节奏的把控,出怪间隙调整好,来设计一个纯血宫模式的游戏要来的好。
关卡比例问题
关卡设计上有个比较大的问题是大小比例问题,很容易造成场景过大角色过小的情况。控制好比例需要合理的参照物
特别是高度到角色脚部,腿部,肩部这几个地方的参照物。有合理的参照物场景的大小才会感觉合理。
特殊的建筑风格
一些古建筑其实比较难做,棱角片数等都有讲究,而现代建筑都是方块要好做很多。应当尽量避开这类建筑风格。
室内室外空间的来回切换
尽量避开这类复杂的空间结构,游戏中经常要用到一些本来就不合理的结构填充到关卡中去(比如凭空出现的跳台,传送台)。
敌人AI的简化
Unity这一块比较常规的做法是用Behavior Designer来设计AI。建议是一上来不要设计太复杂的敌兵AI,特别是涉及需要‘黑板‘这种小队逻辑的
否则会衍生出非常多的bug。所以不一定非得设计出强AI敌人,有很多变通的方法,例如通过一些特殊的技能来增加可玩性,一些弹幕类技能的释放等等。
2.2 技术方面
优先考虑用混合树 而不是 Layer
很多问题用同步层可以解决,但用混合树也可以解决,而且更灵活。只需要指定一个float变量当成bool用即可。
特别是像变身系统,变身后的招式以及动画状态和变身前其实是有较大变化的,这时候用混合树就更为合适。
手柄适配
统一键位的手柄适配使用InControl,这款插件能保证xbox,ps4,北通等手柄都是同样的键位
但使用时需要勾选XInput支持,否则北通手柄无效。另外对于不支持InControl的手柄需要自行自定义键位来处理。
使用InControl还有一个锅,就是PS4手柄没有震动,但作者说这不是他的问题,这需要一个支持ps4震动的dll。
如果只上steam的话,可以模拟成steam控制器来解决震动问题。若是其他平台则需要另想办法了。
steam的成就及DLC
steam这边使用Steamworks.net网上有很多教程,成就部分要额外调一下StoreStarts方法,否则不会前台弹出,需要注意。
Steamworks.SteamUserStats.SetAchievement("ACHIEVEMENT_1"); Steamworks.SteamUserStats.StoreStats();
游戏这次做了音乐DLC,在steam的库->音乐目录下可以查找到,DLC和项目本身共享一个目录,如果是音乐文件steam会自动识别。
3.取舍还是死磕
如果你做ARPG你就要强化剧情部分,养成部分。如果做ACT你就要强化战斗部分。
独立游戏如果想把整体做好,就需要在核心模块上做加法,其他部分上做减法。
而拿ACT来说,战斗部分又有以下3点可以取舍:
1.可以弱化AI逻辑,强化AI技能。避开小队AI这样难以调试容易出bug的内容。
2.敌人模型复用。例如身着盔甲的敌人,通过换武器变为法师,战士,枪兵等。
3.优先考虑人形敌人,半身怪,漂浮怪物。这类角色在美术制作上会节省时间,且人形敌人的动画可以复用。
4.通过改变不同敌人的组合让战斗不至于枯燥。
其他部分,有这几点可以取舍:
1.用文字对话配合程序驱动的演出来代替过场动画。
2.考虑好关卡复用,关卡长度。
3.不要从技术角度/美术角度去决定做一个什么模块/场景,始终要放在策划角度来下决定。
4.少不了HardCode,改成节点或者表来配置反而没HardCode来的简练。
4.结语
终于把这个坑给填上了。也算结束一事,有始有终吧。
以后应该也是往这个方向去做新的游戏,不过什么时候开始谁知道呢。
原文地址:https://www.cnblogs.com/hont/p/8541382.html