Modeling spells/skills as collections of affects

S001GMU at nova.wright.edu S001GMU at nova.wright.edu
Tue Sep 9 09:16:43 CEST 1997


sorry for the delayed response... RL reared its ugly head for a while and I
didn't have a chance to get back to this until now.  :)

Date: Thu, 04 Sep 1997 01:14:50 +0000 (PST8PDT)
From: Miroslav Silovic <silovic at mare.zesoi.fer.hr>

>Caliban Tiresias Darklock <caliban at darklock.com> writes:
>
>> S001GMU at nova.wright.edu wrote:
>> > 
>> > Spell
>> > construction would consist of building the query (would definately want some
>> > interface here so that ppl don't have to learn SQL to create spells on the
>> > MUD!), 
>> 
>> WAIT! WAIT! The language of magic! This is a GREAT idea!
>
>Check mage2mage system (somebody posted the URL here not long ago, or
>I could email if you request). They specced out the costs for each
>executed statement in the language. And I also loved the fact that to
>create a permanent magical item, you have to bind a demon into it, and
>to summon a demon, you have to sacrifice a living, sentient
>creature...

I'll have to look into that...  someone posted it here, I believe, but I
have yet to read it.  RL again..ugh. :P

>> Translate all the SQL syntax into pseudo-Latin words, give your database
>> fields odd names, and make people type in the queries in this strange
>> fictional language. That would be so cool. 
>
>Umm, I don't think this would work all that well. How do you say
>'sphere of 50' radius around the orc' in SQL?

That depends entirely on how you have your world stored in memory.
Diku-style rooms don't use 50' Radii spells, etc.   Assuming you use
a "real" coord system, you could do a query like so (forgive the
psuedo-SQL-code.  I'm not up on my SQL):
  get target orc's coords,
  modify all creatures whose ((coords - orc's coords) < 50').
I believe that's really not all that complicated in SQL.  Depending on the
way you have you info indexed, that can be quite an efficient search too.

>                                              For that matter, while I
>like the idea of using an existing database code in a MUD server, I
>think that interpretation of SQL is completely unnecessary, and far
>too inefficient.

Aye, that may be.  For now, I'm gonna stick with it, though.  When I start
to run into speed problems, and the efficiency of the SQL conversion is the
problem, I'll look into removing it.  :)

-Greg





More information about the mud-dev-archive mailing list