关于运行时，编辑器和3.0的个人意见

[ckcz123]

当前样板已发展到2.7，和一年前不同，我对运行时、编辑器和3.0的看法有所改变，具体如下：

运行时定义： 仅在网站游戏时加载的内容，包括libs/, project, index.html, main.js, styles.css等。
编辑器定义： 制作运行时的可视化造塔工具。

1. 运行时应当只留一套。之后想加什么功能，比如大地图、sprite化等，也应该在现有运行时上改。继续基于全新架构尝试制作，可以尝试，但不会去期望其可用性。
2. 运行时应当是独立的可以脱离编辑器运行的，甚至是允许直接改文件造塔的(即兼容1.x模式)。
3. 在运行时上构建编辑器，目的是为了更方便造塔。编辑器应当兼容运行时并不应该大幅修改运行时本身的架构。现有的2.x编辑器就是编辑器的一个实现的例子。
4. 可以基于现在的运行时开发一套新的编辑器，比如叫3.0编辑器。里面使用全新的界面，全新的造塔和绘制地图方式，等等，与现有编辑器并行。
5. 现有的2.x编辑器由我持续维护，原生ES5实现，支持手机；如果实现新的编辑器可以任意天马行空，可以不支持手机造塔，可以使用任意的新技术。但是运行时必须是同一套，保证兼容性。
6. 在编辑器的逐步开发过程中，反向推进运行时开发。

关于仅维护一套运行时的理由：

1. 运行时是样板的核心。样板可以没有编辑器（回归1.x造塔模式），但是不能没有运行时。
2. 当前的运行时发展到2.7，已经成了一套很自洽的系统，包括事件流，操作，录像，等等，非常自洽。同时基于该运行时才能支持服务器端的人数统计、成绩上传、录像检测系统、存档同步等诸多功能。
3. 我认为，脱离当前运行时，全新构建一套新的运行时体系是一个值得尝试，但是不会予以期待的行为。涉及新的运行时可能存在大量问题，例如事件系统的可兼容性、录像回调链的可靠性等等，都是当前运行时踩了大量坑而最终予以完善的内容。
4. 事实上，随着样板不断发展，运行时也在不断不断的进行完善。2.7已经解决了大量历史遗留问题，2.7.1打算重构大地图的实现，等等，之后也许就会以原生的方式来实现Sprite化或其他功能。

关于两套编辑器并行的理由：

1. 当前编辑器是有局限性的，必须承认这一点。事实上编辑器从v2.0发展到现在，已经基本定型了，之后再怎么改也都是增加新功能，不会从根本上去动编辑器的架构。
2. 现有的编辑器是必须兼容手机造塔的，这是根本。但这也限制了编辑器的可拓展性。
3. 所以，我是推荐脱离当前编辑器架构去做全新的一套编辑器的，包括仿vscode的界面、全大地图绘制，更简便的注册系统（包括素材注册和图块注册）等等；其实，pre-alpha如果是基于v2.x的运行时上的那就好了。
4. 在开发编辑器时，遇到了和运行时的不兼容性问题，反而可以反向推动运行时的开发。

[tocque]

我个人目前来说， 是两者都反对的（即：我支持3.0运行时的开发，而且不支持2.x并行开发两套编辑器），我在这里陈述几点我个人的论调

第一点是，无论如何划分，假设在mota-js的社区里出现了两套编辑器，它们一定会处于竞争状态，就好像h5和rm在进行竞争一样，甚至更加激烈，因为双方甚至围绕同样的受众，这是我从3.0编辑器开发后期就开始担忧的，为此，3.0编辑器进行桌面化改造，设计各种（看起来非常不实在）的大饼，包括搞可扩展性设计，是从各个方面试图与2.x编辑器拉开产品定位上的区分的，不过，到最后仍然没能展现出，和2.x编辑器相比的明显区分点，这使我意识到：mota-js的面向对象是不会编程的作者，瞄准的游戏品类是一个极度小众的硬核游戏，作为编辑器的功能，甚至也是和一个游戏运行时相绑定的，在这种状况下我不认为，会存在

使用全新的界面，全新的造塔和绘制地图方式

这种东西，2.x很可能是仅有一个最佳实践的，所以，只要一个编辑器就足够了

紧接着说说我为什么希望有一个3.0存在，首先是，作为一个编辑器开发者（现在可能称不上了），我肯定会选择更需要编辑器的运行时，给3.0做编辑器毫无疑问比给2.x做编辑器有价值（因为3.0目前还没有自己的编辑器），没有什么比一个新的运行时更能带来区分和差异性了，当然， 为了保证这个运行时的充分差异性，为3.0设计的编辑器仍然需要具备手机造塔和在线打开编辑器的功能， 在这个意义上，现有的3.0编辑器已经走向完全相反的歧路了，因此放弃也是必然的

当然，这只是就“以新运行时和新编辑器之一作为开发目标”的情形进行的讨论中，我个人的倾向意见， 实际上我认为，在mota-js周边，还有很多可以进行的开发点， 在这个尺度上，我觉得开发者没必要着眼于新运行时和新编辑器中的任何一个

[ckcz123]

1. 首先我并不反对3.0开发，我的原话是“可以尝试，但不期待”，即能有更好，实在没有也不会影响什么。

我不看好的原因是，运行时和编辑器不同，从各个意义上来说都是一个非常精密的系统（包括且不仅限于事件流、录像回调链等等）；推翻再重新搞一套新的也许会导致把坑全踩一遍。
另一个是用于操作性问题。网站绝大多数用户都是玩塔的，尤其是手机玩塔，对很多东西都容忍度更低；造塔者其实没多少，他们对于变化的容忍度更高，所以对编辑器动刀子无所谓，但是对运行时动刀子需要谨慎。

与之替代的，我更建议直接当前v2.x运行时逐步推进，包括大地图、Sprite化等的开发。终究是会找到方法解决的，你看当前发展到v2.7解决了多少问题。

2. 你所担心的这种竞争本身毫无意义，因为它们的“产出”是同一个东西，同一套运行时。换句话说，玩家在网站上玩的时候，是无法分辨到底是哪个编辑器做的，何谈竞争之说？因为运行时和产出一致，造塔者随意在两个编辑器间切换也毫无问题，更多的选择，完全的兼容性，何谈矛盾来源？

3. "2.x很可能是仅有一个最佳实践的，所以，只要一个编辑器就足够了" 未必。事实上，对作者来说，样板的本质仅在于project文件夹；换句话说，只要产出是一致的，不管你使用v2.x的当前编辑器，新编辑器，还是VSCode，甚至是写个python编辑器，都是等价的。

我仍然认为，编辑器和运行时不应该嵌入太深，不能出现某个插件写崩了导致整个编辑器都打不开的情况（这也是v2.x编辑器遗憾的地方之一）。难道代码写的有问题就导致打不开VSCode了？最佳情况下，编辑器甚至完全都不应该读libs文件夹（最坏情况也是以<iframe>内置引入），即使是脚本编辑和插件编写也应该是只读而不执行的。

所以我很遗憾，如果之前的pre-alpha是基于v2.x的运行时，其产出是能被当前运行时所接受的，那现在也许beta都出来了。

[ckcz123]

补充一个很简单的例子：

只要用户随便写错了什么东西，哪怕是打错了怪物ID：

保存再刷新，编辑器就崩了，此时就必须开文件处理，别无他法。

这很合理么？非常不合理。你见过哪个程序的源代码写错了导致整个VSCode打不开的？这也是v2.x编辑器当前最大的问题和遗憾，没有之一。这也是我为什么想要一个新的，独立的，不依赖于运行时的，不执行脚本编辑和插件编写的编辑器。

事实上，编辑器的产出目的只有一个，project目录；这些东西真的都是JSON格式的纯数据（唯一区别可能就是getSpecials）；所以完整执行一遍全部的脚本和插件本身就是非常非常不合理的行为；哪怕开VSCode手动编写可能都不会出现这种情况。

我想说的，与相对已经完善的运行时不同，当前编辑器确实不是最优解，问题很大，限制很多。但是它已经定型了，没办法修改了，所以最佳的实践应当是跳出现在的编辑器框架，在考虑如何保证project兼容性的情况下，弄一套全新的出来。

[tocque]

我觉得，有关新编辑器这个需求，其实可以分成两种情况讨论：

1. 是否有必要做两版并行的编辑器

只要产出是一致的，不管你使用v2.x的当前编辑器，新编辑器，还是VSCode，甚至是写个python编辑器，都是等价的。

我觉得艾神可能没有理解我的意思，我这么说吧， 艾神相不相信，在造h5魔塔这件事上， 存在一个银弹，每个需要做的操作，都存在一个理想的解决方案

仿vscode的界面、全大地图绘制，更简便的注册系统（包括素材注册和图块注册）

这很合理么？非常不合理。你见过哪个程序的源代码写错了导致整个VSCode打不开的？这也是v2.x编辑器当前最大的问题和遗憾，没有之一。这也是我为什么想要一个新的，独立的，不依赖于运行时的，不执行脚本编辑和插件编写的编辑器。

艾神提到对新编辑器的这些期许，在这其中，我看不到编辑器功能上存在的取舍，所有的需求都是，有比无好，一种实现强于另一种实现，在这种情形下，艾神所指的“另做一套编辑器/运行时”本质上是用重造的方法来实现2.x无法做到的功能，也就是，不存在并行编辑器的意义

2. 是否有必要，通过全部重写的方式，制作一个更好的编辑器

对这个问题，我现在持反对性意见

我本人曾经是这个问题的实践者，但是在3.0编辑器的漫长开发中我转变想法了，在我的实际开发体验中，我感觉到 “全部重写”这个方案，可行性没有想象的那么大，我提倡，就2.x编辑器存在的某个非常巨大的具体问题，设计长期的渐进式解决方案，就像在 #475 中我在征求意见的这种一样

[zhaouv]

这很合理么？非常不合理。你见过哪个程序的源代码写错了导致整个VSCode打不开的？这也是v2.x编辑器当前最大的问题和遗憾，没有之一。这也是我为什么想要一个新的，独立的，不依赖于运行时的，不执行脚本编辑和插件编写的编辑器。

2.x编辑器引入core本质是复用数据加载和画图, 避免每个改动要在core和editor实现两次. 个人感觉改成容错的引入就足够了, 即使画不出来图或加载不出正确的数据也能继续编辑

正如之前一直感觉问题很严重的素材, 我相信在推拽图片注册/一键注册+一键删除未改名的素材之类的功能全部实现后也是能很好解决的. 这个问题也是.