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

Status
Not open for further replies.

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
6,206
Reaction score
7,476
First Language
Indonesian
Primarily Uses
RMVXA
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.
 
Last edited:

Raizen

Veteran
Veteran
Joined
Oct 24, 2012
Messages
397
Reaction score
700
First Language
Portuguese
Primarily Uses
RMMV
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.
 

winkr7

Veteran
Veteran
Joined
Oct 27, 2015
Messages
99
Reaction score
31
First Language
english
Primarily Uses
N/A
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.
 

Tsukihime

Veteran
Veteran
Joined
Jun 30, 2012
Messages
8,564
Reaction score
3,877
First Language
English
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:
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
6,206
Reaction score
7,476
First Language
Indonesian
Primarily Uses
RMVXA
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.
 

Raizen

Veteran
Veteran
Joined
Oct 24, 2012
Messages
397
Reaction score
700
First Language
Portuguese
Primarily Uses
RMMV
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 :(



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


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".
 

nio kasgami

VampCat
Veteran
Joined
May 21, 2013
Messages
8,965
Reaction score
3,073
First Language
French
Primarily Uses
RMMV
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.
 

Dororo

Gespenst MKII pilot
Veteran
Joined
May 24, 2020
Messages
262
Reaction score
932
First Language
Italian
Primarily Uses
RMMV
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?
 

Hudell

Dog Lord
Veteran
Joined
Oct 2, 2014
Messages
3,602
Reaction score
3,832
First Language
Java's Crypt
Primarily Uses
RMMZ
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.
 
Last edited:

Poryg

Dark Lord of the Castle of Javascreeps
Veteran
Joined
Mar 23, 2017
Messages
4,125
Reaction score
10,660
First Language
Czech
Primarily Uses
RMMV
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
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.
 
Last edited:

nio kasgami

VampCat
Veteran
Joined
May 21, 2013
Messages
8,965
Reaction score
3,073
First Language
French
Primarily Uses
RMMV
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'
 

Dororo

Gespenst MKII pilot
Veteran
Joined
May 24, 2020
Messages
262
Reaction score
932
First Language
Italian
Primarily Uses
RMMV
@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.
 

nio kasgami

VampCat
Veteran
Joined
May 21, 2013
Messages
8,965
Reaction score
3,073
First Language
French
Primarily Uses
RMMV
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.
 

Anyone

Veteran
Veteran
Joined
Aug 24, 2019
Messages
245
Reaction score
343
First Language
German
Primarily Uses
RMMV
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'
@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.
 

Shaz

Global Moderators
Global Mod
Joined
Mar 2, 2012
Messages
42,485
Reaction score
14,818
First Language
English
Primarily Uses
RMMV
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?
 
Last edited:

Poryg

Dark Lord of the Castle of Javascreeps
Veteran
Joined
Mar 23, 2017
Messages
4,125
Reaction score
10,660
First Language
Czech
Primarily Uses
RMMV
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.
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.
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.
 

Shaz

Global Moderators
Global Mod
Joined
Mar 2, 2012
Messages
42,485
Reaction score
14,818
First Language
English
Primarily Uses
RMMV
Code to compare RM version, likely for plugin compatibility
This could be for the auto-update of projects to newest MV version?

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?
 
Last edited:

nio kasgami

VampCat
Veteran
Joined
May 21, 2013
Messages
8,965
Reaction score
3,073
First Language
French
Primarily Uses
RMMV
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.
 

Tsukihime

Veteran
Veteran
Joined
Jun 30, 2012
Messages
8,564
Reaction score
3,877
First Language
English
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?


Pretty much.
 

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,827
Reaction score
974
First Language
Chinese
Primarily Uses
N/A
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 :)

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).

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).

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

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

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.

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.
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.
 
Last edited:
Status
Not open for further replies.

Latest Threads

Latest Posts

Latest Profile Posts

Gotta love when RM just decides it's done with existence and closes when you're in an event.
Good grief am I ever so dusty on music creation. Never move, gentleman and ladies!
After waiting for several months to observe the results of vaccines, I finally decided to go for Comirnaty, because now my job needs me to either be vaccinated or take a regular testing every 2 weeks(240 HKD per test), and it seems to me that Comirnaty is safe enough in my case :)
So, to create multiple faces one needs to first export, then import, over and over... who came up with this weird mechanism...
Away from home now since it reduce COVID spread

Forum statistics

Threads
112,316
Messages
1,067,314
Members
145,947
Latest member
DisguisedCrows
Top