I did not mean to start a discussion. Indeed, I never solde my stuff yet... And tax is certainly not my point of expertise.
...
However, this is horribly off topic.
I did not expect to be quotes so many times. It is hard to keep track of it all. (I wish I got that much response when I am right...)
Lol! Yeah, don't worry too much - it's just that I sensed that an objection to what I think is the single most important and necessary thing we could add to RPG Maker (an in-engine Asset Store) was coming from a place of ignorance, so it was very important to me to clear up your misconception about whether an official store taking 30% would starve artists (it doesn't). I didn't mean to browbeat you.
Several years ago I
did devote a lot of time creating RPG Maker scripts that I was hoping I'd be able to make enough money on I could do it full-time, and what I found was that without an official channel to go through it was extremely hard for anyone to find me. I didn't earn anything at all from my public scripts (at least I was able to parlay it into a few commissions).
===
1. I am finding it amusing how many people are misusing the word "bloat" as something interchangeable with "lazy" or "out of touch with the current market and so don't know what the Industry Standards are".
...
To the first point, if you want to know what "Bloat" actually is... Go look up "Star Citizen". THAT is bloat. People requesting features that most people on these forums change for every game they create... That's not bloat. That is "necessary".
I think when people were bringing up bloat (at least the way I read it when people like Shaz mentioned bloat), they were making the point that adding too many features inside the engine (as default functionality rather than plugins) would badly hamper the deployed game's performance and processing.
For example, a couple people mentioned adding in the entire Yanfly suite, and while a lot of Yanfly's added features are very useful and welcome, if you've ever tried turning on the whole suite (and using most of its features) in an MV project, loading that project up with a realistic number of events (such as 40 events and 1 parallel process event per map), and running it on a mid-range Windows PC (forget the HTML target!)... well, it doesn't run that well, because there's just far too much the game needs to run under the hood.
Additionally, "bloat" can be about adding too much complexity to the core editor - making newer users get completely lost. Not being able to find functionality due to "too much noise" is a small issue, but the bigger issue is if a feature would force you to take extra steps in order to get the most basic game to work. (
RPG Maker 2 on the PlayStation was notorious for this - it offered so much flexibility, but most people who tried it, including a 15-year-old me, couldn't even get their character to walk on a map).
I kind of come down in the middle here - I think that if a feature is something that almost all decent developers would benefit from in almost any RPG they could want to make,
and the feature is something that wouldn't make it any more difficult/confusing to make your first "Ralph crosses the map and fights the Boss" game, then I think it's probably worth adding. Yanfly's Skill Core and State Core are great examples of things that would make the Editor a far better tool. On the other hand, if a feature is specialized to a small number of games, requires a lot of processing power, or would make "Ralph crosses the map" harder to make, it's probably best left to outside plugins. Yanfly's Area of Effect and Weak Enemy Poses plugins are good examples - great plugins that work best as plugins rather than core features in the editor.
===
On asset store topic:
Now on the topic of the asset store itself. I get where you came from. And if they wanted to implement the store, the best start would be to integrate the RMW store first. However, they also sell the DLC on Steam (heck, the main engines are on Steam as well for more potential software buyers). I'm not suuuure now how that could work with the store. If they want to start the store, they better be prepared and I don't think right now they're prepared enough for it.
Don't get me wrong, I don't dislike the asset store idea. I'm just not optimistic enough for that to happen anytime soon (or at all).
Without a doubt, the in-engine asset store would require a lot of planning and a lot of work to implement, not to mention a little bit of disruption toward the asset channels used in the past. You may very well be right that it won't happen in the next version of RPG Maker or anytime soon. But I hope that it does!! I think it would truly be a breakthrough for RPG Maker as a game development engine. And it makes a lot of business sense from all sides, too.
On page script eval condition:
Well, page condition eval script is not entirely impossible. And actually, as a designer, it is your responsibility to "manually refresh the map". Here is an implementation that could work. Consider that page eval condition exists (adding the condition is easy to implement, refreshing isn't) and you want the event page to switch if the actor HP below a certain value. For whatever minigame you have on that specific map.
- Consider you have a map hazard that needs to avoid. And your HP drops if you make a contact with it.
- On the contact, you reduce the actor HP using event commands as well as calling
$game_map.need_refresh = true, that will manually refresh the map, and the page will be switched.
The problem is now you need to it manually
whereas RPG Maker should handle it for you. I believe this is what you have asked. Maybe you just didn't encounter a case when the Hime script just fails to do its job.
As far as I can tell, Hime's script has never failed to do its job. No matter what wacky conditions I add into the Custom Page Conditions, the events refresh perfectly.
I
think I do get what you are saying, but if you're worried about the processing load becoming very high when lots of events need to have conditions checked each frame (instead of only when, for example, a Switch is changed), then wouldn't it make sense to have the engine track which events need to be re-evaluated when certain things are changed (e.g. only events with a "Harold has State X" condition will be checked when Harold gains/loses a state), instead of triggering a need_refresh for the entire map?
Adding more conditions is a more reasonable request. As for now, one thing that drives me crazy is the fact that variable condition only lets you set it to a certain value and above. Why no other choices like exact value or below? Granted, the workaround exists, but it's inconvenient. I see no reason why they need to keep it that way.
Yeah, the "is X or above" page condition always struck me as a strange limitation, too. I could certainly get behind "more page conditions" as an improvement over what we have now! But in my honest assessment having Event Page conditions be as flexible as Conditional Branch conditions is important enough in creating games that it would be worth a small performance hit.
On event x event trigger topic:
Exactly this is the reason why they need the editor itself should be editable/moddable. However, I have no idea how to make the editor itself editable. The editable editor itself has many challenges on its own that I'm also not optimistic enough for that to happen. The only editable editor I know was just Unity. You drop the script component to the object and it will have an exact property field you defined in the C# script.
I would love for the Editor to be more moddable! When I first heard about Plugins in MV, and how they would "offer a front-end interface to change how your game works", this is what I was dreaming of! I thought our "plugins" would be able to add tools and controls to the editor itself that would interact with scripts. I was so freaking excited for it. As it turned out I misunderstood it, and at least so far, RM's devs have been (very understandably) hesitant to open up the Editor's code for modding.
I don't know whether that will change in the future or not, but it's one of the main reasons (alongside compatibility) that I'd rather have something like Event x Event triggers built into the editor rather than offered only by plugins. When there's a control for it in the editor, it's a lot harder to mess things up than when you have to manage things with free text notetags scattered across events.
I'm also no expert on OS-related process (I'm only good at programming logic and algorithm). But as for office software, it is probably easier because they only handle a single file. The entire RPG Maker project? it has many files. To be fair, it is not entirely impossible. All you need to do is to make the RPG Maker software to have "service" run on the background to constantly check and if a certain time passed, make a clone ONLY the data files. Because that is where the important thing matters. If those files corrupt, you have to start over. But if only the assets are corrupted, you can put a placeholder. No need to have the entire project. However, I also have no idea how hard it would be to make a service to do so.
It's beyond my pay grade for now
On resource stripper topic:
This [400MB early demos] is funny and I can relate it so well. Probably one of the huge list of the reasons why I still like VXAce.
It always surprised me that the series moved away from having a centralized RunTime Package! (And it's one of the reasons I'm a big XP/Ace fan, as well.) A Resource-Stripping tool would go a long way towards making the new approach feel good.
Wasting the player's drive space is true, but I'm not sure about the performance hit. I mean if it just sitting there unloaded, why would it hit performance?
I
thought that the MV Engine had to load all resources at least once (even if they weren't going to ever be displayed in game). I could definitely be wrong on that point.
To be fair, A resource stripper is a valid idea. However,
they should state it clearly that it's not a silver bullet especially when it comes to detecting files used in plugins. It just there is no easy way to do so. And don't get me wrong, I actually made
my own script to list the resource used in the VXAce project with addition to stop the game from crashing when a resource is missing while also record what is missing in a separate text file so I could look it up.
Total agreement! The theoretical Resource Stripper would be completely reliable in basic games, but once players are using plugins or script lines that dynamically name resources, it would be up to the designer to add those resources back in. I think it wouldn't be too hard to express that in some help text that could display when choosing whether or not to use the Stripper during deployment.
And wow, you created a script that prevents the game from crashing when a resource is missing? That's awesome, man!! That would honestly be a nice feature for an engine, too. Glancing through your script I see a lot of Rescue blocks, which makes sense for this kind of thing. Once the player has attempted to load a graphic into the game (and can't because it doesn't exist), what happens if the player then tries to manipulate that graphic? Is that also covered by the Rescues throughout your script?
Once again man, thanks for all your thoughts on my ideas, it's a pleasure talking through them with you.
Now give back my two hours!
