A New RPG Maker draws near! Command?

Status
Not open for further replies.

Makeratore

Veteran
Veteran
Joined
Feb 9, 2014
Messages
209
Reaction score
71
First Language
Italian
Primarily Uses
RMMV
While I'd love the new RPG Maker...

It seems like we have "removed features" ever single iteration of these things, and I'm just not really all that fond of continuously losing functionality and well-designed user-friendly stuff.

If you want a "Day One" purchase from me, then it'll have to come with more than like 40 monster sprites. Like, I'm looking for at least 250 in the style of the RTP (at least if the RTP is good, as it usually is) and covering most of the common monsters you see in RPG's. Wolves, Bears, etcetera.

I'm not looking to buy a "minimum viable product" and then HOPE it eventually sells DLC or Features I can actually use. Most of the DLC resources released with MV are nigh unusable or clash heavily with each other.

Otherwise... I think it'll probably be a "wait and see, and buy it only if they haven't removed more stuff".
PREACH! :thumbsup-left:B):thumbsup-right:
 

Shaz

Veteran
Veteran
Joined
Mar 2, 2012
Messages
39,661
Reaction score
13,271
First Language
English
Primarily Uses
RMMV
there would probably have to be a lot of new built-in functionality to get much of the existing customer base to switch over or to convince new customers it's worth buying over existing RPG Makers that already have a ton of community created custom options
I bet a lot of people said exactly the same thing when MV was first announced. MV did not have all the Ace script functionality built in, and it was added over time. The new maker will probably be the same.

As long as its 100% backwards compatible with MV, I'm on board.
lol - the only thing that would be 100% backwards compatible with MV, is MV ;) If you don't want something that's different and won't just take your MV project without you having to update stuff like plugins, then stick with MV.

I doubt that they're taking requests at this stage. If it's been announced, I'm thinking the guts of it is already made and they're just tweaking and debugging now. I'm guessing things posted in the MV Improvements forum were considered, as well as stuff in Touchfuzzy's thread from a few months ago asking what one thing people would like in a new maker.

I'll be preordering and making plugins for it :)
 

JosephSeraph

White Mage
Restaff
Joined
Mar 7, 2014
Messages
1,169
Reaction score
1,417
First Language
Portuguese
I’m a little deflated by this news because of the games I have prepped for and planned for MV. There’s this sense of FOMO. It’s completely irrational and I can’t blame Kadokawa for it.
Just wanted to add that, to be honest, there's no better time than now to make an MV game. Also to make a 2k3 game, since through the years (AFTER MV's release!!) it's been patched and improved several times, both officially and extra-officially. XP and VX are deprecated somewhat, but the Ace scene is quite alive and it's a good moment as ever to make an Ace game, too.

I'm verily looking forward to the new engine, though, I'm HYPE. Even if I'll probably not use it seriously for a long time -- I"m working on 2k3 games for fun and on a commercial VX Ace game, for instance.


Edit: Also, everytime I read "please don't be 3D" I chuckle. The LAST thing I expect them to do is a move to 3D. Also everyone that's requesting for "skill trees", "action battle systems" etc... Forget it, imo.
RPG Maker's default is supposed to cover the basic framework, the very same basic framework we've always had. Add a default implementation of ABSes or skill trees, and you're making every programmer's life hellish; these things are plugins for a reason. That being said, if they're feeling particularily generous, a plugin for these things would be nice. But I don't think the editor should have free extra features like this a plugin, they certainly wouldn't have the resources to maintain it.

What I honestly want to see is for you, programmer, to read the wishlist people are dropping here and cook up a nice plugin. Just PM the mods, IDK, PM Touchfuzzy. Pitch your work. Show the stuff you've made for MV. Create a prototype for this new engine whenever possible. And release it as a commercial product. It would 1000% be more quality than anything that'd come bundled by "default" by a new RPG Maker, merely because of having a programmer dedicated to creating and sustaining such a project for a long period of time.

I love the commercial plugin scene for MV tbh, and if it were to expand, in addition to or even mostly replacing the free plugins we've had, we'd have much more quality -- but paid -- content. Archeia's Luna Engine, or Olivia's Octobattler pack come to mind, both beautiful pieces of quality work.

Contrast some other lovingly crafted, amazingly dedicated pieces of work created by the RPG community -- you get some great stuff like the Tactical RPG systems we've had in the past like Gubid's GTBS, that other amazingly extensive MV one whose name I forgot, and a few others currently in production. But they hardly reach a stable build and their devs hardly can spend time on them, often quitting before hitting 1.0, because of financial insustainability. So if That One MV Tactical RPG Script (which had P**slur**on funding, but wasn't really a commercial endeavor) or Moghunter's Linear Motion Battle System were commercial products sold on itch.io or even especially on RPG Maker's own store... I bet they'd be sturdier and more stable now

Wow that's a big post but idk PEOPLE, MAKE COOL STUFF, thx <3 I'm looking forward to a healthier, richer commercial plugin development scene for this new era.
 
Last edited:

Wavelength

Edge of Eternity
Global Mod
Joined
Jul 22, 2014
Messages
5,404
Reaction score
4,801
First Language
English
Primarily Uses
RMVXA
Command? FIGHT!!! :XP1D:

Super excited to see a new RPG Maker is on the horizon! Twenty-five years (and lots of copycats) on, RPG Maker is still the best at what it does.

I have no idea how far into development it is, but if there's still a ways to go, here's my wish list for what I think would make for a nearly-perfect Maker:


WAVE'S TOP THREE WISHES
  • Integrated Asset Store: An asset store for official and community-made resources, inside the game engine itself; once you buy something, you can immediately add it to your project.
    • This would allow a full community of asset developers to thrive, and make it easier than ever before for designers to find what they need... not to mention it would be an enormous source of income for Degica/Kadokawa!
  • Window/HUD Editor: A new Manager within windows where you can "create" windows by specifying what information appears, where it appears on the window, and how it looks (font, text color, window color, borders, etc.), as well as "Show HUD" and "Hide HUD" event command to display windows in-game. Windows like Window_Equip and Window_Gold would no longer be hard-coded in the game's code base, but would simply be provided as "defaults" in the Window/HUD Editor. (The ability to also create/edit selectable "command" windows would be amazing, but is admittedly a bit of a reach.)
    • This would allow non-coders to easily give their game a unique look and feel, and allow designers to provide useful interfaces for any unique mechanic they come up with. It would even allow resourceful designers to event smooth, interactive custom menus!
  • Flexible Event Page Conditions: Similar to Tsukihime's Custom Page Conditions script, which is the single most useful script ever made, this would allow you to enter any Condition that you could enter into a Conditional Branch, and use it as a Page Condition for an Event to determine whether that page should be active.
    • This would free designers from the limiting and arbitrary subset of page conditions they're currently allowed to use for Event Pages - and allow them to get much more creative with their eventing.

OTHER GAME-CHANGERS
  • Fully-Documented Code Base: Documentation that explains what each method in the game's (visible, editable) code does, how it does it, and when it usually gets called - as well as documentation showing the entire flow of methods for common actions such as "battler uses a damage skill" or "player changes a character's equip".
    • This would make scripting far more accessible to the community, save experienced scripters tons of time, and accelerate the curve toward a solid library of scripts/plugins for the new RPG Maker (making it a more appealing buy for current MV users).
  • Triggered Battle Effects: Similar to Yanfly's Skill Core and Buffs & States Core for MV, Battle Effects would allow you to attach effects (such as "gain HP", "receive a new state", or "run a script line") that trigger when certain actions take place (such as "this battler is targeted", "this battler is hit", "this skill deals damage", or "this state is removed naturally"). Battle Effects could be added to any page of the Database that already has a "Features" Box.
    • This would allow a truly enormous variety of cool mechanics to be easily implemented into games without relying on plugins.
  • Full Keyboard Support: Ability to map game functions to any key on the keyboard, and to check whether any key on the keyboard is being pressed, instead of Ace/MV's very small list of keys.
    • This would allow greater control scheme customizability, enable cooler evented minigames, and make RPG Maker a better platform for strategy and simulation games.
  • Event x Event Triggers: A new Event Trigger option, which causes the Event's content to run when it collides with another Event (similar to the current "Event Touch", but not limited to contact with the player). When this Trigger is selected, the designer can choose to allow triggers with any event (including the player), with a specificother event, or with any event that has a specific event graphic (useful to represent collision with a certain type of object).
    • This would be extremely useful for puzzles, minigames, action sequences, visual encounters, projectiles, and interactive objects, as well as fine control over cutscenes/sequences where the designer may not know where every actor is at all times.
  • Improved Animation Editor: If an entirely new Animation Editor would be too much, some smaller improvements could include allowing up to 8 cel sheets per animation, a side window that contains a clickable list of all existing cels on the frame, the ability to zoom the view in/out, and the ability to choose Events as the sample target for previewing animations.
    • This would improve what is probably the most frustrating section of the database. In particular, allowing more cel sheets would foster creating complex animations without onerous workarounds, and the side window would give the designer an "at-a-glance" view of their cels in complex animations as well as make it much easier to change a cel's options when there's another, larger cel on top of it.
  • "User" and "Targets" in Events: In addition to "Entire Party" and "Entire Troop", the keywords "User" and "Targets" would also appear in event commands where you select a battler to do something to. "User" affects the battler that used the skill or item that calls the event; "Targets" affects all targets that were hit by the skill or item that calls the event. If the event was not called by Skill/Item usage, the event command will affect no one. New Conditional Branch checks "User equals ___(battler)___" and "Targets include ___(battler)___" would allow you to branch based on whether a given battler (or the keyword "No One") is stored in User or Targets.
    • This would free designers from the horribly complicated workarounds they are currently using in Ace and MV to perform additional processing on users/recipients of a skill or item.
  • Main Menu Editor: A simple database tab that would allow designers to add/remove commands from the "main menu" (in-game pause menu). Adding a command through the editor would allow you to specify a single common event or script line to run when chosen. The designer can specify whether an Actor should be selected for the command (which would be passed into the Common Event as the "Target", per above).
    • This would allow designers to heavily customize their menu system without adding significant complexity nor requiring anything too big or new from RPG Maker.
  • Battle Command Editor: A simple database tab that would allow designers to add/remove commands from the actor command menu in battle, on a per-actor basis. The designer could specify what happens when a command is chosen: Perform a Skill, Open a List of Skills, Escape Battle, Run a Common Event, or Run a Script Line. Conditions could be assigned to Commands to determine whether they should be visible/hidden and enabled/disabled. The designer could specify that certain commands do not consume the actor's turn. Add Skill Type/Seal Skill Type could be removed from Features boxes. The extremely unliked "party command" window (Fight/Escape) that appears each turn could be removed from the engine entirely.
    • This would not only streamline the battle interface, but would allow designers to get very creative with battle mechanics and interface features. Changing battle commands is one of the most-requested items on the Script Requests board, and this feature would let designers do it themselves.
  • Native Parallax Mapping Support: A project-level option, "Parallax Mapping Mode", would be available. When enabled, tileset passability is ignored, and the designer can individually set the passability of each tile on the map (with conveniences similar to MV's mapping tools, such as Rectangle and Fill). In the game itself, the parallax background layer will scroll 1:1 with the player's movement (acting as the map). Ideally, a second "over" layer could also be added to display things on top of the player/events.
    • For several years now "artful" games have been turning to Parallax Mapping scripts/plugins, and needing to struggle against the engine to implement passability. This feature would support development of games that make RPG Maker look really good.
  • Automatic Backup Option: An option the designer can set to automatically create backup copies of their project in a specified folder, with a specified frequency, up to a specified "total size" of existing backups. The backup will be created in the specified Backup folder when the player Saves their project. If the total size limit is violated, the oldest automatic backup copy will be deleted.
    • This would mean no more tears from corrupted project files or terrible mistakes! You could just switch to a backup copy.
  • Performance Enhancements: Any and all possible enhancements to make the built game run more smoothly would be appreciated, particularly a better system for evaluating whether to run event pages on maps.
    • This would improve the playability of deployed games, especially on the HTML target and on slower computers.

WOULD BE NICE
  • Resource Stripper: Sounds kind of dirty, but what I mean is a tool that checks your entire project to see which graphic and audio resources it is using (including ones referenced by name in plugins), and onlyincludes those resources in the packaged build that the engine creates when you Deploy your game. The designer can choose to use or ignore this tool during Deployment.
    • This would allow designers to share their games' early builds without 400MB file sizes, and improve technical performance for completed games.
  • Multiple Battle Systems: This is probably the biggest "reach" on my list, but I think it would pay off huge. Giving the designer a choice between "Standard" (current MV-style battle structure), "Individual" (issue commands to actors immediately before they act, one at a time), "CTB" (battlers' turns are dictated by an AGI-based formula, with fast battlers able to "lap" other battlers in the rotation), and "ATB" (battlers have ATB gauges, and get turns when their ATB gauge fills up), would be incredible. Event Commands could be used to change the game's battle system mid-game, except while already in battle.
    • This would provide several battle systems that not only are as common in RPGs as RPG Maker's "default" system, but would also provide a way to achieve them without entire battle system plugins, which (because of their large scope) tend to cause numerous incompatibilities. Action and Tactics battle systems would require too much change from the core product, but Individual, CTB, and ATB systems are very feasible leaps that wouldn't require changing too much to make happen.
  • Object Instantiation: Addition of a "Create Instance" Event Command that creates a copy of any specified event on the same map, in a specified location, and optionally assign it a specific Event ID. Self Switches could either be copied to the copied event's state, or initialized to OFF.
    • This would have tons and tons of uses, especially for visual encounters, minigames, projectiles, building customization (by the player), randomized dungeons, and extension to other genres beyond RPGs. It would also make it far easier to make changes to a large number of events, by using Instantiation to copy the event as the game is played - meaning only one event must be changed instead of dozens.
  • Ten Audio Loop Channels: The "BGM" and "BGS" channels would be replaced by ten numbered channels, and the "Play BGM" and "Play BGS" event commands would be merged into a single "Play Audio" (Fade and Stop BGM/BGS will also be merged into Fade Audio and Stop Audio). The Play Audio command would ask you to choose both a file and a channel, and the audio will keep playing on that channel until you fade/stop it or play another file on that same channel.
    • This would allow designers to play multiple BGMs/BGSs at a time, and also remove the unnecessary segregation between the two.
  • Granular Event Speed: Allow designers to enter decimal amounts when setting event movement speeds. Allow a "Custom Speed" option on all speed selection dropdown menus, which prompts the designer for numeric text entry. (From my own testing in Ace, I've seen no ill effects when setting events to decimal movement speeds such as 4.75, or even absurdly fast speeds like 9.00).
    • This would allow designers to nail the middle ground between two speed levels where one feels too fast and the other too slow. It would also allow designers to choose speeds above 8x Slower or 4x Faster.
  • Change Actor Graphic Feature: An option in the Features Box on the Class, Weapon, Armor, and State tabs called "Actor Graphic", which automatically changes the actor's graphic to the specified graphic when the actor has this Class/Equip/State applied. Sub-options include Actor (choose "all actors" or only a specific actor), Graphic (choose the new target graphic for that actor or for all actors), and Priority (if the actor has multiple Actor Graphic features applied, the highest Priority feature will be used). When the class/equip/state is removed, the actor's graphic will revert to their last (non-feature) graphic. (Change Actor Graphic event commandswould be given a checkbox option to "Override Actor Graphic Features", which would ensure that the graphic changes even if an Actor Graphic feature is present on the actor.)
    • This would allow designers to visually show states that characters are suffering from (such as Dragon Warrior's coffins for KO'ed party members), weapons that actors have equipped, or special class graphics for characters, on the adventure map.
  • Pixel Movement: Designer can choose whether to have events move one "tile" at a time, or four pixels at a time. Collisions could still be kept to tile-based bounding boxes in order to keep things simple, but movement would be much sleeker. Designer could turn Pixel Movement on and off mid-game using Event Commands. Movement commands using pixel values could be entered into Move Routes.
    • This would greatly improve the game's slightly clunky "8-bit" feel, and allow designers to create more exciting light action segments.
  • Native 8-Direction Support: A new database option for "Allow 8-directional movement" would be available. Sprites would be designated as 4-direction or 8-direction sprites; 4-dir sprites would display the nearest direction when the player is moving diagonally. Moving onto a tile diagonally (e.g. lower-left) would require that the tile is passable from both those directions (down and left)
    • Again, this would significantly improve the game's feel for the player.
  • Advanced Event Animation Options: Allow Events to use any number of "walking" frames, not just 3. Have an option in the editor to "Enable Advanced Event Animation", which enables a numeric field in the Event Display Options box (alongside "Walk Anim", "Direction Fix", etc.) where the designer can input the Number of Frames (columns of sprites) the event graphic contains, and a checkbox "Cycle Animation" which indicates the animation should loop rather than reverse (e.g. frame 1-2-3-1-2-3-1 instead of the default 1-2-3-2-1-2-3).
    • Number of Frames would be useful for games with custom character graphics that have more (or less) than 3 animation frames. Cycle Animation would be extremely useful for animated "events" like rotating waterwheels, especially when combined with a large number of frames.
  • Sideview Flip and Actor Positioning: An option on the System tab to "flip" (mirror) the actor sprites in Sideview Battles, so that they are facing towards the right. Additionally, a function for the designer to dictate what X and Y positions the first, second, third, and fourth actor in the party will be placed at.
    • This would allow for better artistic direction and variety in games, with almost no extra complexity nor overhead in constructing the engine.
  • Deco Events: Allow the creation of Events with zero event pages (keep the default at 1 page when an Event is created in the editor), so that designers can use an event graphic as a decoration.
    • This would improve the game's performance by eliminating completely unncessary event pages.
 
Last edited:

rue669

RueToYou
Veteran
Joined
Aug 29, 2016
Messages
443
Reaction score
362
First Language
English
Primarily Uses
RMMV
Just wanted to add that, to be honest, there's no better time than now to make an MV game. Also to make a 2k3 game, since through the years (AFTER MV's release!!) it's been patched and improved several times, both officially and extra-officially. XP and VX are deprecated somewhat, but the Ace scene is quite alive and it's a good moment as ever to make an Ace game, too.

I'm verily looking forward to the new engine, though, I'm HYPE. Even if I'll probably not use it seriously for a long time -- I"m working on 2k3 games for fun and on a commercial VX Ace game, for instance.
Totally. MV has had so many options and features and plugins added to it that it's never been a better time to make a game on MV, which is why the transition period between RPG Makers exists.

I have such a love for RM2k3 from my past that I don't know why I didn't just stick to it. Probably because of the whole "oooohh...new shiny thing!!"

I think the only thing that would make me want to switch makers if this new one made it easy to port to Switch. I am not interested in PS4 or Xbox as I wouldn't play an RM game on those consoles, but I would play RM games on Switch and the PC (like my laptop). But I see porting to the Switch to be very very difficult. People pay anywhere from 40k-150k now to hire programmers to port their game to consoles. It's a complicated process!
 
Last edited:

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
30,397
Reaction score
7,222
First Language
German
Primarily Uses
RMMV
"removed features" ever single iteration of these things
no, the last removals were with RMXP and RMVX - both Ace and MV only added features to the previous versions.
 

Tai_MT

Veteran
Veteran
Joined
May 1, 2013
Messages
5,453
Reaction score
4,776
First Language
English
Primarily Uses
RMMV
no, the last removals were with RMXP and RMVX - both Ace and MV only added features to the previous versions.
I have no way to disagree since I didn't play around with VX Ace all that much to see what all was missing. However, every version of the program before VXAce had at least a single feature removed, many of them had multiple features removed including many "user friendly" options and then they were replaced with what is currently existing in MV... which isn't all that user friendly... or versatile... or useful.

You can see my thoughts on the Makers here as a "quick and dirty" explanation.


My actual list of features I want in the next maker would be larger than this thread so far and most are just simple QOL improvements we likely will never see... Or, features that bring the engine up to "RPG Industry Standards" rather than leaving it stuck in the mindset of 1988.
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,443
Reaction score
6,259
First Language
Indonesian
Primarily Uses
RMVXA
Integrated Asset Store: An asset store for official and community-made resources, inside the game engine itself; once you buy something, you can immediately add it to your project.
  • This would allow a full community of asset developers to thrive, and make it easier than ever before for designers to find what they need... not to mention it would be an enormous source of income for Degica/Kadokawa!
This would be an extra cost for Kadokawa/Degica. Besides I have no idea how could this being implemented in apps. When you claim a resource, do you download it in and put your project or do you download it in as local files that you have to save it manually? what if you have multiple projects? do you re-download it? I'm probably just being skeptical anything about "Store" tbh. It is better for the user to just educate themself than the store trying to make it user-friendly.

Window/HUD Editor: A new Manager within windows where you can "create" windows by specifying what information appears, where it appears on the window, and how it looks (font, text color, window color, borders, etc.), as well as "Show HUD" and "Hide HUD" event command to display windows in-game. Windows like Window_Equip and Window_Gold would no longer be hard-coded in the game's code base, but would simply be provided as "defaults" in the Window/HUD Editor. (The ability to also create/edit selectable "command" windows would be amazing, but is admittedly a bit of a reach.)
  • This would allow non-coders to easily give their game a unique look and feel, and allow designers to provide useful interfaces for any unique mechanic they come up with. It would even allow resourceful designers to event smooth, interactive custom menus!
This can be a great idea and honestly, if this is being implemented in a user-friendly manner, I'm very curious about the programming behind this idea while still allow you to "patch" them so that adding the plugin is also possible without "extra management" because of the versatility of the default base code.

If not, I would just hope an option to remove MP/EXP/Any information related to the battle in the main menu because not all RPG Maker games have battles.

Flexible Event Page Conditions: Similar to Tsukihime's Custom Page Conditions script, which is the single most useful script ever made, this would allow you to enter any Condition that you could enter into a Conditional Branch, and use it as a Page Condition for an Event to determine whether that page should be active.
  • This would free designers from the limiting and arbitrary subset of page conditions they're currently allowed to use for Event Pages - and allow them to get much more creative with their eventing.
The reason why "script" was never been implemented as page condition is simply that the triggers could be anything. If it was only the item change, switch, variables, and self-switch, it is easy to trigger the whole map refresh. "If any of the switch/variable changes, refresh the entire map so that the page changed". Now with the condition as a script call, the only thing they could make sure that the page is always updated is to check the condition every frame. And script eval (executing code from the plain text string) is expensive.

---
I really wanted to reply to every point of it.
 
Joined
Oct 7, 2013
Messages
307
Reaction score
364
First Language
English
Primarily Uses
RMMV
All I want is the engine to not have to rely do heavily on the community for basic functionality.
I genuinely like MV, I have released 4 games with it and have one more on the way, but the fact I had to go digging for scripts to do things like customizing the UI or disabling the blurring when fullscreen, the sort of things that have been standard in-game engines for 10+ years was pretty frustrating, especially when those scripts broke every time there was a patch and you just had to hope the original plugin author would update the scripts to accommodate it.

I often felt like I had purchased a product that was deliberately left with holes for the user base to fill for free.

If the next iteration of the engine isn't feature complete at launch I'm moving onto GMS.
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,443
Reaction score
6,259
First Language
Indonesian
Primarily Uses
RMVXA
I often felt like I had purchased a product that was deliberately left with holes for the user base to fill for free.
Instead of wishing the holes being patched, I genuinely want that the community is allowed to "patch more holes". Namely, editable editor. Right now, there is not much the community can do instead of relying on external editor like TileD and make a workaround like adding notetags.
 
Joined
Oct 7, 2013
Messages
307
Reaction score
364
First Language
English
Primarily Uses
RMMV
Instead of wishing the holes being patched, I genuinely want that the community is allowed to "patch more holes". Namely, editable editor. Right now, there is not much the community can do instead of relying on external editor like TileD and make a workaround like adding notetags.
Oh, I love the plugin feature generally speaking, I just hated the way it was used a crutch for so much basic functionality.

Being able to edit the editor to tailor the engine more to your own needs would be pretty dope for those with the coding chops would be great though.
 

Zliryu

Ryu
Veteran
Joined
Feb 15, 2016
Messages
39
Reaction score
34
First Language
English
Primarily Uses
RMVXA
Took me a while to get out of vxace comfort zone and try MV, but sure, let's see what this is about before I get too invested in MV.
 

JohnDoeNews

Veteran
Veteran
Joined
Apr 25, 2017
Messages
117
Reaction score
59
First Language
Dutch
Primarily Uses
RMMV
Plugins are not available, I get that... But you guys own the Yanfly plugins now, right? Can't you just integrate them in the new system? Make all those options and settings part of the package?

Anyhow, I am excited. And if you add something new, I hope it is the ability to use on-map battle! A cool ABS system is what I think RPG maker is missing. I would love to see that in the next maker.

Edit: I don't mean add the plugins to the new project... I mean, you guys must know the plugins in and out... Take that knowledge with you when developing your new maker. Cause with MV you can do fun stuff, but with Yanfly, you can make it amazing. (Sorry, but you know as well as I that it is true...) ;)
 

Shaz

Veteran
Veteran
Joined
Mar 2, 2012
Messages
39,661
Reaction score
13,271
First Language
English
Primarily Uses
RMMV
But you guys own the Yanfly plugins now, right? Can't you just integrate them in the new system? Make all those options and settings part of the package?
Kadokawa does not own the Yanfly plugins. And what about those people who don't WANT the Yanfly plugins? Why force them to have them by making them part of the package? If they're going to do that, why only choose Yanfly? Why not MOG, Galv, Victor, and all the other popular plugin makers?

For the most part, the engine really is enough to make a game without any extras. The extras are for those who want them, and their requirements are all going to differ. There will always be things the engine doesn't do by default, that we want it to do. That's why we can add scripts/plugins. I'd rather have it this way than to have the engine try to include everything everyone could ever want/need.

Everyone is so keen to have their game be different to everyone else's, that they all run out and get plugins - the same plugins, so their game ends up being the same as everyone else's. Putting the plugin functionality in the engine by default will just increase that. ;)

I can think of maybe half a dozen at most of Yanfly's plugins that I'd think would be great to be integrated with the engine. Everything else should be at the discretion of the individual developer.
 

Tayruu

・ ゚*。・゚(幸)
Veteran
Joined
Apr 27, 2014
Messages
38
Reaction score
60
First Language
English
Primarily Uses
RM2k
Frankly, my biggest desire will always be a return to the RMXP-style map editor. Hell, I would be happy with layer buttons in the editor. I can adapt to some weird limitations with some experimenting but oh my god having to erase upper layer tiles when I wanted to adjust the lower layer drove up my anxiety with VXAce, and finding MV be the same way was disappointing.

I'm also grumpy about weird tile sizes for the sake of asset compatibility, not everyone is a sprite-artist, and not everyone wants to use the same "DLC" resources, but I highly doubt they're going to go back to 32x32 after MV.

I personally feel a lot of features can be created with good scripts/plugins. There's definitely some things that are easier if they're integrated into the editor GUI - which is why I've moved to XP instead of trying to use third-party stuff with VXAce - but I'm not super fussed about the editor not having some fancy features.

... I'm also not that fussed about the face/sprite generators, but I guess those are useful to those that want to hop right into making their first RPG. I'd personally prefer if it was sort of out of the way, I kept accidentally clicking on it in VXAce. :B

...

I guess if I could think of any interesting new features, it would be more modular stats. Instead of having fixed stats and fixed fields to fill things in, let the user define in a Database tab the types of actor/enemy stats that exist, and those in-turn will exist for affecting in actor/item/etc tabs. The user would define the object name (for scripts), a few long/short display names, whether it had a growth rate... and anything else that would be useful. Maybe what tabs it should appear in too?

... of course, this would depend on how integrated those stats are into the scripts too. I think in VXAce the formula field meant you had the atk/def/int right there in the database - so the influence of those stats weren't buried in the scripts. Meanwhile in RMXP of course, those stats were buried away.

The only problem this might cause is there would need to be "game rules" so to speak, unless some stats were fixed. I guess if anything, HP is the one stat battlers would have to have, to make sure there's a lose state for them.
 

EmmaB

Veteran
Veteran
Joined
Feb 20, 2018
Messages
117
Reaction score
157
First Language
English
Primarily Uses
RMMV
I'll be keeping an eye on this; very interesting. :)
I don't know how hard this would be to implement (I'm not a coder), but it would be nice if the new Maker had the ability to make multiplayer games.
 

TheoAllen

Self-proclaimed jack of all trades
Veteran
Joined
Mar 16, 2012
Messages
5,443
Reaction score
6,259
First Language
Indonesian
Primarily Uses
RMVXA
@Shaz The only reason why I could think that people want Yanfly's library bundled by default (or at least, the Yanfly's modification being the base code) so that we have the same reference when it comes to releasing the plugin. No more cross-checking "If this would be compatible with Yanfly's"
 

Shaz

Veteran
Veteran
Joined
Mar 2, 2012
Messages
39,661
Reaction score
13,271
First Language
English
Primarily Uses
RMMV
@TheoAllen true, but that's only for plugin makers, and if we care if something will be compatible with Yanfly's, we can already check that - doesn't need to be bundled with the engine. Doing so means we'd HAVE to make our plugins compatible with Yanfly's, whether the person wanting to use our plugin is using Yanfly's or not. I would hate to have to make plugins for my own use compatible with Yanfly's menu manager, if I don't intend to use Yanfly's menu manager, for example.
 

Wavelength

Edge of Eternity
Global Mod
Joined
Jul 22, 2014
Messages
5,404
Reaction score
4,801
First Language
English
Primarily Uses
RMVXA
[An in-client asset store] would be an extra cost for Kadokawa/Degica. Besides I have no idea how could this being implemented in apps. When you claim a resource, do you download it in and put your project or do you download it in as local files that you have to save it manually? what if you have multiple projects? do you re-download it? I'm probably just being skeptical anything about "Store" tbh. It is better for the user to just educate themself than the store trying to make it user-friendly.
It would be a significant extra cost, but also an ENORMOUS extra income stream! It's industry practice for the platform owner to take a portion of sales for paid assets (usually 30%, I think) when bought through their store.

Implementation could be similar to GameMaker or Unity asset stores (example from Unity's) - this isn't a pipe dream; most respected game making engines already include this level of integration and RPG Maker needs it!

[A Window/HUD Editor] can be a great idea and honestly, if this is being implemented in a user-friendly manner, I'm very curious about the programming behind this idea while still allow you to "patch" them so that adding the plugin is also possible without "extra management" because of the versatility of the default base code.

If not, I would just hope an option to remove MP/EXP/Any information related to the battle in the main menu because not all RPG Maker games have battles.
I totally agree! And if this amazing feature would be too much work, I agree that having an option to simply remove some fields would be a nice compromise.

The reason why "script" was never been implemented as page condition is simply that the triggers could be anything. If it was only the item change, switch, variables, and self-switch, it is easy to trigger the whole map refresh. "If any of the switch/variable changes, refresh the entire map so that the page changed". Now with the condition as a script call, the only thing they could make sure that the page is always updated is to check the condition every frame. And script eval (executing code from the plain text string) is expensive.
While I'm not 100% sure, from my experience with the code base, I thought that the event page conditions were being checked every frame, not just whenever switches/variables were updated. Am I wrong?

In either case, what Hime's script did was to allow any Conditional Branch condition to be used as a Page condition. This is an invaluable tool in complex eventing, and even if the event page condition checks work like you said, all conditions except the explicit "Script..." condition would be able to be minimized to whenever the appropriate data (such as an Actor's States) change. I don't think the processing overhead would be too high - possibly even lower than the extra processing overhead necessitated by having more event pages and additional parallel process events to evaluate conditions and turn switches On/Off appropriately so they can be used as event page conditions.

I really wanted to reply to every point of it.
By all means! I won't be angry if you do!! :D
 

JohnDoeNews

Veteran
Veteran
Joined
Apr 25, 2017
Messages
117
Reaction score
59
First Language
Dutch
Primarily Uses
RMMV
Kadokawa does not own the Yanfly plugins. And what about those people who don't WANT the Yanfly plugins? Why force them to have them by making them part of the package? If they're going to do that, why only choose Yanfly? Why not MOG, Galv, Victor, and all the other popular plugin makers?

For the most part, the engine really is enough to make a game without any extras. The extras are for those who want them, and their requirements are all going to differ. There will always be things the engine doesn't do by default, that we want it to do. That's why we can add scripts/plugins. I'd rather have it this way than to have the engine try to include everything everyone could ever want/need.

Everyone is so keen to have their game be different to everyone else's, that they all run out and get plugins - the same plugins, so their game ends up being the same as everyone else's. Putting the plugin functionality in the engine by default will just increase that. ;)

I can think of maybe half a dozen at most of Yanfly's plugins that I'd think would be great to be integrated with the engine. Everything else should be at the discretion of the individual developer.
The RPG maker team does sell them now, right?

And I don't mean to actually put all the plugins in... But make all the settings you can adjust with yanfly adjustable in RPG Maker.

Doesn't mean everyone has to use each option added to the engine... Maybe you should google the word option. It means: not required.

Also, you say everyone wants their game to be different... With all those setting that is exactly what you can do. That is exactly what those plugins are for. You don't drop the min and let them play. Look at the enormous amount of parameters you can adjust in the yanfly plugins alone. Each and every parameter changes your game... Keep them all on default, and you would hardly see a difference.
 
Status
Not open for further replies.

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

Latest Threads

Latest Posts

Latest Profile Posts

*sigh* I'm so sick of this heat! :kaosigh::kaoeh:

Between Rona and MZ, might as well buckle down and get serious in dev
I did it. I finish the test after 2 days 6 different subjects. Now I'm freeeeeeee
Got a nice little platform coming along backwards compatible with MV.

Forum statistics

Threads
100,659
Messages
978,200
Members
132,279
Latest member
NeverCoreCore
Top