{FP14} We have Technology (Engine)

[Enigma 10]

We have Technology

Primary Engine: 

Secondary Engine: *requires Facilitator*

In previous generations, it was customary to choose a RPG Maker Engine for the project to be developed in. However, choosing a dedicated engine, while it makes sense from a common sense standpoint, it is actually more detrimental over the long term because it locks out potential members and it doesn't take into account of members abilities. In FP14, we will use two engines, a primary and a secondary engine. The primary engine will have the focus and will probably be used to create the demo. The secondary engine will have assets ported(or modified) so that it will work in the secondary engine. However, community members can choose to focus on only one of the two engines and whatever has the most support will eventually become the main engine.
 
This is the General Discussion thread of the FP14 community event.
 
PP: 3 points per meaningful post
 
Also we need at least one Facilitator for each engine.
 

Edited January 25, 2014 by Enigma

[Bob423 52]

I say rmxp.

It can do more than Ace if you use scripts. Anything Ace can do that's better than XP can be done with scripts in XP.

Ace's mapping is terrible.

 

XP may take more work to do certain things that are easier in Ace, but I believe using Ace sacrifices quality for simplicity.

[Polraudio 122]

I completely agree with bob. XP has way more to offer.

[Bigace360 38]

There really not much to say that Bob didn't say, so unless you pick a more superior engine then anything from the RPG Maker Engine genre the obvious choice is RMXP. I say RM​XP myself because I'll mostly be contributing coding to the game, because that is where I work best at. I would however prefer to use something more powerful, but that requires all of us to study it. Which I myself don't mind but others might be to lazy to.

[Metaclaw 21]

I vote RMXP. because mapping and scripting, like everyone else says.

a more powerful engine may be nice too, but it should have a serious advantage over RPG makers to justify itself. it also can't be too complicated, cause we'll have to learn how to use it, before we can even start contributing to the project.

[Moonpearl 32]

RMXP, as we all seemed to agree in a recent discussion on the matter. Because basically RMXP has everything and RMVX(Ace) has nothing.

[Bigace360 38]

We always have this as well for RMXP: http://www.gdunlimited.net/tutorials/t/rpg-maker-xp/how-to-use-the-vx-ace-engine-in-your-xp-games

Because of this we can completely forget about VX ace because the upgraded ruby was the only thing that was great about it.

[Enigma 10]

Using the VXace Engine in XP can be a plus, but there should be a better a way to increase performance of XP through scripting, mainly loading only a portion of the map at one time, and increasing the frame rate and resolution. I'd prefer FP14 to have the least compatibility issues/ bugs as possible.

 

I know there are some VXace guys, and rather than just deciding XP and moving on, I'd rather give them a chance to participate, and vice versa if their is suddenly a surge of support for VXace. This is simply because while we can list pros and cons all day, the fact of the matter is I don't want engine to be a valid reason for lack of participation. 

 

Thus this Dual Engine system, in reality its just an extended voting period determined by participation rather than posts. Which ever engine gets the most support will become the only engine we use later on in the project.

 

Since I can act as a facilitator for RMXP, we still need at least one facilitator for RMVXace. Once the submission system is active, it won't matter how much content their is for RMVXace if there is no facilitator to add it to the RMVXace version of the game.

[Moonpearl 32]

Using the VXace Engine in XP can be a plus, but there should be a better a way to increase performance of XP through scripting, mainly loading only a portion of the map at one time, and increasing the frame rate and resolution.

You can't. Making any of the improvement you mentioned requires to work around the base engine more or less heavily. Well then using RGSS scripting to replace the original C++ code will inevitably result in something slower. So even if you do optimize the code all in all I'm pretty sure it will make little to no difference at all.

 

Plus, sorry to insist on that matter, but I'm really curious as to how people decided that RGSS3 had better performances than RGSS1. On the paper it seems logical to think so, but since I was curious to find exactly how faster it could be I ran benchmark tests using the exact same scripts in both environments, and it turns out RGSS3 is just as slow as its predecessor. Now my experience might be biased and I would love to hear people showing me how their RMXP project run on RGSS3 has a performance boost - but until I do my experience tells me that using RGSS3 with RMXP is just a lot of trouble to go through for a non-existent benefit. Not to mention...

 

I'd prefer FP14 to have the least compatibility issues/ bugs as possible.

...compatibility issues.

[Enigma 10]

Since I don't have any experience with RMVXace and seldom with RMVX I'm just going based off of Bigace. I really could careless about RGSS1 Vs. RGSS3 I'm just interested in better map handling, higher resolution, and higher framerate. Cause if we end up having large maps, I'd like to avoid map hanging.

 

I also don't know how this will affect our ability to utilize 3rd party scripts like XAS or Blizz, so the scripts that affect game mechanics are more important in my opinion.

[Moonpearl 32]

I'm just interested in better map handling, higher resolution, and higher framerate. Cause if we end up having large maps, I'd like to avoid map hanging.

Just as I said then. We should have known by now if there was any flawless means to improve either of the three without a heavy drawback.

 

I also don't know how this will affect our ability to utilize 3rd party scripts like XAS or Blizz, so the scripts that affect game mechanics are more important in my opinion.

Well in theory there shouldn't be a problem as long as the scripts which replace internal classes are perfect rewrites. The thing is, you can never know for sure whether your rewrite is perfect since you do not have access to the original code in the first place (hence the need to rewrite it from scratch by the way). So the best you can tell is whether your rewrite results in something that looks like the original. And the more complicated and dirtier the custom scripts you want that rewrite to handle, the more likely it is you run into some issues sooner or later. As for the scripts you mentioned, frankly I'd be genuinely impressed if they would work flawlessly with a rewrite of RGSS1 on top of RGSS3. Which brings me back to my point - a lot of trouble to go through.

[Enigma 10]

You already made it clear that it can't be done without drawbacks. Which is the reason why I'm hesitant to support it all. My concern is whether or not the drawbacks are worth the benefits and how it affects our options. Also I need to know whether this VXace thing can be done at anytime or at the start of the project.

[Moonpearl 32]

It can be done at any time. As to whether the drawbacks are worth the benefits, clearly there will be different opinions about it, but mine is definitely no. If you want to override RPG Maker's limitations then you shouldn't use RPG Maker in the first place.

[Bigace360 38]

Lol I just notice you guys had this big convo, how did I miss that. :P

You can't. Making any of the improvement you mentioned requires to work around the base engine more or less heavily. Well then using RGSS scripting to replace the original C++ code will inevitably result in something slower. So even if you do optimize the code all in all I'm pretty sure it will make little to no difference at all.

 

Plus, sorry to insist on that matter, but I'm really curious as to how people decided that RGSS3 had better performances than RGSS1. On the paper it seems logical to think so, but since I was curious to find exactly how faster it could be I ran benchmark tests using the exact same scripts in both environments, and it turns out RGSS3 is just as slow as its predecessor. Now my experience might be biased and I would love to hear people showing me how their RMXP project run on RGSS3 has a performance boost - but until I do my experience tells me that using RGSS3 with RMXP is just a lot of trouble to go through for a non-existent benefit. Not to mention...

 

...compatibility issues.

Actually I have no campatiblity issues, but you are right performance is about the same. The reason why I use it is mostly because I can use Ruby 1.9.x instead of ruby 1.8.x. My menu system still lags because of Enterbrains lazy/cheap performance on RPG Makers engine.

 

It can be done at any time. As to whether the drawbacks are worth the benefits, clearly there will be different opinions about it, but mine is definitely no. If you want to override RPG Maker's limitations then you shouldn't use RPG Maker in the first place.

I support this, but the only problem we run into is wasting time studying a new engine. Which can be done, I'm about to get into Unity, how many other people would want to jump into something else when they are comfortable with RPG Maker.

[Enigma 10]

This thread is now closed. Votes have been cast, engines have been chosen, thank you for participating.