That should have been a built-in feature!!

[Kaelan]

Features that add a lot of flexibility for users, aren't too hard to add when building the engine, but are either a pain or downright not possible to add in after-the-fact with no access to the internals. It's not a perfect criteria, but I'd say that's a pretty good starting point. While you can do a lot with scripting, there are definitely fairly basic things that you either can't do at all or can't do without a pretty significant amount of effort and work-arounds on top of work-arounds. Those would be good candidates to take a look at.

I don't think simplicity is a good criteria; like you said, if it's simple, people can just do it themselves and share the script. I think flexibility and extensibility are better criteria. You want to add things that increase what people can do with the program as much as possible, while still being generic enough to be of use to a large variety of users. Being able to add your own pages to the database (or/and customize some of the existing ones, using what's already there as building blocks), for example, would be a huge step towards letting people easily change the structure of their games.

 

[Dust]

I'd love to see visual previews of moveroutes on the map, when in the moveroute-editor. Like a visual trail/line. I often get kinda lost with more complex moveroutes and this would make a really cool and handy feature

 

[Shaz]

Again, this is NOT a "what I want to see" thread. There's already one somewhere else for that. This is things that SHOULD have been included as standard - no-brainers, if you like, not wish-lists.

 

[Dust]

Okay, but for me this is kind of a no-brainer. I think everyone can clearly imagine that rembering the movements, respective positions by yourself can get kinda tedious. So why not support the user by including something like this. Unreal Engines' "counterpart" to the moveroute editor: Matinee has this kind of visual representation since many years. Adobe After Effects, Sony Vegas (and I'm sure many other programs) have this too when tweening or moving objects around across several frames.

 

[Engr. Adiktuzmiko]

The thing is the set move route isn't even read by the editor... That is mainly why you don't have a visual representation of it... So to add that they need to actually make a new editor or section for moveroutes... Given the price tag of RM, it's not really hard to see why they didn't go that far...

 

[Mouser]

Okay, but for me this is kind of a no-brainer. I think everyone can clearly imagine that rembering the movements, respective positions by yourself can get kinda tedious. So why not support the user by including something like this. Unreal Engines' "counterpart" to the moveroute editor: Matinee has this kind of visual representation since many years. Adobe After Effects, Sony Vegas (and I'm sure many other programs) have this too when tweening or moving objects around across several frames.

This is actually a great example of what can and can't be done and why.

In a Matinee sequence, you control everything. You know where everything is, what it's doing, where it's going.

In RPG Maker, there's one very important detail you have no way of knowing for a moveroute: where the event will be when the moveroute starts. You cannot guarantee that another event will not have moved this one, or that random movement was not on, or one of any other things that could change where you thought the event would be.

"Events" are the brainchild that lets RPG Maker run with as little overhead as it does, but there's a lot of tradeoffs that got made in moving to an 'event' model from a MOB object model.

 

[amerk]

Unless he's asking for something completely different, like being able to toggle the windows for the map, the event commands, and the move routes separately so he can visually see the route he is eventing, in case he forgets something. When I command a specific move route now, for example, the event command window takes up space over the map, and the move route takes up more space and I can't toggle them. For simple moves that require no more than a few steps or turns, that's generally not a problem.

But for longer more complicated movement (usally involving longer cut scenes or a complicated event movement), it's not easy to remember what moves to program when multiple sprites are involved. If I forget the position where one of my sprites will be at the time of the scene, or how I want my player to move if triggering a certain event, or even the way an inanimate object (like a lilly pad) flows down the river, I first have to save and leave the current event, go back into the map grid, visually look at and remember how I want the event to move and turn, write it down if I think I'll forget, then re-open the event and the move route window, and type it in. If I forgot something else during that time, I have to once again save and close the event window to go back to the map grid, and back and forth until I'm done.

That seems to be a lot of steps for something that appears to be easily resolved by allowing a toggled window, to go between event commands and the mapping screen. Now, the problem is, you don't want the player to have a hundred windows open at a time. So if they have an event window open, allow them to toggle to and from the map, but don't allow them to open anymore event windows until the one they are in is closed.

I will admit, this appears like a no-brainer. But I don't know anything about the coding involved, or if this would be too hard to program, or even if it would sky rocket the cost of RPG Maker. All that aside, however, I do think being able to toggle back and forth between a current event window and the map would be convenient to a lot of developers.

 

[Dust]

Yeah amerk really summed up what I was going for. I think the toggleable window is at least a kind of work-around since it would give you the opportunity to select the current gridcell in order to remember where the current position of whatever is.

 

[Eurgh]

I think mouse compatibility should be a built in feature with the option to enable or disable it.

It kinda seems like something you'd really like from a computer based game, rather than having to use directional keys and what not.

 

[Shaz]

RE: Move Routes ... the joys of having two monitors. I will sometimes take a screenshot of the map in the editor, zoomed appropriately, and whack it into Paint.NET. Then I can use layers to draw out move routes for several characters at a time (one per layer), then set the visibility to view only one, then use that to build the move route in the engine.


But that's getting a little bit off topic.


Is it a no-brainer? I don't think so. If you look at the list of features people would like to be added, you'll see some come up over and over (this would not be one of them). Those that are requested by many people, or most people, are more likely to be things that "should" have been built-in.

 

[Tigersong]

I think one criterion should be what a feature adds to the player's experience. There'd be no games without players, so that should always be a factor.