MVP(Minimum Viable Product) 最小可行性模型。
为什么要制作MVP，我将MVP总结成：一个结果，两条准则，三个问题。

一个结果

我极力推崇的，制作的一定是MVP而不是游戏的DEMO。
之前和行业的发行大咖们聊天，他们总结出来的是：成功的产品，他们总是有一两个特别出彩的数据，不管是自然新增、付费率或者是留存。
MVP阶段能够挖掘出这些数据亮点，后续的工作内容，一方面完全商业化构建，另外一方面更重要的，是将这些亮点打磨的更棒！这样才算是完成了MVP的制作。
所以一个结果：挖掘出自己产品在数据上的亮点。

两个准则

重要的准则一

相信很多人都有一些项目经验或者练习，但是MVP制作极易出现的问题就是：在可行性方面预期不足。
我曾经也犯过类似的错误：一群人在一起通过头脑风暴或者归纳的方式来获得了许多创意，然后在这些创意中筛选出来我们觉得可以做的内容，然后搭建出一个基础的DEMO出来。最终只是做出了一个平平无奇的DEMO，然后又心灰意冷的从头来过。
这个简单的错误，简单来说就是维度不够。一群做游戏的人在一起，满脑子就是游戏，用一个通俗的例子来讲：一群做马车的人，永远也造不出汽车来。
所以，在MVP阶段，永远提醒自己：想再宽也是必要的，就算想的不是游戏。

重要的准则二

大家凑在一起做游戏，或者好不容易准备开一个项目，可能是一时头脑发热，可能是积蓄已久。
MVP的制作，能够有效帮助找到产品或者团队的优势，或者建立起团队在于这些优势上的信心。
随着后续越来越工程化的制作和可能的人员变动，势必在信心上会不断折损，而在战争中，有一条著名的理论就是：当将军丧失信心时，在这一刻，战争失败了。
所以，在团队管理中需要做的是：将产品的优势预期及信心扩散至团队。

三个问题

有三个问题是我们需要在MVP阶段不断询问我们自己的：
1. 怎么玩？（类型）
2. 是什么？（世界观、风格）
3. 玩不玩？（竞品分析）

怎么玩？

为什么不直接用类型来说明，因为之前有rogue like，现在有魂like游戏，游戏的类型也是在不断的发展的，可以通俗的用类型来说明，但不能框死在某一类型内，这样违背准则一。

怎么玩很多时候和核心团队成员的能力和兴趣有很大关系：比如程序非常擅长于制作3D的项目，并且有一个很强大的相关团队基础；又或者在服务器部分有很强的能力，能够制作及时对战或者多人游戏。这些很容易在类型上给出一个倾向性。
有很多的项目，也是因为这一部分能够形成对行业巨大优势的时候，才组建团队制作的。

是什么？

有许多的项目，是因为是什么来组建团队的，通俗的来讲：我们拿到了一个xxxIP。这句话隐含的意思是：我们在是什么上面已经有很大的优势了。
如果没有IP，那么我们需要自己确定一个，类似上面的：比如美术擅长制作机械风格，那么就可能会有末世或者机甲的倾向，如果编剧擅长克苏鲁，那么可能就会有克苏鲁的倾向。

玩不玩？

实际在商业论证及中间的测试过程中，都会有这样的问题：团队对于玩家玩不玩的感受不精准。
比如在线下测试或者线上问卷的时候，都会有这样的问题：你觉得游戏好不好玩？你觉得怎么样？
玩家的反馈可能是“我觉得还不错。。。”“我觉得问题在哪。。。”
这里一个最大的问题就是：玩不玩其实是一个博弈的、选择的过程，而不是一个单纯评价一个游戏好坏的过程。
理解这一点，才不会被一些表象牵着鼻子走，才有可能找到自己游戏的亮点。

在微观经济学中提到的网络外部性(network externality),在网游中同时存在攀比和虚荣两种效应。
1. 对于现在有着又肝又氪的游戏来说，攀比效应对应加速肝的效率，体现达成感，虚荣效应则直接对应优越感。
2. 由于存在网络外部性效应，特别是对于一些依靠自传播的游戏来说，开发者要对玩家付出的社交成本给予相依的报酬。
在游戏中，大量的资源消耗方式并非是为了更有效率的去玩游戏，相反的是投入到皮肤等无法提高实际战斗力的功能中去。

正网络外部性

攀比效应(bandwagon effect)：在这种情况下，消费者愿意购买一种商品部分是因为其他人也购买了该种商品。
正网络外部性内容集中在收集、养成内容中。
1. 一般游戏中的体力购买系统，有一些游戏中有经验buff加成。

负网络外部性

虚荣效应(snob effect)：在这种情况下，消费者希望拥有的商品是独一无二的或者专有的。
作为高成本投入的内容，对玩家的高投入（不管是时间还是空间）做出的一种筹赏。
1. 玩家只会携带要超级肝或者超级氪才能获取到的头像框，其他玩家也只会关注到这些头像框。
2. 攀比效应对应的货币设计与虚荣效应对应货币做区分（一个反向的例子就是有些游戏的天梯竞技场，第一、二、三名之间会有一级货币的差异）。

同一系统下的正负网络外部性

1. 同一系统下只有有限的内容会受到虚荣效应的影响，其他的内容剩余会转化为攀比内容。
2. 虚荣内容往往对应时限、名额限制等设计，相对的攀比内容往往是资格制。
3. 对于攀比为主的用户比例的控制5-8%，虚荣0.5%
4. 经验-肝的成本会随着玩家外部环境的变化而产生巨大变化。

玩家的养成，是一个从不确定性追求确定性的过程。
但是当不确定性部分（操作和随机）降低时，游戏的趣味和乐趣也随之降低。

1. 前期套装是不确定性为主的，后期会越来越确定
2. 前期的挂件是确定性为主的，后期爬塔的挂件是不确定性为主的。

关于操作部分的不确定性差异可能是70%
关于随机部分的不确定差异可能是70%

技能设计需要回归到游戏最外层

如果在一个以英雄特色技能和差异性作为卖点的游戏；
游戏中的主要特色玩法，或者核心玩法需要围绕玩家在技能上的学习

正面的例子：
《剑与远征》中，玩家可以通过roguelike模式来获得随机角色的技能，从而学习角色
反面的例子：
《云图计划》中，roguelike中获得的技能球是另外一套逻辑，增加了玩家的学习门槛

以群体返璞归真为基点，创造一种新的身份体系，可能是一个好的，符合未来发展的趋势。

生存在一个被过度设计的世界，以现有世界的产品去分析，在这个基础上做出“优化”“创新”。
有可能做出过度设计的产品。即推理逻辑合理，但是用户无法完全感知的产品或内容。

及仓库、图鉴的实现

模块功能

实体是玩家存档中的基础部分，英雄、武器、防具等都会有各自的独特的属性比如：等级，星级… …
英雄、武器、防具被称为实体。

模块实现

下面来用一个例子来稍微解释一下：

很多人都对上面这张图记忆深刻，那么，我们的问题是：
怎么才能实现构建这张图上的武器实体呢？也就是提供武器能够从【破损小木棍】一步一步升级到【+12精·天崩地裂般若奔雷杖】的基础呢？
​

分析

首先从上图中分解出【武器】这一实体所具备的属性，简单分析一下之后：

1. 强化等级 —— +12
2. 精炼 —— 精·
3. 附魔 —— 破损、天崩地裂、般若
4. 武器类型 —— 小木棍、奔雷杖

​

那么【武器】的实体图如下：

​

仓库及图鉴

​

通过仓库或者图鉴等功能存放玩家独有的实体内容，这部分就是玩家存档的核心内容。
比如：你有一把【+12精·天崩地裂般若奔雷杖】和2根【破损小木棍】，要是哪天上线之后发现变成了3根【破损小木棍】，这个时候就应该是很悲伤了吧。
​

说到这里，就能够看到现在游戏中的主流实体存放方式，主要是【仓库】或者【图鉴】两种，两种方式的最大区别在于：在【仓库】中可以存放复数个同一id的实体，而在【图鉴】中同一id的实体只能存放一个。
​

还是以【小木棍】和【奔雷杖】来举例：
在【仓库】这种形式下，【小木棍】的id为weapon_1001, 【奔雷杖】的id为weapon_3001, 那么游戏中必然会有一个单独的【进化】功能的表，将【小木棍】进化到【奔雷杖】。
而在【图鉴】这种形式下，【小木棍】的id为weapon_1001, 【奔雷杖】的id也为weapon_1001, 只不过在会在表中增加1个标识【进化】阶段的字段。
​

 . 
├── id
├── `进化阶段` # 图鉴独有
├── `强化等级`
├── `精炼`
├── `附魔`
└── `类型`

使用场景

【仓库】这种形式更多的出现在MMO, RPG等游戏内交易的游戏中，
而像【图鉴】这种形式更加强调收集体验，现在被广泛的使用在卡牌、二次元等游戏中。

内容原创，转载请注明出处

模块功能

物物交换为玩家提供了使用材料兑换材料的方式，减少部分材料的冗余，提供某些珍贵材料的获得方式。
一般游戏中的金币、钻石等并不具有经济学意义的货币属性，所以对于大多数游戏来说，所有的资源流转都是以物物交换来实现的。

模块实现

字段内容

1.1 消耗物及兑换物的id及数量

消耗物相关字段：consume_item_id, count
兑换物相关字段：item_id,count

1.2 可交易次数

所有交易物品均可以设置最大交易次数，
lifetime_limit为总次数上限，
可购买数量会根据运营需求不定期增加，届时需要更新配置文件以添加。

1.3 每日每周可交易次数

daily_limit, weekly_limit​
根据实际的需要，有时会设置每日交易，每周交易的限额。
​

1.4 道具格子

​

一组消耗物和兑换物为一个兑换组。
​

1.4.1 确定兑换组

在确定兑换组的交易模块中，比如每周刷新的普通商店中，表结构如下：

. 
├── id
└── list<
            ├── `consume_item_id`
            ├── `count`
            ├── `item_id`
            ├── `count`
            ├── `lifetime_limit`
            ├── `daily_limit`
            └── `weekly_limit`

在上述的情况下，daily_limit 和 weekly_limit 字段不需要，而是整个商店添加一个自动刷新时间的字段。
​

1.4.2 随机兑换组

在有些商店中，格子数量是固定的，比如《剑与远征》这个商铺是确定格子数的，但是里面的内容是随机的。
​

那么它的表结构有什么区别呢?
​

. 
├── shop_id
├── refresh_time
└──list<slot_id
            ├── `unlock_level`
            ├── list<
            ├── `consume_item_id`
            ├── `count`
            ├── `item_id`
            ├── `count`
            ├── `lifetime_limit` = 1
            └── `weight`

​

一共会有三点区别：

1. 会在外部增加一个slot的列表，玩家实际购买的不是具体的兑换组，而是具体的某个格子上的物品。
2. 增加unlock_level，因为有些格子是需要一定的玩家等级，或者主线进度等条件来进行解锁的。
3. 增加weight，用来进行随机，简单随机规则会在后续的内容中讲到。

总结

交易模块是游戏中使用最为频繁的模块，在了解最基本结构的情况下，如何最为有效的进行扩充和调整来最高效的实现设计目的，是持续研究交易模块的意义之所在。

内容原创，转载请注明出处

游戏设计师最核心的应该是：设计创造价值。
不管是内容的表达，还是细致的体验设计，都是一种对玩家的价值创造。

但是事实上是，很多时候，很多人都把精力放在造轮子上，不管是设计者之间的讨论，还是和程序、美术的沟通中，这些都花费了大量的沟通成本。

写这些内容，一方面整理一下现有的这些轮子，沉淀一下知识体系；另一方面，也告诉自己，所有写的这些都已经被各种游戏使用了无数遍了，本身已经没有什么价值，所有精力更应该着眼的地方，是在这样的一些基础上，怎么样再去给玩家创造价值。

模块功能

1. 任务模块是游戏中最常见的模块，相对于其他类型的产品，游戏中的任务模块更加的密集，形式也更加的丰富。
2. 任务模块最重要的使命就是构建玩家目标和挑战，给玩家提供达成感体验。
3. 任务模块作为游戏的基础模块，也被广泛使用在例如师徒系统、节日活动等大型系统和功能中。

​

模块实现

任务基本字段

任务基本字段使用在所有任务功能中，用来判断任务是否完成。
​

1. 任务类型 task_type

任务的目标，判断是否完成任务进度的唯一标准。
具体内容功能需要在添加字段后转交服务端实现，
不同游戏根据实际情况不同，拥有一张任务类型功能需对照表。
一个任务的任务类型只有一个。
所有扫描仓库数量形式的任务类型实际计算方式应该均为次数统计。
​

2. 任务阶段 task_order

任务分为多个阶段，每个阶段完成都可以获得该阶段完成奖励。

2.1 完成进度计算

任务进度必须在任务解锁后才会开始计算，例如某些需要解锁条件的任务，必须在达成条件解锁后才会在任务列表中出现，此时完成任务目标才会计算到进度内。
​

一种常见的设计方案-累计型任务设计
一个任务中（id）不同的阶段（task_order）下，任务的task_target_count会一直累计,领取时需按 order 依次领取。
例如：
任务要求：完成1，2，5次副本。
在完成3次副本后可以领取第一阶段奖励，领取后第二阶段出现并可以继续领取，再领取后第三阶段出现并显示未完成（3/5）

2. 目标进度数 task_target_count

完成阶段所需要完成的任务目标的数量。
​

任务特殊字段

在一些情况下，任务模块还拥有这些字段。
​

1. 解锁条件 unlock

一般游戏中常见的解锁条件

• 玩家（战队）等级
• 主线进度
• 队伍战力

一般情况下，任务的解锁和功能的解锁使用相同的条件，这样更方便让玩家去告诉自己我该怎么玩？是提高自己的战队等级？还是疯狂推进主线？
根据实际游戏的预期设计，合理的设计解锁条件。
​

2. 重置时间 refresh_time & 领取时间 take_reward_time

2.1 重置时间

每个游戏都有自己独特的一日的概念，有的是凌晨3点，有的是0点，有的是早上5点。
每个游戏都有自己独特的一周的概念，一般是到周日的那天结束，也有到周六结束的。
每日任务、每周任务、每月任务的刷新时间是基于游戏自己的日、周来进行的。
（在每日、每周的任务附近需要明确的告知玩家自己游戏的日和周分别是什么，因为这也是玩家需要学习的重要一部分）

2.2 领取时间

有些情况下，特别是活动中的领取时间是单独配置的。
即：活动开放2周只能可以做活动任务，2周结束后，玩家还有3天时间可以用来领取任务奖励。
在这种情况下，需要额外配置或者继承活动配置表中的领取时间。

常见的使用场景

通行证

通行证从诞生以来，逐渐成为了各家手游的标配，荒野乱斗中的通行证任务是相对设计的很不错的。

让我们来分析一下任务模块在其中的作用：

任务类型	机制	作用
主题季任务	赛季过程中不重置，每天刷新2个，周二周四额外刷新多个。	通过任务编排，引导玩家熟悉英雄、熟悉地图、熟悉好友间操作等。（熟悉英雄永远贯彻在第一位，因为是它最核心的付费点）
每日任务	每日重置2个。角色or对战为主	增加玩家的留存和每日时长，让玩家每天上线有事情做。
特别任务	新模式游玩为主，限定天数重置。	提供玩家短期高频的新模式体验，对应bonus的奖励，维持玩家游玩的新鲜感。

内容原创，转载请注明出处

现在在一些项目中普遍的存在以下的情况：
1. MVP花费时间过长，风险和沉没成本高。
动辄需要1-2年时间。当然对于一些游戏而言4-5年也是必要的。但是客观来说，还是因为团队抱有“丑媳妇见公婆”的心态来面对自己的玩家，而通过各种道理来延长面对玩家的时间。
2. 游戏的测试目标固化，有几次测试，每次测什么都在游戏立项的时候就确定了。
事实上，我们都很清楚一点：失败的游戏各项数据指标都不是很行，而成功的游戏产品，其好的游戏数据其实不是千篇一律的：有的游戏长期留存很高，但是付费率低于及格线；有的游戏ARPPU很好，但是付费率不行。
对于这样的实际情况，一条线拍死每个指标的生死线和成长轨迹，是没有经过辩证的随大流行为。会导致团队在每个阶段都表现得短视。
3. 目标不连贯及阶段性时间分配不合理。
每次的测试目标之间是没有连贯性的，而且时间分配并不是根据目标实际规划得到的（往往实际的情况下，越是每次测试差强人意，团队越是焦虑）。这也会造成团队一定程度上的鸵鸟心态，得过且过。

优化开发流程

仍然是基于正常的敏捷框架来进行调整的，有两点内容进行了优化：
1. 尽早在MVP阶段进行泛用户的ROI测试，不惧怕暴露问题。也能够尽快破除鸵鸟心态，更加心平气和的进行游戏的开发。
2. 在每次迭代之后，投入更多成本在目标确定上，更仔细的根据确定的目标评估周期和风险，能拆就拆。