《死亡空间》大佬的分享

我看到了一个youtube上的视频:

How Dead Space’s Scariest Scene Almost Killed the Game | War Stories | Ars Technica

国内没有翻墙所以看不到视频的小伙伴们也不用担心,你有2个选择:

  1. 买一个Chrome翻墙插件,网址:xiyou.io,谁用谁知道;
  2. 跳过上面的一步,看我下面的哔哔。

这位大佬叫做Glen Schofield,他的第一部游戏是1991年创作的,因此从业经历可以说是非常丰富了,关于他的具体介绍就看这里就好了:

https://en.wikipedia.org/wiki/Glen_Schofield

这里不展开说了因为说实在的我对这位大佬也并不了解,我想分享的是这位大佬在做《死亡空间》的时候思路是非常清晰的,请看下面的图片:

这张图上就是大佬在做《死亡空间》之前就定下的5个规则,并且后面分别为每个规则的重要性打上了分数:

  • 无UI(2500)
  • 角色从不说话(1000)
  • 分尸系统(7000)
  • 所有时刻都可互动(9500)
  • 任何东西都要创新一点(15000)

无UI这一条,大佬只给了2500分我觉得是给少了,因为《死亡空间》对于3D游戏的UI设计可以说是革命性的,他把所有的非叙事性3DUI都转化成了叙事性的3DUI,这难度可以说相当高。以前我专门看过一篇文章分析2D/3DUI以及叙事性与非叙事性UI的,想看的可以点击下面的链接:

http://gamerboom.com/archives/45431

或者如果你的英文很好想要看原文的话点这下面的:

https://www.gamasutra.com/blogs/AnthonyStonehouse/20140227/211823/User_interface_design_in_video_games.php

大佬还讲了他是从哪里获得的无UI的灵感的,答案是……潜水员,潜水员们的设备都是穿戴在身上然后一低头就能看见面板上显示的数值的。

永远不说话,大佬说的很直接,想要增强角色的代入感,因此主角从来不说话。大佬也说了这个设计的灵感是来自于《半条命》的Freeman博士的。当年我玩《半条命2》的时候因为主角从来不说话所以玩的过程中还是挺紧张的,因为《半条命2》的整体氛围还是很吓人的。阀门后来的FPS后续的《传送门》系列也延续了主角从来不说话的设计。

分尸系统,这东西就很有B级恐怖片的味道了,大佬决定为了角色设计了被各种怪物攻击各种地方死掉的各种方式,在分尸动画中主角的整个身体被分成了十几个部分,这有点像当年的《命运战士》。因为玩家总是死,所以观赏死亡动画反而成了一种奖励。

所有时刻都可以互动,指的是当进行CG叙事的时候,玩家的角色依然是可以操作的。这个其实也不算特别新鲜的设计了,很多游戏都有。这么做的好处自然也是为了增强代入感,你是很难在玩着玩着突然就被打断了强制你去看动画的情况下保持沉浸感的。

任何东西都做一点创新,但注意是一点创新,不是特别大的创新,比如刷怪模式稍微增加了一些随机性,比如主角的跺地板攻击,比如奇葩的等离子切割枪。这些都是在传统的第三人称动作射击框架内,但是只是一点点的改进就让整个游戏有了大不同。更何况视频中花了大量篇幅说的触手怪,大佬为了解决这个触手怪的问题,不惜让团队重做了游戏的射击机制,并且每种武器的设计动画都要加倍(因为要支持角色躺在地上开枪) 。事后大佬说最重要的还是通过制作触手怪,大佬的团队们学会了拆解任务,一次性做出来搞不定的就拆成一小步一小步的去做,确保每一步做出来的都OK。

大佬的分享精神非常好,他能明确的说出来自己想要的某一部分设计是来自于哪部作品的,比如场景设计受到了1997年惊悚科幻片《黑洞表面》的启发,前面说的主角从来不说话则是学的《半条命》,而没有UI则是来自和游戏完全没关系的潜水员。这说明了积累丰富的生活经验和广泛阅读大量优秀作品是非常重要的,但更重要的还是要有解决问题的方法,大佬之所以是大佬,不是因为大佬看过《黑洞表面》,也不是因为大佬玩过《半条命》,更不是因为大佬潜过水,而是大佬在游戏制作的开始就定下了5条规则,并且当团队遇到了困难的时候能够通过逐步分解的方式带领团队解决问题,并且为了达到一个目的而要花很大代价的时候有拍板的果断,这才是大佬之所以是大佬的原因。

版本延误

上周四是要出0329中间版本的时候,在这一天发生了版本延误的问题,导致加班到晚上十二点多才结束。

发生这个问题的表面原因是,原本计划中这一天所出的版本是不包含引擎升级的内容的,而在晚上四五点的时候又决定要在这个版本中加入,而升级引擎的时候又导致某些尚未完成的功能合并代码的时候发生了问题,因此解决引擎升级,以及一些功能合并代码耽误了很久的时间。

有一些原因是客观的。由于这是年后第一次按照新的迭代计划来安排工作,因此在出中间版本和最终版本方面的计划上是第一次经历,在进度安排上经验不太足。第二个问题是这个版本正好还赶上了引擎升级,本身就是一个特殊的版本。第三个问题是当天办公楼的电信宽带还出了问题,导致出包上传速度极其缓慢。第四个问题是这个版本是跨年的版本,中间赶上了长时间的假期,节前有三天时间开发这个版本,因此节后只剩下了一周半,再加上过节请假导致人员不齐,所以这个版本不是以全力进行开发的。

但排除这些因素,还暴露了一个团队上进度安排的问题。在年前的时候就已经完成了引擎升级的工作,但我们在年后回来的进度会上还是一开始决定了这个中间版本不把引擎升级的代码合并进去,且团队成员一直在用老版本引擎的编辑器进行开发,这个安排是不合理的,这种内容赶早不赶晚,应该尽早让团队成员把编辑器的版本都升上去,而不是等到功能都开发完成后再升级引擎。当然,过早的升级编辑器也有风险,很可能导致新功能的开发受到阻碍,因此如何评估这个风险就暴露了另外一个问题:

安排进度的人,对于这个功能的风险评估是不充分的。到底应该尽早升级引擎还是等功能都做完了再升级引擎,事先并没有进行充分的讨论,因此基本可以说是迷迷糊糊的就确定了这个版本不升级引擎,而不升级的理由其实没有仔细想过。

因此以后这些程序独立作业的功能上,还是要加强沟通,完全的评估后作业内容和风险以及和其他功能互相影响的程度,再进行合理的安排。