That should have been a built-in feature!!

[Tsukihime]

Every now and then I see a script request, someone fills it, and then you hear "OMG THAT'S SO SIMPLE IT SHOULD HAVE BEEN A BUILT-IN FEATURE".


Now, this might be just complimenting the scripter, but on the other hand it might be a serious statement.


Given this trend, there probably are over a hundred things that "should have been built into the engine", including conditional statements for dozens of arbitrary different things, custom battle systems (with choices to choose between them), and a number of other things.


But what exactly should be criteria be for a "built-in feature"?


Ideally it would be nice if "everything we can think of" is already built-in like some of those other engines out there.

 

[Alexander Amnell]

   I think that the best way to consider this is in terms of versatility/intrusion. The more versatile a feature is and the less intrusive upon the user the higher the reasoning between making it a built in feature. Things like, say a 'battle events' window in the editor that is enemy specific rather than troop specific (and for actors as well) would be awesome and completely un-intrusive for those that do not want to have custom battle events per enemy rather than per troop, but it's a great feature for those of us who do and offers up new possibilities. 

   On the other hand, features like custom battle systems (such as sideview) I do not think should really be a fleshed out feature of current or future rpgmakers. The systems in place by default are as generic and simple as they are for a reason, so that users can build upon them to gain the results that they seek. The more the standard systems begin to move away from that generic yet adaptable area and into what's, say, most popular among users in regards to battle systems at current, the less versatile the program becomes over all. True for those that want said battle system it becomes much more simple, as they wouldn't have to script/wait for a script to come out in order to get it, but it would also have an adverse effect of stagnating the creativity of the community by polarizing the maker towards one particular direction in regards to battling. 

   Another point I would consider would be how easily said feature is replicated through eventing. I've heard people talk about things that should be a feature of the engine in the past that could actually be utilized with a couple hours time and a little bit of thought through pure eventing. To me such things are all but features already and to create more obvious ways of implementing them to cater to lazy people is redundant at the least and likely a waste of time as well. Now, features that strengthen the event system should definitely be included in the future, two scripts I'd really like to see turned into permanent features of future engines are your extra event triggers script(especially for the by region activation) and Shaz's remember event location scripts, both of which merely build upon the event system but allow the user much more versatility with what they can do within that system.

 

[Engr. Adiktuzmiko]

Aside from Alexander's points, IMHO, if it can be done now using a simple workaround of like a few event calls or script lines, it can stay that way... The things that needs to be built-in are more developer features that we can utilize like those two scripts that Alexander mentioned... I think things like control over what equipment slots an actor/class can have should have been built-in or at least the capability to add more slots in general... and dynamic features too...


So basically, more basic tools that we can use to achieve greater things...

Ideally it would be nice if "everything we can think of" is already built-in like some of those other engines out there.

Which engine does that?

 

[Jesse - PVGames]

I think 8-direction movement should be a built-in feature, with the option to use just 4-direction movement. This could be accomplished with a radio button in the database somewhere that you click - it's not intrusive and could add a lot of versatility for users. 

@Engr.adiktuzmiko - As for which engine does that - although maybe not 100% of everything you can think of, Construct 2 offers way more versatility in what you can make game-wise and uses a very dynamic, expansive, yet fairly easy to use event system to create pretty much anything you want - assuming you can figure out how to do it. If math isn't a strong suit, or logic, then you would have more trouble with it.

 

[Engr. Adiktuzmiko]

but RM is like that too anyways, though of course maybe limited in some ways due to it being made for RPGs... so of course, the other engines that are made for a more general, any genre thing, will surely have a bit more...


And looking at the suggestions thread, most things that people want added to events are just mostly wrappers anyway...

 

[whitesphere]

What I'd like to see:

An easy way to intercept, say, level advancement or other significant state changes, without scripting.  Something like this:

Intercept Event:  

Options:  On Level Up,  On Actor Battle Damage, On Enemy Battle Damage, On Start Battle, On End Battle

The logic would go like this:  When (change in state happens), execute the appropriate Intercept Event(s)

I'm tempted to roll a script to do that, myself.

I'd also really like if you could have Skills require HP to use, as well as the traditional MP or SP.  I'd really like to have a class which has powerful Curses --- each of which draws from the user's HP...

 

[Mouser]

@Engr.adiktuzmiko - As for which engine does that - although maybe not 100% of everything you can think of, Construct 2 offers way more versatility in what you can make game-wise and uses a very dynamic, expansive, yet fairly easy to use event system to create pretty much anything you want - assuming you can figure out how to do it. If math isn't a strong suit, or logic, then you would have more trouble with it.

I'm going to call you on this one. That's like saying Unreal Engine offers way more versatility in what you can make (which it does) and can create pretty much anything you can think of (which it can) assuming you can figure out how to do it. In fact, without even knowing anything about Construct 2 I'd be willing to bet Unreal offers more flexibility and power.

Of course if C/C++, knowledge of basic data structures, semi-numeric algorithms, vector calculus and topology, and the workings of DX11 and graphics drivers aren't your strong suits, you may have a bit more trouble with it.

Edit: One thing I would like to see 'built in' is the ability for one event to activate another (through say 'event touch') and for the event called to be able to manipulate the event that activated it (for example, forcing it through a move route).

 

[Zoltor]

Being allowed to choose what to use for the conditions for yor events. You should need a script(btw thanks alot Hime), to readd a feature some ****** decided to remove from the RM line.

Yes, for those that didn't know, the original RPG maker didn't restrict your option, not only were there more options you could set as conditions for events(which is sad, that the original RPG maker, was less retrictive in such a major aspect, then any RPG Maker that came after it), but you could set any conditions you want, the condition slots weren't pre-asigned to conditions.

You had 6 blank slots, clicking a slot would open a drop down list of every option there is for conditions, and you would beable to set whatever conditions you wanted, no restrictions to speak of.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Next is message codes/customizeable windows(thanks Yanfly). Really why does't RM already have such as a default feature, There's lots of reasons to have text windows open up, char speaking is not the only reason for text windows.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Equipment having a call common event option uppon equiping/unequiping(lol thanks again Hime).  I'm pretty sure this one Isn't a oversight, but a case of developers being lazy/rushed, because seriously how can you make a oversight on such a option, when pretty much everything else in the database lets you call common events.

______________________________________________________________________________________________________________________________________________________________

Let people assign any condition/as many conditions to common events, that they could with normal events(woot woot, thanks again hime, that one script fixes so many flaws), why the hell has common events stayed exactly the same, throughout the history of RM. The developers treat the common event option as nothing more then a after though, but the fact is, It's an extremely useful event type, so it should most definitely not be treated as a after thought/dumbed down event.  The same goes every type of event(Hime's script fixes them all btw), what's the point in purposely limiting the use of event type? It's not like you have to create such from scratch, since other events can already do such, just apply the it to the other events.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Add a mini map navigation system to the map edit, It's so useful when map making, It's not funny, there's a reason pretty much every map making system made in the 2,000s, and up has a mini map navigation system, I can't grasp the reason why RM is the only one that doesn't.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Another map editer thing: Not be limited on how many tilesets we can have access to when making a given map. I mean WTF, getting the tiles to fit into the limited selection we are allowed, is a living nightmare, especially when making town maps(as they require the most diverse assortment of tiles to make). The good thing about computers, and having a HD to store info, is that we aren't restricted on space, so why does the editor go out of its way, to restrict us, on how many resources we can use, it makes no damn sense what so ever. Seriously if every map editor didn't use a unique file type for the created maps, I would use any of the probally thousands(at this point in time) map editors that have no restriction on resourses available for making a given map(generally in map making programs, any tile/graphic you import into the database, you can use for all your map making needs, period)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Special leveling events, it would be nice if actual leveling could trigger common events, it wouldn't be hard for the developers to add at all, yet it would add a insane amount of options to game design, without the need for people to script very complex systems from scratch.

 

[Tsukihime]

So basically "if it is easy to write, it should be a default feature"?

 

[Zoltor]

So basically "if it is easy to write, it should be a default feature"?

No not necessarily, but that one in particular would be an extremely useful feature, that would enable a lot of possible options.

 

[Zeriab]

Being able to create and add plugins or extensions to the editor would be grand.

 

[♥SOURCE♥]

Two little tools for the map editor.

1. Search event by ID or by name.

2. Highlight events by trigger type (parallel process, action button, etc.) or by label (also assign label to events to find them easily).

 

[Shaz]

Things that were in previous versions of the engine but were taken out, for no apparent/logical reason. Like control over layers, fogs ...


Things that you can set in the database but not adjust during the game (like features), when there are event codes to let you adjust other things also set in the database.


Things that only partly work (player can jump, but I don't think followers jump automatically afterwards).


But is this a list of what you think should have been in by default (in which case it's really not much different to the Suggestions for the Next RPG Maker thread), or a question of "what defines what should have been included" which is where I thought it was going, but seems to have (and will continue to) detoured a bit?

 

[Zoltor]

Things that were in previous versions of the engine but were taken out, for no apparent/logical reason. Like control over layers, fogs ...

Things that you can set in the database but not adjust during the game (like features), when there are event codes to let you adjust other things also set in the database.

Things that only partly work (player can jump, but I don't think followers jump automatically afterwards).

But is this a list of what you think should have been in by default (in which case it's really not much different to the Suggestions for the Next RPG Maker thread), or a question of "what defines what should have been included" which is where I thought it was going, but seems to have (and will continue to) detoured a bit?

Don't forget freedom over page conditions, I will never understand why that was removed. I just can't let this go, why would you remove something that was perfect from the start? Have the developers ever hear the phrase, if it Isn't broken, don't fix it?

There's a battle event issue(I think it was more of a oversight, then bad dicision anyway, so the next RPG Maker will likely fix it anyway, but it still doean't change the fact Ace should've had it), event don't proc upon the death of the last enemy in a troop.

 

[Engr. Adiktuzmiko]

I think we need more "event handlers" even for just common events, to do things like whitesphere said (like catching level-up etc)... that would be a nice built-in feature as it will allow you to make more complicated things


PS: I might be coming into this from my experience on wc3 modding where "events" are handled that way...

 

[ShinGamix]

Nothing. Keep it as basic as it has been so we can add as much as we want to it.

just take xp and ace and blend them together. Nothing else I see wrong with the basic features.

 

[Tsukihime]

But is this a list of what you think should have been in by default (in which case it's really not much different to the Suggestions for the Next RPG Maker thread), or a question of "what defines what should have been included" which is where I thought it was going, but seems to have (and will continue to) detoured a bit?

The latter.

 

[Shaz]

Okay, let's keep it at that then.

Folks, this thread is not for things you wish Ace had or should have by default (there's already a thread for that).  It is for "how do you define what should have been included" discussions.  Please take care to keep your comments confined to the subject.

 

[Engr. Adiktuzmiko]

dev tools are what we need... if it's not a dev tool, then it's more likely just something that wraps up a few methods... so it's only there for convenience...

 

[amerk]

I don't think there is a definite way to define what should or should not be in the maker by default, because each designer will have their own personal needs when it comes to building their own game. Personally, I think the most to benefit from this would be the intermediate user. Why? Because a beginner is going to want everything included by default, and an advanced user won't care much at all. An intermediate user will already have some immediate knowledge of the program, maybe skilled in various parts of the maker, if not scripts, and will at least know how to plug the majority of their scripts into their game. Things included by default would be more of a convenience for them, and they'll still recognize that scripts are available for the features not available.

I can't really tell you the criteria for defaults, though. And there is a correlation between convenience and cost. Sure, the more features by default means more convenience, if not flexibility, but EB also wants to keep the cost as low as possible to reach out to as many people. Most people can't even stomach paying $50 for Ace, let alone the original asking price of $90. What happens if the cost rises to something around $150 because everybody wanted as many features as possible? Considering the stigma RPG Maker has outside of the community, the more advanced users might decide it's not worth it and jump ship to a more flexible program.