Angus Mezick <angus@EDGIL.CCMAIL.COMPUSERVE.COM> writes:
> I agree about the 1 room per map-space being a waste. I some questions if you
> don't mind:
Not at all :)
> 1) How do you keep track of who is where? Coords on the player and obj? And
> for going in the oppsite direction room -> thingy? how is that done?
Yep, each player has a map_x and map_y position. (There are other
fields, such as movement mode on the map [there are commands to
automatically follow a road til the next fork, to pathwalk, speedwalk
a la Adom, etc]). Objects also have a map_x and map_y. Mobs can
wander the map. Right now it uses about 44 bytes per character on the
map; this can be reduced when the time comes. I've just not bothered
with it yet. Also there's support for editintg the map online and
saving it. Works fairly well in most cases.
> 2) I am guessing that this one byte per room is the char that is printed,
> correct?
Actually it's the terrain type, which gets translated to a character
when displayed. Same effect; room for up to 256 terrain types.
Memory could be halved by using 4 bits per square but I think this is
a bit (forgive the pun) excessive.
> 3) any way we could see the relevant sections from char_to_room and
> char_from_room?
Actually those functions only have a few lines changed. perform_move
had a lot of work done to it, as did look_at_room (particularly
considering I have optional scrolling/nonscrolling maps that use VT100
scroll regions to keep the map stationary while the rest of the mud
scrolls below it).
> 4) I am guessing a lot of stuff moved into low level functions, just to make
> this easier :)
Yep, a good bit was. In particular, I had to do a bit of an ugly hack
in char_to/from_room. Basically ch->inroom is the negative of the
real room a player is in if they're on the map. This is unfortunately
necessary because a lot of places use was_in = ch->in_room and then
move the player back (at comes to mind immediately). There are other
funciotns I believe that only recorded the room number, which
necessitated this ugliness.
It works well; combat even works on the map. I'm very happy with it.
It took a couple days to get the code map code in, with a few
revisions since then. One interesting phenomenon is that Zmud is very
slow when it comes to some things... so slow that using the stationary
map will basically freeze up zmud if something is moving near you.
Quite odd! It isn't the link that is saturated; it's zmud trying to
keep up with the [rather efficient] cursor movement and drawing. To
limit that I imposed movement delays on the map which actually will
work well; it will take longer to move through mountains than on a
road, for instance.
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerjh/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST