游戏设计的思维过程

为什么关注过程,而不是具体的游戏内容?游戏内容是满足当时当地的玩家需求的,你看梦幻的捉鬼很好玩,但没有梦幻的用户群和整个游戏架构的支持,孤立的照搬1个玩法只是邯郸学步。所以这里总结的是设计过程,学习授人以渔,看怎么去捉住活鱼,而不是游戏产品里已经烹饪好端上桌的成熟内容。

游戏设计的是1种体验,所有的规则、数值和美术等因素都是为了产生特定的玩家感受。1个系统或玩法的设计,包括了构思、表述、执行和评估这4个过程,其中构思和评估是最核心的。

构思

首先,整个构思和设计的出发点,是为什么我们的产品需要这个内容?要考虑的是自己游戏的整个背景,而不是孤立的这个系统本身。要看整个游戏哪里玩起来不爽了?需要增加什么体验来解决问题?还有1种情况是从下到上的,我们看到其他游戏有个不错的玩法,想是否借鉴过来。但从下到上思考时,“上”仍然是思考的出发点和标准,要看这个玩法是否符合游戏的整体架构?是否有这方面需求?我们当时照搬了梦幻的组队合约人,这个在梦幻里是组队练级必备的,但是在我们游戏里门可罗雀、玩家根本不理。为什么呢?因为我们游戏里组队成本比梦幻小太多了,场景小、跑路近,又到处是组队集结人,队伍散了很容易再找到人。而梦幻很不一样,像海底龙宫那样的地方,一旦队伍有人跳水了,基本没可能再找到其他人,这个组队成本催生了组队合约。所以从下到上借鉴其他游戏玩法,要想清楚它在原来的游戏里满足的是什么需求?提供了什么体验?我们自己游戏的大环境有没有这方面的需求。机械移植的话往往牛头不对马嘴,或者是完全是另一种味道。征途的送花系统是花钱买经验的,送花人送花得经验,送花给女性只是顺便借花献佛。我们游戏里的送花系统,送花人没有什么好处,纯粹是女性玩家炫耀能得多少花用的。这两个表面看起来很类似的玩法,因为一点不同,本身的定位和带来的体验是完全不一样的。总之,我们要不要增加这个玩法,出发点是看游戏的整个背景是不是需要这种体验,而不是说看到其他游戏有个玩法不错,我们也加上吧。

其次,如果已经想清楚确实需要增加这个玩法,接下来就是具体怎么设计的问题,要清楚自己玩法的核心体验和定位是什么。这个玩法是做给哪些玩家的?他们是在什么情况下玩的?频率、时间点、等级、技能、装备、组队与否等等。乐趣是相对的,对这个玩法有需求的玩家会觉得很好玩,如果没有需求则什么感觉都不会有。像梦幻的师门任务你可能觉得太简单了,没什么挑战,只是枯燥跑路、找物品、打怪。但对那些找不到队伍的玩家,或者短暂上下线的玩家,能迅速拿些经验就是最大的乐趣。说到底,你要清楚自己表达的核心体验是什么,而不是笼统的说做的好玩。所有设计都围绕这个核心,你才能清楚必须坚持什么、加强什么、可以放弃什么。

最后,在构思过程中,我们肯定要去参考甚至“抄”其他游戏,应该怎么去参考?参考到什么程度?我们要抄的是体验,而不是规则。你自己必须尽量亲自体验过,思考他们的游戏元素又是如何产生这种体验的,在我们游戏里用什么可以再现其他游戏的体验。像刚才说的组队合约人系统,梦幻组队成本大、跑路太远,何况浪费时间就是浪费点卡,这个系统解决了这些问题,所以玩家才感觉很爽。我们把组队合约的规则搬过来,我们的玩家根本没这些烦恼,也就不会有移走烦恼的快乐,这个系统就废在了那里。所以说,要想模仿的恰到好处,达到自己的设计目的,也是个很考验水平的过程。

表述和执行

把自己的构思表达给别人,推动制作人员实现自己的设计,这两个环节是策划日常的基本工作。你需要找策划、程序、QC和美术沟通,让大家了解并支持你的构思。

设计内容的表述要先经过策划这边,已经讨论好了思路和大致规则,再去程序那边问下技术上的可行性。表述过程中,策划、技术和美术的关注点不同。你也要针对不同的人突出不同的重点。策划关心的是这个玩法体验怎么样,你可以用其他游戏截图、草图,挑起大家的想象,这个东西真正玩起来会怎么样。程序那里关键是技术上的可行性,你有时候没有必要讲整个的设计,只把最核心的几个技术实现讲给他们听下,其他的规则都是不成问题的。QC会追着你的文档不放,询问各种可能导致冲突的地方,还有最细枝末节的提示。美术需要的是1种感觉,你把这个东西的功能和作用讲完了,最好还能拉他们一起看下参考的游戏、搜集的图片、甚至听段相关音乐。

表述中不能忽略的是设计文档,它是口头沟通后的备忘和结果,而不能代替当前沟通。以前有很多讨论,说设计文档应该怎么怎么写,有没有标准的格式,好像设计文档写的好就是表述的好。其实设计文档是写给谁看的呢?主要就是程序,还有QC。设计文档不是要求写的多详细、多优美、多准确,而是程序看了说我知道怎么做了,QC看了说我知道怎么测了,这才是好的文档和好的表述。当然文档还有个功能,就是记录你的设计目的和思路,就是构思的过程,这个是方便以后的策划能学习和接手。在表述游戏构思的时候,图片的力量远胜文字,无论是画的草图还是借鉴的其他现成图片。文字是和表达精确的思想和规则,但涉及想象、感觉、体验的时候,图片显然更有力量。所以无论是口头沟通还是写作文档,如果可能的话,你都可以随手画上几笔,或者找些图片参考。这点在对策划和美术的沟通中,尤其重要,因为比起技术来,他们更关注感觉而不是规则。

说到执行阶段,想必大家都经历过也比较熟悉了,主要是面对开发中的各种反馈和疑问。程序在忙开发,QC在分析文档和测试,美术也开始准备你要的资源,大家一起在问你这个怎么样那个怎么样。这个过程中,最常见的是跟进各种细节,有很多当时没想到的东西,比如状态的互斥、物品的绑定等等。还有就是制作人员的一些反馈,从技术上他们可能觉得换种方式更节省,问你能不能接受。细节方面随手处理就行,但是技术的反馈和疑问,如果构思阶段没想清楚、只是照抄别人的话,就会压不住阵脚、往往被他们问住。对玩法的构思比较清楚,明白要营造的核心体验是什么,才知道要坚持什么、谈判什么、放弃什么,也才能努力去说服别人下功夫去实现。在技术做完后,你要自己去跑一遍,看整个流程是不是自己想要的,只有在这时候,你才真正看到了自己设计的玩法,以前还只是存在于构思和讨论中。确认功能上没问题后,再去喊大家一起来玩下,听听他们的意见,也让大家看下自己的工作成果。

评估

评估是检验自己制作出来的玩法怎么样,这也是最核心的1个环节,推动着后续的构思和修改。我们现在看到的评估手段实在是太多了,玩家的言论、用户测试、数据分析、自己试玩、同事的意见等等。如果问用什么手段来评估游戏?我现在的回答就是,没有任何1种手段能单独得出结论,只能把它们综合起来使用。医学上有种“鸡尾酒疗法”是用来对付艾滋病的,这个术语用在这里正好合适,评估时你要把所有能用的渠道都用上。并且要清楚的是,即使十八般武器都上场,你永远也只是得到1个相对正确的结论,现有的评估是无法给出精确结论的。这点与“鸡尾酒疗法”也很像,它综合各种疗法,也是只能使病情有所好转,不能根治。

所有评估手段中,最重要的是亲身去玩。我这里不用试玩这个词,而是说你要真的在外服,和真正的玩家,拿着真正的技能和装备去玩,去体验自己的玩法。玩的时候,不要带着超然去观察的态度,你一定要在乎,那怕是最少的奖励、最微小的损失,这样才有沮丧和喜悦。游戏设计的是一种体验,能检验它的也只有自己的体验,玩家的言论和数据都只是参考,采不采用完全取决于你自己的体验。我们发布前也拉程序和QC一起玩过,那次玩还只是部分体验,更多检查的是可用性,只有到了外服和玩家一起才是真正的玩。你自己到时觉得不好玩了,就赶紧去找问题,一查数据还真是玩的人不多。是不是难度大了?奖励少了?这是再去查数据也好,问玩家也好,去推敲和检查自己的推测,寻找下一步的改进方案。所以说,亲身去玩,亲身体验,是其他评估手段的基础,也是继续构思和改进的起点,这点什么手段也代替不了。

玩家会有非常多的反馈,在聊天群里、在论坛上、在游戏里、在访谈中,对玩家言论一定要慎重。不要以为玩家玩过就有了发言权,他们只是表达出能看的见摸的着的表面东西,对真正不爽的原因他们不了解、也说不出来。我以前做过流失玩家的电话访谈,玩家回答真是五花八门,有的说水做的不好看不想玩了,有的说没人杀了不想玩了。玩家的话是不能作为决策的依据的,只能作为疑问的出发点。你要说玩家这么说了,所以我们要怎么怎么改,那样要跑断腿的,改了玩家也不领情。你要进一步去思考,他为什么这么说,能反映出什么东西没有。有次访谈,我听个玩家说,我们工作后来玩很累了,战斗不要那么紧张。听到这句话,并不是说把所有的战斗都改容易吧?我想的是他们背后的需要是什么呢,我们的玩家需要有段轻松的时间,他们看下网页、回下qq、甚至看下正烤的蛋糕。所以后来就把烧双战斗放开了,允许你挂机,放心去做下其他事情吧。

还有种重要的反馈是游戏数据,数据可以证实或推倒你的结论,但不能告诉你怎么解决问题,还得靠你的经验和构思来提供方案,然后再去验证。对于数据要带着猜测和疑问去看,那怕只是简单的看看玩的人多不多,否则数据提供不了任何信息。

还有现在玩家测试也是种评估,我们的新手任务就通过这个发现了很多问题。这种测试关注的是可用性,那些你想当然的操作,玩家往往不知就里,看到了你才想到去改。对好不好玩参考价值就少了很多,例如帮派跑商的话,玩家会告诉你跑得无聊死了。它确实无聊,只有对那些急需家族贡献点技能的玩家,才是好玩的。

最后,要注意构思、表述、执行和评估这4个过程不是固定的次序,而是彼此重叠、你中有我、我中有你的。在构思阶段,你可能就把初步的想法讲给大家听,评估可能的反馈。在评估的时候,你也可能一直在重新构思,并表述给别人听。但从整个的设计流程看,是可以区分出这4个不同的思维阶段的。

上一篇 下一篇

 

© 2019 老柴的宅. Powered by Chaishiwei.com. 鄂ICP备11006811号