【MZ评测活动】HTML5开发人员角度的鉴赏与吐槽

小秋橙

背景相关：Steam平台RMVA Lite下载者、MV购买者、MZ首发购买者，类似RM的网格地图游戏引擎H5魔塔样板开发人员，RMXP魔塔外行玩家，RMVA黄油轻度玩家（OneOne1三部曲什么的），对Ruby和C#一窍不通，对Java和js较为熟练，日常使用MacOS操作系统。
看了看其他几篇评测，有些大佬是从XP甚至2K/03开始讲的，那我也稍微提两嘴XP，首先XP的安装包是真的小，而且它对tileset和autotile的处理也很棒（autotile为4行3列并且可以任意多个，tileset为8列但不限制行数，而VX开始A~E组全部加起来也只有几千个块了），自带的大量characters也都是1.5倍格子高度。
然后，Steam平台上从MV开始才有汉化，从MZ开始才有中文的帮助文档和简易教程，再加上H5架构比RGSS好的不是一点半点（点击操作、跨平台、在线玩、浏览器调试、数据库为json格式），因此建议没有Ruby和C#经验的小伙伴想入坑可以直接从这两个里选了。

先说一下MZ比起MV的改进：
1. 升级了pixi和nwjs版本（MZ建议能通过Steam选择beta用1.6.0就别用1.6.1因为后者又把nwjs降级了，控制台没有中文了），加入了中文的F1帮助文档和简易教程，XP图层功能回归（早该有了好不好，明明MV的地图json文件里可以看到有四层的），移动路线预览，运行时切换地图自动存档（虽然真的很依赖自动存档的游戏肯定不会只给一个位置），触屏按钮（多少人不知道双指点击是取消的），通过8位数的ID而不是标题来区分作品（浏览器localStorage很需要这个），捏脸器强化（不太清楚，没用过）。
2. 插件指令增强，再也不用像MV一样写那种【一行内用空格分隔的几个单词】了，写那种东西还不如直接写函数调用。当然对插件作者来说jsdoc可能会写的比较痛苦，而且也没个教程教怎么写那东西……
3. TPB战斗，作为魔塔/解谜游戏作者我其实不关心RM的战斗系统（真想做回合制战斗也肯定要做成轨迹系列那种小型战棋而不是只能站桩对打）不过还是说一下，RGSS的传统战斗最大的弊端就是【角色的速度只能影响一回合内的出手顺序而不能随着时间的推移让出手总次数拉开差距，并且很容易出现目标丢失后转移的问题】，然而我不知道为什么MZ要同时提供【我方某个角色时间条读满后不暂停计时】的所谓【全即时制】，而且Steam平台上给的两个范例也都是这种，Wolf's Gang和Winds Rhapsody，真让人火大，只好直接打开System.json改成【暂停等待决策】。全即时制会导致【使用技能/道具】操作变得很费时间，对生肉来说尤为严重，人家最终幻想用全即时制好歹是因为有个自动决策按钮或者只需要手动操作一个角色，你MZ无脑照搬那只能呵呵了。另外时间条这个东西我可能还是更习惯大宇双剑的【大家在同一个条上，起点相同速度不同】或者轨迹系列的【大家在同一个条上显示倒计时，速度相同但不同角色/类型的行动完毕后重置的倒计时初始值不同（CTB）】。
4. Effekseer粒子动画，说起来RM官方组织过一个动画制作比赛然而因为参赛作品过少最后全员获奖了233，不过这也充分说明这种第三方的制作工具比较容易劝退（尤其是缺乏汉化的情况下），好在MZ也兼容MV的帧动画。
5. 其他被官方提到但我比较无感的：全角数字修正（只有日本人会用到吧），变量操作【上一个】（可能是我创造力不足吧），技能与道具效果的【目标范围与多个公共事件】，角色和装备特性的【普攻技能】，其他【游戏表现形式的强化】等。
6. 【系统2】多了很多进阶设置，比如画面与UI宽高（改成1200*720以后虽然舒服了一点但是发现对话框等还是只能四行，很绝望）、屏幕比例变大（其实有了F3自适应以后这个不太需要了，而且这个只能填正整数就很屑啊）、图块大小变小。虽然字号可以一起改小但你特么UI还是以前那么大啊，总尺寸真低于816*624只会更挤。另外吐槽一下为什么只给了四种大小而不能自己输入其他值尤其是更大的值，目前更大的值会导致编辑器里tileset显示异常，因此运行时需要从另一个文件夹加载。而且源代码里明明width和height是两个函数也就是说可以支持长方形图块，但为什么这里的四种都是正方形。
7. 音频兼容性增强，终于不用再像MV一样准备ogg和m4a两种格式了（Safari原生不支持ogg需要借助MZ的vorbis decoder），但是果然还是觉得mp3更好。

再说一下两者共同的缺点或者【MZ改进的不够好的地方】：
1. MZ编辑器比起MV不支持Linux了，虽然我是Mac用户不过还是有点不满意。另外MV有一些捆绑小工具居然只能在Shift-JIS系统运行（详见此贴），不知道MZ还有没有这种低级错误。
2. 库代码的EcmaScript版本升级了但没完全升级（基本只是把var改成了let/const），没有使用class而是还在到处prototype，没有??和?.而是还在到处拿||当??用（比如0表示朝向不变的屑），没有充分使用箭头函数、Promise、async/await等，甚至xhr都特么一个个现写（你不是都有fetch了么，或者至少用jQuery的ajax啊），部分工具函数直接添加到了Number/String/Array的原型上容易让初学者以为是浏览器自带的（clone、contains、equals、remove、Math.randomInt、clamp、mod、padZero、format）。
3. 音频功能还是不够完善，我们知道声效（SE）和其他三个的区别就是【自我叠加】需求（一遍没放完就开始另一遍）因此在H5中最简单的实现也要借助AudioContext，而其他三个不需要自我叠加因此如果不需要用到双声道的话完全可以直接用audio元素，这样就可以【支持更多格式、互相任意叠加、任意控制进度、只变速不变调、变速或变调倍率任意精确】（RM系列的pitch不能只变速不变调，而且范围0.5到1.5还必须精确到0.1就很奇怪，没学过十二平均律么）。
4. 数据库备注以及插件全局参数的类型限制太死，数据库备注的格式是<key:value>但value只支持字符串（尤其是地图事件的备注所有页共用一个还只有那么短一点位置）。尽管可以用Number.isFinite(+value)或者Number.isSafeInteger(+value)来强制识别数字或整数，但更复杂的类型（哪怕true、false、null、undefined、NaN、数组和对象）就麻烦了。插件全局参数好像也都是字符串（尽管在编辑器里可以借助jsdoc来限制范围比如正整数或boolean），即使借助官方插件PluginCommonBase.js也没有太大改善。
5. tileset的属性压缩太狠了（详见此贴），8192个图块中每个图块的所有属性竟然仅靠一个0~32767的整数来表示，而且留给作者能自定义的竟然只有3bits，这不能忍。那个四方向通行是同时控制出入的，做不了【禁止回头】之类的效果（详见此贴）……
6. autotile和载具系统的特性不明，XP的autotile没什么复杂的，而且还多一条【第一行第二列表示特殊相邻关系】，但VX开始的autotile就越来越奇怪了，我都不敢用了。载具系统好像也没在本论坛看到什么人用过，或许这种复杂的东西就不能指望在没有详细文档的情况下开箱即用吧……
7. 图块与事件之间的遮挡关系不明，按理说有了四图层以后完全可以规定【低两层被主角遮挡，高两层遮挡主角】，而不需要再在数据库里指定某个图块的通行性为【★】（凭啥遮挡效果要和通行性绑定啊），另外【以B~E组图块为行走图的事件】也是一个平添理解难度的东西，既然是事件了就应该不管用什么行走图都有着同样的性质（除了没有朝向和帧动画）。
8. 技能/道具缺乏详细的使用条件（H5魔塔样板没有通用的技能系统，但道具的使用条件是直接用一个IIFE来写的，装备的话更麻烦一点因为要考虑穿上以后条件不再满足要不要自动脱掉），道具还好可以先斩后奏（效果写成公共事件并且在里面另行判定是否返还，但公共事件的缺点是会关闭菜单），技能就没办法了。另外我能理解作为RPG引擎为技能和道具设定了【先选择目标，并且战斗中用的话会消耗回合数】这回事，但是还是觉得不对劲。
9. 装备的穿戴条件（确切地说是整个【特性】系统traits）过于散乱，首先特性这东西分散在了角色、职业、装备、敌人、状态这五部分中，其次能力值又分为8种基础值、几种追加值xparam（加法叠加）、几种特殊值sparam（乘法叠加），但是文档里都缺乏详细的说明……
10. 动画系统在战斗外的表现不是很好（可能是默认的缩放率太大了，而且又只能指定在某个事件处而不是某个坐标），实际效果比气泡图标更出戏了，当然我没试过气泡图标那张图片的行数有没有上限，就算没有，因为不能自己取名字也会比较不方便。
11. 事件指令【旋转图片】的参数很奇怪，按理说应该是旋转中心、角度值、用时，但它给的只有一个速度，那就不好控制停止旋转以后的朝向了。
12. 事件中脚本以及插件指令不能像自带的事件指令一样返回false表示不进入下一条指令，从而导致异步处理难写了很多（比如下面这个【数字输入处理】的例子）。也没个全面一点的文档好好讲讲interpreter这东西到底是怎么运作的？
13. 事件指令的函数commandXxx明明接收的是params数组作为形参，但编辑器里却不能为这个数组追加新项或者扩展现有项的范围。举个例子，多少人想要26个独立开关甚至独立变量啊。比如我曾经将【数字输入处理】的位数和范围进行了扩展，最多不止8位并且每一位的范围也不再限制0~9，然而这样就只能手动调用command103了，也就没法让它那个return false;发挥该有的作用了。
14. 开关操作不够全面，开关你都可以【设为ON或OFF】了为什么不再来个【反转】呢，或者像变量一样提供【=、^=、&&=、&&=!、||=、||=!这六种二元运算】，当然最好是能像变量一样用脚本赋值。
15. 变量操作不够全面，在游戏制作这个领域其实除了【=、+=、-=、*=、/=、%=】以外，还有一种很常用的二元赋值运算就是单向clamp（if(a<b)a=b;和if(a>b)a=b;）应该被提供。
16. 流程控制指令不够全面（其他评测中有人吐槽过的1.6.0虽然新增了折叠功能却不能记忆折叠状态就不说了），循环应该以while和do-while形式提供，if应该在六种比较运算之外再提供四种逻辑运算（且、或、非、异或，如果有难度的话应该默认在脚本内用v[n]、s[n]、ss[n]来表示n号变量/开关/独立开关），目前if指令中的【按键】意义不明，按理说应该是【阻塞直至玩家按下/抬起某个键或点击某个区域，解除阻塞时将所按键的keycode或所点击的像素坐标代入指定变量】才对。
17. 其他事件指令的参数范围不够全面（尤其是异步事件结合上面的第13点更为致命），比如很关键的【场所移动】指令居然不能用脚本或变量指定朝向和淡出颜色？
18. （重要）事件页的【出现条件】自由度太低太低了！只能以【至多两个开关为ON、某个变量大于等于某个常数、某个独立开关为ON、持有某物品、某角色在队伍中】这些条件取交集得到，根本不够用嘛，至少也得允许用脚本写对不对。这个问题在另一篇评测中有人回答是因为requestRefresh只会在【开关/变量/独立开关/物品/队员】变化时被触发，因此如果作者写的是其他条件可能会刷新不及时，但我觉得那也不能因噎废食，只要告诉作者这个问题让他们自己在适当时机requestRefresh或者在出现条件中只写上述五种条件就行。
19. 事件页的【优先级】性质不明，和图块一样犯了【通行性和遮挡关系绑定】的错误。实际上按照H5魔塔样板的规则，【能否从某方向进入本格子】和【本格子是否可通行】是两个概念，前者比如说你跟一个npc虽然坐标相邻但一个在悬崖上一个在悬崖下根本触发不了，后者则是【撞击触发还是踩踏触发】的区别。结合第7点所说的【低两层被主角遮挡，高两层遮挡主角】，事件的【遮挡优先级】应该是【一之下、一二之间、二三之间、三四之间、四之上】五种，或者只提供中间三种，而能否通行则应该是另一个勾选框。
20. 事件页的【触发条件】有一些RGSS时代就存在的瑕疵（详见此贴），假设一个事件A是【可通行+确定键触发】，另一个事件B是【不可通行+确定键触发】，那么【只用键盘】没法【踩在A上触发相邻点的B】（MV和MZ可以通过点击B去触发B），【只用点击】既没法【站在B旁边且面向B但不触发B】（不点击B就没法转身，点击了B又会强制触发）又没法【走到A上停下但不触发A】（点击别的地方会路过A不停下，点击A停下来会强制触发），这种小瑕疵（尤其是加上载具系统和柜台地形以后）对一些解谜游戏来说会带来卡关与否的致命影响（想象一下电脑版能通关但手机版无法通关有多么蛋疼吧）。
21. 地图事件在运行时是可以重叠的但在编辑器中又不可以，不知道为什么要这样限制（如果说MV是因为左侧没有事件列表那MZ不应该有这个问题了）。
22. （重要）很多下拉框里只显示名称而不显示编号（比如【设置移动路线/设置事件位置】的事件列表，或者有的虽然当时显示但选好以后在外面又只有名称了，比如变量/开关操作），这在有重名的情况下很不方便（尤其是事件和数据库大家一般都是复制的吧）。
23. 【设置移动路线】指令缺少对跟随者的演出控制功能，比如此贴提的问题就很有挑战性，如果专门做几个队友样子的npc的话，在队伍人员不确定或者行走图不确定的情况下就会非常复杂，如果能简单一点就好了。
24. autotile在地图json文件中就直接是48种数字，而不是像H5魔塔样板一样到了运行时再根据相邻关系去渲染，可能是因为后者的地图修改频率很高要进存档吧，我不确定如果RM也这么干会有什么好处。
25. 数据库其他一些范围限制（按理说你都js了那范围肯定应该是SafeInteger啊，近似一下也就是±9000万亿以内），尤其是那些百分比的精确度实在感人……显示文字4行显示选项6项啥的就不说了。
26. 地图的加载机制问题，每次切换地图都现场加载MapXxx.json挺奇怪的（note也要现场重新生成一次meta了），既然是文本文件那应该启动游戏时根据MapInfos.json一次加载完，这样作者还可以取用非当前地图的静态数据了。
27. 捆绑工具方面，想要一个【xp行走图一键转mz】（裁掉最左侧1/4宽度，并在文件名开头添加$符号，或者一次选八个一样大的文件拼起来），或者一个像H5便捷ps一样的工具（这玩意只支持32格子宽度唉）。
28. （重要）文件名的特殊字符问题，在Windows系统上用浏览器运行游戏时，我发现运行时请求的文件名【不止是中日韩文，还包括空格和$在内的字符】全部会变成%xx的URI，导致素材加载失败，这个问题有点严重啊，如果说运行时我可以把判定$改为判定另一个特殊前缀，那编辑器怎么办呢。
29. UI编辑方面，虽然能感觉到官方试图给作者建立一个【Scene and CommandWindow】的体系，但还是那句话，缺少说明文档和教程的情况下，就算内行也很难自己摸索会啊。至于外行肯定更想要的是可视化编辑，而且外行一般会把UI的【美工绘制】和【操作逻辑】混在一起，需要官方好好对待一下……
30. 没有一键打包apk和ipa确实很难绷（之所以提一嘴ipa是因为iOS17开始可能会允许第三方应用商店侧载），总不能都去用我们H5魔塔的启动器吧（或者发布到4399在线玩）。

对RM Unite的期待的话，看了下宣传页面好像行走图变高了（大长腿的头身比），然后希望编程语言不要是纯c#而是还能来点js或lua吧，数据库也不知道还是不是json了呜呜。
暂时想到就这么多，欢迎拍砖补充。

小怪兽奇奇侠

好厉害，这篇评测真的好专业！给大佬打call

fux2

扩展业务了属于是

89444640

那个……html开发人员的习惯是为了节省空间，不空格分段的吗，太密了看着好累啊。

sncufan

RPG Maker Unite 的话，编程语言是纯c#，数据库也是json，而且部分操作很卡 :(

小秋橙

时隔一年的挖坟：
https://rpg.blue/forum.php?mod=v ... amp;fromuid=2731820
本帖是一个非常好的批判「特性」系统的例子，因为rm的特性之间的逻辑关系是非常受限的，有时候是交集有时候是并集而不能自定义……