[技术] 数据驱动设计思路,带你一天完成独立HTML5游戏

>>>  創業先鋒 眾人拾柴火焰高  >>> 簡體     傳統

GameRes发布,文/猴与花果山,转载请注明出处



很早以前就想写一篇关于我说的一些机制在实际开发中的运用的帖,但是一直没有一个话题,所以一直以来只能零零碎碎的发些技术交流。正好最近在项目后期的空档里,抽1天休息时间单独做了一个HTML5的小游戏,就拿这个我一个策划用一天(还不到)的时间单独完成的游戏来详细说说,基于数据驱动设计思路的游戏该如何设计和实现吧。首先发一下这个游戏的2维码,没东西还说什么了是吧。

阅读原文进入demo页面



游戏规则与详细设计

假如你已经玩了这个游戏,乍一看你会认为这是一个传统的战棋类游戏。这个玩法其实是我们正在做的一款手游《江湖派》的核心战斗玩法的精简版,由于这个手游的设计中允许了玩家实时对战,因此在这个游戏的规则设计中,我们思考且避免了SLG游戏中因为等待时间过长而带来的问题,所以我们改变了传统的SLG战棋游戏的一些规则。你可以发现,这个游戏的核心规则更接近于太阁立志传5的个人战小游戏结合金庸Online的战斗规则。

每个回合玩家需要做的事情是:

1,从可移动范围内,选择一个单元格,这是这回合要走过去的地方。

2,从上下左右4个方向中选择一个,作为本回合的面向,而面向也决定了自己的攻击方向。

在参与的每个玩家发布完毕以上指令之后(在这个HTML5版本中,是单机的,所以只有玩家自己发布指令),回合开始,所有的角色同时先移动到自己本回合移动目的地,如果目的地的单元格内有可以吃的道具,就会先吃掉道具,如回血的药水等。然后所有角色同时发动攻击,处于自己攻击范围(多个单元格)内的角色将受到自己攻击的伤害。而在原游戏《江湖派》中,为了更多的数值可培养性,加入了身法属性,由身法决定出手的先后顺序,所有角色移动到目标单元格后,由身法最高的角色开始到身法最低的角色依次攻击,这个规则的差异产生的结果差异是,身法低的角色在《江湖派》中可能没机会攻击身法高的角色就先挂了,然而在这个HTML5的游戏中,仍然可以对别人造成伤害。

整个游戏的乐趣在于,掌握了敌人的行动规律后,在尽可能少的被攻击的情况下,尽可能多的对敌人造成伤害,其实说到这个玩法的时候,可能灵活的你已经想到了很多很多的规则扩展手段,包括且不限于:

1,增加一些地形,让可以动的区域收到一些限制,如加大一些单元格的移动消耗(这个游戏中都是1),甚至这些地形还可以被摧毁。
2,一些单元格是特殊地形,走上去会产生特殊效果,比如被烧伤。
3,每一个回合一些单元格会出现火苗,在下一个回合单元格内冒出火柱。
4,增加buff给每个角色,增加游戏的不定性。
5,攻击后产生AOE,比如某些角色的攻击可以在攻击范围内留下钉子,持续2回合,移动到钉子上的角色会受到割裂等debuff。
6,增加我方的随从配合战斗,可以释放合体技。
7,角色到一定条件下释放大招。
8,小宠物加入战斗,而小宠物本身和其他伙伴不同,也不是别的游戏那种就增加属性的,而是小宠物可以辅助战斗,且不会被杀死,比如你的小宠物是一只小猴子,当他与敌人移动到同一个单元格时会抱住敌人不让敌人发动攻击。
9,角色的攻击范围可以培养,比如带不同的武功就有不同的攻击范围。

等等等等,你还可以想出很多很多很多扩展的玩法,的确这些玩法在《江湖派》中全都有了,在这个HTML5的游戏中,机制上也做到了,可是我并没有去利用这个机制作这个设计,因为我认为既然把这个核心战斗拿出来做一个小游戏,并且想在微信上和小伙伴们分享,就要让它尽可能的轻。而现在的游戏规则是具有一定的探索性的,也就是说并不是所有人一上来都能看明白怎么玩得,需要一定的学习成本,当然假如你并不是抱着对抗心理(这个在游戏研发的日常讨论中也很常有,最常见的表现就是一个劲的质疑这个玩法怎么复杂怎么不好上手,假如你存心不想上手,你连吃饭、大便都能学不会,事实就这么简单,而存心不想上手的心态,就是一种对抗心理,就是认定了你这个东西不好了,所以这种情况我们不予以讨论),那么这种学习的过程,仅在于2个回合,就目前事实的反馈来说,我老妈的一些老同事,从不玩游戏的阿姨们,都在3个回合内搞懂了游戏的玩法。

数据驱动的制作方式

数据驱动一直是游戏行业在探索的一种思路,数据驱动本身是一个很传统的编程方式,Liunx的作者很早就提出了这个概念,并投入了实用,传统软件行业已经证明了这种模式的优势,之前我在游资网也发过一篇技术交流贴探讨了关于这个Data Driven思路的战斗设计,需要的话前往游资网搜索查看。


我写这个HTML5游戏的时候,思路仍然是客户端和服务器的,和我做其他手游的思路是一样的——客户端只是一个简单的浏览器,这个思路假如你做过早期的WebGame(大约08年时候JavaScript的那种)你就会很明白,我只是将客户端当作一个没有逻辑的浏览器,不用客户端去实现核心逻辑(眼下包括刀塔传奇在内的很多游戏战斗是在客户端的,也就是我用模拟器+FPE是可以轻松改变战斗结果的,所以刀塔传奇不会因为战斗结果带来额外的数据好处),当然我也不抛弃客户端可以写逻辑的优势,一些基础的判断功(比如这个按钮能不能按下)能还是会留在客户端做第一层过滤。当然从逻辑上来说这是一个CS的游戏,但这个HTML5游戏本身是一个单机的,我只是把“客户端”和“服务器端”打包在一起了而已。

那么我们接下来看看Data Driven在这个游戏中的运用:

首先我们要确定在这个游戏中有哪些元素是客户端需要有的,用通常的思维逻辑去思考:

1,地上亮起来的2种格子——一种是我的移动范围,一种是战斗中展示角色的攻击范围的,颜色会有所不同。
2,角色——敌人的、我方的。
3,宝物——小苹果,药、小师妹的啤酒鸡和VIP宝箱。
4,视觉特效——各种刀光等等。
假如是传统的开发思路,我应该开发这些类:
1,格子类:派生出可点击格子,其中属性包括了颜色。
2,角色类:派生出主角,而敌人本身就采用角色类。
3,宝物类。
4,视觉特效类。

那么在数据驱动模式下,我们需要什么“类”呢?事实上在数据驱动模式下,所有的“类”只有Entity一个(事实上,在Entity System这种Data Driven的逻辑下,不应该还有类这个概念,这里只是为了说清楚事情,我也发现很多用unity的程序员仍然还抱这“类”这种OOP才有的概念,当然这也是unity为什么仍然还允许component可以写逻辑的原因),一个Entity所包含的Component(也就是Data)决定了这个“类”“参与的工作”而非“工作性质”:

1,Sprite,这个Component决定了一个“类”能否被画出来,并不是所有的Entity都是“玩家可见”的。在Sprite中有PointerDown\PointerUp等点击事件,这些用来处理玩家对于该“对象”的操作。

2,BattleCharacterInfo,这个Component是标志一个Entity是否为战斗角色的,在客户端上,一个角色本身拥有一些额外信息(Data)要去记录,比如这个角色的UniqueId等等,全都丢在这个Component里面。并且由这个Component的存在与否得到一个Entity是否是一个角色。值得注意的是,由于UI上敌我双方的表现是不同的,所以才在这个Component中记录了一个side属性来决定这个角色在游戏规则下是属于哪一方的。

3,BattleTreasureInfo,和BattleCharacterInfo类似,但他标志了这个Entity是一个宝箱,在客户端,我并不关心宝箱吃掉后的效果是什么,所以他的属性只需要UniqueId和Position(逻辑位置,而不是象素位置)就可以了,像素坐标和他的外观信息,在创建这个Entity的时候已经赋给了Sprite了。

以这个眼光来看,我们游戏中的Entity:

1,地上的格子:仅拥有Sprite。
2,角色:Sprite+BattleCharacterInfo。
3,宝箱:Sprite+BattleTreasureInfo。
4,特效:仅拥有Sprite。

除此之外,数据驱动的另外一个核心是在于逻辑流程的处理,在这一环上,我在上一帖中也讨论过了关于这种回合制游戏的设计思路,那么在这个游戏中,我们又需要那些“动作”来支持“服务器”到“客户端”的交流呢?从策划角度的归纳应该是:

1,移动一个角色:参数:角色uid,目标坐标、指定时间。把一个角色从当前位置移动到目标坐标,在指定时间内完成。

2,角色做动作:参数:角色uid,动作id,是否循环。让一个角色做指定的id的动作(在这个游戏中包括了站立、跑步、受伤、庆祝、死亡、攻击6个动作),Play(执行一次后恢复上一个动作)或者Loop(循环播放)。通过角色做动作(跑步)+移动一个角色就可以实现角色在视觉上跑起来的效果。

3,角色说话:参数:角色uid,说话内容。让一个角色头上冒出泡泡来说话。

4,杀死一个角色:参数:角色uid,死法。确切的说是移除一个角色,角色的死法是一个enum,决定如何移除掉他,在这个游戏中包括了原地消失和飞起来消失2种,因为死法的处理比较特殊,如果用移动一个角色+杀死一个角色来处理效果未必会很好,所以这里采用了客户端写一些特殊处理的逻辑,而这也是典型的需要策划去衡量到底如何实现的点,从用其他动作组合或者单独制作中进行抉择,我选择了后者。

5,添加一个角色:参数:角色uid,角色外观,角色位置。把一个角色放置到战场上。通过杀死一个角色来关闭一个被显示的地面单元格,通过添加一个角色来显示一个地面单元格。所以从一开始,我们游戏中就没有“单元格类”和“角色类”的说法。

6,播放特效于角色:参数:角色uid,特效id,播放次数。之所以独立出这条,而不像处理单元格一样处理特效,是因为如果是一个地面的视觉特效,我可以“添加一个角色”,但如果我想让特效跟随角色,还是必须把角色的Entity当作Parent来使用,所以我额外增加了这条。

在这个游戏中,其实核心的动作只要有这么6种,然后通过上一篇说的组织方法告诉客户端之后,客户端就能顺利的重现出一个回合的战斗来。由于这个游戏每一个回合都要等待玩家的指令,所以它是一回合为一次与客户端交互的,而不是MT类游戏一场战斗一次交互的。

下一时代的人会如何开发游戏?

为什么要采用Data Driven来做这样的游戏?作为一个既得利益主义者,最直接受益的就是可扩展性,你可以看出只要随便增加一个动作,就能给游戏增加很多很多新的东西出来,同样的,客户端也不需要做出很大的调整。而Data Driven的思路,在游戏开发整个过程中的核心好处,就和这个方式被提出来的核心好处是一样的——人类处理数据的能力远强于处理逻辑。因此将来我们游戏的一个开发方向就是——让好的设计师可以通过用自然语言描述来完成一个游戏逻辑层的coding。

你不难看出,假如你在这游戏中,利用我的buff机制开发一个新的buff,可以如何去编写他的效果,比如说我需要一个buff,每回合持有者都可以恢复50点生命值,播放一个视觉特效。策划不再需要填写很长的表单,只需要写一段中文的dsl——“回合1的倍数开始时:回复自己50点生命,同时播放特效1001号于自己身上1次,之后跳出宋体10号绿色"+50"于自己身上1次。”



GameRes游资网 2015-08-23 08:39:18

[新一篇] Chinajoy的7年之癢:喧囂背后,剩下一地雞毛

[舊一篇] 《英雄聯盟》:將對大學生的關注進行到底
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表