CF: Word of Recall and Portal (was: Prot/chaos, Efficiency, and Portals)

[David Andrew Michael Noelle <dave@Straylight.org>]

> Date: Thu, 16 Sep 1999 20:38:17 -0700
> From: Mark Wedel <mwedel@scruznet.com>
> 
>  Not terribly complicated, but a bit of work.  You would probably
> want to change the syntax of the file to be something like:
> 
> 1: sword
> 33: food
> 8: bolt
> 
>  And so on, so the client type is on the same line as the item itself.
> 
>  Then, use linked list or dynamically allocated array, which
> contains the name and item type.  As you read in the file, put the
> new element at the end of the array/list.
> 
>  When you parse an item, you traverse the array, and when you get a
> match, you use the type value in the structure and assign it to the
> object.

Sounds like a good plan to me.  Unless someone else feels motivated to
get that done, I'll add it somewhere near the bottom of my own To-Do
list.


>  It seems to me, looking at that description, that word of return
> and magic portal are very much the same (later allowing more than
> just player), with the only significant difference is one being
> priest, the other mage? (I guess how quickly they operate is
> another)

You're right.  They didn't start out the same, but each limitation
imposed since then has nudged them a little closer.


>  From some perspective, I am not sure if word of return is really
> appropriate.  What thing that was on the idea list was better
> control of the word of recall.

Actually, I was thinking of the word of recall scrolls in some other
rogue-like games.  If you read one from anywhere in the dungeon, it
puts you back in town.  If you read it in town, it puts you on the
lowest dungeon level you've visited.


>  I would suggest a more modest approach for word of recall, and sort
> of do away with word of return:
> 
>  1) If player has no return point, the first altar he prays over
> becomes his return point (this is for starting players).
>  1a) IF the player does have a return point, and is standing over an
> altar to a god, add some minor spell which now makes this his return
> point.
>  2) When player casts the spell, he returns to that altar.  Before
> actually teleporting the player there, make sure it is to the same
> god.

I like that idea.  I only see one problem with it.  What if the player
doesn't want to worship a god?  Praying over an altar the first time
would select that god to worship.  How about setting the return point
by sacrificing a scroll of word of recall?  Or should choosing your
return point be a priviledge reserved for those who have chosen a god
to worship?


>  As for magic portal - I would suggest letting the spell take an
> option, so instead of the requiring the order (suppose someone does
> a first location and realize they don't want it, but instead want
> where the are now the first point?  It would be sort of a pain to
> have to cast the spell 2 times to get that to happen).  So it could
> be something like 'cast magic portal of start' or the like.  I'd
> have to look at the spell options more carefully to see what they
> do.

Actually, that was my first suggestion, except that you could have
multiple destinations by naming them, i.e. "invoke portal set home" to
create a destination called "home".  Giving it just one parameter,
"set" or "open", should be no problem.  The only catch is magic items.
I could solve that by making "portal stones" set a destination if
applied on the ground and open a portal to that destination if applied
from your inventory.  They'd require some special code, insted of just
being balms with a different picture, but I can live with that.


>  Instead of using paths, which while easier, creates more problems
> if some other area is created, having actual attributes in the maps
> that tell you something would be useful.  For example, the map
> structure might have and outdoor/indoor flag (for walls as well as
> weather and night/day), a region value (different treasurelists in
> different regions), information on map reset times and the like, as
> well as a teleport flag or something.

I was just about to object that that would require loading the map to
determine whether the portal can still be opened, when I realized that
there's a really simple answer to that.  The determination of whether
the portal will still be valid after the map has reset can be made
when the destination is created and stored in the portal marker.
Copying some flag from the map is a whole lot more efficient than
storing a list of strings and checking for a match, even with shared
strings.

I think that covers all the bases about as neatly as possible.  I'll
start making these changes to my experimental code.  I think we've
reached a consensus on having a Portal spell.  Is this the final
version, or are there more concerns to be dealt with?  If I can get a
couple votes of agreement with the way it's defined here, I can just
commit it to the CVS tree when I'm satisfied that it works right.

-- 
            -Dave Noelle,                 dave@Straylight.org
            -the Villa Straylight,  http://www.straylight.org
Coalition Against Unsolicited Commercial Email  ==  http://www.cauce.com

Disclaimer: Disciples of E(vi)L may receive guidance in alt.religion.emacs.
GNU Emacs is The One True Editor.  The $PATH to redemption is /util/gnu/bin.
U.C.L.A. doesn't share my opinions; even Emacs can't make life that good.

Quote of the Day:
I am prepared for all emergencies but totally unprepared for everyday life.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]