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

猴与花果山

GameRes发布，文/猴与花果山

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

游戏规则与详细设计

假如你已经玩了这个游戏，乍一看你会认为这是一个传统的战棋类游戏。这个玩法其实是我们正在做的一款手游《江湖派》的核心战斗玩法的精简版，由于这个手游的设计中允许了玩家实时对战，因此在这个游戏的规则设计中，我们思考且避免了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思路的战斗设计（http://bbs.gameres.com/thread_259895.html）。
我写这个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次。”

meigo

江湖派是个啥？我怎么觉得像广告帖。。

野兽神话

这只是一个交流，名字就不要在意了

by2120102707

我没有做过端游，一直是做页游和手游的。在我做过的游戏中，基本没有涉及到通过脚本来实现技能，都是通过表本身实现。所谓的数据驱动，可不可以说是把游戏中的整套逻辑（例如一个技能）抽象成一个个独立的基本变量，不同的整套逻辑是通过不同的对象变量排列组合完成的。抛开脚本运行机制不谈，表的作用其实也是一样的。