A New RPG Maker draws near! Command?

Status
Not open for further replies.

MikePjr

Artist
Veteran
Joined
Nov 7, 2012
Messages
732
Reaction score
454
First Language
English
Primarily Uses
I honestly would love to work on some new 16x16 tiles for this maker if it's going to be a thing.
I've grown incredibly capable of classic pixel art over the years.
I'm very interested to see what tidbit of information is released next.
I'm also hoping we can go back to the kind of tile sets we used to have in XP.. where you can make a sheet of tiles as big as you want.
I'd also like to see them do away with the awkward auto tile setup that's been used since VX... yeah i know that's going to be a sour tone to some folks expecting things to just work with the new maker.. but i really REALLY despised how all the auto tiles were designed after XP.
RM XP had the best set up for auto tiles.. it made making a more organic looking map a lot simpler.
I'd also like to bring up how Pixel Game Maker lets me select how many layers i want to use.. and put what ever i want on what ever layer.
I really hate the restrictive nature of the RPG Makers after XP.. it felt like a downgrade.
XP felt like a fresh new direction.. while VX felt like Kadokawa sort of panicked when interest was being lost in the japanese market.. they felt the need to simplify things.. and sadly that approach has been taken ever since VX.. all the way to MV.
I'm not asking for all kinds of gameplay features and battle system because i know plugins and scripting can help with that.
I'd just like to see the engine be more flexible..
 

PixelHeart

The Pixel Heartist!
Veteran
Joined
Oct 26, 2013
Messages
3,803
Reaction score
1,989
First Language
English
Primarily Uses
Other
you're right, this would not bloat the code - the problem is on another side.

multiple grid sizes would either require multiple RTP for each size, or they would require a resize algorithm that would always loose quality compared to the default grid size.
Just look up the many topics from people who tried (and failed) to resize Ace-tiles to MV without too much quality loss.

If they allow multiple grid sizes by default, they would get that mess multiplied and there would be many people getting problems with that.

What they could do is something like they did with the Patch-EULA for RM2K - giving options while clearly stating that those options are not supported.
In this case, giving only one size of RTP and having all projects default to that grid size, but allowing the editor to use other grid sizes through unsupported changes (like requiring a manual edit of an inifile, but not giving the option in the editor itself).

That is the only way how they could make such an option available without causing more support problems than anything else.
This is what I was going to say. Personally I think providing an RTP for every size ratio would be a bit over kill. I personally probably wouldn't even use the RTP anyway, as Im more into making my own graphic assets these days. As long as I can use the 16x16 assets I make without needing to do some janky plugin voodoo to get it to look kinda ok ... and we can natively adjust the resolution... and without totally breaking the menu UI ... I probably will buy this day one :) .

EDIT: ...my point, which I forgot to make, I think if they make the grid size adjustable they should just make assets for one size standard. I would be plenty happy to make my own in the other possible sizes. Also, if they wanted to provide assets in other sizes, they could just do so in the form of updates or DLCs as they already do.
 
Last edited:

SJWebster

Too old for this ****
Veteran
Joined
Apr 8, 2012
Messages
123
Reaction score
234
First Language
English (UK)
Primarily Uses
RMMV
I know the engine is probably done and dusted, but I want to add my speculative wishlist anyway.
  • Three layered manual mapping, exactly like RPG Maker XP's. I seriously struggle to work with MV's semi-predictive system. The fact parallax mapping plug-ins and TileD both exist shows how much people disliked the mapping system in VX, VX Ace, and MV.
  • More export options. A Switch export option would be an absolute game changer.
  • Implementing some of the most common plug-in enhancements as standard. I shouldn't need a plug-in to set the output resolution. Animated side-view enemies should have been supported out of the box. That kind of thing.
  • Announce the official game jams on Steam! I keep missing them because I'm not that active on the forums, but these mini events are one of my favourite things to do in RPG Maker.
Given what's been said so far, I think we'll still have a default tile size of 48x48 and I think it's unlikely we'll be able to change / toggle that. I think I'll still be creating pixel art as if it was 16x16 or 24x24 and then doing either a 3x or 2x Nearest Neighbour scale to get to 48x48.
 

misterdovah

Villager
Member
Joined
Jul 2, 2017
Messages
13
Reaction score
10
First Language
Portuguese
Primarily Uses
RMMV
More freedom in editor and char generator (both to customize and place parts), a better text input system, customizable menus and a light tool would make me easily pre-order it. ❤
 

JosephSeraph

White Mage
Restaff
Joined
Mar 7, 2014
Messages
1,169
Reaction score
1,418
First Language
Portuguese
This is what I was going to say. Personally I think providing an RTP for every size ratio would be a bit over kill.
Absolutely, it's the sort of stuff that's definitely unfeasible and they have a track record of only implementing features if they have the assets to go with it. That being said, not long after MV released, it got a changeable tilesize plugin, as well as a TileD integration plugin a bit afterwards I think. That was 2016 at most. So even if we don't get integration out of the box (which we might in some shape or form) at the very least I think going that changeable tilesize / TileD route will be easier and more efficient than before.

You say press turn but i've yet to see one in MV. Despite press turn being peak JRPG battle system for me, I'm not an adept programer lol. I only seen one from VXAce and that one costed money.
My bad! I remember it being pretty popular back in the VXAce days, though, which is why I mentioned it. And it only costs money for a commercial license which is a fraction of the games people develop; There were a lot of PTB games released on RMN back then.
 
Last edited:

jonthefox

Veteran
Veteran
Joined
Jan 3, 2015
Messages
1,379
Reaction score
540
Primarily Uses
Definitely no need to ship us RTP in different sizes; a simple option to change the default grid size and then leaving it up to the user to drop in whatever differently sized assets in the image folders would be excellent.
 

JosephSeraph

White Mage
Restaff
Joined
Mar 7, 2014
Messages
1,169
Reaction score
1,418
First Language
Portuguese
I definitely agree with that! BUT what I'm saying is that that goes against the "user friendly out-of-the-box" philosophy they've had with every rpg maker, so I find it unlikely that they do this for the new one, it'd be inconsistent. Though I suppose the middle ground would be having a mini RTP for every one of the (standard, hardcoded) resolution. That would be more consistent with their track record, BUT still potentially expensive.
 

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
30,417
Reaction score
7,230
First Language
German
Primarily Uses
RMMV
that goes against the "user friendly out-of-the-box" philosophy they've had with every rpg maker,
I agree - which is why I described it as being a hidden option in an ini file with a refuse to support in my original post about this.
That way it would still not confuse any kiddy with their first look at the maker while being available to those who know enough to find that option. And since it would be an undocumented option that would also get them off the support requirement.

On the other hand it would require it being programmed without being able to advertise it, and they might not want to pay for that even if it is an easy option.
 

ChampX

Veteran
Veteran
Joined
Aug 14, 2016
Messages
204
Reaction score
136
First Language
English
Primarily Uses
Just scrolling through this thread, I see a lot of debate over things that should or should not be in the engine and I'm going to address my personal take on this here.

Features the engine has should assist the developer at the tool level, not the gameplay level. If we were to take the examples of Yanfly, as many people think all his plugins should just be dumped into RM by default, examples of tool based plugins include "Event Copier" or "Event Hitbox Resize". You can of course build a game without these sure, but these plugins help your game scale well development wise as it grows bigger. Without them, the default solution is copy/paste duplicate events, then "oh you need to change something", and now you're changing events individually, which is error prone and tedious. Even outside the example with events, standard tool based features commonly requested such as grid size and screen size are all things that should be included by default at the engine level.

Gameplay plugins, if we use Yanfly as an example, are things like "Item Core" which control things like independent items, "Quest Journal System", or his deprecated battle systems like ATB. These all affect gameplay unique to your game, and that should go to the responsibility of the developer to get working correctly.

Another simpler way we could also think of this is, would other commercial engines provide functionality requested out of box or is it on the developer to handle that themselves? (I'm not naming engines because forums don't allow it) Event Copier and Event Hitbox Resize, as examples again, are commonly just object instantiation off a class level object and collider adjustment sizes in most other engines respectively, but they most certainly are not going ship a Quest Journal System and it is expected the developer implements that (or find someone else who did and implement that into their project).

I understand a lot of decisions made with the development of RM boil down to RTP art and having to pay artists, but I'm honestly in the camp that RTP does not need to exist for every feature RM ships with. I would rather have an engine ship with less RTP but more functionality to help ease development that isn't gameplay unique, than to have more RTP and less functionality. The would be RTP instead could just be available as DLC packs somewhere, free or paid.
 

Wavelength

Edge of Eternity
Global Mod
Joined
Jul 22, 2014
Messages
5,410
Reaction score
4,808
First Language
English
Primarily Uses
RMVXA
On page script eval condition:
Actually you're right. it is better to just refresh that specific event instead of the whole map. And when I looked at the code, you can totally do this by calling this line --> $game_map.events[id].refresh and this will only refresh this specific event, not the entire map.
Right on! I think the way events are checked/refreshed in the current versions might be less than ideal, and with an improvement to that, a far more flexible set of Page Conditions feels like it wouldn't be a noticeable hit to performance. (Even with the way it is now, my experience with Hime's excellent script which does this is that the performance hit wasn't too bad.)

On resource stripper topic:
I don't think they would preload all the resources at once. Doing so would require a "loading screen" as many games do. Or at least a performance hit at the beginning of the game. The default behavior always loads the resource on demand rather than load all of them. Except maybe you're using preload plugins which totally make sense if you thought this way.
Thinking about it more, I think you're right about resources loading - I've worked with clients who use preloaders before, so maybe that's what I was thinking of; in any case I was misunderstanding how things are loaded under the hood.

So the Resource Stripper probably wouldn't improve the game's performance, but it would definitely cut down on the enormous file size that makes it harder to share early versions, wastes the player's HDD space, and forced MV's devs to load an "incomplete" base of RTP assets into new games. Still a valuable tool that should be built in as an option, I think! :D

If they load a resource that does not exist, I simply replace it with the blank bitmap if it's an image resource. Then I record the file path. if it was the audio, I'd just don't play it (or mute the current audio if it was the BGM). There will be a notification window if the resource is missing, but it won't crash. The players are free to continue. If the one that missing is the enemy battler, they just don't see the enemy. So the players have a chance to save their progress and report it to me if something is missing without losing their progress. Whenever I want to build the demo, I also do this. Strips all the resources I suspected that I didn't use it. And play through my own game to see if something is missing.
Really smart idea!! The blank image to replace it is clever - that way I assume you can manipulate that blank image (such as move/rotate it) without further potential for crashes.

On change actor graphic topic:
As someone who has dynamically changed graphics based on various factors, it's way complicated than it sounds. It is not impossible (I managed to make it work), but wouldn't it just complicate the engine? It is not a basic functionality that should exist, it just an aesthetic pleasure to be able to see the graphic changed by many conditions and factors. Additionally, if they promote the graphic changed based on those conditions. They should also provide the basic RTP resource to do so as "an example" on how to use it. This would cost the production of the RTP asset itself alongside with the feature that is not even important, to begin with. Additionally, I have no idea where "all actors" case would be best used except it is probably only good for "transformation".
I think you might be thinking too ambitiously about its uses. I think I did mention being able to change actor sprites for weapons, etc., and this would be a legitimate use of it, but other uses would include changing the actor graphic to a cursor-style event graphic while on certain maps (e.g. for evented upgrade/skill tree screens), or showing visually that a character is, for example, frozen or dead (while on the map).

These are common things that designers either do in RPG Maker (and often have to struggle around), or want to do but can't (because it's too complex or too risky). The RTPs in the last couple versions of RPG Maker already include Down/Status graphics, so no further work would be needed to provide "examples".

For something like the cursor-style event graphic, of course you could just do this by using the existing Change Actor Graphic event command, but the (very) hard part would be changing the Actor Graphic back to whatever it was before visiting the evented upgrade screen, if the character already goes through Actor Graphic changes elsewhere in the game and can access this screen (and then return to the normal map) from anywhere. For something like the Down/Status graphics, the usefulness of this Feature should be obvious.

As to where the "All Actors" parameter would be used, one of the most frequent uses would be for the "dead" graphic. Several games, including many Dragon Warrior games, represent dead party members as a standard Coffin graphic on the party caterpillar. (A game like Disgaea or Fire Emblem, where you can recruit members of a class, might benefit from using the "All Actors" parameter too if they're not truly instancing the characters but rather creating a couple hundred blank slates in the database.)

I agree this is a functionality that, on the margin, could be either an addition to the editor or an improvement introduced via a plugin, and that's why I listed it in "Would be Nice" rather than "Game Changers". However, the Features Box feels like a really good, intuitive place to put it, and since this would just be one in a long list of options in the existing Features Box rather than requiring a widget of its own (and since this feature should not cause any additional processing load in moment-to-moment gameplay), I personally feel it would be a very good addition to the editor.

On pixel movement topic:
Having a pixel movement as a toggle is almost like having to have a toggle to switch from a turn-based battle system into a tactical game. It is entirely different. It is not impossible, but if they do, they need to be prepared that every movement in the base code already in pixel movement, which is, again, possible.

However, the collision boxes may not as simple as you thought. For the tile-based movement, it is far too simple to implement.
  • You want to move to the left
  • The system checks if the tile on the left is passable
  • Then the system checks if you collide with any event and if yes, check if it triggers the event
  • Turned out it is possible to move.
  • You move, your character physical coordinate information changed from (1,1) to (0,1)
  • Your actual character display coordinate does not. it stayed at (48,48).
  • The system gradually move your character toward (0,48)
  • While doing so, you're unable to input the movement (it's locked until you arrive at the destination).
  • The event touch/player touch event trigger could happen when both of their physical coordinates happen to meet at the moment when either of them checks that specific coordinate even though their display coordinate does not actually represent their actual position (yet)
Now a simple question to the pixel movement if you still want the collision box would be in the tile-based. If I'm in the coordinate (24,48). Am I belong to (0,1) or am I belong to (1,1)? Or am I misinterpreting your words?
Having used a Pixel Movement script and made several bugfixes to it specifically to correct things like collision detection, I feel I'm qualified to talk on this one. I hear your concern for sure - you are right that it is pretty complex - but it's only complex from the perspective of the person that develops the functionality. From the designer's and player's perspective, I think it's pretty simple.

With "pixel movement" of 1 pixel or 4 pixels at a time (which represents a tiny fraction of a second), the system can check for collision after each complete movement, without worrying about events "crossing over" each other and not having their collision detected.

At the coordinate (24, 48), assuming 48-px tiles, you would be at the tile (1, 1) - because your character graphic box would be spanning from 24 to 71. Pixels 0-23 would be tile 0, Pixels 24-47 and 48-71 would be tile 1, 72-95 and 96-119 would be tile 2, 120-143 and 144-167 would be tile 3, and so on.

A more complex issue would be, for example, if I am between two different Action Button events, facing them both, which one should trigger? In the script I was using, both triggered and it got really messy. I solved this by sorting each Action Button event that would trigger by its distance from the player (from event base position to event base position), and only triggering the closest event. Complex from the programmer's point of view, but effortless from the designer's and player's.

It's definitely one of the "reachier" features I proposed, I'll admit. :) It would be awesome, though!

On Advanced Event Animation Options topic:
This idea is not bad but putting a number manually would break the convention that RPG Maker tried to preserve for a sake of "user-friendliness". The only number you would need to manually put would just in the set variable value or the damage formula. Everything else most of the time is a dropdown list. Set animation id? dropdown. Show balloon icon? dropdown. Pick the character index? you choose it in WYSIWYG editor.

Now speaking of the character index, requesting to pick specific character index in move route --> change graphic is a feasible idea and would be a total improvement. As for now (in VXAce) you only have an option to choose the whole set in the move route command, not the specific index/pattern like you do when you're choosing the graphic on the event page. And then, you have a weird workaround like "Turn Up/Left/Right/Down" just to choose the cell you want to use.
There are a few other places that we use Numeric Entry in the editor that you may not have thought of already. The Features Box is a big one - many Features such as State Rate and Param Rate require free numeric entry. Almost all of the Cel Option features (such as Cel to Display, Zoom, and Opacity) also require free numeric entry, as does the "Change Maximum" (number of database items) on each Database tab.

I'm of the same mind that you are that point-and-click/dropdown menus are the simplest, most intuitive ways to work within the editor, and I'm glad that most functionality uses it. But lots of core functionality requires number boxes, and I think a feature as flexible and useful as Advanced Event Animation would justify a (still relatively simple) numeric entry field.
 

ghorba96

Villager
Member
Joined
Dec 23, 2014
Messages
13
Reaction score
29
First Language
Italian
Primarily Uses
N/A
I would actually like an isometric view, although i'm not really sure how the battles would play out
 

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
30,417
Reaction score
7,230
First Language
German
Primarily Uses
RMMV
would not be the first time they decided that a planned tool/update was too much and decided to turn it into a new maker - there was a project to create a mobile export for VXA as well as replace the display library for larger screens, and both functions ended up in MV while their original Ace parts were scrapped as too complex to implement. And there have been calls for an isometric maker for years.
and an isometric maker would require a completely different mapping editor, so that might really be what they made for the this next maker
 

mardin

"...pretty please?"
Veteran
Joined
Nov 8, 2015
Messages
231
Reaction score
121
First Language
German
Primarily Uses
I think the only 2 features that would make me want to switch to the new RPG Maker is something like displayable text on screen (outside of the message box) and clickable pictures. Things that Visual Novel Maker can do. Maybe even an Imagemap? And yes, Isometric view would be really cool as well!

Other than that, I still like MV. But it is the community plugins that make me like it. Plugins/Scripts of MV being unusable is a bummer but I expected that, and I am not sure who will step in for yanfly. I mean think of all the scripts you are using now with MV...


Well, it will be interesting to see what the big selling point of the new engine will be.
 

Zarsla

Veteran
Veteran
Joined
Jan 23, 2015
Messages
708
Reaction score
227
First Language
English
Primarily Uses
Honestly I see us getting MV Trinity Features:
System Database improvements:
-4/8 directional movement
-Horizontal/Vertical Command Menu Choice
-Still have the choice of Side/Front View, but with the additional options to have both(in the same game)
-Visual Novel Format
Others:
-Extended Event Triggers(When Player Enters/Leaves map, During Player Participation). Event Ranges, like how far up/down/left/right.
-Regions in the Database. It lets you add traits, and setup common events to said region. Restrict Player/Event Movement
-There's also an overpass feature, idk what it is.
-Name Boxes(built-in)
-Text message positioning.
-Possibly sub-folders and it being read correctly(I've had trouble with that).
-Basic Editing of Title Screen, Credits & Results(Battle Results) Page.
-Foreground & Background Parallax for maps
-Saving Event Destination, on maps.
-Previewing Movment Routes

And then some kind of update to how Plugins Work, on either the coding/implementation side.

Hopefully an improvement on how mapping works, as we tend to get some kind of change with mapping since XP.

As for anything else, I know were getting new RTP, but honestly idc. Like I want to see it, but that's it.
It would be cool to set up in a project/systems to set the grid size, like width/height but honestly I don't fully see it. It would be nice though.
 

Touchfuzzy

Rantagonist
Staff member
Lead Eagle
Joined
Feb 28, 2012
Messages
7,161
Reaction score
8,532
First Language
English
Primarily Uses
RMMV
I will say that there is at least 1 feature that has been requested for years and years that is in. And it is one that I'm very excited for.

But I can't tell you what it is cause we haven't announced it yet so ahahaha, dance my monkeys... I mean, look forward to it!
 

KaYsEr

Koruldia
Veteran
Joined
Mar 14, 2014
Messages
257
Reaction score
475
First Language
French
Primarily Uses
RMMV
Isometric view is unlikely, creating assets requires more skills, and moving is often confusing to many people especially for an exploration game. Of course, for a tactical game it’s not a problem, but I doubt the next RM would go with a tactical battle system. I had a dream about a Chrono Trigger battle-system last night, that idea is less crazy to think about haha.

Touchfuzzy already said that MV assets would be compatible anyway, so it means no iso view to me.

Plugins/Scripts of MV being unusable is a bummer but I expected that, and I am not sure who will step in for yanfly. I mean think of all the scripts you are using now with MV...
Yes it’s a bit worrisome, but the new one will likely still use JS, maybe they updated the current PIXI to version 5 or went with another one like CocosJS, either way we can be optimistic when it comes to “plugin conversion” even if it’s unlikely that people without JS knowledge will be able to do that.

The new RM could catch-up on MV (when it comes to important plugins) in about a couple of years, if we’re indeed talking about PIXI5/Cocos-JS/whatever-JS.. And who knows, maybe the next RM will have more “vanilla functionalities” reducing the need for some basic plugins.

Today we have plugins to simply skip the title screen or go fullscreen, even to have a proper compatibility with 120hz monitors etc (the list can quickly become big) so for example if your current plugin-list in your MV project is 50 plugins, maybe you’ll be fine with only 25 in the next RM. (Totally random numbers of course.)

I will say that there is at least 1 feature that has been requested for years and years that is in
Default Wide Screen? :LZSlol:
 
Status
Not open for further replies.

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

Latest Threads

Latest Posts

Latest Profile Posts

Well... My game plays better at 1920x1080, so I guess that's the new resolution. Still runs at 60FPS. :LZSexcite: Also... I really want a boss to be able to build new maps around the player... Mostly because it's visually spectacular! I'm er... not quite sure yet how I can do that without making MV explode.... But I'll find a way, anything in service to the "sparkles"! :kaopride:
How to change your netbooks screen resolution

Forum statistics

Threads
100,787
Messages
979,542
Members
132,430
Latest member
Timiti
Top