Gameplans: Modularity of Mods

Suggestions
,
42

In this case, that is feasible. But there will be other incompatible systems that your base game will not anticipate - for example maybe there are two magic system mods, one for flat mana and one for body chakras (different magic levels for different body parts). Since Mechaenetia base doesn’t have magic events, the magic system mods add the events themselves. The flat mana mod does not include body parts in its API or events, as far as magic levels are concerned.

Another mod purports to apply negative effects based on low magic levels, but is written for the chakra magic system - the author didn’t know about the flat mana mod and has since discontinued updates.

Another mod adds a magic-eater monster, which siphons your magic when it attacks. But the logic for the attack is written for the flat mana mod, and a player with the chakra magic system won’t have their magic drained. This mod author didn’t anticipate other magic systems and didn’t leave any custom events for a compat mod to hook on to - because no (hitpoint) damage is dealt, no base Mechaenetia damage event is fired.

Now some player sees the above two mods and wants a magic-eater monster who will drain your magic, causing negative effects if your magic levels get too low. But the mods are incompatible - upon running the game, no matter how long the monster attacks, the player suffers no negative effects.

It is possible to write a compatibility mod that will calculate flat mana based off chakra levels, and intercept any flat mana system events. But even that approach isn’t perfect.

Consider one last mod that adds a “reflect” spell, written for the chakra magic system. The “reflect” spell is like a shield around the player that will take any magic attacks and reflect them back at the attacker.

Our player wants to be able to reflect the magic-eater monster’s mana siphoning attack, so that he ends up draining magic from the monster. Due to the way the monster and mana mods are written, draining magic from the player and increasing mana on the monster are two totally separate events. No information in one event links it to the other. So even with a compatibility mod, the reflect spell only reflects the magic draining portion of the attack: the monster drains its own magic and it increases its own magic by the same amount. Where the player expected to drain magic from the monster, but from his perspective, the “reflect” spell simply neutralizes the monster’s attack.

~Max

2 Likes
43

There will be presets for Basic Systems, such as Health, Endurance, Magic, Food etc. So right from the beginning each of the Mods can make Compat with those Systems to bridge the Gap. That is why Damage Events can for example be of the “Damage to Mana” Type without having to specify which type of Energy is being drained.

And no matter which Damage is done, all of them will specify where on the Body the hit has landed. A Vampire draining from your Neck will clearly deal more damage than them biting into your Finger.

P.S. I would think of Chi as different from Mana, as it is more based on “Life Force”. For example a Jedi/Sith would use the Chi System instead of the Mana System. Obviously Monks/Ninjas would use the same System.

1 Like
44

This doesn’t address the “reflect” problem. Supposing the Chi/chakra mod allows for magic combos, something which isn’t in Mechaenetia’s base. The idea is that multiple magic events are bundled together to make a single “combo” or spell. So the drain spell, if written to use this system, will look like this as an event

Drain combo (
1. decrease target magic by X
2. increase self magic by X
)

The reflect mod takes advantage of this combo system to reflect the entire spell back on the attacker - target and self would be switched throughout the entire combo.

Now, for compatibility, any magic event that doesn’t use the combo system explicitly is given a dummy spell wrapper to hold the one effect. The monster mod doesn’t use the combo system natively and so the monster’s drain spell is actually split in two.

Dummy combo (
1. decrease target magic by X
)

Dummy combo (
1. increase self magic by X
)

The reflect mod will look at each combo and, if an entity with “reflect” active is mentioned, will intercept the event. So it intercepts the first dummy combo, but not the second. The player’s “reflect” will only neutralize the monster’s attack.

~Max

2 Likes
45

Basic Actions like Reflecting and Draining, even if you drain Enemy Mana to increase Own HP by half the amount of received Mana for example, will be native operations to the whole System, and you can still have effects like “if you get damaged, a projectile corresponding to the damage you received, will spawn and fly wherever a random eligible target is”

Also fucking up the Combo by making the Spell have two Effects that do not actually correlate, is a mistake no matter how you look at it. What if you WANTED to do something that Adrenalizes your Mana UP and causes the Enemy Mana to go down due to something that is not related to actually draining the Enemy Mana, but actually destroying Enemy Mana while by sheer coincidence you also power up?

1 Like
46

I think you are fighting the hypothetical. You are going to implement not only a basic magic framework but specific spells to drain and reflect magic as part of your base game? Even though the base game will not include magic of any sort?

The person who wrote the drain spell didn’t necessarily do anything wrong. They wrote their mod for a basic API that only takes one effect per event. It might be something like this in the monster mod:

fn drain(&mut self, target: &mut Entity)
{
    use EventTypes::*; // string constant DAMAGE
    use HitpointType::Mana; // as opposed to Health, Energy, etc
    if let Some(delta) = send_event(
        Damage, (Mana),
        &mut target, &mut self,
        20_i32
    )
    {
        send_event(Damage, (Mana), &mut self, &mut self, delta * -1);
    }
}

Whereas the reflect mod might only intercept “SPELL” events, and a compat mod wraps each DAMAGE event affecting Mana into a dummy SPELL event. If this was not done, none of the mods written for the basic magic system would be compatible with the spell system at all.

~Max

2 Likes
47

HitpointType::Mana will not exist, everything will have String alike IDs, so you do not need to include other peoples APIs if you just wanna flag something as “does damage to generic magical energy” or DamageTo(21, “Mana”, insertBodyPartHere)

You are thinking WAY too constrained to everything having unchangeable Classes, instead its pure Events and Numbers, and the Mods decide to react to those Mathematical Events.

1 Like
48

It doesn’t necessarily need to be an enum (as I envisioned it), it could be a string constant and work just as well with no changes to the above code.

~Max

2 Likes
49

The Event itself will definitely contain a ton of Information, including the Mod that causes the Damage to be dealt, so you could even decide that “damage against Mana done through this mod, also does damage to the Chi of my own Mod”.

1 Like
50

Or wasmer instead of wasmtime, but basically the same yeah.

Shouldn’t it more of give the physical location of the hit, so the character itself can determine what part was hit? Or do you want to force it to be bipeds instead of allowing for robotic or arachnid or whatever characters? Lol

So again the physical location would make more sense then passing in a part? Can always query the character for what part is at that location anyway, which could be an open type since mods could add parts.

1 Like
51

That was my point, you’re going to need a thousand compatibility mods. It would make more sense to just fork the content mod for the other system than to write a compat mod just for that purpose.

~Max

2 Likes
52

I think a dedicated combat mechanics topic is in order, I’m now wondering about performance and bandwidth implications of having nonpreset body parts individually accounted for realtime.

~Max

2 Likes
53

Exactly, hence why only the hit location and radius around it should be passed in.

1 Like