Serendipity is the damnedest thing.

The other day I was neck deep in documenting my Armor changes when it dawned on me that the way I have coded it, allowed for a some unintended potential.

In my attempt to repeat as little code as possible (because my first Armor script is insanely repetitive) I focused on efficient use of inheritance and method overrides, supported by more streamlined note tag use…

Armor_v2_screen1(Screen is of early proof)

Essentially, equipment is assigned any number of Armor objects (Armor Pieces, Armor Options, Armor Attacks) that are then summed up into Magical & Physical Armor totals.

My primary motivation was to allow for each piece to be ‘flagged’ with key words, such as ‘Physical’ and ‘Magical’, in order to allow one set of methods to process ALL Armor, with as little code repetition as possible.

It also had the added benefit of allowing me to more easily extend the code in the future, via new key worded armor types, and only a little bit of added code. But then I noticed how it also allowed for each Armor object to be individually altered during battle in a way that a flat total ‘Armor’ value could not be, without effecting all Armor on the battler.

Because of this somewhat serendipitous coincidence, I am now planning an even DEEPER application of Armor than I had first imagined. Including several key details that would not have been feasible without the ability to separate an armor type total into disparate groups at point of application.

These details include:

Active Armor – Abstraction of the battlers ‘use’ of their Armor. (Usually, requires an Action to generate) Active Armor is subject to a few potential weaknesses (such as Physical ‘Active Armor’ being completely bypassed by immobility) and a few strengths (such as being naturally resistant to being Pierced or Breached).

Passive Armor – Abstraction of the battlers overall ‘Status’ of being Armored. (Auto Restored each turn)

Armor Pieces – Equipment can now contain one or more ‘Pieces’ of Armor, each assigned an atype_id straight out of the database.

Database ArmorTypes Defaults(Default RPGMaker VXAce Armor Types)

Thus a pair of leather gloves may have (1)Passive Leather Armor ‘Piece’, a pair of leather pants may have (3) Passive Leather Armor ‘Pieces’, and a leather chest suit may have (5) Passive Leather Armor ‘Pieces’… For a battler total of (9) pieces of Passive Leather Armor. (Leather has its own default details, assigned its atype_id)

Each piece, tracks its stats individually and can be acted upon individually, by damage. Up to and including failure of that piece of armor. (I have not decided how such failure is resolved)

Also, this allows for each potential ‘piece’ of Armor to have different Armor type ID’s, and thus have different properties when conglomerated. The above mentioned chest piece, may contain (4) Leather, and (1)Mail pieces, instead… etc… (but still be worn as ‘Leather’ armor, for purposes of equipability)

Oddly, I think this new mechanic may actually be easier to configure than my previous mechanic, despite being significantly richer in potential.


Registered Users Can Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s