Doesn't MUSHclient have a plugin that displays a map (as either ASCII graphics or actual graphical tiles) in a separate window?

Yes, KV, that is an example of what I was referring to as a preferable solution. That said, you (the server) would not control this map using cursor control but rather some protocol cooperating with the plugin.

zMud has a marked share of over 50% compared to MC's 5-10%. It doesn't make sense to me to tell players to use a specific client when over 50% of your average player base already uses a client that support VT100.

Not to mention that any decent client should be able to capture \e7<map>\e8 and display it in a sub window, y'all aren't making too much sense.

You can do that easily with the mini windows system in Mushclient. I know Aardwolf has a mush plugin to display their ASCII map and I've seen a similar thing for the IRE games too I think. IRE also have room by room zmapper style maps that they use in their web clients which seem very popular with players. I went with a graphical map though mostly because I wanted to be different.

Yup! Shameful plug: I wrote one of them for Achaea. :cool:

Personally, I very much prefer the graphical map displays over the text-based ones, whether they're displayed in a corner with VT100 emulation or not. They just [have the potential to] look a whole lot better; see Nick Gammon's Aardwolf 'bigmap' plugin (images: [1], [2]).

Not only does a graphical map look much better, but you also have far more information bandwidth: you can use various sprites at each tile, with rotation, full color, maybe even put transparent names floating above sprites… basically, life is far, far easier when you have those tools at your disposal rather than just ASCII characters with (limited) color.

I don't see why you couldn't support both.

I do – if you're spending all this time creating very customized client interfaces, with detailed information display, you probably really don't want to duplicate that effort across clients. I suppose you could have a much simplified version for VT100-compliant clients, but those players wouldn't be getting an experience like the intended one at all.

If it's as simple as Scandum described in post #39 then the required effort would be minimal. The MUSHclient graphical interface would require more effort and look nicer, but only a minority of my players use MUSHclient.

That's for the display part. The positional calculations and updates wouldn't need to be duplicated.

cf. post 46; getting ASCII characters on the screen is not the same thing at all. The amount of information that can be displayed is so different that, depending on why you need the information, it might be far, far less valuable than the graphical display.

I'm not talking about just putting up some characters and declaring victory here. The desired interface is far less simple.

Having thought a bit more about this, it's definitely a nice idea. I already generate ASCII maps showing the position of creatures and objects, but the maps are only generated when you "look". It wouldn't be hard to automatically redraw the map as you and other creatures move around - and your proposal would allow the updated map to be redrawn over the old one.

The exact same solution (performing an automatic redraw when creatures change position) could also be used to refresh a MUSHclient graphical map. No additional data would be needed in order to produce a decent graphical representation of creatures moving around, but should I later decide to expand it it would be easy enough to send extra data, perhaps based on some sort of configurable option.

Whenever I created interfaces in my MUD with codes like these, it always reminded me of the special codes available in the on the old Amiga computers. In the case shown in the following video, an image is rendered pixel by pixel, through both the printing of characters and the movement of the cursor arbitrary numbers of pixels. Admittedly, displaying enough of an image for a mini-map is prohibitively slow, even if it were possible to do this with standard ansi codes. In this case, it takes several seconds to render a small simple image, simply through dumping all the displayed text to the console at once.



To me, making a web-page the sole client to my MUD seems more and more like the way to go. With AJAX/COMET and soon perhaps WebSockets, and real usable options like Canvas 3D (as compared to locked in offerings like VRML/X3D), it is possible to have minimaps showing real-time movement of the character through the world.

It's possible to build your own font with embedded symbols for various map features such as trees, water, walls, etc. This would give you a pseudo graphical display while still being compatible with a normal client. The disadvantage of this method is that it requires people to download and install your custom font of course.

You can certainly do some clever stuff with vt100, but these days chances are if people are reading text on a computer screen it's on the web and not in a terminal window, so I agree the web is definitely the way to go if we want broaden the appeal of MUDs. However, it should still be fairly easy to maintain compatibility with existing clients if you choose.

There's no reason why an online flash client couldn't support vt100. Soiled (a flash client) in fact claims to have VT100 support.

As a side note, a special font can be created like Medievia did to make ascii look a lot better. For example: http://www.medievia.com/fonts.html



Me and a friend worked on a MUD font a while ago but it remains fairly basic: http://tintin.sourceforge.net/download/M... here's a screenshot of it in use.



Would be cool if someone would create a free to use advanced MUD font. My MUD font treats n as bit 1, e as bit 2, s as bit 3, w as bit 4, and the resulting value between 0 and 15 is the offset used for displaying the exit. So a no exit room is character 128+0, an exit leading north 128+1, an exit leading NES is 128+7. That seems like the most sensible standard for exits to me.

Second shot looks like "high" ascii. Not a specially designed font.

http://www.webopedia.com/TERM/e/extended...

Extended ascii lacks the 4 drawing characters for rooms with only 1 exit.

Yeah, maybe you're right. HeYou guys just reinvented the wheel ;)

Just fancied it up and ordered the characters more logically. There was supposed to be more, but my font editor sucked and I think you have to make a set of drawing characters for each font size you want to support, not to mention that nobody seems to be able to get a custom font working on Linux which is 50% of the userbase. So instead I created the infamous multi-platform ascii map.

When talking about web based I don't just mean a terminal window on a web page. My point was that the average person rarely uses a terminal window so a bunch of ascii text is immediately going to look alien to them. If we want to reach out to new players and persuade them that text games have something to offer alongside graphical games we don't necessarily do it by making text games more graphical, but rather by presenting the text in an accessible and familiar way. Even something as simple as using a non fixed width font can make your game look more appealing, IMO.

I'm not knocking the vt100 stuff and I don't advocate dropping support for telnet clients in favour of a completely custom client, I just don't think that it's the best way to get new people into MUDs.

Interesting conversation. I'm currently planning a wild west mud and thought about using a coordinate system in towns etc, but switch to a more free system in the deserts and wilderness. I'm thinking the player would specify a direction in degree's, or something along those lines. Not sure how this would be specified in real life and it would have to be a system which can be picked up easily anyway.
I guess the advantages are exploration might be fun plus it helps give the impression of a vast world.