So I accidentally discovered this incredibly cool thing that I didn’t know about Interfaces.

Apparently when you create and apply an Interface to another object, enums declared within the Interface are treated like they’re uh, “local?” to the implementing object. This is kind of a big deal because it means there are a ton of things I can do… more easily/concisely?

Okay, so this is kind of weird so let me see if I can explain it:

I created an Interface for “Actors” which contains the Ability score enums: STRENGTH, DEXTERITY, CONSTITUTION, INTELLIGENCE, WISDOM, and CHARISMA. These enums are really important to creatures and characters who can act/perform actions, and basically no one and nothing else. There are a few other things that are only important to potential “Actors,” such as Size, CreatureType, Alignment, Speed, and so forth.

By declaring the enums within the Interface, I can actually encode almost everything the character/creature/whatever directly into the Interface without needing to create unique functions within the implementing objects. This saves me lots of time copying and pasting a bunch of stuff that ought to be obvious. It feels like magic… like cheating, in some regard.

I can… barely describe how incredible it feels to have so much of the OBJECT-CREATION portion of programming practically automated for me. I’m looking forward to eventually implementing monsters just to see how EASY it is with most of the code already/automatically done for me through the use of Interfaces.

What it makes me want to do is make Interfaces of a few other “corners” of the process, like Combat. I haven’t started to really implement Combat interactions between creatures and characters yet because there was so much other stuff I had to do first. But among all the other things that I had to do, I had this really awesome idea to create the “Attack” object, which I’ll try to explain:

So I was slaving away trying to create this awesome “gear optimization” algorithm that would find the best piece of gear for each available slot, and I’ll still probably use some derivation of that for semi-permanent pieces of gear that change infrequently like rings, amulets, and so forth but I had a much better idea for choosing the best attack modes for a character…

Implement every (or most) possible attack modes, and then sort them by the desired ones.

I mean, it might sound inefficient, but swapping attack modes in D&D 5e is fairly trivial (it should be in most editions, honestly), it’s just a pain in the butt to calculate by hand for your character sheet. But the computer doesn’t care…

What the computer can do is iterate through each weapon in your inventory and create an “Attack” based on the use of that weapon. It can create additional attacks based on the use of a shield, an offhand weapon, or whatever. It could store them all in a List to sort by desired effect (most defensible, etc). In fact, I could make it a Set to specifically avoid duplicate options.

Then instead of merely including an equipment option that states the “used” or “held” objects, I could provide the best options, sorted. I could apply all the necessary “tags” to the attack at that point like weapon or energy types (slashing, piercing, fire, cold, force, etc).

Given these options, I could then let the program choose from among the best attack options during an encounter, or randomly until I write an attack-mode-selection function.

And wouldn’t it be awesome if a printed stat block actually included a number of lesser-attack options for a DM to choose from when running an encounter? I mean, maybe you’re less likely to run a defender-style monster without sword & board, but it would be useful if they lost their shield and switched to versatile longsword attack mode that it included updated AC/damage information?