one4k4 has asked for the wisdom of the Perl Monks concerning the following question:

Morning guys, it's been a while.

I've got a bit of an odd question / thought process happening here. I'm working on a MUD and for the purposes of this e-mail, lets simply say that it's complete and working..

I wanted to generate maps (using gif/pngs read: GD* type stuff) so that users can view where their character lies online, and so admins can track npc movements, pc movements, etc.. stuff like that.

But my first step is to simply map everything plain-n-simple like.

A sample database record contains something like this: 

room_id,x,y,z
1,0,0,0
2,1,0,0

[download]
and so on..

I can add a column to specify the "type" of room, be it outdoors, woods, lava, etc.. but that's not an issue. Yet.

I've got a relationship table similar to the following: 

room_id,exit_to_room_id, exit_direction
1,2,e
2,1,w

[download]
That's how I can go about building the x,y,z stuff above. If the direction we moved is east, then x++, etc..

I looked into point based maps via some modules found on CPAN, but can't really think about how to draw the relationships.

For that matter, I can use a large-large table with 10px by 10px cells and map that way, but I'd like to use a png/image of sorts.

Any thoughts? Links? Flames?

Thanks in advance,

One4k4 - perlmonks@poorheart.com (www.poorheart.com)

Replies are listed 'Best First'.
Re: Mapping node relationships
by dragonchild (Archbishop) on May 13, 2003 at 13:12 UTC
    A lot depends on if your map is room-based or point-based. If it's room-based, just have a bunch of rooms in your DB and screw the idea of XYZ coordinates. (I don't know how much MUD-coding experience you have, but when I worked on a Diku-MUD, this is the way it worked and it was much better for sparse maps.)

    If it's point-based, I would still recommend only storing the outlines of a room. For example, you'd store the 8 coordinates that are the boundary corners for a given room. Then, any coordinate that doesn't fall within a room is unmapped.

    ------
    We are the carpenters and bricklayers of the Information Age.

    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.

[reply]
      So, in your first paragraph; You'd simply generate a room-to-room display disregarding where they lay.. kinda like those huge "maps of the internet" that Bob Dole invented? Diku-MUD, I'll look into that, thanks.

      Only storing the outlines of the room is something that completly passed me by. This way you could, in theory, have a room that's oddly shaped too.. at least in my theory. Which is to say.. random.

      The MUD itself is basically a large test of my oop/mod_perl/SOAP abilities through Perl. Of course.

      Thanks for the advice

      One4k4 - perlmonks@poorheart.com (www.poorheart.com)
[reply]
        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.

        ------
        We are the carpenters and bricklayers of the Information Age.

        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.

[reply]
Re: Mapping node relationships
by one4k4 (Hermit) on May 13, 2003 at 15:17 UTC 
    #!/usr/bin/perl -w

use Image::Magick;

$image=Image::Magick->new;
$image->Set(size=>'100x100');
$image->Read("xc:white");
$image->Raise('3x3');

$image->Draw(stroke=>'red',primitive=>'rectangle',points=>'20,20 25,25
+');
$image->Draw(stroke=>'red',primitive=>'rectangle',points=>'30,20 35,25
+');
$image->Draw(stroke=>'black',primitive=>'line',points=>'25,23 30,23');

binmode STDOUT;
$image->Write('gif:-');

    [download]
    A nice ImageMagick snippit demonstrated, at least to myself, that it is possible to draw via coords (points=>..), and I think I can create what I need from the tables I have currently.

    One4k4 - perlmonks@poorheart.com (www.poorheart.com)
[reply]
[d/l]
      Have you trid GraphViz? It's great for mapping relationships (example: All Roads Lead to Taco).

      MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
      I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
      ** The Third rule of perl club is a statement of fact: pod is sexy.

[reply]
[reply]

Back to Seekers of Perl Wisdom