A RUNDOWN ON HOW VERSIONING WORKS ON RPG MAKER

When you’re making a game, it’s a necessity to differentiate past game builds from the current ones. This is— not just often— necessary as it details what errors have been corrected in the game and if you can carry your previous save file from another version.

This is Vaccaria, and I’ll give you a rundown on how versioning works on RPG Maker.



Before we dive head on to how we do versioning, we might as well go through basic coding/development lingo. Versioning is the creation and management of multiple releases of a product, all of which have the same general function but are improved, upgraded or customized (Rouse, 2017). And the terms "versioning" and "version control" are sometimes used interchangeably even though their technical meanings are different.

These improvements are then all boiled down to the three numerical identifiers from left to right. The Major, The Minor and the Patch.

This is the definition from what the Semantic Versioning 2.0.0 describes of these three (which is primarily used by all devs) (Preston-Werner, n.d.):

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards-compatible manner, and;
  
• PATCH version when you make backwards-compatible bug fixes.

So when you do that, it would look like this:

MAJOR.MINOR.PATCH (<- there are dots between each identifier)

And a common misconception is that when a minor or patch numerical identifier reaches 9, the next improvement would essentially upgrade either the Minor or Major version up a step. If you’ve seen Minecraft’s versioning, then you know that it can essentially go as high as the possible number achieved by a computer (which you won’t see at all because Patch versions get easily degraded by Minor ones… and people do major fixes instead of a step-by-step one).



RULE OF THUMB: Collate the fixes to a single version release. Don’t do it step-by-step. It makes everyone’s lives easier.



And that when a Minor number is turned up, you must turn the Patch number to zero. The same for Major, but it’s everyone else turning zero. Everything carries over, and it would make sense to just say it’s a different version with the same fixes carried along.

You can read more on Semantic Versioning 2.0.0 at semver.org. It all has the specifics in there.



So, now with that done, let’s dive in on how Semantic Versioning works on RPG Maker games. It’s technically the same, but the definitions become different here. Especially when, by legality, you’re not supposed to change anything in the .dll and you can only change what is visible in the editor (or so, people can be tricky at times).

I mentioned earlier on how save files become the major variable on this system. And yes, they pretty much become your checker whenever you do so. It’s because of various things that you have to take note of.

First and foremost, save files are the lifeblood of… most games. You save data and precious time wasted on progress. They’re going to be the ones checking if the save file still works on the same game… well, maybe with a few inconveniences.

For starters, the Patch number fixes stuff like interactives, menu glitches, and the occasional ‘why do I not get X in here’. So when you save a game, you’ll notice that nothing has changed at all, except for the system to run smoother or not.

You can easily identify these as just text, audio and graphical fixes. It can also be bugs that are just as harmless as it can get (eg. gold not dropping because you placed a # on the gold-giving line in Scene_Battle) or just added events that don’t interrupt the game’s flow.

That and stuff that fixes stupid stuff like things barring your way to the next level. Don’t easily call that a Major version.

The Minor number is when you add a new function (or gameplay function) that does not make the save file incompatible. Most of the time, amateur developers can turn this easily to a Major version because a function is poorly implemented in such a way that it disregards previous versions.

It never tries to call a function that would show the function itself as it should, and/or does not initialize the function entirely, even when the game has progressed as much.

These are identifiable when you add a new function that can still go with the previous save files, as these functions are called out using previous functions from the previous versions.

And then we get the Major number.

Long story short, if your save file doesn’t work at all or you can't progress the game with the previous version save file, it instantly becomes a Major. Congratulations, you just made the player’s life even worse, especially when they wasted 27 hours of game time. Back to square one, sadly.

• These compromise of:
  Changing something big in the default scripts (note: this is pretty much a Major version up if not handled correctly, or you just can’t implement it backwards),
  
• Adding something big that does not callback to the previous functions of the previous versions (and cannot backwards implement it),
  
• Removing critical items for progression (this technically is a Minor version thing, but you’re removing something), and;
  
• The previous version save file does not work at all (this is your visual confirmation)

RULE OF THUMB: Do not confuse ‘Progression Halted’ as a Major version up. This only becomes so when your new/changed function does not allow you to proceed entirely. If the player is just stuck because of a coding oversight (eg. conditions not set correctly), it can just be patched.



And, of course, the beta/alpha/whatever versioning still works. Those are immediately considered with a Major identifier of 0. THE MOMENT YOU PUBLISH YOUR GAME, THE VERSION YOU USED FOR RELEASE IMMEDIATELY BECOMES 1.0.0. Demos do not count. They’re still in development hell.

There’s also the cases of variables and save headers (yes, these exist) where you can’t access the new version of the game because you lack this one header that the game will indefinitely try to read in the new version.

But that’s okay… at times. At least they’ll get a taste of what the first version feels like before getting dumped by the new one.

Tl;dr

• MAJOR version when a previous version save file becomes incompatible or loading previous version save file deems it impossible to proceed without replaying to get the new mechanic (this is just the tl;dr version for this),
• MINOR version when you add a new function (or gameplay mechanic) and that the previous version save file still works, and;
  
• PATCH version when you add a fix, load a previous version save file and do not encounter major differences (in terms of graphics, music and overall experience, also tl;dr descript).

But what about games that don’t have save files? It’s still the same anyway. I mean, you’re the dev, not the player. Who else has the indefinite power to save? Or pretty much the assumption that when you save, this is what you’d expect as an outcome. So do keep that in mind.

So, there you have it. That’s the rundown on how versioning works for RPG Maker. There’s also pre-release versioning (like actually plastering alpha besides the numerical identifiers), but the Semantic Versioning has that covered… if you understand what it means. But I’m sure you would, considering we’ve already translated the major terms to engine terms.

With that in line with your knowledge, please do use it. It’s especially useful on not just tracking progress, but also encountering major bugs that might be prevalent on newer versions.

If you have any questions, please do ask.

See you next time. And as always, happy game deving.


Sources:

Preston-Werner, T. (n.d.). Semantic Versioning 2.0.0. Retrieved April 17, 2020, from https://semver.org/
Rouse, M. (2007, April 6). What is versioning? - Definition from WhatIs.com. Retrieved April 17, 2020, from
https://searchsoftwarequality.techtarget.com/definition/versioning