游戏化答题产品的小总结

chayemo1812

前言

因为各种原因，进了一家编程教育公司，尝试做了一次教育游戏（公司的定位更倾向于游戏化教育产品）。
虽然因为种种原因，项目现在暂停了。趁这段空闲时间，对游戏和教育的结合，做一次小总结和反思。

游戏概况

平台：网页端
引擎：cocos creator
游戏类型：以撒式roguelike地牢探险
核心玩法：答题
目标用户：6~16岁的青少年
研发周期：4个月
画风：轻科幻

一、需要对用户年龄做更进一步的细分

游戏的demo版本出来之后，对用户做了几次调研。目标年龄段的孩子们的成长是非常迅速的。
很明显地发现，用户年龄在11岁以上时，对游戏的操作玩法几乎是无障碍的。但是对于11岁以下的用户，基本上都会出现不同程度的理解和操作上的障碍。7岁以下几乎无法理解（好巧不巧的是，我们的用户以7~9岁的偏多，针对年纪小的用户还是需要做更简单一点的玩法），同时也顺便带出下面的一点，针对年龄层来控制不同的游戏复杂度

二、对游戏复杂度的控制

设置的属性有：血量、蓝量
功能性的有：答题（答对后产生金币、答错扣除血量）、技能（在答题中，提供解题思路或完整的题目解析，需要消耗一定蓝量）、道具（恢复血量、蓝量、在走地图中提供辅助帮助）、buff（对属性消耗的增减和减免）、其他（消耗金币，产生道具、恢复玩家属性等）

其中buff是在制作过程中现加的。因为以答题为主，并没有更多的空间可以增加深度，就添加了buff这一项。但是并没有预估到儿童的理解能力，对于直接产生效果的还比较能理解，但是需要二级转换的，就处理不了了。
例如：答错扣血，这个普遍都能理解
答对得金币→金币买道具→道具回血蓝，逻辑链长到这种程度，孩子们就开始晕了（这里容我吐槽一下，为什么要让这么小的孩子学编程？？？）

三、儿童的思维模式与成人不同

一个很有趣的现象是，我们在调研的时候发现，几乎所有的孩子，都不会用技能（提供解题帮助）。一开始以为是没有注意到，在加强了这部分的指引之后，依旧没什么改善。人工干预了一下，发现孩子们并不是不知道这里可以使用，而是一开始就不愿意使用。原因基本分为两种：1.认为该行为是作弊。2.损失厌恶

1.从教学的角度来讲，查看答案解析，也是学习的一个比较重要的环节。
在经过充分思考后，如何能引导孩子正确看待看答案的行为，也是教育游戏中需要思考的一个点。是否能够通过设置一个比较具有权威的导师形象，对孩子下达看答案的许可，来消除这样的心理屏障呢？

2.对蓝量的损失厌恶，并不是出于对下一个场景需要使用时会不足的担心，而是单纯地，就是不想有损失。
或许UI换一个方式可以改善一下这个状况？
当前的UI，可以很明显的看到已有量和损失量。

但是这种数字型，无法统计损失的，孩子们在使用起来就相对来说没有心理负担

四、难度的控制

对于答题的游戏化产品来说，这一点似乎有点脱离游戏策划的控制了。
难度更多的是取决于教研所给出的题目难度。
但是我们可以做的是，一个合适的匹配机制。
编程类教育在未纳入正式的教学体系之前，无法通过年级和课本来匹配用户，但是我们依然可以根据自己的出题体系来对玩家进行知识测验。
匹配是非常重要的一部分。太过简单会变得很无聊，太过困难会让人焦躁。

五、家长的诉求

对于游戏完全不接受的家长就不在讨论范围内了。
即便是对游戏接受度比较高的家长，对孩子、对产品的使用，也是有一些诉求的。

游戏时长的限制

重度游戏偏重沉浸式，占用较长的用户时间，休闲游戏则会利用用户的碎片化时间，每一局游戏都是短平快。
而家长们对于孩子的使用时间，一般是有严格的限制的。
单次使用时长一般为半个小时至两个小时之间。年纪小的孩子（10岁以下，一般不会超过一个小时，半个小时居多）
使用频率从一天一次到一周一次不等
而各位一定也曾经有过家长喊吃饭，需要立马放下游戏的情况吧（对于家长不理解的游戏为什么不能暂停，到现在也依然存在）
因此在游戏设计时，需要注重的是，最好是单局游戏，并且可以随时暂停（笑），一个良好的保存机制是非常重要的。

学习的反馈

对于家长来说，在游戏中获得的分数高低，击杀多少怪物，是没有一个实际概念的（毕竟玩游戏的不是他们）。
家长们所需要的，是一个更明确的，能掌握孩子学习状况的反馈。
例如：本关卡学习到的知识点是什么、知识点的掌握程度、答题数量、答题正确率等。

——————————————————————————————————————————————

放在后面的碎碎念

这几个月下来，最大的感触还是游戏和产品的不同。
产品，即便是游戏化产品，更多的更看重使用场景。不仅是用户的使用场景，还有来自教学要求的使用场景。
本来这种roguelike是想做无尽模式（或者单词城堡那种极长的），但是最后由于产品方和教学方的需求，改完了关卡式
很多设计中可能有的宽度，也因为关卡式的原因，没办法继续做下去（也有工期的原因）
roguelike在这样的场景下，似乎不是很适用，唯一省掉的，就是策划去设计关卡。但是给程序实现带来了比较大的复杂度。在产品初期，关卡数量较少的情况下，看起来似乎有点得不偿失。

另外还有一个问题一直没有解决的办法：当知识体系不稳定的时候，如何能随时更改关卡。
嘛 不过我们最终没有上线，所以一直没有处理这个问题。

不知道有没有大佬处理过类似的问题？