← 返回全部文章

技术笔记

观察前端游戏化互动交互

技术/前端
文章目录

交互

前端基础交互:受限于浏览器软件和硬件环境,只支持局部固定的点击和滑动等基础动作。首要目标是内容展示,其次是交互体验,所以Web前端的交互体验通常交互策略简单,动效较少。

游戏交互:游戏交互的与前端交互的一个主要区别在于,游戏交互为游戏内容服务,交互体验通常是游戏体验的首要因素,因此在游戏的整体设计中,交互和游戏设计是强绑定的,通常会根据基础gameplay设计复杂的交互策略配合复杂的动效。因此游戏交互的技术和美术资产通常较重。

游戏化互动交互:随着内容的快速增长,内容需求在用户体验的比重越来越低,相对来说,交互的重要性提高,目的在于辅助优质内容在众多内容中脱颖而出,更多的展示给更多的用户。游戏化互动交互在于借鉴成熟的游戏交互策略,在泛Web场景内提供轻量化,快速启动并具有一定内容特征的交互体验辅助内容扩散。

观察

价值

游戏化互动交互的主要目的还是内容扩散,而非内容体验,因此对gameplay与交互的玩法设计要求相对宽松,但对内容X交互的融合设计要求较高。

内容x交互的融合设计简单来说,是根据内容体裁和目的,构建相应的gameplay和交互策略。

目标 组件 模版 独立case
gameplay抽象 高 中 无
交互策略复杂度 低 中 高
应用场景 广 中 少
扩展度 高 中 无
承载 编辑器 编辑器Xcode Code

根据设计目标可以简单分为三个层次,玩法组件、玩法模版和独立玩法case。

这三者的策略复杂度依次渐进,但抽象难度却是递减。最终收益主要根据应用场景和扩展度评估。

相比策略设计,抽象相对更难一点,因此思路上感觉优先通过设计较复杂的独立case的对策略效果进行验证,然后依次逐渐根据策略效果拆解抽象case的gameplay。而相对来说,独立case关注case的具体内容,模版关注目标场景,组件关注通用性。

技术

整体来说,游戏化互动交互处于Web前端与游戏研发的交叉领域,从技术建设来说,相对传统Web前端更重,但比游戏研发轻。

游戏化互动交互领域不仅需要传统的前端工程能力,还需要结合图形、渲染、动画以及软件工程和服务端工程统一建设。但目前Web场景对从基础物理引擎到上层编辑器组件扩展的全链路建设的要求不如游戏研发链路要求那么严格,因为具体特效效果优先级较低。

游戏化互动交互的技术链路还是比较长,从底层的基础引擎、编辑器/组件架构,到工程管理,美术资源管理,性能保障以及上层的应用逻辑与特效实现,需要长期的积累。

目前业界在这一块的建设感觉有两个思路:渲染驱动和玩法驱动。渲染驱动主要学习传统的游戏研发链路建设Web生态的全流程渲染管线,如蚂蚁的Oasis和Cocos团队;玩法驱动则是以玩法抽象为核心,跟随建设相关的辅助设施如基础引擎和编辑器扩展等能力,如淘系的Eva。

业界

蚂蚁 Oasis

蚂蚁Oasis

类Three.js的WebGL完整渲染管线封装,具有完整的引擎-资源-组件的架构体系,兼容支持2D、3D全场景,基于Web化编辑器静默打通美术资源管理和研发工作流,Monaco Editor支持类VS Code原生体验的云端编辑,支持组件脚本级“正反解”,整体架构对标Cocos,但更接近Web生态,Cocos生态更接近游戏研发。

淘系 eva

淘系 eva

基于PixiJS二次封装的轻量引擎包,支持基本的2D动画,可延伸至2.5D,基于ECS架构扩展性较高,性能监控和无障碍支持较好,Web友好,但局限于2D场景。

Cocos

自研跨端渲染框架GFX统一硬件渲染层,并暴露一定的兼容能力支持定制渲染管线,具有完整的图形API,兼容支持2D、3D全场景,支持基于Vue/React扩展 Cocos Creator,扩展性较高。

Cocos

微信小游戏

微信小游戏