cocos教育游戏化理解

内容游戏化也就是游戏教育互动课件开发，我理解的教育游戏化大体上分为两种类型，一种是录播课形式，视频加课件的形式由学生自主操作学习。一种是直播课的形式，采取由老师来把控整体流程。

这里说的游戏我更愿意称之为互动，如果按游戏轻重来分，有重度的rpg或者3d游戏，有轻量级的微信小游戏，我感觉再教育上的定义就是比轻量级还要轻的游戏。因为他面向的群体有两个，一个是十岁以下的学生，一个是家长，所以说如果过于复杂，对两者来说都不会十分友好。我们把每一个游戏都看成一个互动，互动跟随者教学场景而变化，大多表现形式都是视频+互动的形式，这里要分的话也有两种，一种是整个app包括课程都是由cocos来实现的，这种形式一般比较少见。现在市场上比较普及的是第二种方法就是app外壳是由端上实现，课件内容部分是打成web包的形式放上去，通过jsb来进行数据传输调用。这种形式对于视频播放这一块，两种，一种是由端上播放，一种是由cocos播放，用cocos的videoplayer来播放视频，用组件的形式，穿插来实现，这种的一般为录播课。对于cocos播放的好处是自身可控制，缺点是如放到课件中，视频资源占比大，再有就是cocos组件的videoplayer是最上层，也就是说，没有办法实现在视频上添加互动，播放视频只能是视频。如果由端上播放视频的话就可以实现在视频上添加互动，cocos层课件盖到端播放的视频上，只需要通过消息告诉端视频是否暂停或者播放，不过在之前会有ios不能自动播放视频的问题，需要做一下处理。

如果把一节课看成一个课件的话，这个课件就是由若干个互动组成，每个互动可以简单，可以复杂，但是都与整体联系起来，也就是整体会搭一个壳，然后互动会在壳里面进行运行，任何一个单独的互动都可以放到壳中实现与其他互动的配合。

这样只需要把控整体的外壳，然后每次去单独开发模块互动。在开发模块的时候要注重通用性，这样就可以实现复用。

从逻辑上来说，就是有一个做题的基类，基类实现了简单的展示，消除，初始化以及是否结束的一些功能，然后每一个互动去继承这个基类，然后可以根据需求来开发并重写

就个人开发互动来说，继承基类做题模块后只要，模块的加载和消除都不需要再去操心，只需要开发游戏逻辑就可以了，，一切通用性的功能和需求可以放到基类中，这样也可以避免重复开发

关于整体的开发流程，我是这样理解的，从容错率和效率的角度来讲，从产品评审到开发测试上线中间需要两次评审和最少三轮测试 第一次需求评审，是产品跟教研沟通评审互动本身和功能，然后由产品设计开发文档。第二次评审，技术美术和产品。产品讲解需求，美术和开发沟通需要什么样式的资源，分别评估各自开发或者资源给出的时间，确定开发周期。排期之后就是后续互动功能的开发，开发完之后第一版是给到产品和美术确认样式和整体流程，接收返回修改（大多是资源上或者是整体流程上的修改），修改完后第二版提供给测试，进行测试，主要针对以上内容和互动本身出现的bug。然后再次修复，至此一个互动的开发结束