<offtopic>Never read the book, but I do <3 my Vibrams…Barefoot running is the only way to run!</offtopic>

As promised, a follow-up on the automapper subject:

While a number of advanced MUD clients support automapping, the quality of the resulting map varies greatly, the features it comes with may not necessarily fit what you want to show, and plus implementing OOB automap support doesn't really bring automapping to all players at all times.

With that in mind, I've started work on a solution that will enable all players (regardless of their client of choice) to see a real-time automap. Version 1.0 of the solution, in C/PHP/JS (AJAX) has been uploaded to the code repository (pending approval). I'd like to share some screenshots in this topic because I believe it's the first graphical automapper that supports mobile browsers (although the screenshots below are taken from Mozilla). The site scripts are very lightweight (written from scratch), and map information is transferred in JSON, but at this stage the solution can still be optimized further.

The automapper shows closed and locked exits, death traps, and rooms with exits up and down, all up to three rooms away. Users can click/tap on any room to see details of its contents. The contents 'fade' as the distance increases but this can be tweaked according to taste. The automap supports smart linking of rooms (e. g. if east-south is a different room than south-east, they are not linked, and sub-rooms appear as needed).

Just to be clear, you mean that all players can see the automap by using a browser probably separate from their MUD connection, right?

That's right. Desktop computer users can open a borderless popup and have a floating minimap next to whichever client they use. If they have a smart phone, they can tune it into the automapper. The Bedlam app has an integrated browser, so its users will have a seamless automap experience, probably with a split-screen (top vs. bottom) and a semi-transparent overlay options.

After the initial images are cached, data transfer is better than normal browsing - I can imagine it's comparable to what advanced MUD clients' automappers move because the principle is the same: new data is sent only when/if the player moves.

With a bit of additional work, the automapper can turn into a full info hub, showing health bars, visualizing surrounding mobiles, etc, for my non-mobile players. It would be a kind of universal hub that requires no installation and can sit next to their main client. It won't ever be as responsive as a Java client with an integrated hub, but it has its advantages.

Does it use GMCP, or something custom? From what you've told I assume the user points the browser to a different port, where a matching IP for a character is found and JSON data is transmitted?

The way Achaea handles this over GMCP is by sending all the room data whenever you change rooms, which is quite wasteful. A more efficient method would be to only report room changes, with an option for the client to request all available data for a given room or area.

From looking at your map an obvious improvement would be to use colors based on the terrain type of the rooms. I like the way you're shrinking overlapping rooms, it's really quite clever.

I get the data out of the MUD (and out of C's outdated string manipulation funcs) as quickly as possible, then JSONify it a bit in the php script. If you already have a protocol in the server that sends this info OOB, you could just cc it to the php script and adjust the parsing accordingly.

For my solution, I have a separate login to enter the automapper, which means this doesn't have to be on the same machine or same IP as the main client. Separate authentication is a bit of a hassle for telnet users (app users will auto-authenticate) but the advantage is you can actually tune into and follow another player if they share their password.



I can understand why they'd leave it at that. To report only changes, the server has to keep track of the previous reported state for each user. In the case of three rooms away, the number of rooms to remember the state of can sometimes exceed 100. I'm also showing the contents of adjacent rooms–that's even more data. And then, to take full advantage of this approach, the renderer would have to get a whole lot smarter because it won't have all the data to draw the frame from scratch.

I'm not going to attempt this kind of optimization unless I hear from a number of users concerned about bandwidth. In the case of the app, I don't think people will be running around with an automapper on all the time due to lack of screen space. And of course desktop users are far less likely to care about total data transfer. Overall, my bet is that if the feature is sleek enough, people are more likely to ignore or accept any higher connection cost it involves.



Sector types are a mess on my mud so I didn't add them to begin with. But maybe now's a good time to clean them up. See the updated screenshots above. New version will be uploaded to repo in a day or two.

The thing about room changes is that all data points are relatively likely to change when you change rooms, unless the rooms are all very similar in the first place. But note that if you only want to track changes, you don't need to care about how many rooms were previously visited; as long as you update the current state of the world that the client sees (the agglomeration of all rooms visited so far) you need simply compare the new room to that and send changes. So you don't need to remember 100 rooms to only send changes – you need only remember one "room" (really a combination of data points) and update it appropriately.

I don't think we're talking about the same thing. Easiest for the MUD would be to set a time stamp whenever a room is modified. When a player enters a room the mud would send the vnum and timestamp, then the client could check if the time stamp matches, and if not request the full room info.

Besides saving bandwidth, another advantage of being able to request data is that a client can check if a room's exits have already been mapped, and if not go ahead and request the data so it explores slightly ahead of the player and removing the need to venture into one exit rooms just to map it.

Regarding sending a 7x7 grid all at once, this shouldn't be a big problem if the client stores the data locally, in which case the client simply request all unresolved exits in a 3 room radius.

A mud data cacheing scheme is much simpler than that. IMHO, it likely exceeds the both bandwidth and processing requirements of MCCP.
I include it in MUDP.

I'm not sure I follow some of the current discussion and I think it's because the automapper solution I'm working on is a lot more "subjective" than other approaches to the problem. The room-scanning func needs to visit every room up to 3 rooms away to determine what the player can see of it. If the player doesn't have infravision, his/her world shrinks. If the player doesn't have a light source, some rooms may appear as dark. If the current state of a door is closed or locked, then the scanner doesn't show anything beyond that. It is also able to show mobiles/players/objects up to 3 rooms away but only if the player is currently able to see each of these entities. So even if the client knew how to draw the map with such and such room at the center, I would still want to re-scan to get the latest (and individualized) state of that viewpoint.

Client-side caching can still help, but for that to translate into bandwidth savings, the server needs to send only the differences from the previous state. So then we'd have to cache on both sides, plus make the renderer x10 smarter. My head hurts.

Some of the discussion I think assumes that the server pre-formats the information into a flat visual representation. I think this is true for most automappers out there, but not mine. At this point, the scanner func is completely agnostic about how the information is going to be displayed. It's not sending a 7 x 7 grid but a flattened associative array with each element labeled "sw", "nnw", etc. Interpretation of the information happens entirely on the client side, mostly because JS is much faster for me when it comes to string processing.

As far as optimization options for this specific automapper, one thing I can do is to assign a number to each unique room name and send over a translation. This can be done per frame or for the entire world (this may backfire if the typical automapper session is short). One could apply the same logic to any visible mobiles and objects for some more savings.

Could you link the protocol definition? It's hard to beat zlib which typically reaches 80-90% compression rates on MUDs, I'm very certain zlib uses a combination of both compression and caching.



Just MCCP should suffice, especially if you send the data in such a way that it's as identical to previous send data as possible so zlib can easily cache it.

I hadn't even thought of compressing the JSON stream until zlib was mentioned. Apparently, it's not only possible, but super-PHP-easy:

header('Content-Encoding: gzip;Content-Type: text/plain');
echo gzencode('rooms = '.json_encode($r));

And now we're transferring bytes instead of kilobytes…

Thanks, guys!

MCCP? What a great suggestion - I'm surprised nobody mentioned it before!

Wow, it's a good thing we're now talking about browser streams and not MUD client streams!

Still no real projects to work I see, Haley?

Glad to see that personal insults are still your modus operandi, KaVir. :smile:
By the way, I thought that you established in post #38 some interesting points about relevant, related experience – but maybe only you get to use that wiggle room?

I think it's been well established for a long time now that your "relevant, related experience" only applies to trolling, disrupting discussions, and driving away quality posters (yes, I actually get people emailing me asking if I can suggest somewhere where you don't post). Whether that relates to your nickname or not, I can only speculate, but just imagine what you could have achieved if you'd spent even a fraction of the time you spend spewing your drivel actually working on a real project!

I'm sure there are many good reasons to use MCCP when you're working on a client written in a supported language and compiled as a standalone app.

Given that my renderer is (any) browser, JSON is more better. It comes with a 1-line encoder in PHP, and a 1-line direct assignment of the incoming data to a JS object (doesn't get any easier than that). JSON + gzip is I imagine comparable to MCCP + zlib.

In fact, given that there are JSON APIs for C/C++, I would seriously consider it on par with MCCP and other OOB protocols even if I was developing a compiled MUD client. Going with JSON (apparently GMCP is very close to it if not a sub-protocol of it) means that your server can cc the same info to a web-based app if you want to, e. g. conquer Facebook one fine day :)

KaVir: I'm pretty happy with how my "real project(s)" have been coming along, but thank you for the concern. Fortunately, I'm secure enough to not have a hissy fit or lose sleep over your repeated insults and put-downs, but I will freely confess that I'm rather unsure of what you're trying to achieve here. Whatever it is, it feels rather mean-spirited and ugly, and unnecessary, like your sarcastic reply regrading MCCP. Oh well. :sad:


MCCP isn't really an OOB protocol; it's a protocol to compress the stream between a MUD server and a MUD client (although typically only in the server–>client direction). OOB protocols are generally used to send additional information, whereas MCCP compresses the information sent. They aren't necessarily incompatible.


ATCP2 (aka GMCP) is a mish-mash of a data transport protocol (using JSON, more or less – it's actually not exactly JSON!) and semantics. I guess you can think of it as something that uses near-JSON to transmit data, and gives additional information regarding what the data transmitted means. JSON doesn't care what you send; it only specifies the format.

I see. So a more accurate way of describing MCCP would be as a zlib implementation for MUD server/client that carries some MUD-specific meta-data with it?

Hmm, if ATCP2/GMCP is near-JSON, one can't really use it for a web-based renderer. But if it's already implemented on the server, it may be relatively straightforward to cc the data in strict JSON. Not my problem since I found my server in a literally "dark ages" state and am now having to code every bell and every whistle.