RPGMaker MV Cometh…

This decision has not come easily. But I think it would be a serious mistake to cling to the dying remains of an inferior engine while its community moves on to the next.

I am not totally abandoning my VXAce work. But I would be lying if I guaranteed to return to it.

The simple fact is that after all this time, I have very little to show for all my work, other than my experience. And that experience is telling me there is a BIG opportunity about to present itself, which I can choose to take advantage of, or watch it pass me by.

Golem Legend, is going to take a nap for a while. Hopefully, to awaken better and stronger in the not to distant future.

Reality Check… Incoming.

I never thought I would say this.

But I may have written to many optional mechanics… 😉

I keep telling myself that I am future proofing my game, so that I can plan ahead and trickle out new mechanics as the game grows in content and older mechanics get stale.

But that is assuming my game has an audience that will want it in the first place.

While I would like to believe that everyone will enjoy what I enjoy, the truth is that the RPG Maker community at large may not like what I am working on at all… It is quite a departure from traditional JRPG fare.

I have already re-designed Golem Legend’s world map twice, Skills and Class structure three times; including the Equip Slots structure. Not to mention the States structure has changed now that Armor v.3 is a parameter and no longer a state charge based mechanic… (Several months ago, it was functional but clunky so I re-wrote it as Armor v.1)

Iteration, iteration, iteration…

I also tell myself that writing it once and implementing it later, is more efficient than re-writing it later, AND implementing it later, due to potential retroactive consequences. But if the only content the new mechanics apply to, will be new content, then its sort of a wash anyway. (Assuming new mechanics don’t interfere with or unintentionally replace old ones)

But when the intent IS for core mechanics to be replaced, they often break (or make totally trivial) random content, balanced with the original mechanics. Which forces a revisiting of entire content arks. (As if I am not wasting enough time, every day, as is)

But getting something playable in the hands of the community sooner, allows time for audiences to grow and helps guide the creation of new content. Rather than having to guess what they want.

As a matter of fact, some of the most successful indie developers preach the release early and release often strategy like dogma… And I have not released anything more than a few practice builds over the last few years.

And now that RPG Maker MV is releasing, the total obsolescence of the VXAce community scripting is a forgone conclusion. In other words, if its not already written, and in usable form, it won’t be.

A consequence of MV using Javascript, not Ruby.


It’s become pretty obvious that I must begin working on something that people can play, soon. For my own sanity if nothing else.

This means that I am going to have to scrap the last of my Battle Mechanic plugins ‘Aptitudes‘ and button up my State Mechanic… With as few features as I can manage. Aura States, Disjunction and Living States will have to wait… /cry

Preliminary Classes (Excluding Golem)

A small example of some of the extensive documenting I insist on doing so that I do not accidentally step on my own toes during this process.

(All stats are indicative only. Based on top left ‘Level’. Using ‘Warrior’ as the base class.)

preliminary_class_specifics_15_1020You will notice that each class has a Tier, an Ethos (sometimes), Primary Aspects and Secondary Aspects. Each corresponding to further detailed lists.

Tier is indicative of the expected access and level bias involved. (Tier 0 is game start, Tier 0.5 is halfway through chapter one)

Ethos corresponds to Deistic Order. A plot device used to add constraints to behavior.

Aspects are my solution to class planning. each one corresponds to specific details that are identical for each class with that Aspect.


  • OccultistsCan read Casting Scrolls and Cyphers.
  • RitualistCan perform Rituals at Shrines and Temples.
  • MedicCan Craft Medicine, and focuses on Curing effects. Can Quick-Rest without Camping.

Note: Resting is a party activity used to pass time and restore some ‘Use’ limited abilities.

For the record, this screenshot is already obsolete. 😉

States Engine – Part One (Normal States)

I’ve managed to code up most of my Armor and Battle mechanics but found myself finely needing to revisit my States Engine. Mostly in order to complete my collection of systems which focus exclusively on battle, and to FINELY look forward to fleshing out what I hope will be a unique and powerful Golem Legend – Battle Demo. (Sooner or later)

A lot has changed since I first mentioned my States Engine and the vast majority of that change has been in my capacity to imagine where my code is headed before I stumble onto it…

I remember that shortly after I started I got badly burned out and had to do something else for a while. It was the third attempt at writing the entire state mechanic, and while I had finely gotten the right idea it didn’t take long for me to realize that I was still trying to bite off WAY MORE than I could comfortably chew.

So I went sideways (Yay: AP Battle Mechanic!) and success led to renewed productivity, which lead to another mess…. 😀 But I re-wrote that as well, and a half dozen plugins, and nearly an entire Battle_v3 system.

I have not been here to talk about them because I was writing them!

(I seem to do my best work in the third attempt for some reason)

So… Why am I here now and not still coding?

I think its because I bloviated so profoundly several months ago and thought that I might take a moment to tell you (and my posterity), that was the moment I think I finely realized that I can do… this.

All of this.

Until that moment, I had been Running on Empty. Running Blind… 😉 It wasn’t 100% apparent to me at that time, but something was clicking in my head and whatever that was, gave me the push I needed to tackle these last few months with hitherto unseen consistency.

Today, as I buttoned up the first 2/3rds of the Core of the States Engine I figured it would be a good time to mention a little of my progress.

Here is the first 3rd… Regarding Normal States.

Normal States

Normal states function as they always have with a few notable exceptions.

First, is that a state can now be Hardened once it is applied to a target. While feature objects that totally resist a state still do so, once they are successfully applied they might become hardened. Thus, it is always easier and cheaper to work at prevent states, rather than removing them!

Most support classes sport plenty of (Feature: Rate – State) abilities.


Second, is the inclusion of Dispel note-tags, that are currently only applied to States, but will also be applied to actions with extended formula based chances.


Such actions differ from normal effect based remove state, by the simple fact that they do not directly remove the state, but only weaken it, in order to allow a countering state to remove it through resistance.

Hardened states can not be (Feature: Resist – State) removed from a target without first being Dispelled.


This dispel requirement only applies to states added after the hardened state was applied, in an attempt to remove it. Primarily because the majority of my plans regarding the removal of states in the field (such as inside a dungeon) is through the application of counter-states.

Think of how modern medicine works. When you are sick, you apply a medicine to yourself in the hopes that it removes the sickness. Now, imagine how a magical spell works, as it instantly vaporizes the bad stuff somewhere in your body. Hardened sicknesses can not be removed via medicine, without first being weakened with a dispel. But if an action outright removes the state, even a hardened one doesn’t stand a chance.

While magic actions with (Effect: Remove – State) exist, they are rare and expensive.



Next time I will detail Permanent States. Hopefully by then I will also have completed the last 3rd of the States Engine and will write up a post about Trait States!



Armor v.3 – Continued

Here is an excerpt from my write up of Armor v.3.

At its most simple, armor prevents damage…

Damage, consumes armor in an attempt to remove it completely, allowing it to consume health instead.

Not all types of damage consume armor at the same rate. This rate is dictated by the TYPE of armor the damage is applied to. Some armors are better at preventing some damage and thus are consumed slower by that damage. Still some armors are worse at preventing some damage and thus are consumed much faster…

The hit that applied damage plays a very large part in the amount of armor that damage can consume. The ‘Hit Type’ of the action is compared to the type of armor being consumed, determining if the armor is even able to defend against the hit and, if it can, how much armor it consumes with every point of damage applied.

Note: Damage element consideration is added in the ‘Advanced Actions’ plugin.

Armor comes in several types that each belong to one of TWO categories: Dark and Resonant. One armor of each category can be active on a battler at a time, and the total of both are displayed as the battlers total armor in the battle GUI.

Rest assured, the armor most suited to defending against an attack is the first armor applied to preventing it.

Dark Armor:
Dark armor is materially based, is the least complex and applies most evenly towards preventing the damage fro hits the armor is able to defend against. However, this simplicity is deceptive, as Dark armor is also the easiest of the armor types to completely bypass via use of special attacks.

Example: A Ghost’s Incorporeal attack, passes right through Dark armor.

Natural Armor:
It is easy to assume that ALL creatures have some sort of natural armor. It reflects the creatures innate ability to defend against incoming attack, as well as how hard its hide is to penetrate.

Consumption Details: (Preliminary)

  • 100% vs. Physical Attacks
  • 100% vs. Magical Attacks
  • 200% vs. Eldritch Attacks
  • 200% vs. Sacred Attacks
  • IGNORED BY: Incorporeal

Shadow Armor:
This is an end game based armor that is superior to Natural armor in every way. It is intended to completely replace Natural armor by the time the player is able to equip it. (This is based on Golem Legend Lore)

Consumption Details: (Preliminary)

  • 25% vs. Physical Attacks
  • 50% vs. Magical Attacks
  • 100% vs. Eldritch Attacks
  • 100% vs. Sacred Attacks
  • IGNORED BY: Incorporeal

Resonant Armor:

Resonant armor is energy based, requires resonance to maintain, and suffers from what can be very extreme differences in consumption. Also, resonant armors block all Incorporeal attacks, as well as a selection of other special attacks that complement its character.

Note: Special Attacks other than Incorporeal are added in the ‘Advanced Actions’ plugin.

Arcane Armor:
Most magic based spells and equipment will grant Arcane armor. As such enemy casters, of all types, should have a heaping helping of it.

Consumption Details: (Preliminary)

  • 100% vs. Physical Attacks
  • 50% vs. Magical Attacks
  • 150% vs. Eldritch Attacks
  • 300% vs. Sacred Attacks
  • IGNORED BY: (See: ‘Advanced Actions’ plugin)

Divine Armor:
Most religious based spells and equipment will grant Divine armor. As such enemy priests, of all types, should have a heaping helping of it.

Consumption Details: (Preliminary)

  • 50% vs. Physical Attacks
  • 100% vs. Magical Attacks
  • 300% vs. Eldritch Attacks
  • 150% vs. Sacred Attacks
  • IGNORED BY: (See: ‘Advanced Actions’ plugin)

Entropic Armor:
This is the ultimate type of armor, and should be the hardest to get and maintain. It is reserved for the deadliest of end game content.

Consumption Details:

  • 25% vs. Physical Attacks
  • 25% vs. Magical Attacks
  • 50% vs. Eldritch Attacks
  • 50% vs. Sacred Attacks
  • IGNORED BY: (See: ‘Advanced Actions’ plugin)


Because Resonant armor requires a specific energy source to maintain, the user of the armor must resonate that form of energy in order for the armor to manifest.

Arcane armor requires that the user be resonating Arcane energy, as does divine, and even entropic!

Should the user lose this resonance the armor will vanish until the resonance is restored. At which time the armor returns as if it had never been lost.

Likewise, if the user somehow resonates another energy, then that armor will manifest (if it exists) instead.

Switching between resonances DOES NOT destroy the armor in transition, and can freely be switched between as frequently as the batters resonance switches! This is assuming the armor has not been consumed or drained in
some way.

Note: Armor drain still effects non-manifested armor!

Note: Resonance switching is not always voluntary! It is a good idea to
have multiple ways of re-establishing resonance when it is lost.

I will mention that the script is complete and functional. As well as the ‘Advanced Actions’ plugin. In the process I wrote the core of an ‘Advanced Attack Elements’ as well. Which got me started writing ‘Battle_v3’!! (I am currently writing it up)

Productivity abounds!

Introducing Armor v.3

Back in July I began writing what would become the Leviathan known as Armor v.2, and attempted to explain my reasons in a rambling post regarding the necessity to re-think health and armor. While the core of my intent remains the same, I have tempered my expectations following a healthy dose of REALITY. More specifically, the reality of trying to actually use the mechanic I designed in a standard and intuitive way. Neither of which were easy.

So, reluctantly, I began from scratch and completely re-designed the mechanic. Before I wrote a single line of code, I had made sure that this time, I learned from my mistakes, rather than compounded them!

This is the result.

Normal Defense = ‘Natural’ Armor

I attempted to point out previously, that RPG Maker VXAce has a default implementation of Defense, in the form of parameters that are intended to be used in the damage formulas of the standard skill or item based action. Normally, it would resemble something like this:database_skill_damage_menu In this example, the damage formula is taking into consideration the attackers ATK parameter, and comparing it to the defenders DEF parameter, which is reducing the potential delivered damage.

The result of that formula, then passes on to the Variance value you see there, which says that the total will randomly vary by as much as 20%, either UP or DOWN. Lastly, the result can be a critical hit.

Which will multiply the value by 300% if successful.

My armor mechanic is effectively removing the need to define reduction inside the damage formula.

Instead, all targets have a minimum armor defined by their defense parameters. Every attack is essentially reducing that armor defense, until its gone. At which time, the full force of every attack reduces the targets health.

Taking into consideration the above damage example, imagine if it instead, looked like this:

database_skill_damage_menu_2And the targets ‘DEF’ parameter was instead used to define that targets MINIMUM ARMOR of (b.def * 2).

Now, any attack against that target, this round, will first reduce its armor, instead of its health, until the armor is exhausted. At which point 100% of all damage, reduced the targets health.

This is the most ‘basic’ of the functions of armor, in Armor v.3.

Minimum Armor
As noted above, all targets regardless of their natures, will now have a number of Natural armor points, defined by that targets defense parameters. To more naturally replace the original implementation of defense;

minimum armor is completely restored at the beginning of every turn.

However instead of being automatically reduced from every possible attack (assuming it was included in the formula) that defense is a finite resource that is conditionally applied to incoming damage, if it has not already been exhausted.

Current Armor

Like a battlers health, its current armor will fluctuate depending on several factors. The largest of which is the last time the battler itself acted to increase it.

Like casting a healing spell or resting at an Inn, would increase current health.

Only armor would require repair, or restoration of some kind.

As with the previous armor mechanic, this one maintains the option of making feature objects benefits dependent on the existence of current armor. Imagine a magic ring that grants armor as well as resistance vs. sleep states. However, if the wearers armor is ZERO, the rings sleep resistance does not function. Presumably, the ring is recharging, after having been drained providing the armor that has been exhausted!

It is possible to flag individual or all such features as armor dependent.

Armor Types
Currently there are five different armor types implemented. They are: Natural, Arcane, Divine, Shadow, Entropic. However, more can easily be added, and might just be. As of this moment I am still toying with a sixth armor… But I will leave that for future necessity.

As you can imagine, each type of armor has its own personality, complete with conditions to their use as well as their reaction to specific forms of hit types. Such as a physical or magical hits.

database_skill_invocation_menuTo that end, I have already implemented three additional attack types: Eldritch, Sacred, and Incorporeal. There are more in the works.

Each type of armor reacts very differently to each possible hit type. 

Furthermore there are two armor categories each armor type can belong to. Only one of each category can be manifest at one time.

No more than TWO of any armor types can be active on a battler at a time.

And of those, the most effective armor vs. the incoming attack is applied first. This way, your best defenses are always the first applied, in order to prolong survival.

There are many more details I could go into, but they will have to wait. I will likely be revealing them in due time.