[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 . 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]

You might want to check out - in particular, look at the screenshots of their (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!



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: and medievia has some interesting screenshots as well not sure if there are other muds out there with cool fonts.

There's a list of clients and what they support here:

[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]

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]

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.

[KaVir]

Sorry to necro an old thread, but I've now done exactly what was discussed earlier in this thread, and thought it might be of interest to other mud owners. This is a simplified version of what I did.

First, I added support for to my mud, and downloaded the latest version of MUSHclient (as it supports open protocols). I then created a simple MSDP plugin, allowing me to transmit out-of-band data between the server and client. You could also do this with ZMP, ATCP/2 or Aardwolf's 102 protocol, but I chose MSDP.

Next, I obtained the images I needed. Two of them came from my website (a title bar for the left side of the screen, and a textured tile to use for the background). The other two were generated by the mud from internal data - a 20480x20 tiles.bmp for the overview map (1024 tiles side by side, each 20x20 pixels) and a 2560x20 terrains.bmp for the zoomed map (128 terrain types side by side, once again each 20x20 pixels). MUSHclient allows you to easily extract parts of an image, which means you don't need thousands of individual tile and terrain files - I simply pass the client a series of tile/terrain index values which it uses as an offset of the appropriate bmp file.

Finally I had a play with MUSHclient, learning how to display graphics using plugins - fortunately it's fairly straightforward, the documentation is very good, and Nick Gammon is always quick to answer questions and provide working examples. I reduced the size of the text window, drew miniwindows below it for energy bars, and to the side for maps and combat information, as follows:



The player has to update to the latest version of MUSHclient, then download the graphics and install my plugin. Fortunately I can see which client version they're using from within the mud, and also detect whether they've activated the plugin, which makes troubleshooting a bit easier. The plugin is still a work in progress, but even in its unfinished state it's proving .

I've also had a bit of a play with Mudlet, which should be able to do the same thing, although it doesn't support MSDP, ZMP or open protocols - so you'd need to use ATCP or 102. It also doesn't allow you to extract parts of an image, which means each tile/terrain will need to be loaded as an individual image - I'm not sure what sort of impact that'll have on performance.

John from WGF is also working on a which may be able to support maps done this way, so that'll be worth keeping an eye on as well.

[Ide]

I can attest that when you play GW2 with the plugin in fullscreen MUSHclient, it's quite good. Very close to a custom-looking client.

[silvarilon]

I am so totally impressed

[KaVir]

Thanks - my plugin is open source, so if anyone is interested in doing something similar you could copy it and modify it to suit your tastes, or just use it as a guideline or reference.

One of my players has created his own plugin, for example, which includes a portrait (changes based on which character he's playing) and buttons. He uses smaller maps than me, and has created some custom images for creatures and buildings:

056af1edd9.jpg(click to enlarge)

This approach gives you a degree of flexibility that you wouldn't normally find in a custom client - I offer players a default interface, but they can customise it as much as they like, or even create their own from scratch. It also saves you a huge amount of work, as creating a feature-rich client is no small feat.

Several muds and codebases already support , which uses the same data format as MSDP. If your mud has MSSP then you could copy that to create a basic implementation of the MSDP protocol with very little effort. You could have an interface like this for your own mud with only a few hours of work.

[silvarilon]

Most of our players use a browser interface. They're used to just going to a webpage and getting a pop-up window, so convincing them to download a client may be tricky (at least until they're comfortable with the game)

How hard would it be to adapt a browser client to have similar functionality? I'm less concerned about players being able to customize the browser client (if they are interested in that, they'll be willing to download)

Apologies for being ignorant on this, I don't have direct access to my games codebase, just a sandboxed programming environment - so it's a bit of a black box to me.

Cheers,
Tony

[KaVir]

Agreed, I think providing a browser client for newbies is the ideal solution - this is more for established players really.

It would depend entirely on the client. What I'm showcasing here is really the power and flexibility of MUSHclient - if you want to do the same in another client (browser or otherwise), it would need to support the same sort of functionality.

I know the Maiden Desmodus browser client has a map and energy bars, but the public version of the same client (FMud) doesn't. The browser-based client I linked to earlier looks very promising in that regard, but it's not yet finished.

That may be a problem then - are you able to implement new protocols?

[Orrin]

I get asked fairly often about energy bars and other stuff in FMud, but the main problem is that there is no standard protocol for exchanging this kind of data between clients and servers. There's already MXP, ZMP, ATCP, MSDP etc., so I was waiting to see what happened with mudstandards.org before implementing anything in FMud. However, given that not much seems to be happening there it may be better to just pick one and go with it. The wgfriends browser client you mentioned is going to face the same problem of course.

[KaVir]

But you already do this in Maiden Desmodus - what do you use there? If other muds really want those energy bars, they will add support for whatever protocol you choose to support.

Honestly, yes, I would just do that. Here are my personal thoughts on the different options:

MXP: I would tend to avoid MXP for transmiting out-of-band data (I think only CMUD supports that so far, and I don't know of any muds that use it), and you don't want to send this sort of data in-band. MXP is also the least trivial of these protocols to add to a mud.

ZMP: I don't think any clients support this natively, and half the specification seems to have vanished (as dead links) along with its author. The use of NUL bytes can also make this a bit tricky to implement.

102: The unnamed protocol, currently used only by Aardwolf - and from my understanding they're planning to move to ATCP2 in the future anyway. It is, however, natively supported by MUSHclient and Mudlet. The data is sent as Lua code, which may not be so convenient for you.

ATCP: The IRE protocol, it's supported by their muds and at least one other (the German Avalon), and also seems to be the most popular choice among client developers. However it's already being phased out to make way for ATCP2/GMCP, and the specification seems to be following their implementation rather than the other way around.

MSDP: Used by over a quarter of my players, but not supported by any other muds at this time, nor natively by any clients (although you can add it to at least MUSHclient, zMUD, CMUD and TinTin++). IMO it's the simplest to implement, being very similar to MSSP (which is already supported by a couple of dozen muds).

They're currently going with ATCP. I would speculate that if/when ATCP2 is finalised, they'd probably switch over.

[Orrin]

I use my own protocol, although it's similar to ATCP or MSDP in that it's just text inside a telnet subnegotiaition. I was hoping that a more generic standard protocol would emerge rather than me introducing yet another custom protocol with a very narrow use.

I would probably go with ATCP as that has good support in other clients and MSDP seems just a little too generic as is. Taking energy bars as an example, using ATCP you already have the char.vitals module which follows the pattern name:current/max name:current/max etc. which is super easy to parse into graphical bars on the client regardless of how many different stats the MUD uses or what they are called.

[KaVir]

Using an existing protocol would be preferable I think.

MSDP is really aimed more at script/plugin writers. The nice thing about it is that it lets them request the exact data they want - so the protocol can support a wide range of obscure and unusual variables, without bombarding players with lots of data they don't want.

If you plan to have a standard interface, like silvarilon mentioned, then ATCP is fine. But if you want the interface to be customisable (either manually by the player, or remotely by whichever mud you connect to), then I would suggest either MSDP or a custom ATCP module.

True, although it does mean resending the entire sequence every time any of the stats change. The advantage of MSDP is that it only sends the variables that change, and only the ones you care about - and variable/value pairs are pretty easy to parse as well.

I guess a mud could allow the players to customise their char.vitals in-game though, which would allow some degree of on-the-fly interface customisation.

[shadowfyr]

They have entire OSes, like EyeOS, as web apps, so.. probably. Development of the client would be a nightmare though, for one. Second issue is, I can't even get something like EyeOS to install on my provider for my web page, due to them using PHP4.3, while the "base" version it needs is PHP5.0. This is both an issue of features, and speed. Prior to 5.0, things like Javascript where actually "faster" than PHP. The same would be true of a mud client run via the same sort of setup.