BeyondRM

The github pages for my BeyondRM org.

Project maintained by BeyondRM Hosted on GitHub Pages — Theme by mattgraham

Welcome to the BeyondRM Pages.

This is the webpage to find information about BeyondRM, the "Beyond RPG Maker" software.

The Initial Idea.

The idea began with my usage of Enterbrain's RPG Maker software, of the VX and VX Ace varieties. While these programs are incredibly powerful enough to allow a person to create a game, they have some needs associated with their usage -- mainly to produce a game that is not the same as any other game.

Any rpg-maker (generified) must be, to some extent, extensible, to truly be more than static content creation. Now, these game-maker programs do have scripting support included, as the platform is inherently based upon Ruby scripts; and if the game creator wishes to add more features, then most likely, "there's a script for that" (or one can be created).

So, browsing around on the RPG Maker English forums, I did see a thread or two about desired and suggested features for the "next RPG Maker". To date, we have no indication of these suggestions having even been vetted or viewed by the main RPG Maker developers; but many of the ideas are good ideas for implementation.

So, being the keen Java developer, I began considering the requirements of creating my own open-sourced clone of the editor &mddash; so that games could be created with a more modernized program.

The BeyondRM Project.

BeyondRM has been in development for a short while, just on my local drive since earlier in 2014; it is programmed almost entirely in Java, and will utilize a library for script handling of Lua code. The entirety of it is broken into three primary component parts: the platform, the game engine, and the editor. Each of these exist in their own repository, and each of them can be broken down to separate projects, for specific dependency-management.

The Platform.

Our platform handles aspects of the target game, such as the things from the Database tabs in "the other rpg maker". It has project modules for loading and handling of the images, audio, and various content which makes the game function. Useful for attributes, classes, conditions, character definitions, map definition, event data, anything which the editor would be used to create the game content. Even the meta-definition of a battle system and a crafting system begins here; the specifics of those are in the Engine modules. For future reference, I also intend to allow implementing one's own RPG system with different character stats, if those from the baseline RPG Maker project are not relevant to a game-maker's game content....

Platform module projects are for the storage-backed game assets that are implemented in the game environment; this platform data is used by the Engine module projects to actually play the game, and by the Editor module projects to create and edit such content.

The Engine.

The engine, it should be no surprise, is the literal "game loop" in which a game operates, like the engine in an automobile. The main game loop is being designed with multi-threading in mind, to spread the computation of game functionality across multiple cores, where necessary. Full-screen access is intended to be native.

Our engine is also "state-based", meaning that its broad functionality can be logically separated into various "states" of operation, with a common ancestor class to unify how they are defined. The game title screen is one state; game loading or saving screens are also each a unique state; cutscenes are a special kind of state, can be canceled but otherwise not interacted with; an in-game menu is yet another state; and finally the actual game-play is in another state. Each state allows defining relevant methodology for its initialization, drawing, and updating of what happens per game tick, as well as what happens when switching to or from a different state.

The Editor.

The editor is perhaps the gaming aspect where most game-makers will be spending their time; and to that end, it is being created with JavaFX (from Java 8.0) visual components, a lightweight declarative component layout, styled with visually-pleasing CSS attributes as much as possible. Don't like the way it appears? Copy the cascading style sheet to duplicate file, edit the FXML CSS to your liking, apply it to the editor interface, and optionally share it, for others as well.

At first glance, the editor is being designed to be a fully tabular interface, meaning that most content can be accessed from within a tab pane in the editor, and not depending upon opening a new window … in most cases, this may speed up game development somewhat. Tabs are arranged according to the sub-tabs containing editing features, and navigation between them is intended to be smooth.

Editor tabbed interface.

One main tab will function as an "editor control center", featuring sub-tabs for information and configuration statistics, as well as metadata for an opened project.

Second and third are two tabs for editing the parts of the "database", separated for content that is either:

(A) unchanging through a game, or
(B) changing by its nature when a game is played.

The former contains sub-tabs for defining animation, attributes, classes, conditions, items, et cetera, things that do not change and do not need to be saved in a running game. The latter is for such things as characters and variables which change throughout a game, and should be saved when the player saves the game.

A fourth tab is for anything mapping-related: managing the tilesets used across the Editor, managing the maps lists and editing of events, et cetera. It may also be useful for managing battle system terrain, specifying the battle background and placement of the combatants, and more.

Another main tab is for specifying features of the game system, the localizable strings (a planned feature), core features and initial state of a game window, basically properties to control the broader workings of the game engine, thing that are not part of the game database.

A final tab may be for the various meta-project tools, such as handling graphical media (setting up animations or tweaking sprites), character sprite generation, et cetera.

Editor, Work With Engine and Platform.

While the Platform is mentioned to be the storage-backed point of commonality between what occurs in the Editor and Engine, the Editor components should allow game development in a way the current RPG Maker editors do not: cooperative or "team-based" game making. Meaning that for a small team of two or three people who share a single objective for a game, each can each focus on the aspects of an RPG that they like. (The specifics of how to perform this are currently under consideration, but may depend upon a version-control methodology.)

Editor functionality depends upon both the Platform and Engine modules, and adding functionality is possible, although corresponding functionality should be added to the Platform first, then to the Engine, and finally to the Editor.