RPG Maker MZ, Preview #3: Character Generator, Plugin Manager, Event: Plugin Command!

Status
Not open for further replies.

Jitsu

Villager
Member
Joined
Oct 3, 2017
Messages
16
Reaction score
18
First Language
German
Primarily Uses
RMVXA
The change from MV to MZ becomes a gradual process. Many will end old projects first and / or wait for more MZ plugins. At some point the MZ will replace the MV like VXAce replaced VX. Apart from the plugins, there are not many reasons to stay with MV. There are People who finde there perfect place to dev in older engines. Its fine too :)

Would MZ have the same Plugin Pool like MV i see no reason to stay with MV.
 

GethN7

Veteran
Veteran
Joined
Sep 22, 2014
Messages
186
Reaction score
77
First Language
English
Primarily Uses
N/A
@Touchfuzzy As an earlier poster asked, do you know about how limited the database and map sizes are?

MV had to chop sizes in half from VX Ace, and the Database was hard to extend past 2000 for most things.

Any increases or decreases in any of the above, or are you not at liberty to disclose that at his time?
 

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,616
Reaction score
670
First Language
Chinese
Primarily Uses
N/A
Regarding on the beginner friendliness towards plugin developers when it comes to the codebase, I think that it's a delicate balance that can only be shifted incrementally.
Being too beginner friendly can at least cause the following problems:
1. There will be many plugins with very low code quality, causing compatibility towards other plugins to be unnecessarily low(like overriding everything when aliasing/hooking are totally feasible in those cases), or even the number of bugs to be excessively high(all these hurt plugin users at the end), especially when it comes to seemingly edge cases that are surprisingly common.
2. Plugin users will be harder to find high quality plugins with excellent supports, as a direct implication from the above, thus worsening their experience with using plugins, or even MZ in general.
3. The productivity and motivation of veteran and/or even professional plugin developers will be generally lower, due to them being harder to use more advanced yet also more effective and efficient constructs and techniques(that's 1 reason why some plugin developers write their own core engines), and having to tolerate or even workaround with some very obvious yet serious codebase design flaws(code quality wise at least) that are very hard to fix without breaking many other things.

Whereas being too beginner unfriendly can at least cause the following problems:
1. There can be too few plugin developers or too few number of plugins developed by those who're not even experienced in programming yet, causing the number of plugins to be low, perhaps even too low, meaning that users will have less choices that still work for them(a high quality plugin with excellent support doesn't always mean a working plugin for a particular user after all).
2. The workload of veteran/professional plugin developers can increase a lot due to having less plugin developers to cater with the plugin user needs. In extreme cases, the workload can be so high that some plugin developers just can't/won't take them anymore(unfortunately this has already happened before).
3. Some RM users buy RM solely to write scripts/plugins, and some of those are beginning programmers(I think that "Easy enough for a child" somehow applies to scripting/plugin development at least in VXA and MV as well), so potentially driving them away can lead to decreased sales, and I'm not sure whether it'll be compensated by the increased number of plugin users and veteran/professional plugin developers(as I don't have the numbers).

While I prefer more advanced yet also more effective and efficient constructs and techniques to be the default in the MZ codebase even when I'm still just a bad junior programmer, I think that this has to be a gradual progress.
I mean, I definitely expect a drastic codebase improvement from MV, but not so drastic that beginner MV plugin developers can't even recognize the important similarities(default functionalities, plugin development workflow, coding styles, etc) between MV and MZ codebase anymore, otherwise I could expect a drastic drop in the number of MZ plugin developers, at least in the early MZ days(which can last quite a long time).
In the case of adding native hooking support, I agree that this alone is easy, simple and small enough for even a beginning programmer to pick up quickly, but if there are man such "easy, simple and small" concepts new to them all at once, the combined learning difficulty can be unexpectedly high. Of course, I don't have access to the MZ codebase yet so I'm not sure, but if it turns out to have no default hooking API, then maybe it's because it's to avoid having too many new "easy, simple and small" concepts altogether.

  • Maybe being able to edit the editor and add your own variables (like new "stat" variables)
  • Maybe make smarter enemies (such as they can only heal a wounded ally
  • Maybe make more troop event conditions
  • Maybe make more potentials for events on the "world map"
  • Make animated enemies- I care about this one a lot
  • Make support for other languages, such as C#. So when you build it, you tell it's language and you can create plugins in that language
  • Maybe make native support for various battle systems (or just include well-programmed plugins for battle systems like tactical. action and Conditional Turn Battle)
In MV, there are some optional plugins that are shipped along with the MV itself. Also, I'm told that the MV editor's made with QT, meaning that programmers can write their own QML to edit the editor. Would it be acceptable for you to have those functionalities provided by free high quality MZ plugin with excellent supports written by some plugin developers, and be able to download some free editor mods given by some programmers?
As for C#, I wonder what do you think about transpiling C# to Javascript(I've no experience on this but I've heard that some such tools do exist), even though transpiled code can be very ugly at times :)
Alternatively, I'd like to know what you prefer in C# over JavaScript in MZ. If it's some kind of static type checks, then MZ later might have some official or nonofficial(from the community) TypeScript support. I don't know if you'll consider TypeScript a good enough substitute for C# though.

Not gonna happen. If you get all of that forget plug-ins, as the more you make native the HARDER it is to make plug-ins. So you really should just decide do you want plug-in support or not? As the more battle systems pre built there are the more plug-ins have to dance around them and/or support all of them when most authors don't have the time to do that, especially for free.

Same with adding or your own custom stats. You put that in fuget ever seeing a menu plug-in as they will have no way to handle all of your stats you set up, especially as they can't read your mind on how you want them to relate to each other.
I'd summarize it as: It's generally easier to add new features than to remove existing ones in the codebase when developing plugins, especially when it comes to compatibility issues :D

I'll say that as far as CTB, I imagine it would be trivial to turn the TPBS into CTB.
In general, yes, but if the TPBS is written very poorly, then it can be a big no(I've worked with a very poorly written ATB system script in VXA so I know).
While I'm very confident that the TPBS will be very nicely written just like the rest of the MZ codebase(otherwise I could expect a very severe outrage from the community), I've to be able to actually access the codebase after I've MZ just to be sure whether turning the TPBS into CTB is indeed trivial :p
 
Last edited:

nio kasgami

VampCat
Veteran
Joined
May 21, 2013
Messages
8,865
Reaction score
2,818
First Language
French
Primarily Uses
RMMV
Regarding on the beginner friendliness towards plugin developers when it comes to the codebase, I think that it's a delicate balance that can only be shifted incrementally.
Being too beginner friendly can at least cause the following problems:
1. There will be many plugins with very low code quality, causing compatibility towards other plugins to be unnecessarily low(like overriding everything when aliasing/hooking are totally feasible in those cases), or even the number of bugs to be excessively high(all these hurt plugin users at the end), especially when it comes to seemingly edge cases that are surprisingly common.
2. Plugin users will be harder to find high quality plugins with excellent supports, as a direct implication from the above, thus worsening their experience with using plugins, or even MZ in general.
3. The productivity and motivation of veteran and/or even professional plugin developers will be generally lower, due to them being harder to use more advanced yet also more effective and efficient constructs and techniques(that's 1 reason why some plugin developers write their own core engines), and having to tolerate or even workaround with some very obvious yet serious codebase design flaws(code quality wise at least) that are very hard to fix without breaking many other things.

Whereas being too beginner unfriendly can at least cause the following problems:
1. There can be too few plugin developers or too few number of plugins developed by those who're not even experienced in programming yet, causing the number of plugins to be low, perhaps even too low, meaning that users will have less choices that still work for them(a high quality plugin with excellent support doesn't always mean a working plugin for a particular user after all).
2. The workload of veteran/professional plugin developers can increase a lot due to having less plugin developers to cater with the plugin user needs. In extreme cases, the workload can be so high that some plugin developers just can't/won't take them anymore(unfortunately this has already happened before).
3. Some RM users buy RM solely to write scripts/plugins, and some of those are beginning programmers(I think that "Easy enough for a child" somehow applies to scripting/plugin development at least in VXA and MV as well), so potentially driving them away can lead to decreased sales, and I'm not sure whether it'll be compensated by the increased number of plugin users and veteran/professional plugin developers(as I don't have the numbers).

While I prefer more advanced yet also more effective and efficient constructs and techniques to be the default in the MZ codebase even when I'm still just a bad junior programmer, I think that this has to be a gradual progress.
I mean, I definitely expect a drastic codebase improvement from MV, but not so drastic that beginner MV plugin developers can't even recognize the important similarities(default functionalities, plugin development workflow, coding styles, etc) between MV and MZ codebase anymore, otherwise I could expect a drastic drop in the number of MZ plugin developers, at least in the early MZ days(which can last quite a long time).
In the case of adding native hooking support, I agree that this alone is easy, simple and small enough for even a beginning programmer to pick up quickly, but if there are man such "easy, simple and small" concepts new to them all at once, the combined learning difficulty can be unexpectedly high. Of course, I don't have access to the MZ codebase yet so I'm not sure, but if it turns out to have no default hooking API, then maybe it's because it's to avoid having too many new "easy, simple and small" concepts altogether.


In MV, there are some optional plugins that are shipped along with the MV itself. Also, I'm told that the MV editor's made with QT, meaning that programmers can write their own QML to edit the editor. Would it be acceptable for you to have those functionalities provided by free high quality MZ plugin with excellent supports written by some plugin developers, and be able to download some free editor mods given by some programmers?
As for C#, I wonder what do you think about transpiling C# to Javascript(I've no experience on this but I've heard that some such tools do exist), even though transpiled code can be very ugly at times :)
Alternatively, I'd like to know what you prefer in C# over JavaScript in MZ. If it's some kind of static type checks, then MZ later might have some official or nonofficial(from the community) TypeScript support. I don't know if you'll consider TypeScript a good enough substitute for C# though.


I'd summarize it as: It's generally easier to add new features than to remove existing ones in the codebase when developing plugins, especially when it comes to compatibility issues :D


In general, yes, but if the TPBS is written very poorly, then it can be a big no(I've worked with a very poorly written ATB system script in VXA so I know).
While I'm very confident that the TPBS will be very nicely written just like the rest of the MZ codebase(otherwise I could expect a very severe outrage from the community), I've to be able to actually access the codebase after I've MZ just to be sure whether turning the TPBS into CTB is indeed trivial :p
Yep i will be mainly working on the typescript definition files.
Meanwhile a certain kino might be working on a haxe support as well
:vxmegane:
 

ssunlimited

Veteran
Veteran
Joined
Oct 3, 2015
Messages
231
Reaction score
21
First Language
Russian
Primarily Uses
RMMV
Hey I have some questions about this, please answer them. Here they are:

1) Since we are talking about how you can choose to not upgrade to MZ if you don't want to, why exactly are they releasing this version? Also, who is being targeted for this release? Why wouldn't someone just learn to use more "flexible and powerful" game engines like Unity and Unreal but buy this?

2) What is the TPBS about? How will it work? Why is it being included as part of it built-in (not as a plugin)? What is different about it than the other BSs such as ATB and CTB?
 

Sharm

Pixel Tile Artist
Veteran
Joined
Nov 15, 2012
Messages
12,706
Reaction score
10,670
First Language
English
Primarily Uses
N/A
That first question is really odd. It's not all or nothing, you know, just because some people won't want to move on from other engines doesn't mean no one will. Lots of people have already stated they're going to buy it as soon as it's out.
 

MikePjr

Artist
Veteran
Joined
Nov 7, 2012
Messages
732
Reaction score
453
First Language
English
Primarily Uses
I feel like maybe I should say more on this topic.
But i'm not a programmer.. i'm an artist at best (geeze.. de ja freaking vu)
So i've got nothing much to add...
I could sit and talk about the sort of plugins i'd like to see.. but i think that would just put a lot of pressure on plugin creators.
Maybe i'll have more to say on the next announcement.
Honestly, i'm happy with the changes they have made to the plugin menu/system though.
I look forward to seeing what plugins get created.
 

nio kasgami

VampCat
Veteran
Joined
May 21, 2013
Messages
8,865
Reaction score
2,818
First Language
French
Primarily Uses
RMMV
Hey I have some questions about this, please answer them. Here they are:

1) Since we are talking about how you can choose to not upgrade to MZ if you don't want to, why exactly are they releasing this version? Also, who is being targeted for this release? Why wouldn't someone just learn to use more "flexible and powerful" game engines like Unity and Unreal but buy this?

2) What is the TPBS about? How will it work? Why is it being included as part of it built-in (not as a plugin)? What is different about it than the other BSs such as ATB and CTB?
Just going to answer the first as it is very odd.

Simply rpg maker is an engine that is extremelly good for newbie to introduces game dev.
Its also powerful enough to do some very good games such as to the moon , unravel and the witch house.

The strenght of rpg maker over unity is its simple to use and offers a lots pf toolset that you would need to program in unity.

I Can tell you that as yes unity is flexible but it require WAY more works than you have to do in rpg maker. I wouldnt recomend unity to a newbie.

As for why i would go for mz? Mainly i am excited for the new software in general rpg maker was the first game engine who introduced me to game dev and i just like the engine a lots.


And who is targeted for this release?
Anyone that want to do game dev lol
 

chalkdust

Resource Staff
Restaff
Joined
Mar 23, 2015
Messages
359
Reaction score
549
First Language
English
Primarily Uses
RMMV
Regarding the whole update-vs-upgrade debate.... It's clearly a full upgrade from an "advanced user" standpoint, but perhaps not for a novice user.

Improved map layer control alone is a big enough change to qualify as a full engine upgrade. People with beginner level mapping skills won't notice a difference, but it's a big deal for people who want to do more advanced mapping tricks, like creatively using transparent autotiles over ground tiles. There's no need for more layers. What we're given is perfectly adequate for a creative designer. Yes, it sucks hard that there's no tilesize option natively built-in, but the workarounds are adequate.

The JS updates and new Plugin Command puts massive power in the hands of plugin creators. This is another area where novice users won't see the value of the upgrade. It's a bit upsetting that top plugin makers didn't get a beta invite or something to get a headstart on their work. I hope that still happens before launch.

Generator updates are good. The offset function looks handy, especially for tweaking details on beast race faces which don't quite line up with human features. The gradients option is AWESOME, definitely not seeing the level of praise it should. The directory structure and filename scheme of the generator is fine. It's really not that difficult to figure out and work with. Really a non-issue. The only real problem is that the methods for adding nonhuman body options are janky (temporarily replacing the defaults, or by adding them as Facial Marks). Simply adding a Body category and leaving "Human" as the only default option would catapult the generator to the next level, and it would help add value for all those "novice users" that aren't really seeing the value of MZ. (Don't anybody tell me Japan doesn't understand the ROI on a generator capable of making cat-people!!!)
 

KoriCongo

Villager
Member
Joined
Jul 19, 2012
Messages
24
Reaction score
27
First Language
English
Primarily Uses
1) Since we are talking about how you can choose to not upgrade to MZ if you don't want to, why exactly are they releasing this version? Also, who is being targeted for this release? Why wouldn't someone just learn to use more "flexible and powerful" game engines like Unity and Unreal but buy this?
I can explain 1 for you.
Generally speaking, a company would like to have a consistent source of revenue. Physical goods will at least break and need to be repaired or even replaced. Software, however, basically has no shelf life. Meaning that eventually, the company that makes them cannot gain any revenue, as their consumer base hits critical mass. Everyone that would buy their service has already bought it.

So either they need to build a new product, or find a way to gain revenue off the existing product (see: subscription services). That's why these "marginal updates" to RPG Maker exists over just patching MV. It's a way to provide a means of revenue over building another free update. As they say, is man not entitled to the sweat of his brow?

The main complaint, however, comes from how pricing works compared to what they are getting for that price. Because they aren't treating this as an expansion, but a complete upgrade worth moving from MV to MZ, you have to argue a lot that it is something you should buy. Honestly, this is where the jump from VXAce to MV is biting them in the tail. For the same price, you got a lot of new features that...ultimately didn't work, but it was still major stuff, like multi-platform support, 48x48 tiles, resizable windows, mouse support. With that in people's mind, you can't blame them for wanting more for the same price.
 

ssunlimited

Veteran
Veteran
Joined
Oct 3, 2015
Messages
231
Reaction score
21
First Language
Russian
Primarily Uses
RMMV
@KoriCongo has explained it very well in his/her answer!!

I honestly had reasons to buy RMMV for plugin support, Javascript support (though this wasn't such a big reason, I just thought this was great), side view battle system, a little because of the tile upgrade to 48x48 and being able to export to multiple platforms (I only care about Android in addition to Windows.) See that's a lot, I only needed 2 major reasons, which are plugin support, export options and side view battle system. I have purchased RMMV as a beforehand as a pre-order. See that was a "real" improvement to a new RM. I just don't see it in RMMZ.
 

Knightmare

Knight of the Night
Veteran
Joined
Mar 14, 2012
Messages
1,128
Reaction score
217
First Language
English
Primarily Uses
RMMV
:kaopride:CHIBIS ARE GONE :kaopride:
I didn't mind the chibi style but this is an absolute upgrade :kaojoy:
You have no idea how much I wish that were true but it is still chibi.
 

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,616
Reaction score
670
First Language
Chinese
Primarily Uses
N/A
The JS updates and new Plugin Command puts massive power in the hands of plugin creators. This is another area where novice users won't see the value of the upgrade. It's a bit upsetting that top plugin makers didn't get a beta invite or something to get a headstart on their work. I hope that still happens before launch.
I also wish so(even though I don't think I'd nor should be ever qualified), but I doubt whether it can indeed work well:
1. Does those involved plugin developers need to sign some kind of (official or nonofficial) NDA to prevent them from leaking anything important before launch?
2. If that kind of NDA's needed, then can anyone written any script/plugin in XP, VX, VXA or MV just jump in(restricting it to MV can lead to backlashes from scripters sticking to earlier versions)? If there's no other criteria, then I'm afraid that the risk of leaks despite the NDA things being present would be too high.
3. If there are additional criteria, then what should they be? Objective metrics like the number of plugins and/or users(even then there's still a subjective part - What does these numbers mean)? Or partially subjective(but not entirely) metrics like popularity and/or reputation? Or are plugin developers just selected via some kind of poll(letting everyone or at least all plugin developers to poll)? Or are RM picking some plugin developers directly?
I can already see that getting the criteria, polling and/or selection process wrong can lead to irreversible PR disasters and even conflicts among plugin developers(in extreme cases their supporters as well) that are hard to reconcile, and I don't think that it's easy to get the criteria just right.
So while I share the same dreams as you on this one, I actually think that it can easily become a very bad idea :)
 
Last edited:

cji3bp62000

Tsukimi
Veteran
Joined
Oct 25, 2017
Messages
74
Reaction score
202
First Language
Japanese
Primarily Uses
RMMV
Why wouldn't someone just learn to use more "flexible and powerful" game engines like Unity and Unreal but buy this?
I would like to share my experience.

I got into game-creating from RPG Maker, and started making some games in Unity after made some plugins for RMMV. I'm now in a small company creating games using Unity. However, RPG Maker is always the first choice for me if I want to make some RPG games.
Why? Because creating all the systems by myself is REALLY, REALLY heavy work. RM provides a structured, stable and easy-to-use interface that could help me quickly make a prototype of my game plan. After that, I could continue making the game on RM, or switch to Unity if RM doesn't meet the needs of my game plan.
On the other side, Unity is indeed super strong, strong enough that it didn't provide any templates, expecting you to make all the systems by yourself (or to buy it from the asset store, which is a lot more expensive than RMMV). Time is money, so I would like to use some money to buy me some time.

There is no almighty game engine, there is a trade-off between flexibility and agility. For me, it is better to use both Unity and RM, and I love them both.
 

Touchfuzzy

Rantagonist
Staff member
Lead Eagle
Joined
Feb 28, 2012
Messages
7,148
Reaction score
8,476
First Language
English
Primarily Uses
RMMV
Sometimes I think it is funny that people consider some things that were from VX Ace to MV better and significant changes, when at the time, many people were saying "why do X, that is worse". Move to Javascript over Ruby. 48x48 tilesets rather than 32x32 were both heavily criticized.

I think it is interesting that people look at something like sticking with the same size tiles as "doing nothing" rather than "remaining compatible with the huge library of materials already available".

Like that was actually the reason for that decision. We wanted to make sure people could move to MZ as smoothly as possible and not feel like all the money they spent on MV materials was a waste, because people were not happy about all their VX Ace materials they spent money on being incompatible with MV.
 

R1PFake

Villager
Member
Joined
Jul 11, 2020
Messages
12
Reaction score
13
First Language
German
Primarily Uses
N/A
Im sure this was already answered but I can't find it anymore: Can someone explain how "turns" will work in the new real time battle system?
 

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,616
Reaction score
670
First Language
Chinese
Primarily Uses
N/A
Im sure this was already answered but I can't find it anymore: Can someone explain how "turns" will work in the new real time battle system?
I've just read everything in all 3 preview posts but failed to find an answer(maybe I've overlooked something), but here's my wild guess:
1. An ATB frame update is a frame that runs battler ATB value updates(e.g.: filling the battler ATB values)
2. Not all frames are ATB frame updates(For instance, in full wait mode, inputting actions won't have any ATB frame updates)
3. A turn consists of a certain number of ATB frame updates. For instance, if the game runs in 120FPS and a turn consists of 600 ATB frame updates, then the turn will last exactly 5 seconds if every frame's an ATB frame update.

Alternatively, turns can also work by counting the number of actions executed during the same turn.
If a turn consists of 10 actions and 10 actions have been executed after the turn has just started, then the next turn will come into play.

These are what I can think of when it comes to implementing turns in real time battle system, at least according to my experience in writing ATB system scripts/plugins.
Of course, it's entirely possible that the actual implementation might be something else entirely :)
 

Touchfuzzy

Rantagonist
Staff member
Lead Eagle
Joined
Feb 28, 2012
Messages
7,148
Reaction score
8,476
First Language
English
Primarily Uses
RMMV
Honestly a lot of the stuff with how turns are counted, I just want to make sure I get the information right before I say anything. We want to make sure it is documented correctly, and we're working on that.

I don't want to say it works one way, and then learn that that isn't actually how it works.
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,438
Reaction score
6,255
First Language
Indonesian
Primarily Uses
RMVXA
1) Since we are talking about how you can choose to not upgrade to MZ if you don't want to, why exactly are they releasing this version? Also, who is being targeted for this release? Why wouldn't someone just learn to use more "flexible and powerful" game engines like Unity and Unreal but buy this?
Literally "everyone" is targetted for this release.
As for why they don't bother to learn a more flexible engine, is exactly why because they don't bother to learn. And that's fine.

2) What is the TPBS about? How will it work? Why is it being included as part of it built-in (not as a plugin)? What is different about it than the other BSs such as ATB and CTB?
Because it is built-in, everyone will have the same reference to the codebase. If ATB/TPBS is separated, we will have like 3 ATB plugins and when someone said "I'm using ATB", you have to ask "Which ATB plugin". And if some of the features are added by plugins, the plugin dev probably will not bother to try in 3 different ATB plugins to make sure it works. But if it's in the codebase, it's easier.
 
Status
Not open for further replies.

Users Who Are Viewing This Thread (Users: 0, Guests: 2)

Latest Threads

Latest Profile Posts

ESAMarathon on Twitch, now streaming "Eat Girl". Yep, that's the title of a game... Apparently it's a Pacman knockoff.... Which is of course the only logical conclusion one would get from a name like "Eat Girl". :kaopride: I can't believe anybody would think anything else! :kaoback:
Super stoked i just finished my first town in my project, by finished i mean i can always add more decorative aesthetics and the NPCs don't talk yet but the mapping is complete and all the important chess pieces are present!
My brain: Hey, I have an idea how to make the transition to the main story quest in The Wastes more natural!
Me: Good!
My brain: You need to remake the hotel you start out in, it's not realistic enough.
Me: Ok... This was unexpected, but I can do it.
My brain: Now make each hotel floor 5 times as large to match the main part. Oh, you also need to make a bunch of new npcs to fill in the space on these maps.
Me: Crap.
Should be able to release Haxe MV/MZ next weekend.
It look that somehow MZ tracks are messed up (for example battle4 is obviously a theme, castle2 is a ship, ship1 is a scene and so on..). Maybe they just named them after with some ambiguity.

Forum statistics

Threads
100,617
Messages
977,828
Members
132,227
Latest member
YourBaka
Top