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. 反响热烈；
2. 反响平平；
3. 没有声音。

非常实际的，最终的情况就是没有声音了。

设计初始的目的没有达到

预期很简单，游戏价值 = 用户优越感体验 / 游戏投入；
那么降低用户的投入预期，不断增加用户的优越感体验，从而达到价值突围，产品突围，似乎是一个非常不错的衡量方式。

实际上，从优越感的给予上，就出现了问题。

对于平台、流量和用户群体认知过于浅薄

没有确定的群体，抛弃用户画像带来的问题，就是希望能够获取到更多的泛用户。但是这样也出现了一个问题：当你的测试数据，经验积累的平台过于单一时，你的用户群体也就变成了这个平台的群体。
而不能否认的，群体间的差异性和优越感的诉求是天差地别的。
犯的最大的错误：能力有限的情况下，想要的太多，做到的太少。

简单问题切勿复杂化

有时常常会把问题复杂化，实际上就是表现出来一种对底层需求的把握不足，真正的好的需求或者方案，都能用短短几句话甚至几个字来找到感觉。

平凡的才最不平凡，自以为是的不平凡才是最平凡的

认为自己独一无二，自己的设计独一无二或者略有所长，这些都是最平凡的想法（事实上每个人都是这么想的）。
正是因为每个人都有这样的认知，才构成了这个平凡的世界。

优越感，达成感… 永远来自于自己

不管是优越感，虚荣，攀比等等，永远来自于自身的感受，用唯心主义一点的话：我不存在，这个世界也就不存在了。

顺势而为

过于要求自己的内容不同，甚至出现了一些洁癖的影子。
创造需要一些与众不同的底子，但是最重要的是，这些东西不能变成逆势而为的借口。
时代

最近在思考电影院现象：前排的人站起来，后排的人也会站起来。从而表现出一种没有自组织情况的群体自我伤害功能。

这和我之前思考的另外一个现象一起思考就很有意思了。
公交车的用户传递打卡：当公交车很挤的时候，后门上车的用户需要在车头打卡，所以需要把公交卡传到前面去打卡。表现出一种混乱状态下的自组织。

用户需要在向前传递的其他用户中，找到最信任的那个，从而快速建立起来路径，剩余的所有人也会尽可能的使用这个路径。从而能够维护出一个保证群体最低安全感的基础。

当用户表现出来被需要的状况，利己和利他的转换能够带来结局的不同。在强行操作势必会造成巨大浪费或者损耗的时候，或许能否转变整体的心态的设计及引导，才是真正需要思考和研究的对策。

景区的酒店

在一个风景区中，人来人往，催生出了很多酒店。越来越多的人看到了这个契机，来这个风景区开酒店。随着酒店越来越多，用户挑选的眼花缭乱。这个时候酒店业主就在想，怎么样才能让用户来我的酒店呢——对，我把酒店搞的足够奢华，足够逼格高，这样用户就会更想来我的酒店。

这样各种轻奢级的，高星级的酒店出现在了风景区。

由于酒店越来越贵，来这个风景区的用户越来越少。
终于有一天，一个年轻人问他周围的人为什么不去那个景区，得到的反馈是——酒店太贵了，我们只想有地方能住就行了。他想了一个方法，我去那边租借帐篷。

游戏玩家的诉求

1. 整个事情有参与感
2. 不那么无聊的度过时间
3. 社交或者社群

持续性创新导致用户的需求已经过饱和了，是时候该改变了。