手机传奇法师火球术雷电术 游戏策划如何正确的设计表头和配表？

手机传奇法师火球术雷电术 游戏策划如何正确的设计表头和配表？

事实上，创建数据表是一项需要一定编程思维的工作。 对于游戏策划者来说，可以按照这个思路来做：

区分模型和对象

在游戏中，有两个东西，模型和对象。 简而言之——模型就是规划时需要填写的数据，是这个问题的核心； obj是游戏中运行的数据。 一个游戏从开发的角度来说，无非就是大量修改数据块的逻辑（所以ECS架构非常适合游戏开发）。 通常很多技术能力不足的团队或者开发者，包括市面上主流引擎的一些例子，都没有model和obj的概念。

举个最常见的例子，在游戏中，法术有很多，其中之一就是火球术。 然后玩家可以学习火球术1级、火球术2级、火球术3级……对于外行来说，这个设计了一个法术表，里面有火球术1级到3级的三个数字。 它们是不同的咒语。 当玩家在游戏中“升级”法术时，他们实际上改变了法术。 这种做法看似很有道理，但实际上只是想达到想要的效果。 根本原因是这里model和obj混淆了，而没有意识到。

如何理解Obj

obj是游戏运行过程中的数据，所以在这个数据中，往往有以下几个组成部分：

这是什么，即从模型生成的数据？ 注意，它是“从模型生成的数据”，这意味着模型是一个初始化的东西，这并不意味着你可以使用. 直接索引火球术。 在上面的火球术例子中，玩家学到的火球术技能应该是.Clone()获取的数据。 因为在游戏的实际操作中，Obj中的所有Model都可能会发生变化。 例如，游戏中有一个设计，玩家获得一本邪恶火球之书。 使用这本书后，玩家的火球术所发射的火球不会发生变化。 是红色而不是绿色，但这并不意味着规划设计的数据表（模型）中的火球术必须是绿色的，或者必须配置带有绿色火焰的火球术，因为火球术可能不仅是颜色是一个属性，我们的实际需求只是改变玩家现在已经学会的火球技能的模型值。 当值发生变化时，它与模型完全不同，因此应该使用克隆数据来生成新的实体数据，而不是引用。 有些值只能在运行时赋值。 在 的示例中，级别只能在运行时分配。 玩家可能不是唯一将火球术等级从2级升级到3级的人。它可以通过这种方式进行设计和升级。 规则可以有很多，但无论怎样，关卡只会在游戏运行过程中发生变化。 因此，关卡等属性可以在游戏运行过程中被准确赋值，因此属于Obj。 属性。 再比如，如果游戏设计使用20\30\40...火球来升级，这个次数也是一个只能在运行时赋值的属性，所以也是运行时。 当然，最典型的就是CD，也就是剩余多长时间才可以再次使用。 对于类似的概念（即充值多少次），Array可以当做CD使用。 如何理解模型

Model用于初始化某个元素的核心数据，但仅仅依靠Model是无法完成Obj的初始化的。 因此，在Model中，所需要的只是一些“基本属性”数据。 这里所说的“基本属性”应该具有以下特点：

这些值构成了元素的描述。 这是最基本的要求。 通过这些属性和运行时的变量，就可以得到一个完整的Obj。 我们具体以火球术为例——现在我们要确定的是，他是一个moba，还是像《大菠萝》这样的实时回合制ARPG游戏，或者是《魂》这样的游戏。 现在我们想要一个像火球术这样的咒语。 它至少应该有一些属性：名称、图标、描述和其他显示数据。 ：在这种类型的游戏中，所有法术技能最终都会产生一个。 施法者以此为主体，在适当的时候做一些事情，比如让角色发挥一个动作，产生一个视觉特效，产生一个，产生一个，产生一个等待行为。 因此，你应该已经嗅到了一丝端倪——这个技能表可能与一个表相关联。 如果你理解的表格只是excel，因为excel表格是一个二维数组，如果你理解的表格是“数据结构”，无论是excel还是json，它们都只是输入，所以这只是一个结构化数据。 条件与消耗：条件是指技能可以使用的条件，比如要求mp>=20； 为什么条件和消费项目不同？ 因为可以有一个技能说“当玩家有20或更多MP时，消耗所有MP......”。 CD等：技能的CD信息。 其他辅助信息：至少在最简单的arpg中，没有必要。 在游戏内容上，应该是“公开的”。 一旦我们有了上面结构中的数据，我们就可以准确的填写一个火球法术了，但是为什么我们需要在模型表（即数据表）中填写这么一条数据呢？ 就是因为他在游戏中会被大量使用，形成一种“公共知识”。 如果我们以上面的Green Fire为例，它是否需要一条数据？ 其实不需要，这只是“通过一个进程改变一些运行时数据”。

当我们真正设计一个游戏的玩法的时候，里面的每一个元素（也就是我们可能需要设计一个数据表的东西），如果我们思考这个东西，我们就会思考游戏进行过程中的情况，比如玩家背包里的道具，地图上行走的怪物，场景中出现的宝箱等等，这些实体是游戏运行时存在的，那么这些就是Obj，还有它的很多属性，比如坐标，生成时间等。 比如自动消失时间等等，这些是Obj特有的值，不应该填写在表单中。 去掉这些Obj唯一值之后，剩下的元素就是需要用作的内容，也就是Model数据。

阐明数据依赖性和可扩展性

也许此时，有人会对火球术的表格结构有一些想法——比如，为什么我的火球术等级上限没有显示在表格上？ 再比如，我游戏中的火球术需要向训练师学习。 为什么表中没有列出火球术各个级别的学费？ 这就涉及到一个依赖关系和可扩展性的问题——我们在设计表的时候首先要考虑业务的内容以及谁依赖谁，然后再从可扩展性的角度来考虑这种依赖关系。 性别准确吗？

谁依赖谁？

这是根据业务来理解的。 例如，当我们刚刚谈到“火球术等级上限”时，我们要回到具体的游戏设计，问自己几个问题：

每个角色的火球术最高等级都一样吗？ 如果不一样的话，比如猴叔的火球术可以达到20级，而你作为普通玩家的最高等级是10级，那么这是根据人而不是技能，所以等级限制并不是技能的属性。 火球术的等级上限变化因素是多少？ 如果无论是谁，无论什么情况，火球术的上限都是10级（计划默认值），那么等级上限应该属于技能的属性。 反之，当玩家还是见习魔法师时，火球技能上限为4级，普通魔法师时则达到5级，然后完成魔法师挑战任务，达到等级上限6.成为强大的魔法师之后就变成7级了，然后去一个岛屿进行修炼训练等级上限是9级，在岛上训练等级上限是10级。然后当你离开的时候遇到飞机事故的时候岛屿，等级限制降低至5级……各种原因都会改变等级限制。 那么等级上限就不是技能的属性了。 改变的因素本身就是一种技能吗？ 这里的技能使用可能不是一个很好的例子。 比如我们买一个道具西瓜，可能从鲁大师那里买20G，但是从猴叔那里买就要35G。 那么此时的价格就不属于道具了，而是属于卖出道具了。 这件事。

基于这些想法，我们将对游戏设计进行更深入的审视，包括对很多细节的可扩展性进行进一步的讨论，比如道具的售价。

表格可读性设计

至此，设计一个表头的思路其实已经很清晰了——根据你对游戏内容设计的理解，选择数据作为Model，丢弃与“这个”无关的数据后”，我们就可以得到哪些数据属于这张表。 但接下来就会有一个问题——如何保证这些数据的值的可读性？ 毕竟，并非每个值都是数字、布尔值或字符串。 在这里我建议大家遵循几个原则：

可以用也可以不用

最常见的就是id，通常很多菜鸟都喜欢用它作为id。 当然，我们听说过的id，比如ID号，确实是一串数字，但这并不意味着游戏的数据表的id就一定是。 为什么我们需要设计id数据？ 因为它需要被其他地方引用。 例如，drop表中prop的ID需要索引到prop表中。 许多“聪明的策划者”使用数字规则来表示有关道具的信息，使他们更容易记录。 比如10000从消耗品开始，20000从盔甲开始，22000从鞋子开始……这样的规则，但是当你确实需要找到“钢盔”时，或者当你在掉落物中看到id=24316的数据时表，你真的能知道谁是谁吗？我不知道，那为什么不直接用“”呢？只要保证不存在重复的字符串，或者重复的字符串有解决办法。

如果它是枚举，请勿使用它。

这也是一个常见的坏习惯，比如装备零件，包括帽子、衣服、鞋子。 很多菜鸟喜欢用1来代替，比如0=帽子，1=衣服，2=鞋子。 但这是一个非常不好的习惯。 要么用它，要么充分利用枚举（比如excel提供了“可填充取值范围”的功能），或者在编辑器中做一个下拉列表（excel可以下拉列表选择）。

没有魔法

魔法通常会暂时产生一些特殊的数字，以达到效果。 比如最常见的“-1代表无穷大”，与原来数字的含义不同。 更致命的是“如果这里填1-7，就意味着“对于星期几，填8代表整周。”在制作之初，无论是设计表的人还是上帝知道这些数字代表什么，但几周后，只有上帝知道。

善用Tags解决索引问题

在一些购物软件中经常可以看到标签的概念，比如“服装”、“快餐”、“汉堡”等，都属于标签的类型。 我们在设计数据表的时候，不妨添加一个Array作为Tag，这样可以为很多业务建立非常方便的连接关系。 当然，这里也会存在Tag管理问题，但它是一个利大于弊的东西。

为什么需要标签

举两个实际例子：

例如，在设计掉落表时，我们希望一些道具会在圣诞节掉落。 圣诞节可能会掉落几十件物品，而这几十件物品是不稳定的。 第二年圣诞节，我们添加了“圣诞老人帽子”等数十种新道具。 他们也会掉落。 如果根据id填写掉落物品，那么当我们添加新的“圣诞掉落”时，就得在掉落表中维护大量数据。 但如果我们按照一开始的标签在掉落表中掉落东西，比如有30%的概率掉落“圣诞道具”，那么当我们添加新的道具时，只需要标记“圣诞掉落”即可标签将被视为有30%概率掉落的道具之一。 在此基础上进一步设计算法，可以省去大量无意义的重复填表工作。

再比如我们在设计技能和buff的时候，有这样的想法：角色身上的每个中毒效果可以增加2%的伤害，那么最终伤害增加多少呢？ 我如何知道某种效应是否有毒？ 我们知道，“效果”实际上是指角色的身体。 我们如何知道一个人是否中毒？ 花毒有毒（一），蛇毒也厉害（另一）。 “被猴叔鼻屎子弹击中”是中毒吗？ 因此，在 中，我们可以有一个作为标签的数组。 如果标签中含有“”（.model.tags.("")>=0），则认为中毒。

可见，标签不仅解决了输入（表单填写）问题，还解决了很多设计逻辑问题。 因此，我们在设计一个元素的数据时，善于添加标签，并且管理好标签的范围（之所以不是枚举，是因为它的扩展频率还是很大的），这是一项非常重要的工作。