While that is true, several of the requests in this thread are about stuff like "tactical/action battle systems", "pixel movement", 3D or other functionality that is not baseline. RPG Maker needs to be a framework. Anything that exists within it must not get in the way of the user. Having a tactical battle system hardcoded in the base engine would get in the way of any user that's not making a tactical RPG.
I see you missed my point about only including the "industry standards". 3D isn't an "industry standard". It is a Stylistic Choice. Pixel Movement could also be considered a "Stylistic Choice". "Action Battle Systems" isn't an Industry Standard either. Nor are "Tactical Battle Systems". These are genres of games to be more precise. There's a world of difference between a Turn Based RPG and a Tactical Based RPG.
Though, perhaps there's a separate point to be made there. If there are potential customers who want to create these types of games, perhaps there's money to be made in creating RPG Makers that cater to those specific genres.
But, no, I do not expect the next RPG Maker to cater to those crowds as those aren't "industry standards" for Turn-Based RPG's, which is what RPG Maker has always been. They're not even all that heavily requested features for the engine.
However, something like "Active Turn Battles" where speed fills a meter and then you get a turn... That's more in line with an "Industry Standard" for Turn Based RPG's. It's frequently requested and even used.
So that's the distinction to keep in mind. New features are welcome, but only stuff that is baseline; anything that's specific to a project should be a plugin and not base engine.
Yes, anything specific and relatively "unique" to a project should be a plugin or a script. Not things everyone changes or requests plugins for constantly.
Which, if we're honest... Eliminates most of the plugins and scripts people post on these forums. At least, if they're made "standard" to the maker.
Wrong. The purpose of a plugin or script should be to do something that is not integrated with the base engine for the aforementioned reasons. Trying to make every feature that 20%+ of the users of the program has ever thought about something that's deployed within the base engine is pure insanity. Giving that to us as free, or even paid, DLC, would be an act of generosity.
Why are you contradicting yourself? You were doing a fine job agreeing with me that plugins should be used for things specific to a project, and then you go and say that something that 80% of users would use and request is the purpose of the plugin.
No. No no no no no no no no no no no no no no no no no no no. The purpose of a plugin is to do something fairly unique to your own project. It is not to add basic functionality and common features to the base program because the devs of said program were too lazy or too short-sighted to even know what the Industry Standards are.
If 80% of the users of your program are requesting the ability to resize windows or have greater control over customizing those windows... Guess what? That's not a job for a plugin! That's a job for the devs to implement into their next iteration! INDUSTRY STANDARD. If 80% of your users request and use a "Quest Journal" plugin... INDUSTRY STANDARD.
The purpose of a plugin or a script is to cater to the 20% who request "niche" things. "I want a Stagger System in my game, and it needs to fit X specifications". Okay, script or plugin for it. Not many people use it. Not many people request it. That is the purpose of a script or plugin.
It is pure insanity not to include features that 80% of your users want, request, or need. That's just bad business. Heaven help you if someone else ever comes along and offers you a program similar to yours, but it does the 80% of things the customer base does while you refuse to. You've just been put out of business if that happens. Can you imagine that? Someone comes along and advertises, "It's like RPG Maker, except it's better!" and it does all the things the devs refuse to make standard? Yeah, there goes your customer base. There goes all that wasted dev time into the new product you wanted to sell, because you refused to cater to the majority of your potential customer base.
It's just business. If you want to keep customers, you cater to those customers.
"Good customers are as rare as Latinum. Treasure Them."
It's a complete overhaul in the base framework / backbone / code that makes the engine run. Even if it superficially looks the same, it's still something new that gives us a large amount of new options. If you don't need them, then you shouldn't buy the new RPG Maker.
MV might feel similar to Ace, but things have been achieved within it that, because of the updated framework, could hardly have been achieved with Ace.
I have a hunch that the new MV will look even more similar (superficially) to MV but will give us a ton of power, and it's technology that the devs are now familiar with and could greatly improve and polish (unlike 5 years ago when they released MV)
If it's just an overhaul of that stuff, then I expect it to be an update to the existing program rather than an entirely new paid product. After all, we're dealing with software here and not hardware. If you just update/upgrade your software to be more efficient in terms of code and such, then it's just an update.
I will refuse to pay for such an update as it's a ripoff (this isn't hyperbole, this is fact).
I'll buy a completely overhauled engine that implements Industry Standards in place and has more resources available within. As in, I'll buy a completely new product if it's good enough. I'm not going to drop money on the same product just because the devs figured out in 5 years they can make code more efficient.
Let them roll out an update to the existing program if that's all they're going to change/fix. Don't rip me off by trying to sell me the same product again, "except better, 'cause we know how to optimize our code this time".
Customers should not have to pay for dev/designer oversight.
But yeah, my guess is that the new RM will be a rebuild/heavy improvement over MV, with the team going back to the drawing board and rebuilding the engine from scratch with the acquired expertise, and technological improvement, of 5 years dealing with JavaScript, to deliver a product that is sturdier, more modern, more compatible, easier to program in, while delivering a familiar toolset.
This is my guess as well... and why I'm not eager to drop money on it. Without a complete overhaul of every feature and implementation of Industry Standards, there is little reason to buy it. There are faster ways to get rid of money, like throwing it off a bridge.
It is simply asinine to create a product that is a "slight improvement" over the last one and try to sell it at "full price". Though, I guess there are enough stupid customers that companies like Apple can get away with it year after year.
We've got a 5 year gap here. What I expect of a company that took 5 years between products is to have been doing a ton of market research and built an engine with all the most requested features in it as well as most common plugins used, as part of the backbone.
If all we have to show for 5 years of time between releases is, "here's a new feature, and we overhauled all the code", then I seriously wonder how they're managing their money over there at the company. Mismanagement of Resources does not often make for a strong-standing company.
