[MUD-Dev] Re: let's call it a spellcraft

[Vadim Tkachenko]

quzah [sotfhome] wrote:
> 
> From: Vadim Tkachenko <vt at freehold.crocodile.org> on Tuesday, September 22, 1998
> at 8:39 PM

[skipped]

> In addition to the above, I replied to this in an odd order, (I
> started at the bottom after I had read through the message, and
> wrote my reply to something near the bottom first, so, hopefully
> it makes sence. Heh.
> 
> >OK, I want to create the 'Apocalypse' spell, destroying every player in
> >the area of effect, except myself.
> 
> >
> >And at the same time I joined the game 5 minutes ago.
> >
> >How are you going to define the limitations on the spell being created?
> 
> [snip]
> 
> >What about the side and cumulative effects of the variouse spell
> >components?
> >How about creating a complex spell by sequencing some simpler spells and
> >setting a proper timing for them (I guess, that was discussed here
> >before)?
> 
> You'd just have to write some sort of spell editor, and allow
> the user to dump more and more effects into the spell. I would
> do it so the order they are added (effects) decides the fireing-
> order of the spells effects.

Actually, I meant a different thing: is there a limit on the power of
the spell implied by the power level of the creator? And the subsequent
users (this is easier - you don't have to be THAT smart to turn the
ignition key)?

> Shrug. Anyway, there's another way you could do it. Then, the
> way I'd do it is that they would trigger (the effects) in the
> order they were put onto the spell, however, depending on if
> you had a delay on them or not (effect_delay) they would be
> added to (in my case) the global effect list in their "time I
> trigger" order.

Or, if we call it a composite spell, just the initial trigger for the
whole sequence

> So... if I the spell I made had 100 things
> that were its effects, they would be checked in the order they
> were added to the spell, however they would "fire" in the order
> they fell in the world's effect list. (Not necessarily in the
> order the creator of the spell thought they would)

And, to aggravate this (and add more fun) we can state that there's only
way to time sequence this stuff: absolute units. And, there may be some
context-defined delay (time compression/expansion) for some atomic
actions (like fireball will be cast slower in the inert atmosphere and
fast as a lightning in the pure oxygen).

This goes back to the asynchronous event handling again ;-)

> >[Vladimir Prelovac]
> >> He would then give it a name, write it to his spellbook, and maybe teach
> >> it to his friends. That way the new spell, carrying the name he gave it,
> >> would be tought in the lands for generations after.
> >
> >Good idea, tough to implement, though ;-)
> 
> No, it should be really easy.

;-) that was remark to the whole message, not the last statement ;-)

> >Now, can you give me a real example when Y can be _set_ to X, unless
> >it's boolean? Also, let's consider this:
> 
> Sure, here are a few types real quickly:
> 
> spell_random_teleport:  SET( character->room_i_am_in, random_room );
> spell_quicksand:        SET( room->floor_type,  FLOOR_QUICKSAND );
> spell_evaporate:        SET( water_barrel->liquid_amount, ZERO );
> 
> Shrug. Just a few. Bascially, anything that is not a damage/heal
> type of thing, is a "set_to" type of thing. If you are not just
> altering it by a known amount, then you do specific "set_to" stuff.
> At least that is how I see it, and I think it will work great.

Sure, no doubts. I've just had my internal representation of the
property in mind and didn't think that you call things like current
location etc. properties. In my implementation, "properties" belong to
the visible to the player representation of the character, and things
like these go below the visible layer.

> >And again, I'd propose to include the response actions along with the
> >property changes into the action results (touch that plant I don't know
> >the English name for (mimose?), and it squeezes its leaves).
> 
> I am sure I'll have to limit myself, none of this "butterfly flapping
> in the wind causes a tornado 5000 years later" stuff. Dang ;)

Which in turn creates a problem with the loop recognition ;-)

> -Q-

--
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are