RPG Maker MZ, Preview #5: TPBS, A Closer Look

● ARCHIVED · READ-ONLY
Started by RPGMakerWeb 236 posts Page 5 of 12 View original ↗
  1. TheoAllen
    #81 Source
    nio kasgami said:
    the problem come from the newbie to rm who wants to learn programming. Normally you look at how people does it right? (which I did in the past) then look the code base but now MOST and I can tell you will write in ES6 and when people will look the codebase and the plugins they will be like : why it's written differently?
    The problem with "newbie programmer wants to learn by looking at how people code it" is that, most of them begin to just use IIFE for the sake of IIFE because people do it. For plugin dev, it makes their code can not be overridden outside of it. You have to directly edit the plugin file so you can not make a separate patch to preserve the original code or make a compatibility patch for two or more plugins.

    Come to think of it, what is the benefit of IIFE to plugin devs?
    My point is different programming and different environments call for a different paradigm. RPG Maker default code is not responsible to teach them how to actually write proper code. They need to learn about the environment. It just a part of being a programmer.
  2. Raizen
    #82 Source
    I think a lot of people here are confused to why should that switch to ES6 be made, at least the non-programmers are. The reason is simple, we are always looking for a different engine, why get the MZ if we can just whatever, do the same thing on MV right?
    ES6 has been standard for some time now, if for any reason it should be ES5 written because some programmer learned on MV, he learned it wrong already, Javascript is one of the worst languages to actually learn programming, but ES6 syntax brings it closer to how other languages are written.

    Anyway the main thing is, it isn't a full revamped engine, it has a LOT of things extremely close to MV, the closer you are to an older engine, the less reason for you to exist. Effekseer/PIXI v5/other superfluous systems that there were plugins for, everything was able to do it for MV, everything we could have already made and some were actually made for MV. What we could not do, was to change the core code, because the core code is what ALL plugins are based on, THAT was the thing to change. The moment the core of the engine (what has been shown) has 90% similarities with its older part, including the ES5 syntax, then IT IS a huge letdown.

    I know some projects in MV uses PIXI v5, I've put effekseer on mine to test it and probably some others also did, the ATB/event manager are nice additions, but everything is possible on MV, and some aren't even that hard, but the core code... That is the part it should have gotten better, because that is the part we coders can't just fix it without breaking everything else.

    Anyway, I've got it on pre-sale, it is a big let down, even though on the leaks there was already showing some prototype stuff. I'll still keep it, but I got a little disappointed now, not with the NA team of course, I don't think they had anything to do with it, but with the product itself.
  3. winkr7
    #83 Source
    I would guess less than 5% of the current MV owners know what ES6 and ES5 are--albeit an important 5% since they are doing plugins. As for new people learning code so they can get programming jobs--there is no better lesson than a mixed mess of code from different people trying to be backwardly compatible with earlier versions not quite done and full of bugs to get started. It mirrors the paid programmers real working life pretty well.
  4. Tsukihime
    #84 Source
    Raizen said:
    I know some projects in MV uses PIXI v5, I've put effekseer on mine to test it and probably some others also did, the ATB/event manager are nice additions, but everything is possible on MV, and some aren't even that hard, but the core code... That is the part it should have gotten better, because that is the part we coders can't just fix it without breaking everything else.

    MZ has layered mapping :cool:
  5. TheoAllen
    #85 Source
    Raizen said:
    Anyway the main thing is, it isn't a full revamped engine, it has a LOT of things extremely close to MV, the closer you are to an older engine, the less reason for you to exist. Effekseer/PIXI v5/other superfluous systems that there were plugins for, everything was able to do it for MV, everything we could have already made and some were actually made for MV. What we could not do, was to change the core code, because the core code is what ALL plugins are based on, THAT was the thing to change. The moment the core of the engine (what has been shown) has 90% similarities with its older part, including the ES5 syntax, then IT IS a huge letdown.
    When they said the core code is revamped, I'm not expecting to change from ES5 to ES6 class syntax. I'm expecting it that the code structure changed. I don't know if you were around in RMXP era, but that era was a horrible era for scripters because there is a little modularity. Imagine that one single scene only contains 4 methods to handle everything and that was a compatibility nightmare. VX did it better but the command windows were still hardcoded. And then Ace comes with cleaner base code.

    If MZ is just MV but with ES6 syntax, then it's not a revamped engine. It just a conversion.
  6. Raizen
    #86 Source
    winkr7 said:
    I would guess less than 5% of the current MV owners know what ES6 and ES5 are--albeit an important 5% since they are doing plugins. As for new people learning code so they can get programming jobs--there is no better lesson than a mixed mess of code from different people trying to be backwardly compatible with earlier versions not quite done and full of bugs to get started. It mirrors the paid programmers real working life pretty well.
    They don't, but 95% uses plugins, and who make them do haha, that is exactly the point, its not like its going be hugely horrible compared to a revamp in ES6. Its just that... we expected an updated software :(



    Tsukihime said:
    MZ has layered mapping :cool:
    Oh yeah, you got a point there haha :yswt:


    TheoAllen said:
    When they said the core code is revamped, I'm not expecting to change from ES5 to ES6 class syntax. I'm expecting it that the code structure changed. I don't know if you were around in RMXP era, but that era was a horrible era for scripters because there is a little modularity. Imagine that one single scene only contains 4 methods to handle everything and that was a compatibility nightmare. VX did it better but the command windows were still hardcoded. And then Ace comes with cleaner base code.

    If MZ is just MV but with ES6 syntax, then it's not a revamped engine. It just a conversion.

    But If I do it, who is going to use mine if I break everyone's plugins haha. I was there also on the RMXP, I agree, but I didn't mean it that way, I meant... if you are going to rewrite it, then rewrite it, and not grab some stuff from MV like it is on the API. The ES5 looks MUCH MUCH more a "We want less work so we stay with ES5, than ES5 is better for what we want".
  7. nio kasgami
    #87 Source
    the problem as well is :
    I did met problem with some ES6 class who was extending ES5 prototype class.

    I don't recall 100% but I think it was about the constructor not applying properly for Super. but after it's YEARS ago.


    I see the points I just hope the code is better than it was.

    AS for the ES6 alias problem. As I said both es6 and ES5 works together and the method was just a bonus but yeah it was indeed an problem but as they said : javascript doesn't really come with the concept of 'alias' built-in anyway. WELL import does now but it's not the same.

    so what we was trying to do for alias is like witchcraft so unexpected behaviour is prone to happen.
  8. Dororo
    #88 Source
    I don't see point of the whole ranting. ES6 changelog is 5 lines. What people expected for? To inspect the core and see LUA?
  9. Hudell
    #89 Source
    Here's a summary of changes I've detected so far (reminder that this is based only on the rpg_core file, there are more files they haven't shared yet)

    • No more canvas mode (Pixi 5)
    • Map rendering has changed a lot, can't tell if it was for better or for worse without testing.
    • Sprites are not using Z position (I thought for sure they would, as pixi supports it now) - It still uses sprite sorting which is extremely heavy and the main cause of lag on MV
    • The way Bitmaps handle images has changed
    • No change to the way keyboard and gamepad input is handled, but two new things:
      • Input.virtualClick method lets you simulate a key press
      • Tab key added to the list of keys that the game will ignore (may break alt+tab ??)
    • Default font face changed from "GameFont" to "sans-serif"
    • Default font size changed from 28 to 16
    • Default outline width changed from 4 to 3
    • Support for bold font
    • Encryption seems to have changed completely
    • The main Game Loop is now managed by a PIXI.Application
    • Touch and Mouse input changed a bit, but seems to have been mostly code reorganization, I didn't detect any new feature other than the ability to check if the mouse is hovering something.
    • Many changes on the audio playing code, but I didn't look at it too deeply.
    • No changes on the weather effects
    • Things such as Cache Handlers and Request Queues were removed (looks like anything added to MV after 1.0 was released is not there?)
    • No more m4a audio files.
    • Removed compatibility with windows phone (as if that even mattered lol)
    • Window class code has improved a little to make it easier for different plugins to be compatible among themselves
    • The background on windows are now separate from the content
    • Blending and screen tinting were reprogrammed using more modern stuff

    There's some interesting new methods too:
    • Code to check if the game is being played on RPG Atsumaru (A japanese game hosting service)
    • Code to compare RM version, likely for plugin compatibility
    • Sprites and other objects that use Pixi containers now have a .destroy method.
  10. Poryg
    #90 Source
    Kaliya said:
    Could you name one objective benefit for using class syntax and not the "old" es5 prototype way? The code itself uses es6 where applicable and an objective benefit over es5 is there, from what I can tell.

    Class syntax allows you to define inheritible vs. non-inheritible static functions. If you define static foo inside Scene_Base class, it will be inherited by its children. If you on the other hand define Scene_Base.foo, it is a static function, but will not be inherited by its children.
    That's the biggest, but not the only objective benefit of the class syntax.

    Another objective benefit of class syntax is, modern IDEs can minimize nests. If MZ corescript files are as big and ugly as in MV, aka not separated class by class, it means much easier navigation by minimizing the entire class over having to minimize the functions one by one.

    Another large objective benefit?
    It's IMMEDIATELY obvious what's a new class and what's an addition to existing class. Because you're going to have to use prototype for class additions.

    The class syntax is also much closer to other programming languages than the prototype syntax. Therefore
    Kaliya said:
    Doesn't mean it is the smart thing to do for the engine, as not everyone who uses the engine or codes for the engine, codes for a living.
    is totally irrelevant. The prototype syntax has been outdated for 5 years (for comparison it's 166.6% of my programming life). Meaning those who are new to Javascript won't have any idea wtf they're looking at and neither will those that have some small let's say python experience, because even python uses a class syntax, albeit an abomination of one too.


    There you go. Now give us a single reason why STAY at ES5 prototype syntax apart from those people that are "moving from MV". I'm definitely interested in hearing them.
  11. nio kasgami
    #91 Source
    Dororo said:
    I don't see point of the whole ranting. ES6 changelog is 5 lines. What people expected for? To inspect the core and see LUA?

    because of the error in communication we all though it will be rewritten in ES6 standard which something a lots of programmer wanted for a Whileee.

    Maybe to you it doesn't seem as negative but this is a big letdown for many people especially as the post Poryg said : ES5 is 'obsolete' since like MANY years now.

    of course we can still write in ES6 for our plugins but I mentioned: style clashing will be strong which can lead to a lots of problem

    + what Poryg mentioned above.
    it's not just a little matter of 'oh buhuhu it's not lua'
  12. Dororo
    #92 Source
    @nio kasgami
    Well, now I understand the ranting a bit more.
    I wasn't totally aware of coding people essentially purchase the old thing again, after being "hinted" the engine got a total overhaul.
    AGAIN I think this come from the strange marketing strategy that aimed to old users ("Now with that!"), while the product seems aimed instead to first time customers like me.
  13. nio kasgami
    #93 Source
    yes this an error who happen when communication between team happen.

    Now I am not much angry I know perfectly Touch was overworked so I am not even mad at him for that I am just kinda eh but I will still try to use MZ and we will see how it goes and AT LEAST I hope the jp team used For of instead of for each (which for of is more optimal and have a way more simple syntax).


    So far I welcome the engine. I am happy a new RM happened it's just this little thing that burst the bubble a little. regardless I will still work to bring nice plugins to RM.
  14. Anyone
    #94 Source
    nio kasgami said:
    because of the error in communication we all though it will be rewritten in ES6 standard which something a lots of programmer wanted for a Whileee.

    Maybe to you it doesn't seem as negative but this is a big letdown for many people especially as the post Poryg said : ES5 is 'obsolete' since like MANY years now.

    of course we can still write in ES6 for our plugins but I mentioned: style clashing will be strong which can lead to a lots of problem

    + what Poryg mentioned above.
    it's not just a little matter of 'oh buhuhu it's not lua'
    Dororo said:
    @nio kasgami
    Well, now I understand the ranting a bit more.
    I wasn't totally aware of coding people essentially purchase the old thing again, after being "hinted" the engine got a total overhaul.
    AGAIN I think this come from the strange marketing strategy that aimed to old users ("Now with that!"), while the product seems aimed instead to first time customers like me.

    Let's not forget that some news of changes of the editor itself, or rather, the lack thereof, has been pretty disappointing. There are so many small but insanely time-saving & useful Quality of Life changes that wouldn't just benefit veterans: they'd make it easier for everyone, especially beginners.

    - You wanna sort your many items by type so you can keep an overview of a couple hundred items? You need to plan the space ahead in time. You want to move an item's index slot, in order to keep everything organized after you ran out of space? You now break all references and can go through every event to reassign the reference to the correct one.
    • Solution: Use the index to visually sort items when displayed, but when creating an item, automatically assign a unique creation ID for the slot. Copy-pasting creates a new entry with a new creation ID, cut&pasting transfers the creation ID along. Now everything will still feel and be the same as in RMV, nothing has changed, except one thing: since every entry uses the creation ID as reference, you can move items in your database and no reference breaks. You don't need to go through 200 chests and change the contents.
    Just to throw a quick one out there. It's not even a complex concept, games have done that way back in 1998.

    • Bonus Points: Add a tab filter at the top where people can add custom lists they can switch to, so "Items" for example can be sorted across user-created tabs, from "General", "Consumable", "Loot", "Quest Items" etc.
    The tenor was kinda that all the countless improvements that could've been made but didn't happen were because the entire engine was reworked and due to time & fund limitations, all the stuf that would save users endless hours in actually using the editor couldn't be done.

    And even though it may not actually be the case, it feels a bit as if in truth, the japanese devs (not the NA team) simply overhauled MV, but not nearly to the degree that was marketed.

    And when you look at the editor, and you realize that if we had the liberty to have 2-3 people in the community who can code in the editor's language have a few weeks access to it, we'd have 30+ new features that would massively make life easier.

    But we didn't get all the QoL features, we didn't get the fundamental improvements that would've allowed more advanced plugins & coding, and an alternative to notetagging, we didn't get the long begged for ability to program plugins for the editor itself or even the RIGHT, just the allowance, to do so on our own.
    And now it kinda feels like we're not even getting the fundamentally improved engine that was used to justify why we didn't get any of the above.

    And it does feel frustrating, to sit here and be able to come up with a list of 20 features on the spot, that could be realized in 2-3 weeks, just by the community, and would help beginners & veterans alike and save hundreds of hours of working around some of the tedious and clunkily designed database tabs.

    It's not the fault of the NA team, it's not even necessarily the fault of the devs, who are restricted by the funds that are available to them. And to Degica it's a business, they're not the ones making games.

    But it is draining, and it is very unfortunate, that RMZ, with the help of the community could be a massively better product than it will be, and the reason that we accepted for it - that the engine had to be remade from the ground up - just feels fragile after seeing that we might not be getting the engine update we were sold on.

    Maybe that's a pessimistic outlook that'll disappear when we get to see the actual code, maybe there's a positive surprise down the line, but right now it's draining, seeing what could be, knowing it won't.
  15. Shaz
    #95 Source
    I don't get why everyone is so up in arms about ES6. I couldn't care less one way or the other. Sure, a class syntax would be nice to use and easier to read, but MV's method really isn't that difficult, and if they're not all rewritten as classes, that means it's possible for a lot of MV plugins to just work in MZ with no changes. To me, that's good news! It also means I don't have to learn ES6 and completely restructure the way I make plugins because of it, so it's not going to slow me down as much as I thought it would.

    Seriously - I'd question if many people preordered MZ because it was all rewritten as ES6. Surely you'd want some better reasons than that to part with $60-$80?
  16. Poryg
    #96 Source
    Hudell said:
    Things such as Cache Handlers and Request Queues were removed (looks like anything added to MV after 1.0 was released is not there?)
    Nah, it's unnecessary to have these. Async loading allows for async handling, hence request queues are pointless.
    Not to mention, PIXI has a pretty capable garbage collector, so it's unnecessary to have another cache handler.
    Hudell said:
    The background on windows are now separate from the content
    The backgrounds were actually separate from contents even in MV, just a bit differently. They weren't rendered as two different sprites, the content was blitted there, but you could still play with the background without altering the contents.
    Hudell said:
    Sprites and other objects that use Pixi containers now have a .destroy method.
    Sprites and other objects that use Pixi containers have destroy method already from Pixi. That's nothing new. It was just unnecessary, since MV did not use PIXI.TextureCache.

    Well, I hope that we're at least going to see a smart preloading system instead of on-demand loading.

    EDIT: @Shaz ES5 vs. ES6 has no influence at all on whether MV plugins break, or not.
  17. Shaz
    #97 Source
    Hudell said:
    Code to compare RM version, likely for plugin compatibility
    This could be for the auto-update of projects to newest MV version?

    Poryg said:
    ES5 vs. ES6 has no influence at all on whether MV plugins break, or not
    You mean I could write a function in ES5 that aliases a function in ES6 and it would work, if the aliased function used class syntax and my function didn't?
  18. nio kasgami
    #98 Source
    well Shaz I actually still excited for MZ don't get me wrong I just enjoy a lots ES6 more than ES5 (I am an lazy typer) regardless I will not change how I program my plugins lol.

    I will still try to support MZ as the best I can.
  20. DoubleX
    #100 Source
    Regarding TPBS -
    Wavelength said:
    However, it's not something I would worry about too much, because it seems like it would be a questionable to ineffective tactic - if you want to stop, say, two ticks of Poison from affecting you, you essentially have to wait for two turns (or almost that much). Usually the action is worth more than the chip damage from the Poison. In the rare situations that may arise where it's not, that's clever play on the part of the player - sort of a case of "it's not a bug, it's a feature". ;)
    I agree that it's a clever play introduced in TPBS(provided that things really work that way), and this feature will only make me like the innovation of TPBS even more, it's just that I want to know whether I've a solid understanding on how TPBS works in details :)

    Touchfuzzy said:
    It advances your turn count at the beginning of your action, not at the end. And I would imagine poison would be set to tick at the beginning of the characters turn.
    So "at the beginning of your action" corresponds to "right before a battler execute actions" and "at the beginning of the characters turn" corresponds to "right after a battler becomes able to input actions", meaning that the HP/MP/TP regeneration timing's different from the state turn update timing(and I'm ok with that as they can also be different in both VXA and MV).

    Touchfuzzy said:
    On the question of if the time scale changes based on who is the fastest dynamically, I'm 99% sure that it is set at battle start and stays the same throughout the battle.
    So let's say there are 2 battlers, where battler A's 64 agi and battler B's 16 agi, meaning that initially, battler A takes 4 seconds to fully fill the bar from empty, while battler B takes 4 * 2 = 8 seconds to do the same.
    Then, let's say battler A receives an agi debuff causing the agi to become 16, and battler B receives an agi buff causing the agi to become 64, now battler A still takes 4 seconds to fully fill the bar from empty, while battler B takes 4 / 2 = 2 seconds to do the same(I'm just verifying whether my understanding's solid).

    Touchfuzzy said:
    But most of this falls into "feature, not bug" category if you keep these in mind while designing.
    Of course, as it's our job to have a solid understanding on how TPBS works in details before building games based on it, and I'd say TPBS is really very, very innovative :D

    Tsukihime said:
    For me, thinking of things in terms of frames was much easier than thinking in terms of turns, because there are different kinds of turns. If I think of things in terms of "start frame" and "frame duration" then everything becomes normalized to a single unit of time.
    Agreed, and I reason about most of the ATB system plugin codes in terms of frames, so now I'm still trying to fathom the relationship between the TPBS individual/battle turn count and ATB frames, even though I've yet to find any meaningful relationship there, and I'm not sure whether there's really none or I'm just too confused about how TPBS works in details :p

    Regarding The 'Announced ES6 Standard' -
    I personally like Promises, generator functions, arrow functions, const and let vs just var, template literals, Object.assign, import and export keywords, objects with computed keys, default values, rest parameter, some syntactic sugars available in ES6(especially destructuring and spreading, and object matching), and some other nice additions(they all noticeably boost effectiveness, efficiency and readability for me), so I'd say I do care about how many ES6 codes are in the MZ codebase.
    However, while I do think using appropriate ES6 constructs in appropriate places are important, it's still not to the point of being a deal maker/breaker for me, as I don't think the difference between ES5 and ES6 is at the level of game-changing, and I'm still okay working with ES5 codebases as long as they're not too poorly written.

    After all, while a bit unlikely, ES5 codebases can still be written very, very nicely, and ES6 codebases can still be written very, very poorly(it's generally a bit easier to write poor codes in ES5 and a bit easier to write nice codes in ES6 but still), and my priority on the MZ codebase quality's much, much higher than whether it really follows the ES6 standard(meaning that as many appropriate ES6 constructs are used in the appropriate places of the codebase as possible).
    Ideally, I'd want to work with a very, very nicely written MZ codebase really following the ES6 standard, and I'd avoid very, very poorly written ES5 codebase like a plague, but if I've to choose between a very, very nicely written ES5 codebase and a very, very poorly written ES6 codebase, I'll definitely go for the former and never ever missing the latter, even though I hope there doesn't need to be such a choice to begin with.

    Archeia said:
    The only ES6 is the use of const and let that I am aware of. Everything else is still ES5. However, you can use ES6 no problem just the code itself isn't written in full ES6. We are still unsure how much of the core script is still being (re)written as it is still under development.
    Kaliya said:
    Please try to look at the bigger picture, at whom this product is targeted for. Hobbyist, not exactly professional programmers who keep up to date and adapt to the latest standards whenever a change is made to them.
    Still using tons of ES5 constructs has at least the following advantages:
    1. Porting MV plugins into MZ don't have to convert them into ES6 to be consistent with the default MZ codebase, and it's a major factor for many MV plugin developers planning to do so
    2. Those not being familiar with/not preferring ES6 don't have to learn/work with it, and the number of such MV plugin developers' better not to be underestimated
    Whereas really following the ES6 standard has at least the following advantages:
    1. New RM plugin developers(i.e., those never workjed with MV before) not being familiar with ES5 don't have to learn it, as there are quite some JavaScript programmers(hobbyists or not) picked up JavaScript after ES6 becomes the mainstream
    2. It allows the RM codebase to improve more quickly and keep closer to the mainstream when a new RM comes and thus encourages more new RM plugin developers to join the RM community, as sticking to ES5 for the advantages it gives for THIS MAKER can lead to the subsequent RM versions LOCKED INTO ES5 for a long time(the later the switch the harder and more costly it's in general), causing fewer and fewer new RM plugin developers to join(being consistent with the default RM codebase is a major factor for many plugin developers), due to the fact that ES5 will only become more and more outdated, eventually causing the later RM versions to become too dependent on existing RM plugin developers, which can be serious troubles if many of them decide to leave RM, and this will happen eventually

    But first, let's divide the potential MZ plugin developers in the following groups:
    1. MV plugin developers already being familiar with ES6 and preferring ES6 over ES5
    2. MV plugin developers already being familiar with ES6 but preferring ES5 over ES6
    3. MV plugin developers not being familiar with ES6 but is already learning it
    4. MV plugin developers not being familiar with ES6 but isn't learning it
    5. New RM plugin developers already being familiar with ES6 and preferring ES6 over ES5
    6. New RM plugin developers already being familiar with ES6 but preferring ES5 over ES6
    7. New RM plugin developers not being familiar with ES6 but is already learning it
    8. New RM plugin developers not being familiar with ES6 but isn't learning it
    From the following 3 dimensions:
    1. MV plugin developers vs new RM ones
    2. Already being familiar with ES6 vs not so
    3. Preferring ES6 over ES5 vs the opposite(Of course there are plugin developers being okay with both)

    Now let's think of how each among the 8 potential MZ plugin developer types will generally react to MZ still using tons of ES5 constructs(those okay with both ES5 and ES6 likely don't care about this one bit):
    1st type: They'll likely treat this move as a massive disservice, as ES5's very, very outdated in the JavaScript community(but still far from being totally irrelevant though), so most JavaScript programmers should be familiar with ES6 already, meaning that still using tons of ES5 constructs is prioritizing the minor group of not being familiar with ES6 over the vast majority of the JavasScript programmers.
    2nd type: They'll likely be okay with this move, as porting MV plugins to MZ can become easier, simpler and smaller tasks when the need of converting those ES5 codes into ES6 codes reduces significantly(being consistent with the default MZ codebase), and sometimes direct prototyping does make more sense than using classes, and most importantly, those preferring ES6 over ES5 can still write their MZ plugins in ES6, if the use of ES6 over ES5 means so much to them that they're willing to pay the cost of writing codes not being consistent with the default MZ codebase.
    3rd type: They'll likely be so mad that some of them will probably just "rage quit" by cancelling the MZ pre order and never caring about MZ ever again, as it's only natural(but still not fully justified) for them to feel that their efforts on learning ES6 just to adapt to the MZ codebase's all wasted, even though it's crystal clear and obvious that it's not wasted at all, as becoming familiar with ES6 gives them a vast advantage as JavaScript programmers.
    4th type: They'll likely praise MZ for making this move to take their needs/preferences into account, as being familiar with ES6 still demands a nontrivial amount of work(even though even a bad junior programmer like me can do so within just weeks), and some of them may have no time to learn it but still want to release MZ plugins as soon as possible(it really depends on their situations), which can cause troubles for them if MZ really follows the ES6 standard and they need/want their codes to be consistent with the default MZ codebase.
    5th type: They'll likely feel that MZ prefers existing MV plugin developers over those new to RM, and perhaps similar moves will be made for the next makers as well, as it's hard for them to fathom why MZ made such a decision otherwise, especially for those not being familiar with ES5, so some of them might just cancel the pre order and even conclude that RM's going to be deprecated in the foreseeable future, all because of refusing to update the codebase to the mainstream ES6 from the outdated ES5.
    6th type: They'll likely think very similarly to the 2nd type, except that porting MV plugins to MZ won't be their concerns, so they're unlikely to praise this MZ decision as much as some of the others.
    7th type: They'll likely think very similarly to the 3rd type, but maybe even more so, because unlike the 3rd type, they won't get the benefit of having less work to do when porting MV plugins to MZ.
    8th type: They'll likely think very similarly to the 4th type, but perhaps even more so, because nowadays it's quite hard to find a ES5 codebase to work with, and MZ will be a blessing to them as they aren't familiar with ES6 and aren't going to learn it, so it's normal(but still not certain) that they'll be some of the biggest supporters of this MZ decision.
    So, if still using tons of ES5 codes is indeed a wise decision in MZ, it means:
    1. Currently, the 2nd, 4th, 6th and 8th types, and those being okay with both ES5 and ES6 will be the majority of potential MZ plugin developers, despite the fact that most JavaScript programmers in the JavaScript community are familiar with ES6 and some of them aren't even familiar with ES5, meaning that MZ is a niche even in the programmer/programming perspectives
    2. For the whole RM franchise, it's more important to prioritize the existing RM community programmers, especially for those wishing to stick to outdated practices, than attracting new programmers into the RM community, especially when some of them can't/won't work with those outdated practices(despite the fact that existing RM community programmers will eventually leave RM), and this can be due to the fact that many MZ users will be existing MV users as well and vice versa, thus the need of porting MV plugins into MZ will be large enough to place the need of "removing the work for converting them into ES6 codes as well to be consistent with the default MZ codebase" into a very, very high priority
    Of course, I don't have the numbers while both Degica and Kadokawa definitely have, and I don't know how many new RM after MZ will be while they might already have plans on it, so I'll refrain from judging further whether still using tons of ES5 codes is indeed a wise move in MZ ;)

    P.S.: Not all hobbyists will remain hobbyists forever, so the average rate of change from hobbyists into professionals is also a very, very important number when evaluating whether this MZ decision's a wise move.