Maintaining compatibility

If you are forking your own version of the OHRRPGCE, or writing a game editor or a game player that has some level of OHRRPGCE compatability, there are some things you can do to help maintain compatability. We don't want people to download an OHR game only to discover that it only works on some versions and not on other versions, without any way of knowing which is the correct version.

New Features

If you are adding new features that aren't supported by the standard version of the OHR, you can change the RPG format version number in the GEN lump. Naturally, coordinating different feature sets is a more complicated problem than can be handled with just a version number, you may also need to add one or more auxilery lumps to describe what new features are and are not supported, and as time goes on, a standard for doing this may emerge, but changing the RPG format version number is a way of making sure that the standard version of the OHRRPGCE will show a warning message if you attempt to open a game designed to require an enhanced version of the OHR. If you plan on adding features that will never be supported in the standard OHR, change the version number to something high, like 100.

Communicate

If you plan on adding features (or fixing bugs) that will affect compatability, discuss your plans with other developers. They may have ideas for backwards compatability that you have not thought of.

Drastic Changes

If you are making drastic changes, and want to abandon backwards compatability, consider implementing RPG file format support as an "import" or a "converter", rather than trying to hack your new features into the RPG format. As an extreme example, suppose you are working on a hypothetical project called OHRRPGCE3D that uses polygon models for heros and NPC's and uses 3D bump-maps in place of tilemaps. It would probably be better to make your own completely new .RPG3D file format, and be free from the internal imitations and idiosyncrasies of the RPG format.

Details

General principles of compatibility

1. Symmetricness. Supposing you wanted to increase the number of frames for attack graphics to 6. You could just make an alternate lump which contained full sets of 6 frames per attack graphic. If you wanted to keep backwards-compatibility, though, a better way would be to save the new 3 frames in a new ATKGFX.BIN lump and the old 3 frames in the .PT6 lump.. like this:

1 2 3 4 5 6 
1,3,5 go in .PT6 (these are the original frames, which is all the original OHR would show)
2,4,6 go in ATKGFX.BIN (these are the extra frames, elaborating on the basic attack animation)

.. in this way, the attack would animate sensibly in both OHR and your derivative.

Unexpected compatibility-breakage

This section describes the effects of changes of the kind looks like a duck, but isn't. -- changes which have non-obvious and potentially confusing effects.

• Supposing you implement a new plotscripting command that draws a circle on the screen in your version of OHR, and someone uses that to implement a crude tracking / minimap system. That minimap system will be broken in vanilla-OHR; It will not cause an error, but it simply will not be drawn. This could effect gameplay severely in vanilla OHR.

• You implement a new lump that intends to replace an existing inferior type of lump. The old and new lumps can coexist in the same RPG file. Therefore, this places responsibility on the user to keep both the new enhanced lumps ```and``` old lumps up to date, unless your editor can automatically translate them.

In my (NeoTA's) view, both of these kinds of changes are grounds for increasing the RPG version number. If possible, they should be done after OHR is switched to a more easily expanded underlying system( see OHRRPGCE Source Ports), so that these changes can be standardized and won't confuse the general user.