[Fiz]

I'm with a MUD which was designed with an integrated graphical map system (i.e., imps add area images to the map when designing their realms, and they are exposed on player's own maps as they player explores those areas).

What we've never had is an instant-update client interface, although the MUD-side support for that is nearly finished. On the verge of writing a custom client for this, I have to wonder if some existing client (or a protocol standard like MXP or whatnot) might already exist, which we can just use or be sure to be compatible with.

Here's what we have so far... if anyone knows of an existing client which (could be extended so that it) supports this sort of thing, that would be greatly appreciated. Failing that, we'll just write our own client I suppose.

Each room has an associated map fragment, which is a collection of resolution-independent, scalable vector components like lines, polygons, arcs, boxes, text, etc., and possibly bitmap images. These are located at a certain absolute position on a "page" of the map book. A page is usually a realm or part of a realm, which is assigned to the imp to draw however he/she likes. Each room has a unique RoomID which the client and MUD can use to refer to it. This RoomID is opaque so a client can't trivially just guess all the IDs and download a complete map.

The player can turn on or off the feature of having the client's map follow them around the MUD. The MUD sends a special escape sequence to the client indicating whether the MUD believes this feature is being turned on or off (so the MUD could turn it on or off for the player).

If on, whenever the player enters a room, the MUD sends an escape sequence including the RoomID. The client can then highlight the current room on the map somehow (flipping to the page that room is on, too, of course). If the client doesn't yet have the image fragment for that RoomID, it can arrange to fetch it from the MUD system. Currently this is done by opening (and keeping open if desired) a separate TCP connection to the MUD specifically designed for data transfer operations like this, keeping that isolated from the game playing engine. I suppose it could be folded into the game system using special command tags if clients can't easily support the idea of a data stream socket in addition to the game service one.

The client can check periodically if a map image has been updated, but otherwise can just keep using its cached image to display or print the map as the user has it so far.

Pages may also have a "background image" of the same elements already described, which is always drawn on that page, and the room images overlay that as they are added to the map.

So... what do you think? Keep going with a custom client design, or is this something an existing client can already be extended to do?

Thanks!
--Fiz

[Milawe]

Check with Archons of Avenshar. Their admin, Darsh, has done insane things with his graphical map. While he may not have anything that's open sourced, he might be able to either license something or at least point you in the right direction. If nothing else, you might want to log on and poke around to see what he's done. It's pretty inspiring.

Hope that helps!

[Fiz]

That looks pretty cool. I was hoping to do this in a regular client, but I have to admit the flash client looks well done from what I saw there. Or maybe I'm thinking too old-school to still want a compiled client or telnet or whatever instead of a web app... hm...

[KaVir]

Originally Posted by Fiz So... what do you think? Keep going with a custom client design, or is this something an existing client can already be extended to do?

You might want to check out MUSHclient - in particular, look at the screenshots of their graphical map plugin (particularly the ones on the second page). You can of course modify the plugin (or create your own), but the existing one should give you a good place to start.

[Hephos]

Check out ScapeFX!

ScapeFX Mud Client

With ScapeFX it is easy to add your own plugins and you get a well tested and functional client codebase to work with when building your own custom client. No need to implement all the standard features since they are already there.

I've also implemented graphical maps in the past and if you are interested just drop me a line. Perhaps we can build a sample plugin for the wiki that does what you want.

[scandum]

One option is using a VT100 map as is common on Emlen Muds, in combination with a custom font, like Medievia's.

VT100 support works with telnet, putty, zmud, and wintin++/tintin++ which should cover over 50% of the mudders out there and all platforms. The VT100 codes are described in man console_codes, you typically set a scrolling region, using \e[11;24r which would split a 24 row screen into a 10 row static upper part (row 1 to 10) and a 14 row scrolling part (row 11 to 24). Then you can save the cursor using \e7, jump to the top section using \e[1;1H (first row, first column), draw the map, and return to wherever the cursor was when using \e7 by using \e8. You'd likely need to implement NAWS to get the client's screen size.

It could look somewhat like this: http://www.happypenguin.org/images/tintin.jpg and medievia has some interesting screenshots as well http://www.medievia.com/images/trellorcat.gif not sure if there are other muds out there with cool fonts.

There's a list of clients and what they support here: Comparison of MUD clients - Mudpedia

[shadowfyr]

Well, the displays in Mushclient are text because the muds that generate those maps are text. However, you can see where its drawing things onto that map, which are not text. So, in the case of that client, it could be possible to link images, or even send vector information to it, and have a plugin translate that into a map. In fact, pretty much anything you do come up with could be reverse engineered for it, and probably will be by someone, if you put it out for some other client. There are still some gaps in function between it and some high end, graphics mixed, clients, but not much of one, and unlike them, its designed to allow "any" system (well, except ones requiring text positioning, due to the complexity of how its triggers, buffers, etc. work, and no one having a clear idea, or just wanting to spend the time, to find a fix for it. The author never intended it to be anything but a scroll style client, and its been hard to convince him that it would be worth it to figure out how to handle non-linear text, which is to say, something that changes "after" it arrives and has been displayed/handled already.).

[KaVir]

Originally Posted by shadowfyr Well, the displays in Mushclient are text because the muds that generate those maps are text. However, you can see where its drawing things onto that map, which are not text.

Right, the MUSHclient images I mentioned used brushes, and as Nick Gammon said in that thread, "it would probably be better if you sat down and worked out individual images for each terrain type". The OP would obviously have to provide those images himself, but there's no reason why it couldn't do what he's asked for.

[Fiz]

Originally Posted by KaVir Right, the MUSHclient images I mentioned used brushes, and as Nick Gammon said in that thread, "it would probably be better if you sat down and worked out individual images for each terrain type". The OP would obviously have to provide those images himself, but there's no reason why it couldn't do what he's asked for.

True. And a possibility to consider while I'm thinking about the next generation of this thing. Having the option to open a text area (even a scrolling VT100 region) with a text alternative to the vector graphics would nicely complete the package and be compatible with more clients, even telnet in a pinch.