How to implement Modules



After speaking with some EasyRPG developers I am curious as to what some people might think as the best form of a module system. There are three main ways that it could be implemented. The first is direct scripting in which a language is embedded in the editors. The next is dynamic loading which has the advantages of less dependencies. The third which is how I think some people have been leaning towards is a socket server model that could have an API build around it. All of these methods are cross system supported, however only the first and the last allow for modules themselves to be cross system.

The last one has the advantage of simply having to implement a simple protocol that allows a server to be called however you want in whatever language you want with the possibility for a folder to hold modules to be called upon the server being started. This approach is similar to how X works for those familiar to Unix and how every web server works for web programmers. The biggest disadvantage is that data structures cannot be passed directly between editor and module unlike the other models.


This topic makes me curious, since i dont event know what modules are to programs and what advantage they can give to it: What kind of stuff will you be able to do with editor using modules? and, Does the player also need to be extended with modules to play the games wich uses them?

One of the reasons i (personally) i’m working on EasyRPG Editor (besides of RM’s lisence of course) is because binary files are not friendly to repositories like github or sourceforge. This makes team work harder specially when everyone works at home. that’s why we are saving files using xml style. So, modules may give any kind of problem to the people willin to work in team?

I’m exited about the posibilities this could bring, in the meanwhile there’s something i want to tell you, in a (far far away) future i was thinking on allowing users to write implementations for new event commands, and allow them to use these commands on the traditional event editor.


By the way, maybe you are interested on this:

that’s how to implement the first of your 3 choices. A shared library.


A module/plugin/add-on is a way of extending something in a packaged (distinct but interrelated unit) fashion, it is most useful in allowing a program to do something nobody has thought of in a simple fashion. Plug-ins might (as in quite possibly definitely will) be a bad idea for the player as it would result in games that are dependent on plug-ins which would be a step backward from having the player work on all the different platforms it does (the editors only need to work on general purpose computers). A good way to think about modules is if the editor is a compiler (in a way it is since it turns a visual representation to one that is player readable) and modules have the ability to add macros which while producing the same output as their definition, are much cleaner to look at and can make lots of little tasks work as if they were a single task.

I do like the idea of saving files in an XML like fashion (readability in source code is always important plus sourceforge/github/bitbucket are great for group projects which is what most games are), modules themselves could be written in any language as long as the editor has some form of API to deal with it. Modules would be the exact opposite of anti-team work (think ruby or python script level) because it allows anyone to extend and add to the editors without imposing a feature that might not be a good idea for many people (maybe emacs/vim/qt-creator/some other ide integration especially for people debugging the game output of editor if there are issues(also something like this is also a VERY far future type of thing)) avoiding bloat (unlike this overly long reply).

In summary the biggest idea is that maybe somebody does the same task over and over and wants to have it done automatically or in a way never intended by the editors developers (place 500 tiles this way in a spiral, load this project from this directory from this server, git integration, mercurial integration, any number of revision control/image manipulation/anything imaginable integration).

Shared libraries do look like a good idea especially due to lack of extra dependencies and simplicity, I am trying to figure what system is the best because there are a massive number of different valid approaches to extending programs.


you mean like a “create a chestbox here” command on popup menu? :stuck_out_tongue: sounds fun, I’m on it. Once again i suggest you to see the video above and also the one bellow, these are examples of plugins created for a Qt applications wich launches plugins remotely. There’s too much to say about the way for creating plugins when Qt already has it’s own way to do it (thought maybe it will force people to use Qt to make plugins, not sure if it’s posible write plugins in another language and load them with Qt’s plugin loader…) anyway, i liked specially the plugin for creating a ftp server: … O3iL8YaAKA


Exactly like that! I do like the qt way of plugins, however I hope to maintain both the qt and gtk versions of the editors (I have already submitted a pull request to replace depreciated stock items on the gtk version and hope to replace the depreciated use of gtk.action). On a set up some of qt’s text fields do not work, it is a qt issue thought and is due to drivers so my case is too specific to be considered an actual issue and I have another setup where the qt editor works aside from crashing and oddly requiring a recompiling to work every now and then. I would like modules to work regardless of editor the same way and creating a window or fancy graphics that are library specific is not necessarily important for a plug in since it deals more with placement and not rendering.


The main disadvantages of shared libraries are
[li] They are tied to a specific platform (CPU and OS).[/li]
[li] You have to maintain a stable ABI.[/li]
[li] A bug in a plug-in can crash the application.[/li][/ol]

Embedding an interpreter avoids these issues. However, it requires more work, as you typically need to write code for each function which you want to make available to scripts.


to be suitable, plugins should use an interface wich allows to add elements to the GUI’s and create own dialogs. This will need to create an interface for GUI generation and implement it both in Qt’s and Gtk’s projects so they look about the same… many libraries of this kind uses some kind of OnGUI() functions wich make uses of functions like:

if (GUI::button(rect)) {do_something();}

Widgets are automatically placed row by row.


I think a basic key-value input method for parameters is the most simple way for this, e.g.:

parameter label:

  • label for the parameter
    parameter type:
  • for multiple array selection, show some multiselection widget
  • for simple array selection, a dropdown, or radio buttons if they fit on screen
  • for string input, a simple text input
    Some help text is worth.
    Translation support for strings.

Plugin dialog could be built automatically from these to keep them simple.


For widgets I think it might be good to have an area right of the map in the editor deticated to having buttons added to it by plugins so that things avoid clutter.

So should I write some bit of extensability as text fields in the editor so that things are like:

(Not a good example, but it was the first that came to mind. Ignore the contents, the point is that it is a gui parameter based input system)

I am not sure what you mean by multiple array selection, is this an array in terms the programming sense or do you mean a way of grouping similar options like when you mouse over “map” icon a drop down menu appears with “tiles”, “layers”, “battles” or something along those lines until you reach a point where pressing an option opens up a dialog like the one above.

I would like to at some point in the future after I get some start to a plugin system like to use mRuby especially since the original RPGmaker series uses ruby (this would make it easier for people to switch over) and it is a very very cross system was of doing things.


whati mean is a general way to refer widgets. You can always create a GUI using QtCreator and conect all the options, but to “extend” editor you need a way to attach it properly: is this a toolbar? wich window have it? popup menu item? where? a new menu with new features? this needs generalization, and should be included in the interface to give module creators as many options as posible.


by the other hand, imagine you want to make a “hero picker”, a “variable picker”, a “charset picker” and so on. You may want to make a module to convert music files to ogg for example…