Suggestions for the next RPG Maker

Status
Not open for further replies.

Onomotopoeia

I don't know, nobody's told me yet.
Veteran
Joined
Jul 11, 2014
Messages
222
Reaction score
27
First Language
English
Primarily Uses
If anyone wants to write their own RGSS (please don't do that, look at other game engines) or even a RPG Maker using Python or Lua, then I'm totally fine with that, too.
Because I've got my own "alternative rpg maker" that I'm developing, I may be more-or-less doing just that (mostly the "more" part, or for an almost certainty), recreating a "pseudo-platform" the equivalent or greater than RGSS; the projects are already begun development, but I'm also determining which scripting system to go with. (Seems to be either Lua or Python, at this point.)
 

whitesphere

Veteran
Veteran
Joined
Mar 14, 2014
Messages
1,688
Reaction score
784
First Language
English
If they were going to swap scripting languages around, I think the most logical choice would be Java, because it is already widely supported and optimized and runs natively on Android phones, since cross platform support is one of the most often requested features.  In theory, a purely Java based RPG Maker could run on Windows, Linux, Mac, iOS, Android and as a Web-based game in general.

And there are already extensive IDEs to work with Java.

But I have no idea how well or poorly Java would perform with a heavily graphical system like RPG Maker.  Then again, I don't think everything in RPG Maker is running in a variant of Ruby, either.
 

Zoltor

Veteran
Veteran
Joined
Jan 18, 2014
Messages
1,550
Reaction score
211
First Language
English
Primarily Uses
If they were going to swap scripting languages around, I think the most logical choice would be Java, because it is already widely supported and optimized and runs natively on Android phones, since cross platform support is one of the most often requested features.  In theory, a purely Java based RPG Maker could run on Windows, Linux, Mac, iOS, Android and as a Web-based game in general.

And there are already extensive IDEs to work with Java.

But I have no idea how well or poorly Java would perform with a heavily graphical system like RPG Maker.  Then again, I don't think everything in RPG Maker is running in a variant of Ruby, either.
Yea I completely agree, I know well the capabilities of Java, and if they were to change to another language, that would be the best option.
 

cremnophobia

Veteran
Veteran
Joined
Dec 10, 2013
Messages
224
Reaction score
100
Primarily Uses
Ha! I've wrote, but deleted it, in my previous post that a rewrite would make the most sense, if support for other operating systems gets added at the same time (which is also much work). Java, or in particular the JVM (which allows using other languages than Java including Ruby), is indeed great for that. There are also downsides. E.g. higher memory and maybe disk space requirements.

Because I've got my own "alternative rpg maker" that I'm developing, I may be more-or-less doing just that (mostly the "more" part, or for an almost certainty), recreating a "pseudo-platform" the equivalent or greater than RGSS; the projects are already begun development, but I'm also determining which scripting system to go with. (Seems to be either Lua or Python, at this point.)
As I've already said, don't let the RGSS inspire you too much. Do you already have a game engine? If not, then maybe use an existing one like https://love2d.org/ and build your RPG Maker upon it. Just an idea to save some work. Good luck!
 

Onomotopoeia

I don't know, nobody's told me yet.
Veteran
Joined
Jul 11, 2014
Messages
222
Reaction score
27
First Language
English
Primarily Uses
As I've already said, don't let the RGSS inspire you too much. Do you already have a game engine? If not, then maybe use an existing one like https://love2d.org/ and build your RPG Maker upon it. Just an idea to save some work. Good luck!
I haven't actually heard of that one, so thanks for the link; as long as I can keep it open-sourced and freely-available (will have to see what that project does).
I've actually been trying to develop both editor and engine somewhat simultaneously, so that I know the features as I'm developing. With a separate engine, I could come to learn about its features as I'm developing too, but maybe miss something at odd points in the development, so it's a tossup. Which comes first, the chicken or the egg? Oh wait, science already proved the answer on that... <insert other cart-before-horse analogy instead>
 

Tarumes

Villager
Member
Joined
Mar 2, 2014
Messages
27
Reaction score
10
First Language
German
Primarily Uses
Games and Maker for all OS (Linux, Mac)

Pluginsupport for Maker (like GUIs for Scripts)
 

Sharm

Pixel Tile Artist
Veteran
Joined
Nov 15, 2012
Messages
12,760
Reaction score
10,892
First Language
English
Primarily Uses
N/A
As I recall the argument against plugins is that it trades the easier creation and higher flexibility of scripting for only slightly easier implementation. It's not a good trade off and would loose the interest of all the higher end programmers you'd need to actually make those plugins.
 

Onomotopoeia

I don't know, nobody's told me yet.
Veteran
Joined
Jul 11, 2014
Messages
222
Reaction score
27
First Language
English
Primarily Uses
As I recall the argument against plugins is that it trades the easier creation and higher flexibility of scripting for only slightly easier implementation. It's not a good trade off and would loose the interest of all the higher end programmers you'd need to actually make those plugins.
... Not ... necessarily. You are making it sound as if developing plugins for the editor interface means you are losing scripting; but I don't think so. I believe implementing a plugin infrastructure on top of the editor could allow adding additional Database editing tabs so that customizeable content can be implemented within the game editor itself. (Using the Notes section isn't always an optimal solution to adding functionality. It works, but -- we need a better way....)
 
Last edited by a moderator:

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
32,355
Reaction score
8,081
First Language
German
Primarily Uses
RMMV
While that is true, it doesn't change the problem Sharm was pointing at:


Turning a script into a plugin requires additional work, and it needs a skill that is not identical to scripting - not all scripters could create a plugin-GUI for their scripts as easily as they write the scripts themselves.


Don't forget: almost none of the scripter earns money from the work (at least not for public scripts), so they often have no interest in adding more work into a script that works without a GUI. The only people who would need the GUI are the people who are using the scripts, not the ones who are writing them.


And implementing a Plugin-Interface is not something that's done easy or fast - and that means you have to pay Enterbrain/Degica additional to money to get that feature.
 

Sharm

Pixel Tile Artist
Veteran
Joined
Nov 15, 2012
Messages
12,760
Reaction score
10,892
First Language
English
Primarily Uses
N/A
*shrugs* That's what it sounded like to me. It had something to do with impossibly complex compatibility problems if you had both in the same program as I recall. I'm not a programmer, I wouldn't know.
 

whitesphere

Veteran
Veteran
Joined
Mar 14, 2014
Messages
1,688
Reaction score
784
First Language
English
It sounds like we're saying "Can we make plug-ins that allow straight GUI editing of features scripts need?"

In order to do this, either script writers will have to somehow define detailed meta-data which explains which plug-ins they need, what data is required, etc.  And those definitions won't end up being sufficient for the many script variants.

Or, script writers will have to create plug-ins as well, if they want to have, say, custom fields associated with a Map.  

Then, we're asking script writers, most of whom aren't paid, to learn another language altogether (not every programmer is good at making DLLs in C or C++) and dramatically raise their workload in doing so.    If they make new versions that need extra parameters, the plug-in must be updated as well.

And debugging GUIs, like the plug-ins, is VERY time consuming.  

Then, if the script writers haven't bailed because of the drastically increased workload, you'd be asking game developers not only to manage a horde of scripts but a horde of plug-ins.  

So you run the risk of not only breaking the runtime game, but even the GUI which could put your game in an unrecoverable state because you can't open the GUI to fix it.  I can easily see a GUI plug-in breaking the GUI irreversibly.

I agree there needs to be some intelligent, consistent way of adding meta-data to game components, but GUI plug-ins which interact with scripts is just asking for trouble.
 

timk1980

Apprentice
Member
Joined
Mar 15, 2012
Messages
123
Reaction score
42
First Language
English
Primarily Uses
I agree there needs to be some intelligent, consistent way of adding meta-data to game components, but GUI plug-ins which interact with scripts is just asking for trouble.
Quite honestly, I think part of the reason noteboxes have caught on (apart from being really the *only* option in some cases) is that they are simple, flexible, and can be used for just about anything.

One can imagine a world where various database elements all support a list of arbitrary name:value attributes that could be used by different scripts to do what they need.  But, even something like that falls apart when you start dealing with data that is hierarchical in nature or has complex types.  And you'd just have attribute values being used the same as noteboxes are now, with increasingly complex formatted strings representing more complicated data.

I guess you could also imagine being able to assign arbitrary XML or JSON snippets (perhaps tagged with a script title) to these DB elements as well, but that's barely different from using noteboxes today.  Perhaps having an XML or JSON library available for scripters would facilitate something like this a bit better.

As for a true GUI-plugin, I think it would suffer in many of the ways already described.  eB/Degica adding it would be a monumental programming effort to architect in any kind of sane way, and at least as much effort would be required on the other end to integrate properly.  The fact is, the editor just isn't (currently) designed an built in a way that lends itself well to something like that.  For those already familiar, or who want to check it out, play with the Unity engine a bit to see what an editor that is built like that actually looks like.  Then look at some code that actually integrates its own custom GUI elements into the editor, and you'll quickly see that just the GUI editing code (most of it uninteresting, almost boilerplate) can be a substantial effort.  And this is for an editor designed and built to work like that.
 

Tai_MT

Veteran
Veteran
Joined
May 1, 2013
Messages
5,528
Reaction score
4,960
First Language
English
Primarily Uses
RMMV
Suggestion for next RPG Maker:

Blood graphics? :D  For maps?
 

amerk

Veteran
Veteran
Joined
Mar 13, 2012
Messages
1,433
Reaction score
495
First Language
English
Primarily Uses
Plugins are certainly a lot easier and not as flexible, but they can give some alternatives to newbies looking to change some mechanics until they've had a chance to learn about scripts.

Actually I thought plugins were frowned upon because of source code issues, as noted with the plugs for RPG Maker 2003, but maybe I'm misunderstanding here. After all, those plug-ins do add some features that can be scripted in the newer makers, but they also change some things in the way the editor is handled by directly adding things to the database.

I'm on the fence in terms of plugs. I'm not a script writer, but I like the ability of having some flexibility in how scripts are handled. At the same time, if there were plugs that could modify the program without granting access to the source that gave add-on program options that aren't possible with scripts (similar to how Bulletxt added the tileset swap to VX), I'd be all for it.

The problem here is there are already so many 3rd party tools you can use to do a lot of the things the maker can't, that it'd probably be a moot point.
 
Last edited by a moderator:

Tsukihime

Veteran
Veteran
Joined
Jun 30, 2012
Messages
8,564
Reaction score
3,872
First Language
English
Personally I don't see much of a difference between scripts and plugins. I already consider the scripts people use to be "plugins".


I'm sure if the RM devs wanted to invest time and money into it, they could make the editor itself customizable with ruby code. It likely just isn't in their interest to do so.


Unity has it so that all you have to do is define a public attribute in your scripts, and the GUI will automatically display a field for any objects that the script is associated with.


And this doesn't require complex metadata on my end or anything; it's just declaring a variable.
 
Last edited by a moderator:

timk1980

Apprentice
Member
Joined
Mar 15, 2012
Messages
123
Reaction score
42
First Language
English
Primarily Uses
Personally I don't see much of a difference between scripts and plugins. I already consider the scripts people use to be "plugins".

I'm sure if the RM devs wanted to invest time and money into it, they could make the editor itself customizable with ruby code.
You've actually hinted at the difference already... plugins = changes to the editor.

And your second point is exactly what I was going for as well... "if they want to invest the time and money", something I tend to doubt.
 

Zeriab

Huggins!
Veteran
Joined
Mar 20, 2012
Messages
1,288
Reaction score
1,460
First Language
English
Primarily Uses
RMXP
Notice the contextual difference between the editor modifying the static game data and the game interpreting the static game data without modification.

We can make scripts that modifies the static game data. These script however typically require a generating state (game dev running the game) and playing state. Some can do certain trickery to accomplish both at the same time, but it is merely a hack. The best solution would be to place the code in the proper context. Yes, by the editor.

Being able to create an add-in, a plug-in or in some other way automate static data creation tasks directly in the editor will be a great boon. I imagine a plug-in would consist of two primary concepts. On one hand, we have the visual representation. On the other hand, we have the logic dealing with the reading and/or writing static game data. (Meta-data, etc.)

Yes, an optional plug-in system will increase the complexity of the program. How much for users not using any plug-ins though? Looking at Visual Studio and Eclipse (Java IDE) the answer there is very little nearing nothing. You can easily use both without ever needing to pay attention to the VS extension system or Eclipse plug-in system. I do not see any reason why the same should not apply for the rpg maker editor. (Assuming the system will not be implemented in a stupid fashion)

Creating both a plug-in and a normal script will likely require more effort than just creating the script. The beauty of the optionality. Just do not create a plug-in. Create scripts as you would now. Similarly a plug-in system will allow development of say macros that focus on the standard scripts. New quick events is an evident possibility. Moreover in the context of a single game you can create plug-ins to support game specific systems.

The implementation effort for Enterbrain/Degica to create a plug-in system will probably be great. My gut feeling is that we will not get the ability to extend the editor. Still, it is a great idea :3

*hugs*

 
 
Last edited by a moderator:

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
32,355
Reaction score
8,081
First Language
German
Primarily Uses
RMMV
There is one fundamental difference between adding scripts to a game and adding plugins to the editor:


While both can theoretically break the engine (and often do if mixing the wrong scripts), the game project can be recovered from the editor be removing or repairing the scripts.


If the editor breaks down due to a buggy or incompatible plugin, that will not be as easily recoverable, unless you add another layer of priority and code security. And that would go far beyond the capacity of what Degica and Enterbrain can do on their limited funds and personal - you might also remember that in the working examples above (Visual Studio or Java), the companies behind those editors have a few more employees than Degica and Enterbrain...
 

Zeriab

Huggins!
Veteran
Joined
Mar 20, 2012
Messages
1,288
Reaction score
1,460
First Language
English
Primarily Uses
RMXP
The editor would be more likely to break. I agree.

Problem can be solved if there is a way to start with a fresh editor. Give an option to remove all plugins and related configuration when uninstalling. Then uninstall->install can be used to reset the editor.

Sure, you should take backup of your plug-ins. You already should take backup of your static game data. Remember, only additional work if you are using plug-ins.

As for actually breaking the engine, I consider it less likely as the engine is normally not running while you are working in the editor. You could of course do something stupid like deleting Game.exe or deliberately mess up the game data, let's disregard deliberate malicious intent. After all, if the source code is required for the plug-in it looks like the same level of trust is required, as it currently is with engine scripts.

You seem to imply that adding plug-ins is somehow technically worse for the users (us, game developers). I am strongly against that notion. Having a plug-in system for extending the editor in addition to what we already have can be a great boon.

I do not dispute that developing such a solution is costly and difficult. It would almost certainly require another layer of abstraction and accompanying complexity. Such a system will allow the function of the editor to grow after release and independently from the RM devs, so it does provide value. Personally, I do not believe we will see plug-ins implemented. My gut feeling is that they will consider the cost too great.

To summarize: Plug-ins are a boon to us, the game developers and a boon to the RM devs. Therefore I suggest it.

*hugs*

 - Zeriab
 

Zoltor

Veteran
Veteran
Joined
Jan 18, 2014
Messages
1,550
Reaction score
211
First Language
English
Primarily Uses
I must agree with Hime, there's really no point for so called plugin support, because that's really what scripting already is, anyway. 

To Timk: Sure there are things like battle scripts that don't effect the editor at all, and what you see, is what you get, but make no mistake, people are using scripts to add to the editor all the time.

Any script you see using Note Tags in the database/map properties, using comments,condition branches, text boxes, and script calls, are always either adding a option to the editor or changing how a feature in the editor reacts in game, when used.

While you can't "directly" change the editor its self, you don't need to make a extra command button show up in the actual editor, to add options to the editor or change how features react in game.

To topic: Allow for the actual launcher to be customizabe. It's one of the weakest aspects of RPG Maker, just because you can't use script to edit it, nor do you have access to the source code of the launcher, because It's not part of RPG Maker at all, It's a hard coded RGSS App that gets attached to a RPG Maker game/project.

Why aren't things like viewing screen size, and button configuration/support up to the developer sigh(nevermind the client icon, which people tend to use a hack to change, because It's beyond stupid not being allowed to use a icon that represents the game "you" made)? Generally when a engine has built in systems like that, they can be edited, but for some reason,Enterbrain doesn't want people to have access to the launcher/any of the feature tied to the launcher at all.
 
Last edited by a moderator:
Status
Not open for further replies.

Latest Threads

Latest Posts

Latest Profile Posts

Dam, does the night get to me, I sound and look like a monster. Its 3:54 am right now...I need sleep...or...coffee.
It has nothing to do with my project, but I'm in love with voxels
If you feel like your story isn't that great, just look at final fantasy.
My original idea of a quest where you just paid money to complete it (it made sense in context) somehow got turned into decorate a table with a variety of choices so that the majority of players will have different looking tables.
XGkudjn.png

Latest custom tileset work for Raptor Revolt includes beach debris and palm tree. Can't wait to go to the beach!

Forum statistics

Threads
110,481
Messages
1,053,596
Members
143,572
Latest member
Sparyx
Top