• entries
  • comments
  • views

About this blog

Wherein I think, and think, and think again.

Entries in this blog

Gregory Cheyney

Followup over comments found in https://www.gamedev.net/topic/675409-what-is-an-engine/ and defnitions of the engine. -- I used to think somewhat like Norman Barrows, "if it contains a main loop", but lately I've been on a similar quest to refine the definition of terms.

In my case I'm working on my own brand of "rpg maker" much like Enterbrain's official products; and in this case it's not just an engine infrastructure but also contains editor, platform modules, and assorted shared-resources objects. It's true that I would define "engine" to be the "main game loop" and "game state management", but in my personal context it's because I supply infrastructure that "most" people who use an RPG Maker would require in place, because they "want to make a game but don't want to learn to program". -- Taken (somewhat verbatim) from real comments on RMW.

Also in my case is a matter of keeping things open-source and creating a public SPI so that "real" programmers and game developers could extend the editor, engine, and platform modules in a way that none of Enterbrain's little programs could before. Because I want to provide a platform in which the definition of maps, characters, events, essentially a lot of the things an RM-user would be familiar with, yet allow custom things to be developed for both editor and engine to enhance the core parts, ... it takes a lot of work on my part.

While the RM releases allowed somewhat extensibility with Ruby scripting, the editor part was not extensible at all, and Enterbrain license appears to disallow such. For things like RPG Maker VX Ace (to name one recent example) I see quite a lengthy list of Ruby scripts developed by third-party users to enhance the engine with custom functionality, but poorly implemented in the way such things could only be added via "noteboxes" in certain panels of the editor. And with no way for a scripter or game author to add in custom tabs and panels into the editor itself, I view as a tragedy of the modern rpg-makers.

(To be fair, the newest RPG Maker, MV, goes a little further in allowing custom scripts to be added into the scripting portion of the "game database", but I feel that it does not go far enough, and Enterbrain developers are not truly considering the weaknesses of their products in terms of how "power users" would like to extend it, if they could only have the means to do so. Whether they develop their products in C, C++, or C#, Enterbrain could have some way of implementing some kind of plugin/SPI framework for both editor and engine. Such as what I'm attempting, for my own meta-projects.)

So, Definitions, Then...

In this specific example of my meta-projects, I use most common terminology that a past or present user of an RPG Maker system might agree on; except in my case I'm breaking things up into at lear five primary meta-projects.

  • The Editor infrastructure is the GUI/visual used to edit aspects of the game content; even though it is a container for the second aspect, where most of the UI is obtained.

  • The Project infrastructure is all the modules and components that actually "handle" the editing of the game-project's data files, templates, and metadata. It is used to translate, for example, compilation of XML files and project-resources into a more "binary logic" format, readable by the remaining two parts.

  • The Engine infrastructure "drives" the functionality of the game, much the same way a car engine drives the motion of the entire vehicle. In this sense, it handles the main game loop, the game flow, and game-state management (pushing and pulling states to/from a collection).

  • The Platform infrastructure is used to provide the baseline game-object functionality, of the actual data structures used in both project and engine.

    but not called a platform in the same sense as RM's "RTP" infrastructure.

    This is a set of "common libraries" and not the default-shared graphics.

  • The Shared-Resources infrastructure is to be somewhat comparable to the RPG Maker's RTP, because it is to contain various graphics, sounds, and prototype data as may be used in a game-author starting a new project with pre-made game assets. It is primarily useful in the project infrastructure, such as if I use a "new project" wizard for pre-generating a starting project for usage.

    In the ultimate usage and inter-connected nature of all these modules, as far as would work for the common person using this system, I see it as a very complex set of relationships between modules. To a developer such as myself, the Editor depends upon the Project, Platform, and Engine modules, and also the Shared-Resource files which are not technically modules but file-locations; and the Project module depends upon the Platform modules, but not the Engine. The Engine modules depend upon the Platform modules alone.

    What this all means for a developer of custom modules for my RPG-Maker, should be clear -- the editor, engine, and project infrastructures contain SPI infrastructure for "plugging in" custom Java libraries for custom functionality. One example from the rpg makers is in developing something they don't have, say a crafting or even a questing system as its own self-contained implementation. A developer might develop two or three separate libraries implementing the SPI interfaces for each one: a platform library to define a crafting recipe, an engine library to define how crafting is implemented in a game, and a project library to define those parts for the platform-data and engine-operability.

    In summary, the platform libraries are meant for statically-defined game content, things which, once defined, do not change during game-play; the engine libraries are for controlling those things which do change, and/or can or will be saved or loaded with the game-saved data; the project libraries are for the editor's use, in containing the game-project's data files and compilation methodologies of each data types; and the editor libraries (perhaps only one or two) are for containing meta-project information, user preferences, and miscellaneous file links.

    An editor, in my opinion, should be able to compile only the necessary data that the game requires, and be able to add in whatever functionality is customized to the particular game. A game which uses custom battle processing and resolution may be able to replace the "default" battle-processing with one from a custom source, and fully be able to customize its properties in the editor's project infrastructure, with such data being saved with the project files, to be compiled and presented into the game's engine at runtime.

    It's hard to describe it any more particularly than this, but believe me that I've been thinking on how to break-away large game projects and editor infrastructure into smaller pieces, and yet allow for pluggable functionality, without over- or under-performing for customizability. But what started out as my writing about "definitions of an engine" has morphed completely into something of far greater meaning (I hope).

Gregory Cheyney

I find it odd that so many classic rpg will just go with the default human and humanoid characters (especially humans, elves, sometimes kemonomimi or nekomimi characters, and other mostly humanoid or human-hybrid species). Okay; I know a lot of non-human races won't be very represented in the classic RPG, because they cannot or would not have the tendency to equip armor, weapons, and items the same way, if at all. Can a slime creature equip armor without absorbing and dissolving it? Perhaps not. Can a gryphon or harpie hold a sword in their talons? Again, likey not. Where are the recruitable bears, lamias, harpies, gryphons, and slimes?

I did once have a minor daydream about making a game where nonhuman characters and creatures could be just as recruitable as, say, Viktor and Flik in a Suikoden game. (Speaking of that, Suikoden games did have a small selection of recruitable non-humans, very small indeed; it might be interesting to have games where just as many of the characters if not more than the humanoids were specifically not humanoid.) To that end, the concepts relevant to including race as a primary controlling aspect of characters as well as classes must be handled first. This means, race defines the traits and characteristics which the potential classes must obey, and so forth down the line to characters themselves. It might be as simple as size, mass, and other physical properties.

A race definition must include a default growth curve (and maybe bonus growth, for variability) for each of the rpg system stats, and list of innate skills, to tweak the experience, leveling, and advancement for an individual of this species for each stat. This is to remove some of the stat-leveling from the classes themselves, and to keep it relevant to the race instance that a particular character is. It's to simulate the growth potential between a human and a dwarf, in a game where dwarves make excellent blacksmiths, craftsmen, and tinkerers; level one human and dwarf characters might be around the same level of prowess at crafting something in a forge, but for each character level of advancement, the dwarf might get a pronounced edge over the human when it comes to forging weapons, armor, trinkets, and such. -- A second example might be that avian species would possibly have flight as a capability that non-avian species just could not do, or at least unassisted.

Also, due to the inferred biological differences in a race's form, the race could or would possibly have its own unique equippable slot definitions. I will presume that most humanoid bipeds would share the basic same equipment slots for headgear, footwear, chest/torso armor, pants, and perhaps some hand or arm armor; but the difference becomes obvious when something like a harpie or a lamia is involved. Neither harpie nor lamia wears footwear; a harpie might be able to adapt some pants or skirts, but a lamia creature doesn't have the legs to wear pants, and a harpie would not be able to wear gloves or handwear due to its wings. Other non-human species might have just as unique equippable points on their bodies.

So to this point, we have custom stats ranges, skills, equippable slots, and ... what else? Well, above I wrote something along the lines of classes must obey the race definition; but on the flip side of things, a race should also allow or limit which classes a character of that race may be -- a harpie cannot be a very good archer, if at all, and a sentient bear-like species might be a natural-born mauler class of combatant, with their long, sharp claws.

Also, if we are in any way implementing a realism-like method of limiting party item-carry capacity, it might be handled from the race definition itself; or at least as a baseline, the individual character might have other strength-related bonuses which boost the carry capacity. An aforementioned sentient bear species, due to likely larger mass and musculature than most humanoids, have a quite larger carry capacity but not need as much proportionally-larger a set of armor than their humanoid fellows in the party. -- How it works is this: the party's carry capacity would be a computed total of each party member's individual carry limit, subtracting the weight of their armor, weapon, accessories, and items. (Item weight is one additional thing which would be required. It might even be a unique twist to an RPG, that size and mass affects carry capacity: a party can buy that fancy class-specific item, but if a member of said class does not have the carry-ability for its weight, the item is just extra weight in the party inventory. Very unique twist, indeed; one that would require the player to be very tactical about which things are equipped and carried.)

And it goes on like this; the main point of having a race or species for organizing characters and classes, is to remove some similar functionality from the characters and classes definitions themselves. In the long run, this will allow us to do even more interesting things in characters and classes, down the road.

... I feel all typed out, now....

Gregory Cheyney
For anyone who has considered or is working on RPG engines, at some point we come across the source image that I found in a tutsplus.com article, that refers to a generalized "architecture" for the modules of an rpg engine. This is a good starting point when developing a state-based system, where each state represents a current activity that does not run in parallel to another state. For example, each of the game menus could be states, the game maps could be controlled by one map-controller state, and the beginning and ending(s) could be more states. I've taken this approach before having seen this graphic, but oh boy am I glad I'm on the right track...

The article where I found this image also has other good aspects for a beginner, and perhaps even someone with fair knowledge, to peruse; if you haven't seen it yet, please take a few minutes to look at it here. (In fact, the whole gamedevelopment.tutsplus.com site is replete with a few interesting tutorials and thought-provoking articles; it may be good to follow the site in general.

The Point?

In my case I had originally put all the states as equal sibling Java classes, all descended from the same abstract class; but in reorganizing my work, I found a few interesting facts about the use of states in general, and things in specific I should have realized about classic rpgs when playing them, had I been more analytical. It's these few new facts that will be the basis of additional refactorings of the source code.

  • First, a few states are specifically for application-level notifications and meta-game states: an "engine beginning/initialization" state for when things start up; an "exception-handling" state for capturing and displaying crash states, if possible; and even the "title screen" that shows when the player can select whether to load a game, start a new game, or just exit altogether.
  • Second, a few more states for game specials, such as cut-scenes and interstitial scenes. A cutscene state could be either a playing animation, a "text-roll" or info-dump at the beginning of a game, or a video that gets played. The interstitial scenes, I'm sure you have seen them, are the transitions between "stages" or "chapters" of a game (at least, how I imagine them to be). Another few game special states might be for handling of "game over" events - essentially displaying a background graphic and some ending text, and optionally for asking whether the player would like to continue, resume, or quit.
  • Third, the primary "in-game" states such as map handlers, battle handlers, and such, anything not a menu or system.
  • Fourth, the menus and systems that the game engine will handle, as a part of a supplemental expansion of the "core" play of a game. I say it like this because, it's entirely possible a game could be made for only map-based movement, with no menus, no controllable "systems" such as crafting or item management; yet the game is supplemented with the proper use of such.
  • Fifth, some additional states that may be used while a game is in development, not of use to the intended player. The use of "developer-only" game states may provide some inherent debugging functionality from within the game itself, via displaying the values of some variables, and possibly, through a menu-based selection screen, being able to test-play battle of selected party members versus opponents.

    And perhaps more ways to break it down than that. With obvious compartmentalization like this, menus and systems are only relevant to an in-game playthrough, so they would only be accessible from within an active game. Also, the primary in-game states are only relevant to an active game as well, so they won't be accessible until a game is either loaded or started anew. With a little more introspection, game states can be tweaked somewhat by common functionality and application...
Gregory Cheyney
I've been thinking for some time of a more "professional" title for this editor and engine. A lot of this goes to the intended "mental mindset" that I want to convey for the project as a whole.

Some time ago, I changed the working title of this meta-project to something a little more attention-grabbing than the generified "alternative rpg maker", to a more specific "BeyondRM". This doesn't really stem from any arrogance, but rather in having seen posts in the English RM forums for "suggestions for the next rpg maker", et cetera, yadda-yadda, and so forth, and so on.... And I really want to indicate that my projects are taking on something that the (Enterbrain, et al) RMs are either not capable of, or not willing to "fix". Being the sole developer of BeyondRM, I am perfectly aware of what it is meant to be, and what can and will be done with it, as it nears completion.

While the features I select may not fully take on each and every suggestion of such a lengthy list, I do find it within reason for many of them to be included. Take, for example, one of the most commonly-requested features, of going "3D". I'll step out onto a limb and say that this is not what I'm going for; while it would be interesting to be able to develop a three-dimensional game with the ease of a prototypical rpg maker, it would tend to make the editor and therefore the resulting game(s) a little more like the typical MMO.

On the other hand, another quite common feature request is for "better resolution". Now, I've already discussed in this post that it's not 'resolution' but 'screen size' as the proper terminology; but being able to see more of a map on the screen at one time would be a great benefit, at least for the player if not for the developer, as well. Of course, I must mention the caveat deluxe: if we are able to make game maps displayable in higher screen sizes, such that there is not the scaling and stretching as it has been, we must also be aware that the maps and the characters will also appear to be smaller. Rather, it is not that they are smaller; but in reality it is that we are taking away the scaling and stretching part of rendering, so that they are displayed more one-to-one on the screen. More of a "what it should be" type of display.

In that respect, game makers should then start thinking at a "better" scale for their mapping; a classic RPG Maker mindset is in making generified town houses as maybe two to four tiles wide, sometimes one or two tiles high for walls, and perhaps one or two tiles for roofing. In the "screen scale" I'm going for, these would look a little more like garden-tool-sheds and out-houses -- I'd like to think that a map-maker would be able to think more complex than that; and I'd like to think we can supply the kind of mapping tools that such a person could use to good effect. Parallax-mapping is one thing; but I would hope that even a tile-based system would be able to create a little more believable houses, building exteriors and interiors, than that.

Overall, the issue may be one of keeping the touch and feel of the old classics, while updating the specification to more modern hardware and software capabilities. Many of the more "classic rpg" game elements can be incorporated to "re-make" (I know, an odd turn of phrase) the classics, which were originally created very simplified so as to fit within a console game cartridge, to something that can still give homage to that while still improving upon game customization and creation.
Gregory Cheyney
Just a picture of a flower from this last fall, to look upon.

And, ... back to the development talk. It has come to the point of needing graphics to start testing some of what I got. If you happen to know me, you would know that I'm no artist; even Colonel Klink could draw better doodles than I, lol. But, I do need some graphic assets for testing my project.

Since what I'm creating is directly inspired by the works of Enterbrain, namely, that "RPG Maker" program, I will be using sample tilesheets to test out my program's features. In the initial state of development, I will be coding to parse those RM tile sheets into their individual tiles, so that I can both begin working on the Mapper part of the editor, and have the engine capable of reading the same tiles for display to the screen.

In the VX Ace program, I have been examining the properties of the tilesets. Each tileset has a name (for in-editor use only), a mode, a number of tilesheets, and a note field. In turn, each tilesheet contains the selectable tiles that are used to make the maps. Finally, each tile may have assigned a number of bit-based properties.

For each tile, RPG Maker apparently uses twelve bits; that's right, one and a half bytes (unless they have undocumented tile properties). Five bits are for boolean-state properties (is passable, is ladder, is bush, is counter, is damage); four bits are for passage in the four cardinal directions (north, south, west, east); and three bits are for the field tag (0-7) assignment. If we wanted passage also in the diagonal directions, that would add four more bits; and if we wanted to extend the maximum field tag value, we could add additional bits to that, if necessary.

In my editor and engine implementation, I would be using something akin to Steganography, the science of putting information in plain sight, as it were, inside the images as additional rows of pixels. The editor would parse these pixels' RGBA color byte values as booleans and other bit-based information. (From reading RPG Maker's help files, the A1 through A5 "auto-tiles" may have additional properties; for example: a tile may be classified as a forest-type autotile if the pixel four inward from the bottom and right sides (coordinates <27,27> from the tile upper-left) is transparent. For auto-tiles, this might be better as a bit-based value, instead of blocking that pixel location.)

  • The bottom-most row of pixels might be for general tilesheet-relevant metadata: default tile width/height, expected tiles wide, expected tiles high, a simple name, ext cetera. Perhaps we might have space for encoding the tilesheet update URL, so that the users of the editor and engine both might be able to update their graphic assets at program launch.
  • The second-from-bottom row of pixels would be for the tiles' metadata, the twelve bits per tile mentioned above.
  • Everything else in the image should be parsable as tiles.

    Note that RM's tilesheets B through E are 512x512 sized PNG sheets, with 256 tiles per sheet. If these are images with RGBA values (recommended), that's up to 32 bits per pixel; so if each of the 256 tiles used one sequential pixel on the second-from-bottom row, we would still have room for about twenty more bit-based values for all tiles. But, for what it's worth, I cannot think of other expansion properties to use them, at this time; but I'll take reasonable suggestions.

    It also comes to mind that, while discussing the tiles themselves, and their uses in mapping, that each and every tilesheet could, and perhaps should, have a miniaturized version as well, for a "mini-map" feature (like the saying, "killing two birds with one stone") that is lacking from Enterbrain's products. If normal tiles are 32x32, then the minimap tiles would be 2x2 or 4x4, whichever looked better for a map overlay.

    Also, that depends upon the minimap size; the 4x4 tiles are a one-eighth reduction in size, so to show more of the map beyond what's on screen, the mini-map size must be larger than one-eighth of the screen width and height. A 2x2 minimap tilesheet is a one-sixteenth reduction, and may be adequate for generic games, though minimap definition would be low. A single pixel from the 4x4 tile represents 8 pixels wide by 8 pixels high, whereas in the 2x2 tiles, each pixel equates to a single quadrant of the parent tile that it represents. See the difference?

    In summary, I've got basic classes for Tilesets, Tileset, Tilesheet, and Tile objects, all used to define the hierarchy of mapping tiles; these will be tested and tried, in the coming weeks.
Gregory Cheyney
A further divergence in my RPG Maker from the Enterbrain "stuff" is that a lot of the engine will be state-based. These states are essentially container classes which are extensible to exhibit the intended action. In fact, I use a number of states which inherit from other states, for a multi-tiered approach.

I have been working quite regularly lately on the states, and what is resulting from this effort is quite a few game states, just waiting to be implemented.

  • A few of them are for application-level activity (game loading/initialization, error state, application closing).
  • A few are for the more-than-one game endings possible (lose, win normally, and win "secret" or "extra-special" ending); many players might actually like to get that special ending. While we generally only need one "fail" state, we could potentially have multiple "winning" states. I happen to refer to console games like Suikoden II, et cetera, which might show something slightly different, based on how the game ended (such as who saved/not killed/et cetera).
  • A few are specific to "cutscene" handling (one for animated, one for "chapter" interludes, one for text-roll (scrolling text), one for playing a pre-recorded video scene, et cetera). The animated cutscene I refer to is from games like "Tactics Ogre: Knight of Lodis" and "Final Fantasy Tactics", where between battles, we may see an interlude with a static background, and the character sprites, and some often-tense moments of dialog. For such an animated cutscene, these elements are typically scripted or evented in a static fashion, but could reflect earlier player choices quite well. Character sprites can change their facing, and characters themselves could move within the limits of the screen.
  • And the rest of the states for active game-play and menuing states. More on the active map state later; but the in-game menu screen is initialized and controlled from the game-menu state. The outer main menu allows for opening sub-menus, to check the condition of characters, inventory, et cetera, or to perform some general task.

    Why so many states, might you ask? One primary reason is ease the transitions between one part of a game to another part, such as from playing on a game map, and then opening the in-game menu; we want to keep the in-map state, merely 'pushing' it aside, then opening a menu state to take its place; afterward, we merely close the menu state and 'pull' the game state back into view.... Also, these states link back to the game objects, so we do not lose our state values. Each state that is first pushed aside, keeps in memory its values, so when it is pulled back into view, we should have little to no delay of play, no clunky interaction, just smooth transition and correct values (hopefully).

    In developing this editor and engine system, I have found that Java's aging Stack object was used to "push" and "pull" objects into and out of a flexible collection; but since Stack is no longer recommended, I will use the more modern Deque collection interface in a "LIFO" process. Last In, First Out. For our game, an object that is "pushed" into the "head" of this deque will be the first one to be "polled" from the deque.

    In my state-manager class, I have a Deque collection for the states that are pushed into it, and a single state class instance for the active state. The parent of every usable state is an 'AState' abstract class, with a constructor which contains a parameter reference back to the 'StateManager' controller class. The states have methods for drawing and updating things in it, as well as to "help" the StateManager with handling when the state itself is pushed or polled.

    Some states might naturally be cancelable; for example, we who develop rpgs might be proud of our cutscene; but we also know that some players just want to "skip it" and go straight for the game-play. Myself, I do like actually seeing a good cutscene every now and then; but the cutscene states should be customizable to allow skipping them or not. On the other hand, some states -- like saving an active game -- should NEVER be interrupted in mid-save, unless we are going to perform cleanup on broken game saves after-the-fact.

    One state is the map state, which handles all maps and map transitions. In fact, the map state would also have a Deque of its own; it does for maps what StateManager does for states: provides a way to "push" into and "pull" from the deque of maps, so that transitioning from an overworld map, to a town map, to a building interior map, will keep each "parent" map to return to. Exiting a building interior will return us to the town map; exiting the town map will return us to the overworld; all without need to re-load each map from disk -- with the albeit minor proviso that each map in the deque is still somewhere in memory. But I agree that most fairly-modern computers should have enough memory to make this a somewhat moot point. What is it, about two or three Megabytes of memory-space per 500x500 map (in RPG Maker) with events? (I could be off on my estimates; I haven't done any profiling of RM games.)

    The "Battle Scene" is for the battle system management; it is meant to launch a combat scene when encountering an actual "monster" in a game. (For some reason, I still don't like the term 'monster' for the encountered events; 'enemy' seems somewhat better but still somewhat generic.) I have been doing further work in generifying the battle system components, so that we can have a basic battle system and multiple specialty battle systems, all in the same game, and used where necessary. Front battle, side battle, tactical battle, each one its own battle system (I think, haha). I am still working on just how or where to initiate the battle event; but that's a problem for a different day. (I'd be the first to admit I wish I knew more about using the battle systems in rpgs; feel free to educate me in what is needed for an rpg battle system.)

    Somewhat new to rpg-maker engines, is the fact that I want to provide an extensible Crafting System; like our Battle System above, crafting also inhabits its own state class, instantiating our crafting menu as we launch it. The crafting state is for taking raw materials in a player's inventory and transforming them into more utilizable resources, tools, or consumable items.
    And since the "Title Screen" is a state in and of itself, we can extend the static background and menu buttons a bit, perhaps even parallaxing the background somewhat into multiple image layers; in one idea I had, it would be more interesting to designate these as a skybox (background atmosphere), a background terrain/horizon, a near-ground content, and a foreground/focus imagery. We might even have the skybox part moving slowly, to imitate a semi-active scene; and perhaps even weather effects affecting one or more background layers. Buttons might have visual effects such as sliding in from a side, or a textured "glint" or color change. Where such a title-screen system might be useful to a game, would perhaps be in a game with its own unique theme, rather than what ordinary static background imagery can provide.

    Finally, I have given some thought to the general order of much of the above; with Enterbrain's products, if we want a "cutscene" to start the game, we could start with a blank map bearing a relevant background, perhaps scrolling text, or some effect; but it's not quite the same as what I originally wish for. In my implementation, I would allow starting with any of the aforementioned states, as the game's starting point -- so the starting game experience could be quite a bit more customizable, to the theme of the game, even a "character customization scene" if so required.
    Granted, all of the above thoughts may not be "perfect", but I would like to assure my readers that I have, indeed, put a lot of thought into how we put a game together, using what is possible in Java gaming. That I do intend for this to be, and remain, an open-source project is no small feat; the primary reasoning is a hope that it will be a useful alternative to Enterbrain's RPG Maker series of editors/engines. I am, and always shall be, awaiting thoughtful commentary.
Gregory Cheyney
This post is something I came across in a forum I frequent, and it sparked a bit of commentary on my part; not wanting it to sound like a meta-rant to that forum, I decided to write a post here.

I find the phrase "solo development" to be an oddity. It may fit in a literal way, but doesn't have to be true in the figurative sense. I mean that nobody is or has to be truly alone in what they do; there's usually some family, friends, or assorted people around us that we draw inspiration from.

It just seems an oddity that, to develop something that we hope others use and enjoy, many or even most of us approach it from a "solitary" perspective. Those who are fortunate to have gainful employment in a successful games-development-house probably know that they have a wealth of experience from colleagues and industry contacts; even those who don't work in a company environment or who go at it on their own, should probably know that it's never a matter of developing in a vacuum.

To round out the post, I guess I'm interested in seeing how it affects you, the reader; perhaps you have an example of a non-traditional or unusual source of inspiration for your project? I'd be curious to know.
Gregory Cheyney
I have no screenshots for this post, because here I'm going on about the ideology of variables and data types. First, a brief comparison with Enterbrain's RPG Maker programs.

Most of you who are also developers likely know all about variable types, but on the off chance that one or two of my readers are traditionally non-programmers or have only passing knowledge of RPG Maker, I'll discuss all this to the basics.

In the RPG Maker game editor, you can specify Boolean conditional states, but they are confusingly called "switches", used in either global visibility or as "self-switches" within Events. (The reason this is confusing to any "proper" programmer, is because the 'switch' keyword is actually listed in most object-oriented programming language (such as Java) as a "reserved keyword" used in conditionally branching through functionality based upon the value of a variable or result of a method. Why Enterbrain chose to go with 'switch' to denote a Boolean state is, you know, beyond me....)

The editor also allows specifying numeric (integer) values (also, quite oddly, simply called "variables") although they are not "typed" like Java variables are (byte, short, int, long, et cetera). At this point in my examination, none of the RGSS or RTP documentation seems to specify exactly how the RPG system handles numeric type-conversions and mathematic operations; it just seems something of a "gutless wonder" in Ruby (of which I'm also quite oblivious).

In terms of the RPG Maker editor, it seems you are only able to access the list of global "switches" and "variables" and per-event "self-switches" via Event page editing; as there is no Database tab to list and modify all those variables.

Variable Types In Java.

To my logical mind, at least, I am quite happy with the variable types. The types native to Java are (primarily) thus:

  • The Boolean Condition. A boolean value is what most RM'ers think of when they use switches and self-switches in RPG Maker events; it merely handles true:false states (also called on:off state), which is technically just flipping the polarity of a single bit.
  • The Numeric Values. A number of numeric variable types exist to use in calculation.

    • A byte value (whose value range is -128 to 127 and only requires 8 bits) could be used for "small" values.
    • A short value (whose value range is -32,768 to 32,767 and requires 16 bits, or 2 bytes) could be used for most normal integer values.
    • An int value (whose value range is -2,147,483,648 to 2,147,483,647 and requires 32 bits, or 4 bytes) could be used for larger values.
    • A long value (whose value range is -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 and requires 64 bits, or 8 bytes) are definitely for incredibly humongous values. One typical use is for tracking the milliseconds' value of the operating system's time. -- For most purposes, I have no idea why an RM game would need this, but I am supporting the type just in case.
    • But for the non-whole-number values we have a 32-bit float and a 64-bit double type, (floats for 7 significant digits, doubles for 15 significant digits).

    • The Character Values. A char and a String are for textual objects; the char type is purely for text of one character in length, and a String object (merely a Java class that wraps around a multi-length array of char objects). For plain-text ASCII, each char takes one byte; but for extended character sets you could double or even quadruple the number of bytes per literal character.

      And so it goes. The number variable types are signed to be positive or negative; so, you cannot have an unsigned byte for the range of 0 to 255 (as much as I'd like it to).

      All of the above is important to the point that (when this is all completed) we as a game creator can optimize the game classes to make variables use the least amount of memory bytes when running. Such problems used to be the concern of game makers back in the early console system days, when games came on cartridges with limited memory. (Thankfully, we are past the memory-limited days, ... although it never hurts to be concerned about game optimizations, in a general sense.)

      Variable Types In My ARPGM.

      In my own Alternative RPG Maker, and Java development (in which variables are strongly-typed), I am using variable fields arranged according to their specific Java types. In fact, I've written Java classes that wrap each of these types along with some handling methods so that it simplifies mathematical operations and comparisons from elsewhere in the engine; these operations shouldn't be too unfamiliar to someone who has used RPG Maker's Event system "required conditions" and the switch or variable operations to get or set a value, or to compare to another value.

      As far as their representation in my editor interface, I am wanting to show the variable name for each of the aforementioned/defined variable types, in their own tab; both the name and initial value, if so desired, should be modifiable from within the tab page. Of course, for a literal-minded programmer like me who loves strongly-typed variables, this means that I will enforce creating and editing variables according to my wrapper classes. And this means that variables can be a bit more organized.

      Where This Is Useful.

      This is incredibly useful to my design philosophy, for any typed data that can be editable in the editor. It isn't even solely for the global variables, either; actually, the Event instances can have appropriately-typed self-variables such as boolean, integer, and String objects. In RPG Maker, a typical event has access to four self-switches but no numeric values. (Four boolean conditions might be too few for some events, so it is possible to subclass the parent Event class so that different types of events can use more variables.) And a map instance could possibly have its own per-map variables, for values that may only be used on that map - and unloaded and saved when leaving that map.

      And especially for events on a map; I have ideas for games where you have some seed and a plot of land. For the individual crop tile, I should want to track various aspects of its life-cycle; soil fertility, moisture, stage and time of growth, et cetera. And a different event type on a map might be a specialized NPC Event with its own characteristic variables; a dating sim or relationship management sim might have NPC variables for times talked, last time talked, current favor, maximum favor, relationship level, or something.

      Basically, I have been looking into any way possible to streamline the potentially extensive list of switches and integral data that RM creators could end up having. If certain variables may only ever be needed when certain characters are active, or when certain maps are active, or from within certain events are running, and not used when they are not in memory, ... then why not make them a part of that character, or map, or event?

      It's obvious that I'm an incredibly big dreamer; I see what Enterbrain hath wrought, but I see how an rpg maker could have or should have become, and I want to provide it.
Gregory Cheyney
This is the second time I am trying to post this; the first time, the Ethernet cable came unplugged, and as you may know, the post is usually lost when that happens. Oh, well; I hope I can recall all that I had typed earlier....

While doing a bit of research on scripts for the various RPG Maker programs, I have seen a little bit about how defining races and genders could be of use, and how to implement these features; I have not yet attempted to use such scripts, but they seem to be useful in many respects, in that it provides yet another way to specify an attribute about the character, about a class, about whether an equipment or item is used by a certain character, et cetera. Problem is, I haven't seen even one of the rpg makers available make this a valid selection within the editor interface, when it could be so useful in game terms. I hope to be the first. (And if I'm not, please let me know; I hate being wrong/unaware.)

The general purpose of this post is a discussion on the general parts of a character-creation process, for what I intend to implement in my open-sourced, extensible, Alternative RPG Maker in specific. The point in discussion is where games may allow the player to specify what the main character is, or does. Usually this only requires just a couple steps, and it's possible to make it even more complex if so desired. I don't have any overarching examples of a truly COMPLEX set of steps; but for my purposes, I'm starting with some basics.

Define: Gender Versus Sexuality.

For the purposes of what I'm trying to create, I must define some things clearly, so that you have no misunderstanding. Where most people refer to the "sex" of the person, I am specifically meaning the biological gender, with the primary determinant being specified by the reproductive organs, not the "sex" as an activity or even "sexuality". This word "sex" is equally used as a descriptor for biological gender, for the procreative activity, AND for one's chosen sexuality; thus, the reason I specifically use the word "gender" instead of sex, where possible, when referencing the biological sex.

Among psychology's domain, it gets a bit more complicated; beside biological gender, you also have mental gender ... or so psychologists would have us believe. It's formed in part by exposure to our parents, friends, social circles, et cetera -- even at a very young age. It's also highly driven by personal choices and motivations, as we either accept or reject certain external stimuli. With these factors and more, it's how you can have effeminate "pretty-boy" males, as well as masculine "tomboyish" females. That's mental gender.

(I have read in RPG Maker Web posts how typically in games, a male hero is usually brash, happy-go-lucky, and often equips swords and heavy weapons, and how female heroes tend to be more observant, reserved, and be the "magic user" of the group. This is not to say that it always has to remain this way; a male hero could just as well be the support character, and a female hero could just as easily be the heavy-damage-dealer and tank; although for such a game to be plausible, it needs a specific reason ... especially when outside of social norms.)

Sexuality, on the other hand, is a particular aspect I'm not specifying in my system, as that is something that a particular game creator would want to implement. But for the record, I say that a person's sexuality is typically by choice. (My presumption is that most games will go with a traditional "Straight" male-female sexuality for interaction, if even mentioned; but for various perversions you might have "LGBT" types that some might want to implement for their story-lines.)

Character Gender and/or Sex In Game Terms.

To begin, gender is typically obvious from the character graphic, and I would say that most games might not even need to refer to sexuality, other than specifically for games of romance and outright sex.

The biggest choice in a custom character-creator is often one of character gender, and sometimes of which race (if differentiating between human/non-human races). A choice of race will constrain which genders are available for selection, such as a race of child-bearers being all female, or a two-gender race such as ours, or even a three-gender race like in the television series Alien Nation.

For one example, say you have a fantasy-themed (or even science-fictional, for that matter) game, with multiple active races to choose from. A game where the player could choose to play as a slime creature just as well as any other fey-folk or alien race, humanoid or not. this would then allow the player to select from the valid gender options specified in the Races tab of my editor (if I get to it, need ideas for traits of races to implement). Besides that, the race and gender may further constrain which class and equipment that could be selected. - If I add race and gender selections natively within the editor interface, it will be almost mandatory that the other database tabs get a looking-over to see if character gender might, in even the slightest, affect its implementation or usage.

In the Editor; How?

Gender can and should be specified within the editor interface when defining characters, and could also be changeable within events/scripting, however this may work out. This would likely be a single combo-box with a few choices (male, female, neuter). It is presumable that most human(oid) beings fall into the male/female genders; but it is also possible that, if creating a race for a game, it could be fully humanoid but reproduce in an asexual manner, such as by budding (bearing one's progeny as a physical offshoot of the parent body, and at some point at "infancy" it separates from the parent to become an individual) or self-cloning.

And, if magic (or even, advanced future-technology) is part of the game/world, you could add complexity by adding/modifying the gender choices: along with the natural gender options, you might also have selections for whether the character was artificially/unnaturally transformed to another gender (whether by magic or tech). So, an extended listing choices could be:

  • naturally male
  • naturally female
  • naturally neuter
  • unnaturally male
  • unnaturally female
  • unnaturally neuter

    (When I first wrote the original post that this should've been, I posited that I couldn't think of a realistic reason that this might be so important for a story reason; but then I did happen to come up with one idea: a female hero just turned magically into a male, but for the sake of her romantic interest, is aggressively pursuing the wizard who turned her this way.... Et voila, a new story side-plot, or main story-line, even. See? Sometimes I need to start a post over, just to get a better idea of things.)

    What Next?

    It's been a long, tiresome post to (re)write. I've looked it over a couple times, though I'm not completely sure I remembered all the main points I wanted to cover from the original post, so forgive any incomplete thoughts; but if you have any further questions, comments, or even general encouragement to get this thing developed, don't hesitate in the slightest: I value honest feedback, humor, and even criticism when given in honest fashion.
Gregory Cheyney
Apologies to anyone and everyone who might be following this journal. I've been busy of late, mostly in helping family with things. I have not forgotten my journal here; but life-events and health conditions kinda attacked all of a sudden. I *will* be better about posting here.

One of the biggest aspects of my RM is in how I want to allow a game-maker to be able to plug-in their own "rpg mechanics" system, so that they could develop their game with attributes, stats, and assorted roleplay mechanics as they are used to, in the same way as I discussed previously in Battle Systems. Myself, I am more familiar with the Alternity Science Fiction Roleplay Game System, so I would want to be able to create a game using something in that venue. A system that is more fantasy-inspired would not work for me; but if I can "generify" the core system to allow the creator of a game to specify their own system, then that should help somewhat for the more advanced game creators out there who want some more customizability.

System Timing and Calendars and Seasons, Oh My!

Another aspect I may not have specifically mentioned is, how to implement the in-game clock and calendar system? For games where the passage of time may have an importance (especially for tracking the progress of things not-controllable by the player), I am determined to figure out just how I should implement these things.

For one aspect of a game, you have a linear counting of second, minute, hour, day, weekday, month, season, year, and so on; for another aspect, seasons and times-of-the-day, you may have potential weather and climate effects. In this post on RMW, I mentioned some of my random thoughts on timing and weather effects. In that post, I suggested handling of climate effects such as rain or snow might not be so doable without note tags; but as I am designing the editor, I can provide support for editing these things in a sane manner (not having to resort to note tags, see below).

I've also stated in other posts that I find it odd that many calendar and clock scripts still use the same lengths as here on Earth, when it's obvious that these fantasy worlds created should be somewhat unique -- custom day-hour-minutes lengths, custom weekday and month names, perhaps even custom season names. This timing system I'd try to implement will allow for specifying as many time-period lengths and names as generally possible.

A Minor Rant On Note Tags.

Now, don't misunderstand, I don't dislike the uses for note tags; but I want a better non-generic way. I would rather an in-editor way of specifying attributes and things where note tags are typically used, without having to parse a block of text that could be mistyped by accident. I have always had the feeling that those notes were to be used for temporary solutions to problems that Enterbrain and company should take upon itself to implement for next-version features; however, that hasn't seemed the case in reality. Naturally, my way would mean a more complex editor interface and more data files; but in exchange, more specific customization of the engine and data is accomplished.
Gregory Cheyney
One of the aspects of making an "rpg maker" is in implementing a battle system. I understand the basics, but I will admit to not being a master of it by any means. But I do want to provide a solution so that the game maker, him/her self, can provide the battle system specific to the layout and operation that works for their game.

At this point, I am laying down a framework of sorts for GMs to be able to implement battle layouts and methodology, whether these are provided by others or whether the GM is designing a custom layout or methodology. Since I'm aiming to keep this all open-source, I am hoping for a decent amount of code sharing -- from those who understand implementation, to those who are looking for a pre-set solution. My framework should allow for this.

To begin, the framework starts with a few abstract Java classes that must be subclassed to provide the implementation; first, the ABattleSystem class provides the basics but must be subclassed to provide the specifics. Next, I have abstract classes ABattleSystemLayout and ABattleSystemMethod to provide some of the specifics of layout/presentation and turn-based methodology.

It does not need to be so difficult to implement a battle system; although I will have to decide first on which layout and methodology will be the "defaults". The different layouts (front, side, top-down, isometric) each have their benefits and weaknesses, followers and detractors; and the methodolody can be just as difficult to determine. More may be added as necessary; but I'm hoping this will be a good start, for when the engine is ready for a test-play. Beyond this, I'm open to further comments and questions.
Gregory Cheyney
I must point out that, even though I'm starting development of this alone, and even got quite a bit started on my own, I've also done a fair amount of following other peoples' Java tutorial series. This project has been in the works for a couple of months now, but I'm just coming out of the shell for publicising my works. And so, I must also give appreciation and thanks for what is of general interest and help in development.

Most of my ideas in creating my ARPGM have come from the last couple months of playing around in RPG Maker VX Ace, and in reading posts in the web forums for other users' wants and needs from the editor and engine; but probably the largest influence is specifically from a thread titled "Suggestions for the next RPG Maker" or some such. While not optimally organized, this huge listing does show what "seems to be lacking" in the modern maker.
Just a scant few days ago, less than a couple weeks ago really, I also managed to come across an interesting video series on YouTube by ForeignGuyMike, wherein he narrates his development of a Java-based "platformer" game. I know, a platformer seems different on the outside from what is required of an "RPG Maker inspired" engine and an editor infrastructure; but examining the more particular aspects, it did have much of what I was already trying to implement. It's not a cut-and-paste drop-in replacement for what I already have; but the general aspects gained from watching the video series and examining others' code does help.

  • It is a tile-based engine/game, using tiled images in a number of graphics files, which means it also has a basic manner of parsing the graphic images from a tile sheet and keeping them for the next steps.
  • Its tile-based maps are easy to understand how they are implemented; a map in these terms is merely a plain text file with space-separated integer values, corresponding to the tile ID.
  • It also has a class acting as a "jukebox" or music manager -- allowing for playing, pausing, stopping, and even looping the sounds. That class has a boolean field for specifying if the sound is "muted" but it isn't actually utilized so much; it is a mere tutorial series, anyway. That's just one single mute-state for the whole game; an improvement over that would be having muting/volume states for several audio aspects -- for the whole audio system, for the main-music channel, for the sound effects, and for various system-sounds like menu navigation and selection. Of course, there's no options or preferences menu to set that; but yeah, um, that might be a little bit useful.... ;-]
  • The source code linked at the end of the tutorial produces a compilable, playable game, although there was no graceful way in the pause screen to menu-select to end the game or return to the title screen, like is seen in the competition...

    As I mentioned at the start, I have already got the basis for my implementation of an RPG Maker (both the editor and the engine) in the beginning stages; this guy's project does help me understand some more about putting the idea to use, on both counts. Mike's code doesn't have any concept of scripting or eventing in that tutorial, like what is seen in the commercial RPG Maker product, and I do wonder what his take on that would be if he got around to another tutorial series, platformer or not.
Gregory Cheyney
This post, is a long long LONG one; I feel I have a lot to say. You can reap the benefits of my thinking, if you have the patience to read a bit...

I have already mentioned that Events are almost a must for the game-maker I am creating; and it also follows that Scripting control is a highly-desired feature by people using the Enterbrain products. But in part, I do wonder if this is because scripting is generally the only way to control or reconfigure the RGSS features, or because if the source code to RM were available, some of the scripters would be more apt to develop their features in the native language?

You see, because what I'm planning is, and will remain, an open-sourced project, I am considering leaving the engine uncompiled, so that "Scripters" can add in Java classes to support their additional features, and the end-user could compile their game, engine and additional scripts, to control the creation of the game without being quite so needy on a third-party scripting system. Ha; Java itself is the scripting language.

A brief note, and this is only fractional in my opinion, might be that game-makers would be required to use the JDK to compile the project before testing and game release, not just the JRE (or, at least, just ONE collaborator on their project have a JDK). Again, it's a minor point; but one I believe will be easy for the game-maker to come to terms with....

Theory: Example Events, and Potential Application.

On thinking of how to implement some of the eventing solutions that are possible, or even impossible, in current RPG Makers, I've come up with a few scenarios and examples, that I've been mulling over.

First, the types of variables. With the RPG Maker programs we have Switches and Variables, the latter of which are numbers. In using the Java language, I would prefer the variables to be more strongly-typed -- so, variables specifically typed as booleans, doubles, integers, longs, and even Strings.

Second, subclassing and subcategorizing events themselves by a type. I will keep a generic Event class as the parent of all other events; but I'd also categorize event-able objects as one or more of the following:

  • A basic NPC, for characters on a map who are merely there to provide "flavor text"; on top of the baseline Event class, is added variables and controls for movement-pathing-routing, naming (first, last(maybe), nickname), money/value (heh, I see a lot of games coming out with Thief classes for utilizing this...), position-rank-title values (I had a thought about NPCs with actual authority),
  • A Classed-NPC, for a subtype of the basic NPC where it makes sense to possibly have stats, useful for conditionally-branching event control based upon an independent stat value, in comparison with the player's own stats; race/racial traits and gender (both of these appear valid enough for supporting in the engine and editor, for all you wanting more control over classes and skills), character alignment-mood-morality-personality-reputation (maybe not so high priority on its own, but doable), NPCs susceptible to conditions, et cetera. Classed NPCs could theoretically also have weapons and armor, so that during town sieges they could "help" in its defense, although NPCs probably do not need experience and levels....
  • Further Classed-NPC subtypes where it makes sense to further expand the possibilities; they should inherit all the aforementioned stats or properties mentioned above. Examples: Battler NPCs whose purpose is for combat, such as player-trainers and the like, but not necessarily like the random battlers encountered; Merchant NPCs who remember their own inventory, what's bought or sold, and the amounts of each in stock; and perhaps any other classed or class-able NPC subtype.

    (Also, theoretically speaking, the Player could be considered to be a Classed-NPC Event of sorts, just with more options available due to being controlled.)

    Third, is for events related to "farming" and crop-growth. This is traditionally done with some scripting and/or eventing and using plenty of global variables. How the crop is displayed (relative to its growth-stage) is one aspect that is traditionally done in the event pages and using the event's self-switches; but how to specify if a statically-places plot is planted with one type of seed over another, and controlling the hydration state, is yet a different problem. Thus, the reliance on so many global variables and switches alongside the scripts.

    Eh, well, I do have a unique approach to "solve" or diminish this ... since I am the one who is taking the lead in making both editor and engine. Simply put, while I've decided to allow increasing the number of self-switches for events, I will also allow events to have "self-variables", to reduce dependence on global variables; I feel the "global variables" should truly be for values that are global to the game, quest states and whatnot. (Generically speaking, events already do contain self-variables, in that self-switches are merely a variable of a Boolean kind. But allowing the event instance to have access to its own numeric variables may keep the global stack of variables somewhat streamlined.)

    Along with all the above-mentioned NPC event types, at least one subtype could be for Plantable and Growable events, with variables specifying the timer-based controls like first planting time, current crop type, current maturity, maximum age, etc. These plantable events don't even have to be single-planting events, either; they could be for perennial crops and plants that continue to produce, even through many seasons or even "years" in game. It just depends how intricate a planting/farming system is desireable.

    And, I'm done for now. Didn't think I'd get to this point? Haha. Have a good day y'all...
Gregory Cheyney
Just a general question to begin; how often are screenshots desired, and what is a decent number of images per screenshot post, before the viewer starts to get sensory-overload? I'm considering adding the occasional screenshot, with the proviso that "features may change before release". In my opinion, I'd try to give a screenshot or two, at least every third or fourth post, more when necessary, with a likely cap of four screenshots per post, max. But, on to other matters; a bit more of a description of some of the things I intend for my ARPGM.

First, the most noticeable of the competition is that game-creation seems to be a solitary act -- Enterbrain's makers are fairly good at presuming it's just one person making a game; however, I know from reading the English rpg-maker forums that it's somewhat of an economy of asking for project help, and recruiting for the project. I am hoping to include some form of versioning for project data, for those who wish to split development to specific persons on a project. So, it will no longer be so solitary. Also, support for I18N/L10N (allowing a game-maker, et al, to provide for game accessibility and translation to additional language-speaking players).

Second, is the fact that I do want to support larger screen dimensions than Enterbrain's products; although to make it make sense, it will be a per-project setting where the game-maker can specify minimum, maximum, and default resolution ranges, so that it makes sense from the developer's point-of-view. One game-maker (herein abbreviated GM) might make a project title screen for a 800x600 resolution, while another might go for the 1280x1024 -- and I need to keep track of that on a per-project level. As well, in multi-GM projects, settings for testing fullscreen versus windowed is important, as well as various other editor state-remembering factors.

Third, adding new aspects from a particular "Suggestions for the next RPG Maker" forum thread-listing. To me, it does make a little bit of sense to also include a Database tab for specifying Races and Genders, so that further specifics of Character creation and eventing can be implemented. I know that some GMs wish they could make certain classes dependent upon certain races or genders, or even inaccessible to certain others. It would also be nice to be able to check in the Events whether a target character is Male, Female, or even Neuter -- like Final Fantasy Tactics, seducing enemy NPC with "Vixen's Whisper" or other skill....

Fourth, some aspects of an RPG Maker will remain similar to what people are "used to using"; but some things will by necessity be different, due to how I may implement my ideas for such. The items list, for one; I want armor, weapons, and consumables to all be in one Database tabbed hierarchy, but I also want it to make sense, in the implementation. Armors can be sub-typed, and weapons are most definitely categorizable by manner of use or form. As well, I also am planning to allow for a default implementation of Item Crafting to be included -- with item ingredients, recipes, tools or utensils, et cetera.

Fifth, Eventing and Scripting. Yes, I want to provide both, but I am still figuring this out. Events are a must; I have several ideas on that end. Scripting is desired as well, but this needs a little more thinking -- along the lines of which scripting language would better go with a Java-based application, and therefore either be natively supported in Java or have a class-library to implement these features. Then, figure out how it works on the editor side and engine side. Actually, I do have a decent idea that will work in the editor part, of how to store and write the scripts, but since the engine part is behind in percent-completion, it'll be a while until I can test it.

In conclusion, I have more ideas than this; I just wanted to start with a few aspects, to keep in touch with people following this journal, as well as allow for input where you have ideas or questions for me. The image included is of the main editor UI, using FXML with CSS for styling.
Gregory Cheyney
I've been tinkering with developing games for quite some time, in general since before the Y2K rollover. I've been primarily focusing on the Java language, though I've taken a peek into just a bit of C++, PHP, and Python as well.

I have tinkered with making Minecraft mods, as well as examined some game-making software, such as the RPG Maker series from Enterbrain. I've currently been using VX Ace to try developing my tile-based game ideas, and am reading up quite a bit about Ruby scripting as a back-end to the RGSS part of RM. I also read a lot of the forum threads where other gamers and game-makers wish for features in the next version of RM.

FYI, I have found other 'makers' out there on the web; for one example, I know of the Open RPG Maker editor on Sourceforge. I like that the data is stored as openly-readable/parsable XML data, but the program is incomplete, as the developer has mentioned going off to college. Developed in C++ and the Qt library, the program has random crashes inferring the Qt components' fault, when navigating the Database sections. Perhaps the UI needs a bit more of a lookie-loo.

Which leads me to my newest project: my own "Alternative RPG Maker" editor and engine. Since I'm most familiar with Java, this is what I'm using as the coding language and interface design. I actually do have quite a good idea of the prerequisites for developing this, and I do have the Java projects underway.

As a project, this ARPGM, or Alternative RPG Maker (trying to think of a catchy name), will remain open-source and free to use, even for commercial game release; although I may include a "suggested donation" phrase in the licensing, so that it's not so disadvantageous to me.

Where I Am Starting.

I'm programming using NetBeans IDE v8; some of the modular projects are plain Java class-libraries, and the engine project is a Java application project, and the editor is being implemented using JavaFX, for the componentization of the interface with FXML.

Whereas Enterbrain's products utilize the main part of the program as the map editor, and the tabbed Database as a dialog box, I am taking a slightly different approach: the map editor and tabbed Database sections are to be designed as on tabbed-pane hierarchy, all available in the application main interface, to ease navigation. I dislike the requirement of opening the Database from a menu entry all the time, when it seems half the time I am opening it anyway, to edit some feature within it.

Where is it now?

  • I'm finishing the general XML format of my project's data files. I'm taking cue from Open RPG Maker's formats; although with the improvements I have in mind, my formats will be restructured somewhat.
  • I already have an initial approach with loading and saving of the XML data in the editor; I just have to figure out how to represent the data to the engine.
  • The editor program UI is perhaps 50-60% "complete". Mostly it's waiting for me to finish the XML formats above, before completion.
  • The game engine part is somewhere around 10-20%, so, still not quite ready to test and debug; but I do have a specific direction to go with it.

    And more. These comments are just a starting point; I'll be refining things as I go on, but overall I believe I'm off to a good start.

    Final Thoughts.

    I intend to keep posting to this developer's journal, where possible. Please follow, and give a comment if you feel like it.