I've blogged about this on my gamedev.net blog as well, last year, but thought I could also start a blog here on the same lines: my development of an indie rpg-maker, which I'm calling "BeyondRM".
What It Is.
BeyondRM is my development of an alternative role-playing game creator program, which will meet or exceed the features many of Enterbrain's RPG Maker series of programs.
My primary effort in this weblog is in discussing and obtaining feedback on the various aspects of such an editor, engine, and platform composite level of applications. This is based upon my use of Enterbrain's RPG Maker VX Ace editor and engine, most specifically upon seeing a thread for "suggestions for the next rpg maker"; while somewhat disorganized a list, many of those suggestions seemed to be things can can and should be incorporated into an actual editor and engine system. So, with my own experience in programming in Java, especially in Minecraft modding, I sought to look into each of the features that make a core 'rpg maker' type of framework for creating classic-console-styled games.
Note, I've also been tinkering with the Open RPG Maker editor; but it's perpetually in an unfinished state, but comparisons may also be present in that, as well.
Just The Essentials.
Boiled down to the essentials, I have been taking the aforementioned suggestions-list and assorted 'master scripts lists', combining and organizing the features into a cohesive features-list that meets or exceeds Enterbrain's own efforts. My work in examining popular Minecraft mods as well as other Java-language apps and utilities gives me specific insight into how it can be developed in Java itself, allowing for far more cross-platform potential than in being hard-coded for each OS in particular, in C-like languages.
The meta-organizational aspects of this meta-project are that it has (in its current state) at least three core parts that are being developed:
- an Editor, to handle game-content creation and building;
- an Engine, to run the built game as well as test-running working data;
- a Platform, a collection of dependency modules that both the Engine and Editor may depend upon in common;
and a fourth potential core part might be for supplemental modules, such as a "plugin framework" collection of supporting modules to the main editor and engine. The core Java documentation learning trails contains a page for creating an "SPI framework" for an application; and both the engine and editor will each have their own, to allow extensibility.
Why Not Enterbrain's Program?
Part of RMVXAce's inflexibility is, for the editor, in its inability to add in new Database panels for adding new content-creation panes and tabs, and in the engine, in its limited inability to support new extraneous content, only through parsed data in note-tag blocks. If using SPI infrastructure, both our editor and engine will be able to properly extend the ability to create and play with new forms of data.
For example, some of the RM third-party scripting is for creating additional systems for a game engine to handle, such as a Crafting system that the baseline game would not have, or for adding in alternative layouts for menus and scenes, even up to and including new Battle Systems and combat methodology. Many of the scripting is for what amounts to minor tweaks in layout, positioning, and sizing of the screen and things shown on it. By far one of the most popularly-requested feature was the ability to use the full-screen resolution (even though "resolution" is the incorrect terminology); Youtube already has many Java video tutorials which can be freely copied, for creating and drawing to a full-screen video context. (In fact, if not copying wholesale an existing engine, a developer can find code for almost any and every aspect of a game engine, by a few patient searches; the key word being, "patient".)
Extensibility of Editor and Engine.
While extensibility is a "must have" feature, and a lot of the functionality may actually be placed in plugins and extensions, the editor and engine cores will have functionality at least on par with what is available in Enterbrain's existing products, if not exceeding them, where possible. At a minimum, for some parts like a Crafting system, this project of mine should contain built-in interfaces and abstract classes, that a third party can use to create a personalized version of one or more variations of a crafting system. It would be good to have a small library of such things, so that a non-programmer could use them with minimal struggle.
It's a bit humorous, but I've also seen suggestions for the next rpg maker, that are in essence, "more built-in events, so we who don't want to be programmers can do things"; those events are just as much a part of programming, albeit in a minimal way, that lends to its hilarity. The mindset behind knowing what you want an event to be and perform, is the same as beginning to learn programming in a "serious" language; that is to say, how a person puts together the event code may not involve actually typing out the code, but it's very much a practice in analysis and iteratively adding or removing lines, until a desired result is accomplished. Having more built-in events, whether it be from a previous RPG Maker release or not, depends a lot on what can be or should be optimized into the engine and editor.
Where Next?
This blog will be a semi-regular event, wherein I ponder, muse, and digest my understandings and intentions on developing this meta-project. Perhaps next blog entry will discuss what is in a typical RM project.
