某游戏设计缺陷.docx
- 文档编号:12663098
- 上传时间:2023-04-21
- 格式:DOCX
- 页数:8
- 大小:22.19KB
某游戏设计缺陷.docx
《某游戏设计缺陷.docx》由会员分享,可在线阅读,更多相关《某游戏设计缺陷.docx(8页珍藏版)》请在冰豆网上搜索。
某游戏设计缺陷
前言
截止到12月10日,AAAA开服超过50组,数据方面仍然不理想,远没有达到我们在09年Q1时的期望值。
我们的期望值是日平均收益X/服,但从6月份至今,已经半年了,无论是老经验版本或新经验版本,都没有达到这个要求。
中等情况的服务器,日收益也只是在X—X之间波动,如果没有运营活动的介入,这个值还会更低。
运营的实际情况能够反映出游戏的设计水平,通过半年的实际运营,可以评判出,我们在《AAAA》的设计水平上是非常平庸的,没有与主要竞品《BBBB》拉开差距,与08年立项时击败《BBBB》的目标差得非常远。
从这一点上来说,我个人负主要责任,同时也感谢公司在明知这个产品的品质不高的情况下,仍然拿出市场费用进行推广,为我们收集和分析数据提供了资源。
我为没有在这个产品上给公司带来充分收益感到自责,游戏设计上的缺陷导致了运营部门的困扰,也挫伤了开发人员的激情和信心。
一个产品的成功和失败或许是多方面因素共同决定的,但我清楚的看到,策划人员的前期设计失误和缺陷会如蝴蝶效应一般拖累到后续开发、维护和运营工作,这也是我认为《AAAA》没有大成,其主要原因在于策划和设计上的一些硬伤。
我希望通过总结,能够归纳出我们在开发网页角色扮演游戏时需要注意的一些点,并把我在犯错误后吸取和学习到的教训分享给同事们,希望我们在开发后面的产品时,不再犯同样的错误,增加新产品的成功率。
本文不涉及到具体的非常小的细节,我个人持这样的观点:
游戏细节可以通过不断打磨和维护进行更新,是实现问题,但策划的大方向一定要准确,能够预测设计大纲将会带来的风险,如果方向有问题,在已经歪曲的方向上去做调整,是调整不回来的。
策划设计人员一定要在前期谨慎的设计,以减少风险和修改成本,修改永远是下下策,只有吃透用户,做出良好的设计和判断,才是使产品快速成功的途径。
毕竟我们身处于一个竞争激烈的市场,没有太多的时间容纳失败。
一、系统过度设计的错误
1.用户没有太多的时间
《AAAA》在立项时,我们遵从这样一种思考:
现在的游戏产品,都尽量做得非常的
完整,系统非常多,才能够给玩家带来足够的吸引力。
这个概念本身没有问题,并且根据之前做clientmmo的经验,产品推出时,系统越是完整,就越能满足方方面面玩家的需求,从而减少流失。
所以我在立项时就提出了约28个玩法,每一个玩法都是一个系统。
事实上,我们真的需要这么多吗?
这是我们吃的第一个亏,我们没有很透彻的去做用户的需求分析,没有吃透网页游戏用户的特点,特别是他们在游戏时间和节奏上与客户端游戏用户的差异,虽然我们知道webgame的用户大多数是办公室用户,但事实上我们无视了他们的特点。
现在倒过来看,我们当时努力做的事就是:
做一个玩起来很象clientmmo的游戏,以讨得那些玩过clientmmo的用户的好感。
而事实上有两点潜在的问题:
1.办公室用户没有非常多的即时操作时间。
时间等待式的操作模式是webgame的重要基础。
2.大规模推广模式下,许多用户之前是不玩游戏的,做得再象clientmmo,也只是让很小一部分人觉得好。
由于没有意识到这两点问题,加上死搬硬套clientmmo的经验,使得我们在一开始就
使产品出现了方向性的错误:
《AAAA》是一个需要不断去操作才能够优胜的游戏,同时也是一个玩点杂而乱的游戏。
高达20项以上的规划玩点,使得那些本来就缺乏大量即时游戏时间的用户感到非常紧张,如果他们玩所有的内容,他们可能耽误自己的工作,而如果只玩一部分内容,他们又会被小部分时间宽裕的用户无情的超过,形成悬殊的差距,这使得用户非常为难。
而大量的开发内容,又对技术人员造成了很大的压力,前期开发时间非常的紧张,所有人陷在加班里,而为了缓解这种压力,策划方面又对一些系统进行了简化设计,但这些简化设计又使得系统变得肤浅和鸡肋,无法满足用户的需求。
举一个例子,在最早的帮会系统中,我们设计得很全面,但开发那样一个全面的仓库系统,将会花费非常多的时间,而我们认为这些前期时间花在这上面是不经济的,所以我们修改为一个简单的帮会系统,但在运营了一段时间后,我们发现帮会系统的种种弊病,于是我们又花了许多时间去增强它的功能,在前后折腾的过程中,我们既折腾了自己,也折腾了用户,用户不得不面对系统面目全非式的修改,不停去适应产品。
而这些问题的根源是我们在一开始就没有吃透用户的需求,导致一开始的摊子过大,在一定程度上过度设计,许多系统成为了鸡肋系统,还占用和浪费了宝贵的前期开发时间。
2.系统太多会提高学习成本和分散用户行为
过度设计的另一个危害就是学习成本,即使是RPG这样最具有粘着力的游戏模式,用户面对一大堆的系统也会感到手足无措。
我们本来规划的玩法树状结构还算清晰,但在用户看来,所有的系统几乎都是一起出现的,光熟练掌握这些系统的操作就要花费一两个小时,怎能叫人不头疼,光为这些系统搭配的新手任务就多达几十个,学习成本的提高必然会带来新手转化率的降低。
过多的系统使得用户缺乏重心,也使得产品缺乏明显的特点和倾向。
最终,用户的精力仍然是投放在升级上,而大量的旁支系统,没有达到我们预想的那样“在用户升级累的时候去玩玩”,我们不得不在没有人玩的系统上加大奖励,以吸引用户过来玩,而这恰恰是本末倒置的做法。
类似结婚、称号、**、生活技能的内容,我们完全可以在后期进行开发,但我们错误的把他们都放在前期去做,而且是在匆忙的状态下去设计和制作,使得这些旁支系统的质量低、提升效果差,成为了鸡肋系统。
这些鸡肋系统又在后期占了不少二次开发和维护调整的工作量。
直到今天,通过在运营过程中的摸索,我们意识到,学习分析用户游戏过程和时间分割是多么的重要,用户没有无限的时间投放在一个网页游戏上,我们就要让他清晰明白的去做哪些事,可以获得哪些收益。
一个日常任务花2分钟以内做完是乐趣,花一小时做完就是灾难了。
网页游戏用户在时间上的特性,是我们需要非常谨慎把握的重要因素,这一点我还没有完全认识,但已经感受到它的重要性了。
二、游戏形态的设计缺陷
游戏形态,决定了用户在基本了解游戏后,是否认为:
“这个游戏我可以玩”或“我想
玩这个游戏”。
这方面,策划设计上虽然慎之又慎,但还是犯了几个错误。
1.势力划分上的错误
《AAAA》的国家系统是所有关键系统里第一个倒下的,宣告失败的系统。
我说一下
犯这个错误的来龙去脉。
最早,我们在《AAAA》的设计之初,是希望将之打造成一个网页版本的《cccc》,同时竞品《BBBB》也有国家系统,同时又为了避免产品给人以“只是打怪升级很枯燥”,增加玩家间的互动等多种因素,我们设计了国家系统。
初衷是好的,但我们自相矛盾的犯了这样一个错误:
首先我们严格了国家的机制,禁止不同的国家间的玩家不可以组队等友情互动,因为这样更能增加玩家的归属感,容易引发敌视。
而同时,出于“如果搞3个国家太象三国,而10个国家又太多,搞5个国家,即使有不平衡,也会相对均匀”的想法,设计了五个国家。
这里,我犯了一个严重的错误:
忽视了服务器的总人数和日常在线人数。
在最开始,我们的设计人数是2500+同时在线,照这个规划,每个国家能平均到500人,而实际上,在不断增加系统的基础上,我们达不到这个峰值,并且在实际运营过程中,单组服务器也无法长时间达到这个高峰,再加上必然会发生的衰退,实际上我们能够达到的基本人数仅仅为500-1000+。
这样一来,五个国家一分流,每个国家同时在线人数并不高,加上玩家间的等级差距,使玩家又被地图分流,于是每个国家的玩家,经常会发生找不到自己国家的人组队的状况。
在这种情况下,且不谈国家间不平衡造成的流失,即使是一个人数不算太少的国家,想找人组队都是比较困难的。
虽然我们将之调整为三个国家,但我们仍然无法阻挡服务器衰退和地图分流带来的影响,经过认真的分析,只能“痛心”的取消了国家机制。
国家机制作为关键系统,它的取消也引发了玩家对产品的怀疑和信心不足。
这是一个典型的因为策划没有想清楚就设计出来的关键性错误,如果之前能够多思考和计算每个势力的人数和可能因为总体人数减少带来的生态变化,就不会犯这样的错了。
2.背景和氛围上的力度不够
本身作为一款**游戏,既然已经决定了吃**题材,并且知道市场喜欢这种题材,就
该彻底吃到底。
但这里我们犹豫了,一方面想沾光,一方面又害臊,于是搞了个四不象的剧情,夹杂着**的一些东西,自己又加上一些自创的剧情,使得游戏的**味道不够浓厚。
特别是在怪物的命名、主分支剧情上,让人感觉不到这是一个带有浓厚**色彩的游戏。
这个错误在数据上无法体现出来,但它降低了产品的品质,弱化了**题材本身的吸引力,在客观上是对产品有损害的。
这个教训在于:
如果我们要做的是大众化的东西,我们就该拿出大众喜闻乐见的内容,遮遮挡挡的反而效果不好。
三、消费设计和生态上的缺陷
1.消费设计上的缺陷
在消费设计上,《AAAA》做得很差,口碑很不好,主要表现在收费赤裸裸,毫不婉
转,缺乏引导性,收费高昂。
主要是以下几个原因造成的:
a)收费规划上的预估错误
在最开始,我们在收费上主要是参考了《cccc》,作为最赚钱的免费游戏,我们也
希望通过大额RMB玩家来支撑我们的收益,并没有考虑相对平均化、缓和化的收费策略,一方面是对网页游戏的付费转化率信心不足,一方面是寄希望于大额RMB玩家的投入。
所以主要是犯了两个错误:
一是RPG网页游戏付费转化率并没有想象的低,而我们设置了高额付费反而阻碍了中小额玩家的付费热情。
二是由于网页游戏在画面表现和操作感上达不到诸如《cccc》那样的水准,使大额RMB玩家在产品上的投入有限。
前期的收费策略失败,主要体现在玩家投入到一定程度,就不肯再投钱,收入忽高忽低,玩家对收费抵制严重,反弹大,抱怨多,继而影响了后面的收费。
我们通过不断的降价,才慢慢的使付费转化率不那么低,但产品仍然给人以“投入和获得不成正比“的感觉。
b)游戏设计不考虑付费的严重错误
这一点错误是整篇总结,最令我觉得失败的一点。
我们没有在做基础游戏内容时,
就考虑收费问题。
正是这一点,损害了游戏的整体收益。
这也是免费游戏设计时,最需要去考虑的问题,否则,如果前面不做铺垫,后面想收费,是比较勉强的。
策划的习惯性思路是,我先做个游戏,然后看能卖什么就卖什么,而这个思路是很有问题的,应当是我准备卖什么,然后根据我要卖的收费点去做设计,至少游戏内容点和收费点是相辅相成的。
比如:
玩家最喜欢什么,一定是等级,其次是装备。
为什么是这两个,是因为它们代表了游戏的主要核心玩法:
升级并增强自己。
我们就可以把“玩家增强自己”给拆开来卖,一部分送给玩家,一部分做为收费。
而我相信,如果在一开始就去考虑设计,那么在一、二级属性设计上,我们就能延展思考到与之相关的其他系统,这样能够通过潜移默化的方式去收费。
而目前我们的收费是:
给一部分,剩下的要钱,是勒索式的收费。
我认为通过与收费点进行融合的设计,更容易说服玩家付费。
我在观察了《dddd》的收费模式后,感受到的就是,他们在做游戏设计时,是
充分考虑收费的,它每个游戏点,都可以转化成完全免费或收费,可以根据运营的实际情况进行调整,而且收费的点并不多,但能够收上钱。
我们的弊病在于收费点又多又明显,而效果却并不讨好。
2.玩家生态上的缺陷
公司在Q2时曾经特别提出过对玩家生态的重视,但由于策划在前期没有把握好,这一
块还是留下了许多问题,这些问题几乎是不可逆的,对产品也造成了很大程度的品质损害。
问题主要集中在,游戏货币的无价值上,它导致了收费用户和免费用户之间完全没有“有价值的经济交互”,《AAAA》由于在收费上做得很皮毛,所有的收费项目都是直接挂钩于RMB,而游戏货币在游戏中起不到关键性作用,又没有渠道进行回收,使得收费用户可以绕开免费用户进行游戏,双方可以完全不存在交集。
游戏内没有形成良好的生态,而没有经济循环生态的恶果就是,免费用户完全成了下层用户,导致了流失,而流失又反过来影响收费用户。
在生态设计上,一定要从基础设计做起,因为一旦形成上述的状态,就几乎无法逆转,这是非常危险的,特别是对于角色扮演游戏来说。
我个人建议设计人员能够仔细看一看《dddd》的整体设计,因为我感觉,如果把经济环境做好了,能够起到留人、高付费转化的作用,那是一个良性的循环。
四、一点心得
再说一些心得,是通过这半年来的实际运营过程中,对游戏设计的一点反思。
1.游戏设计要以运营过程为最终思考
我们一般是凭借着自己玩游戏的经验进行游戏设计,那么在考虑一个设计点时,往往会
把它放在较为理想的环境中去考虑,会模拟一个稳定的环境去思考。
但这还不够,我认为游戏设计除了整体的协调外,更要注重单个系统在整体环境中的影响以及实际运营过程阶段中的指标变化带来的环境变化考虑。
单个系统在整体环境中,与在设计单个系统时的环境是不一样的,一个系统在A产品中的形态与在B产品中的形态,两者发挥的作用和影响力也不一样。
要根据整体的需求和用户的需求去判断系统的大小和参数,并且避免其他的系统影响到预计的参数。
如,如果游戏的战斗形式是比较个人化的,就不要设计太多集体交互的内容,两者之间会产生碰撞而削弱系统的理想状态下的作用。
运营过程中必定会出现的活动也要考虑到位,尽量在最基础内容时,就考虑到运营环境下的需求产生的可能性。
运营过程中会发生什么事,这些事会影响到哪些系统,包括政策上的风险,如可能无法开放情侣系统,则最开始就要做出变动和让步。
实际运营过程中,玩家会玩多久,服务器在什么时候衰退到什么程度,会影响哪些交互,这些变动因素也需要计算进去。
我觉得可以通过两个手段来控制预估的准确性,一是计算,模拟出各个阶段玩家的收费、生态,通过最保守的计算,得到预估值,就能知道大概在多久我们能收到多少钱,多久后将降低这些收入,原因是什么。
二是及早让运营参与进来,与运营一起制订开发计划,能够控制产品上市周、月的变动因素,也能够对可能出现的问题有后备方案。
2.数据分析和数据预估
公司的数据分析环境非常好,我们也都养成了一定的数据分析的习惯,但同时我们也需
要养成数据预估和前后比较的习惯。
这是我在**工作学习到的一个方法,它能够很好的控制无效需求的介入,当我们提出一个需求时,应当同时提出这个需求解决什么问题,它会在数据上有什么体现,通过测试服进行数据吻合比较,如果达不到要求,就修改或撤换它。
数据分析是后发的,有一定的滞后性,而数据预估则是提前预警,不光预计好的,也预计坏的,比如新上一个系统或活动,会使消费降低还是提高,各是多少,至少是有的放矢的提出需求。
3.三思而后设计
这是我个人的心得,我认为上面所说的教训中,很大程度上,是因为我在做基础设计时,
过于草率造成的,虽然可以借口为时间紧张,必须快点出方案,但通过实际的运营情况,我发现我们付出的代价实在是太大了,综合我上面说的要结合运营的实际情况考虑,我认为还是值得多花时间去反复衡量设计,特别是前期基础设计,而往往我们花在基础设计上的时间是最少的,包括每个属性的设计,为什么要有这个属性,它将关联那些部分,都必须一一说明和解释,我认为这样才能相对的使设计的结构稳定。
另外公司的审核机制也能够避免一些错误的发生,但同时审核机制有时会带来新的问题而破坏原有结构,可以说是双刃的。
简而言之,即使是前期做搭积木的工作,也是需要非常的耐心和谨慎,一切都为了后面的实际运营过程着想。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 游戏 设计 缺陷
![提示](https://static.bdocx.com/images/bang_tan.gif)