Kayle said:
I'm trying to keep the system as simple as possible, so that I can attempt to maintain compatibility with existing snippets and the like.
As I discovered from the little bit of work I did on the RAM project, backwards compatibility is a myth.
That is to say, if a snippet is being applied by a competent coder, it can be pushed into some code that's been chopped up and spun around a few times, as long as they are patient enough to read the snippet AND the code they're trying to merge it into. If not, nothing short of a perfect patch file will be good enough, and unless they get lucky, that never happens.
With that in mind, I suggest going for the tool that makes the job easiest to do, and also makes the code easiest to modify and work with. I don't know that maps are that tool, they're just the one that seems the closest fit to me.
Kayle said:
1. I'd like people to be able to set up heal-over-time and damage-over-time spells easily. Without having them have to be poison related.
2. I'd like it to allow for multiple modifiers to a single effect. For instance, a single affect could give +5 Str, +3Wis, +2Holy Resist. Without having three entries showing up on the affected by/affects commands
Good goals. For that, I would suggest making the affect structure/class itself contain a std::list which contains all the modifers that affect contains. That way, you can extend the system in arbitrary ways, such as making an affect that gives +5 to strength and causes you to be unable to wear armour.
The code that does checks for things like that could either know that the spell "HULK" prevents you from wearing armour, or it could iterate through the set of affects and then search each one's list for such a thing.
As for timed affects... probably just having a defined pair of counters would work. One for number of ticks, and one for delay between ticks, and then a tick() method that gets called to adjust the affects.
All pseudo-code hand-waving below:
class affect {
int tick_count;
int tick_delay;
int tick();
...
}
Let's say you had an affect from the fireball spell, after the initial damage, it applies aff_fireball to you, which lasts for 6 ticks, spaced apart by 2 seconds each.
ticks: 6 -- ch_printf(ch, "Your are blinded by the intense light and feel your hair burning off!"
;
ch->add_affect("blindness", 2);
ch->damage(20);
ticks: 5 -- ch_printf(ch, "Your eyes are still tearing up and you're pretty sure your shirt has burned away"
;
ch->damage(20);
tmp_item = ch->unequip(chest_slot);
remove_item(tmp_item);
ticks: 4 -- ch_printf(ch, "Your vision returns, and you notice your arm is on fire too!"
;
ch->damage(10);
this->tick_delay = 1.5 seconds;
ticks: 3 -- ch->printf(ch, "The fire has ignited your spellbook, and your pants are smouldering."
;
...
You get the idea.
Obviously, the closer you want to stick to the original implementation, the less possible many of these things are... but if you really want to rip this subsystem out and rewrite it, there's no reason you can't make it far more flexible in the process.
In this toy example, the fireball affect actually added the blindness affect to the character, with a tick count of 2.... and let that affect manage itself.
It all boils down to your overall goals. If you want SmaugFUSS to remain strictly a bugfix only version of Smaug, then any real changes are going to be very difficult to accomplish. If you want to make the system more flexible and rip out infrastructure, don't worry about compatibility, because it won't be possible to maintain anyways.
Soooo.... "Smaug" in technical implementation, or "Smaug" in the more nebulous look-and-feel?
.........................
Top Posters
Top Uploaders
Stats
Affiliates
