及仓库、图鉴的实现

模块功能

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

模块实现

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

很多人都对上面这张图记忆深刻，那么，我们的问题是：
怎么才能实现构建这张图上的武器实体呢？也就是提供武器能够从【破损小木棍】一步一步升级到【+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. 在每次迭代之后，投入更多成本在目标确定上，更仔细的根据确定的目标评估周期和风险，能拆就拆。

实际在更新游戏内容之后，可能预期出现三种情况：
1. 反响热烈；
2. 反响平平；
3. 没有声音。

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

设计初始的目的没有达到

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

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

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

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

简单问题切勿复杂化

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

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

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

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

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

顺势而为

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

臭鼬工厂的核心理念问题：
1. 有没有价值？
2. 客户会不会认为有价值？
3. 客户如果有钱会不会买单？

创意产品分析矩阵 (Creative Project Analysis Matrix)

大类	字段	说明
新颖性	—	成果的新意。包括过程、技术、材料、方案等相较于世界关于该领域内外的成果，以及对未来的影响。
—	原创性	同类成果中少见的
—	震撼性	评估开始前就能令人震惊的
—	萌芽性	可引发高度原创性的结果的（种子）
解决度	—	对于问题情况所提出的要求，该成果的满足程度
—	价值	通过考察，因为满足了要求，具备价值
—	逻辑	符合某一学科内的定律
—	用途	在其领域内公认具备实际应用的
加工和整合度	—	成果由不同要素整合后的连贯程度
—	组织	有组织性
—	优美（优雅）	准确到位
—	复杂	各种要素综合在一个或者多个层级上
—	表达	表达清晰，易于理解
—	加工	仔细斟酌和反复加工

核心管理要素

1. 在技术上能够胜任，可以做出权威领导的领导者。
2. 一个有具有高度工作激情的员工主导的工作环境。

最近从团队成员口中听到一个有意思的话：
“你给我的排期都是满的，我没时间去做其他事情了。”（这里面的你指代的是PO）

这句话非常有意思，也非常有典型性。
首先翻译一下这句话：
“你给了我很多我觉得没有价值的事情，没有时间去做更有价值的事情。”

根据实际的语句，我们分析出来以下这些问题：

1. 你给了我很多事情（但是PO是关于价值的判断）

这里实际上默认接受的一种情况是：你给了我。
这在很多团队中都是非常非常常见的。但是实际PO的核心是确认价值，这也是我觉得敏捷最为核心的地方：专业专项，动态平衡。
而“你给了我”这个事情实际上是违背整个逻辑的，所以很多团队在敏捷的实际操作上是降维的

2. 在团队内价值的一致性没有得到保证

在这句话里面暴露出来的问题，就是实际情况下，这个敏捷团队中的价值判断是没有达成一致性的。
那我们来看看在敏捷中通过哪些方式来保证一致性：

途径	说明
私下讨论	在提出故事点之前的团队内自组织讨论
plan meeting	确定故事点达成一致时
做的过程中	在实际制作过程中（站会时

实际情况下会在这些场合进行多重保证，但是显然，这部分是有问题的。

3. 其他事情（是什么？）

在追问的实际过程中，会问到：那什么是其他事情呢？
最多的可能是：我想把美术搞搞好，我想把测试搞搞好之类的。
那这里也是一个很基础的问题-沟通专业性。实际上更多的希望团队基于INVEST原则来进行沟通，至少在具体事务层面有这样的沟通理解。

4. 没有时间

敏捷团队的核心是在于：内容可变，资源和时间固定。
所以没有时间是观念内的一个巨大误区。
对于一般团队向敏捷团队转型的过程，没有时间或者deadline等等这些问题是需要特别小心处理的。因为一个不妥当，就会敏捷方式就会降维成一个更加混乱的瀑布方式。

5. 并未最大化价值

这句话实际暴露出来的一个底层问题是：团队并没有保证最大化价值，也就是沟通存在问题。
显然团队成员和PO之间，关于价值大小是没有达成一致，或者都是有一定的误解的。
在这种情况下，提高沟通效率和沟通品质是至关重要的。

最后的问题就是关于翻译的问题，即把其他事情翻译成有价值的事情。

“我是个做UI的，所以你说要体现产品价值，那在我的理解上就是把UI做做好吧。”

这是一个典型的自我降维逻辑，在很多的确定性项目中，这样执行会使得事情变得简单，成员会对相对路径更加清晰。
但是这种自我降维最大的问题，不是发生在团队和PO之间，恰恰发生在团队成员之间。

比如：有人降维成把UI做好，有人降维成把测试做好，那么在每个人都自我降维的方式中，整个团队的沟通就瘫痪了，成员之间没有一个统一的对于产品本身的衡量标准。

MVP: minimum viable product
A concept from Lean Startup that stresses the impact of learning in new product development.
A product with just enough features to satisfy early customers, and to provide feedback for future product development.

MMF: minimum marketable feature
A small, self-contained feature that can be developed quickly and that delivers significant value to the user.

Value Stream Mapping(VSM)

是用来分析信息流、人员和交付产品或服务给客户所需资源的技术。

• 是基于精益生产的
• 有一系列的步骤、增值和非增值活动组成的
• 是识别和消除过程浪费、提高效率、吞吐量和效果的核心工具。

价值流图的步骤

1. 识别过程的开始和结束点
2. 识别高层级步骤、库存和序列（较高维度）
3. 识别支持群体和替代流
4. 分类增值和非增值活动
   过程循环效率 = 增值时间之和 / (增值时间之和 + 非增值时间)
5. 消除和减少非增值步骤，优化过程。