good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
Re3: Mapping node relationshipsby dragonchild (Archbishop) |
on May 13, 2003 at 13:37 UTC ( [id://257722]=note: print w/replies, xml ) | Need Help?? |
FYI: In the DikuMUD (and its descendents) representations, there is only the room. Each room has an ID and a list of exits. An exit is a pair consisting of direction ID and room ID. If the exit doesn't exist, you can't go that direction.
Now, this ends up with a Zorkifying influence. You stand in room 1. You go "south" into room 2. However, to get back to room 1, you have to go "northeast" (or whatever). This is poor mapping technique, but the possibility still exists. As for storing just the coordinates - there's another problem to be aware of - you have to make sure that you don't have overlapping coordinate groups. Also, it is possible that you will have the same coordinate list up to 8 times, once for each room. Now, the storage of this - I would recommend having a ROOM table and a ROOM_COORD table which foreign-key's back to the ROOM table. This also allows for something like ROOM_TRAP, ROOM_ITEM, etc - all FK'ing back to ROOM. Of course, the entire room discussion presupposes that you want an imperfect model. Another way is to have objects contain their location rather than locations containing their objects. The room system is the latter. The problem with the former is the issue of description. It is very difficult in a text-based system to auto-generate descriptions back to a user when there isn't a set description for the location. Object-based systems are only really possible with graphical ray-traced systems, like EverQuest. But, it's still something to think about. ------ Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
In Section
Seekers of Perl Wisdom
|
|