对3.0编辑器开发失败的检讨

[tocque]

对3.0编辑器开发失败的检讨

在相关开发工作停滞接近三个月之后, 5月29号, 3.0编辑器正式宣告失败, 这意味着在编辑器上数百小时的工作报废, 应该算是mota-js相关开发里最大的失败项目了(笑), 因此在此我试图梳理一下, 3.0编辑器的整个开发历程, 分析编辑器开发失败的主要原因, 抢救一些作废的部件, 并且制定下一阶段的开发目标

3.0编辑器的源起

3.0编辑器最早的源流大约是在去年2月份, 在设法复刻精灵石, 废都物语等游戏时, 感受到现有编辑器难以满足需求, 尝试开发的新编辑器, 不过, 在8月之前, 整个编辑器都近似于一个空壳, 这一阶段中, 编辑器的api与现在有很大区别, 仅举一例

// 地图编辑器初始化函数
mapEditor.initialize = function() {
    this.loadMapData();
    $mapPanel.mapid = 0;
    $mapPanel.leftPanel = document.getElementsByClassName("mapLeft");
    // 侧边栏
    $mapPanel.sideBar = new navBar("mapSideList", this.switchLeftPanel.bind(this), true, 0);
    $mapPanel.mapExplorer = new mapExplorer();
    $mapPanel.mapEvents = new mapEvents();
    $mapPanel.mapProperty = new mapProperty();
    // 地图编辑器
    $mapPanel.mapTiles = new mapTiles("mapTiles");
    // 素材区
    $mapPanel.mapUnit = new mapUnit();
    if ($map.length > 0)
        this.switchMap(0);
};

在这一阶段, 对整个编辑器的结构并没有太详细的认识, 可以算是走一步看一步的阶段, 不过, 已经表现出尝试组件化开发的倾向了, 写出这段代码的时间点, 是我在神鸡建议下, 阅读rmmv代码之后, 因而有比较严重的OOP倾向

而在视图层的方面考虑, 编辑器大概的视图形式已经明确了, 整体窗口, 配色, 图标均来源于vscode, 对当时普遍反应的一些编辑器痛点, 如大地图编辑, 地图树, 做出了对应的解决

正式开工

大约在8月份的时候, 由于3.0相关开发被提上日程, 在展示了一个demo之后, 这个编辑器壳子受到了不小的反响, 因此, 我开始正式进行3.0编辑器的开发, 这一阶段里, 我对3.0编辑器的基本设想是, 在进行一定组件化的情况下, 按照新编辑器的界面实现2.x编辑器的全部功能, 然后作为3.0的编辑器使用, 由于2.x编辑器耦合度非常高, 在数次解耦失败之后, 选择抛弃既有代码, 完全重写

进入vue化阶段

vue化的想法来源是同期在做的软件工程大作业, 在大作业中尝试了vue全家桶之后, 我感觉到这种形式是一种设计水平非常高的组件化开发范式, 在这一阶段的实施过程中, 借助vue的设计形式, 组件化的程度进一步提高了, 具体来说, 在这一阶段, 从编辑器整体的视图层中拆分出了一个组件库, 它包含以下内容:

• input // 输入相关的组件
  • Button
  • Checkbox
  • Search
  • Switch
  • Table
• layout // 布局相关的组件
  • Board
  • Container
  • FormItem
  • Window // 类似uievent的弹出层
• notify // 右下角消息弹窗
• others
  • Contentmenu
  • Icon
  • ImagePreviewer
  • ProgressBit
• shortcut // 快捷键管理器
• canvas // 画布操作库

这个库是仿照市面上主要的前端组件库建立的, 当然也根据编辑器的需求增删了一些部分(例如canvas操作库)

在搭建了一整层组件库, 以及配置了大量工具函数之后, 开发的体验变得非常顺畅, 这一轮开发从12月开始, 突破了很多前几次重构和开发尝试难以解决的问题, 完工的曙光似乎出现在地平线上了(并不)

将可配置化作为目标

在这种情况下, 我开始考虑一个新的想法: 可配置, 说是新想法, 也不尽然, 利用插件修改编辑器的做法很早就实践过, 在这里我预想的一个场景是, 对于某一个类型的塔(例如境界塔), 可以通过载入一个插件, 或者载入一系列依赖插件, 构造出专有的编辑环境, 譬如对于境界塔, 在安装插件之后, 会在手册中显示境界, 同时在编辑器中提供对应的修改方法, 为了这个目标, 在一些地方花费了很大的代价, 例如给blockly, monaco, 地图编辑器设计了一系列扩展点, 以及按配置加载面板, 其中地图编辑器从地图面板的拆分被证明是完全失败的设计, 使得整个地图面板的可维护性变得非常差, 以至于一些相关编辑功能持续难产

最终成型的整体结构

在大概2月初的时候, 编辑器的整个结构基本固定了

具体来说, 编辑器按以下结构划分:

• 服务层
  编辑器对样板的任何修改都在此处进行, 例如, 增删楼层, 调整楼层顺序
  这一层向中间层暴露单一职责的api, 如, 传入一个楼层的属性以新增一个楼层, 这一层同时维护游戏实例的数据和文件, 例如, 当调用修改floorIds的接口时, 会同时写入文件以及修改core.floorIds
• 中间层
  这一层基于状态管理工具vuex, 内部保存了一份可响应的游戏数据, 以及相关的修改方法, 视图层从此处读取游戏数据, 并调取修改接口以修改数据, 在修改后, 会隐式更新视图层数据, 形成单向流动, 相比服务层的api, 这一层的封装更好, 譬如, 在这一层的新增楼层方法会调用修改data.js和增加楼层文件两个方法
• 视图层

  • 面板

  • 组件库
    包括上述所说的全部组件, 编辑器的基本元素均籍由此构建, 以满足, 在可自配置插件的情况下维护皮肤系统的需求

  • 编辑工具
    包括blockly monaco 表格 地图编辑器, 这些工具被包裹在一个独立的vue组件内, 对外只暴露少数api

问题出现

第一个被长期无视, 但是客观存在的问题是手机编辑器, 尽管长期以来, 群内对这个问题都维持着"3.0不提供手机编辑器"这一观点, 但是手机造塔是样板的固有优势, 在君浪师傅通过修改2.x编辑器达到编辑3.0的目的达成之后, 实际上已经不可避免在维护一个供3.0使用的2.x编辑器的需求了, 在这种情况下, 为了一些可有可无的fancy特性, 维护一个结构完全不同的3.0编辑器, 似乎已经没有价值了

宣告失败

大概在4月左右, 编辑器就陷入了缺乏进展的阶段了, 在无法克服上述两个问题的前提下, 3.0编辑器被抛弃是完全可预期的

下一阶段目标

尝试探索桌面编辑器相对全平台编辑器的优势，进行2.x编辑器在桌面端的渐进增强，或者找到3.0编辑器的立足点