I'm with Runter here. That the client is the same as the user is especially true for JavaScript running in your browser. If you don't want the user to have access to certain location info, just don't send it.

As for favoring tech-minded people, this client in the cloud will be able to combat this fact better than others before it. If someone techy maps their favorite game, others will gain access to that world file automatically. I picture a simple wiki model for collaborating on the map (with revisions kept automatically) as well as giving people the ability to overlay their own custom notes, or clone off the world file completely.

Rarva, I think I know what you're getting at and the solution I believe is for the game to send info on what exactly it wants the map view to render at any given location for any given player. This is what I do currently for the old web app and the iOS app, except the renderer is not nearly as powerful or sleek. The big advantage to this approach is that you can render subjective views, not just fog-of-war, but really, anything you may want to vary based on a character's current state. Since the server is in full control, it is easier to push overlay data like players or mobs passing nearby. And since you're sending only display info, you're not divulging anything you don't want players to know. I am pretty sure this mode will be supported by code I write (as opposed to people having to add code later). One, it's pretty straightforward to make the renderer "dumb". Two, there are quite a few games with server-side automappers that can be leveraged fairly easily to drive this mode. Three, I may use it myself for the mobile app.

There will also be an option to upload a world file in JSON format that the mapper will interpret. I want to do a little better than Mudlet in this respect by not requiring this file to contain any room coordinate data, something that most MUDs would have great difficulty providing.



I've also heard that Mudlet's new automapper can scan room descriptions and contents to automatically check for room uniqueness. All that's doable, just tricky. At some point, there's gotta be some kind of freeform edit mode where players can just move rooms around to get the best result.

My sense is that I'll focus first on getting this out to games that do want their players to get around more easily, then worry about empowering geeky players on games that put up a fight.



Does your game already send location data via msdp in a fairly standard format? If so, maybe I should use it as a model. I'm almost ready to start alpha testing with different games.

That's the approach I use as well. As GW2 doesn't have rooms, regular automappers wouldn't be much use.


I've seen other automappers use the same approach, but it's not foolproof. I wouldn't personally consider it a priority if I were in your shoes - better to focus on features for those who want to make MudPortal look good for their games than workarounds for those who don't.

I know you're only listing the "most frequently supported" ones, but I'd just like to say that XTerm mouse tracking is of great utility on top of these.

I perfectly agree, never trust the client is a basic security measure. I think I just supposed for some reason that the final map would never be sent to the client, but would stay on Plamzi server and all calculation done on it before being sent to the plugin.
On second thought, I do not understand why I supposed it was done this way per default.

Still have question for the plugin though, can you specify the size of link ? Or is it purely automatic ?

I could send the msdp info in the they way you like it best pretty quick. Just create a basic 'format'
lsomething like this
room name
room vnum
room desc
exit up
link lenght up
exit down
link length down
exit north
…etc

I think I already provide some info about room but not link length as I had no use for it.

Indeed I do

if (pRoom && pRoom->vnum != (unsigned int)d->pProtocol->pVariables[eMSDP_ROOM_VNUM]->ValueInt) {
                unsigned char door; /* Loop counter */

                strcpy(buf, "\003"); /* MSDP_TABLE_OPEN */

                for (door = DIR_NORTH;door < MAX_DIR; ++door) {
                    if (pRoom->exit[door] != NULL) {
                        const char MsdpVar[] = {(char)MSDP_VAR, '\0'};
                        const char MsdpVal[] = {(char)MSDP_VAL, '\0'};

                        strcat(buf, MsdpVar);
                        strcat(buf, dir_name[door]);
                        strcat(buf, MsdpVal);

                        if (IS_SET(pRoom->exit[door]->exit_info, EX_CLOSED))
                            strcat(buf, "C");
                        else /* The exit is open */
                            strcat(buf, "O");}
                }

                if (pRoom->area != NULL)
                    MSDPSetString(d, eMSDP_AREA_NAME, pRoom->area->name);

                MSDPSetString(d, eMSDP_ROOM_NAME, pRoom->name);
                MSDPSetString(d, eMSDP_ROOM_EXITS, buf);
                MSDPSetNumber(d, eMSDP_ROOM_VNUM, pRoom->vnum);
            }

I have a problem with sending all the map the player can view at all time though, it can be pretty big.
I support a 'minimap' that I think is what you mean (player can see up to 3 room around him (provided he visited them)

but if he types map, he can see all the map he knows that is on the same level.
I can send it once, and only update it if a new room is visited though, but that means the plugin have a way to store that?

This may be part of a larger conversation about resolving the many kinds of non-Euclidean conflicts. The short answer is that I can definitely let the server specify link lengths, but that I'd rather not have this as the only way to generate the map, since I suspect that for many devs link lengths would be as difficult to provide as it would be to ask for x, y, z coordinates. Maybe I'm misunderstanding this but are you saying that your game already has "link length" ready to send out?

Right now, the mapper is trying to resolve some simple overlaps automatically. After that, it lets the server supply some form of "inside vs. outside" flag or meta data field. It uses the "inside" flag to increase density and it will, at some point soon, also use it to decide smartly when not to draw certain parts of the map.

I experimented with auto-extending link lengths to avoid overlaps but the results can be very poor when applied automatically to huge maps, and I'd rather not make users think about those things. I think the "inside vs. outside" approach is very simple for server devs (I suspect many world already have sector types and indoor flags, etc.) and can ultimately produce better results. For example, if you have a city and many houses inside that city, the city street rooms may be enclosing a number of rooms inside a house. Now, even if said house is not a different area, it can be flagged as "inside". If it's only a few rooms, they will fit nicely between the "outside" links framing them. If it's huge, the mapper will detect overlaps and suspend drawing the house until a player actually enters (or maybe when they get near, mimicking a "line of sight" experience).

At least, that's the idea. From what I've tried so far, things look nice, without information overload. And the map remains dense so people can still see (and soon click) pretty far.



Not the whole world every time, of course. If you're serving display info, like e. g. those old-school real-time ascii maps, you'll be sending the immediate surroundings when/if they change. The mapper is not going to need to store anything that lies outside the visible range because when the player changes locations, the server will send the new view.

In this mode, the awesome power that is d3 can really help optimize things. For a new frame, you can choose to send only the data points that have changed. For instance, if a player or mob is passing by, you know not to re-send terrain info. But even if you do send all the display info every time you want to change the view, d3 will automatically skip over data points that haven't changed since the previous frame and achieve the best possible rendering speed on the client side.

Why?

Nope, those has to be manually entered. But could it not be an option that if present have the rendererer use it instead of trying to calculate it? (or use a forced 1 length per default if the map send: do not auto calculate link length ?)



It was definitely looking for something optional. My minimap (ascii) is dynamically created, but I have mapped the whole mud in zmud, and I know some minimaps definitely look awful because of numerous magical mazes or stretched secret passages, non logical exit etx, though I have made those maps look quite fine when manually reordered (like how the builder created them to begin with)

If my memory is right zmud use a very simple database to store the info, so I could extract the info quite fast as well.



How I see map in my game has nothing to do with line of sight. (that I can deal with my dynamically generated minimap that I could very quickly add in whatever format you would decide on) It is basically like a magical parchment that draws a map of every room you visited. So once you have been somewhere, you can just click on it and walk to it, wherever you are in the world. You can also share your map with friends so you get instant knowledge from someone else. It is a road map. Wont help you at all to how to avoid mobs or find keys to reach some places. Exactly like what someone would have done with a client automapper as a matter of fact.

That gives me an idea though: with two map plugins: one that is as updated eveytime the player moves, showing its 'line of sight', automatically calculated, and one that is updated only when a new room is visited. (with a still optionnal forced display format)

Well, the plugin will probably support both, but my guess is if you offer both to your players, few, if anyone, will choose the more limited option. Having both on at the same time seems redundant.

The mapper looks pretty good. I'm curious about what makes it vector based?

One would follow your position, one would stay static so you have a better view of an area (and can navigate in it independently of your position). Not the same goal. Difference is also in limiting the info you send.
You can send the full explored map only once at boot, and only update it if a new room is explored, and the minimap is send everytime the player moves.

But maybe you can combine the two thing with the plugin, I would need to know exactly what it can do to know if what I say makes sense :)

The SVG. Powered by d3.



The big map can move with your position as well as let you navigate it independently. It can be limited to render a smaller window, which effectively makes it a minimap. I'll let people preview how it works soon.



There's no need to send the fully explored map on every boot. You can upload an initial file, then send info on current player location only. If the room layout changes, you can send the new info when players re-enter those rooms–it will be merged into the client's flat-file world data.

If you don't upload an initial file, you can send current room + exits info as players move around. The mapper builds the world data file incrementally.

Ok, guess I will get a better understanding on how it works once you put it live. It looks very nice as is, I am just wondering how I can use it to the best for my liking.

Latest screenshot, showing zoom and a larger area with some non-Euclidean room links.

That looks really nice. Looking forward to getting going with that!

I think this is pretty impressive. Good work with that.

Thanks for the encouragement, all. It helps a lot, especially when this much math is involved :)

I'm still dealing with some performance optimizations and working on big features I want this plugin to have from the get-go. But it's now good enough for people to see it in action and play with it:

http://www.mudportal.com/play?host=mud.p...

The "dev" parameter loads the mapper. The "debug" parameter enables more logging to the console. You will be able to see a lot of what's going on under the hood.

Charting new rooms and editing existing ones is enabled via a button on the toolbar. In edit mode, you can select rooms and move them. Ctrl+click selects a whole area.

Outside of edit mode, clicking on nearby rooms will move you there. Clicking on more remote rooms may fail silently (for now).

I'm disabling the save option for now until I get a basic system up for map data locking / sharing / cloning.

This is still alpha, so if your browser hangs, it's probably me. Open your Task Manager beforehand so you can kill me more easily. :)

Now (at last) in Open Beta!

How to get started:
http://www.mudportal.com/forum/site-app-...

Preview of the edit / data upload menu:

Do you have any RSS feeds I could use (like for new MUDs listed)?

I'd like to add the feed to https://twitter.com/MUD_news

There's a pretty lean feed for new forum topics:

http://www.mudportal.com/forum/topics/mo...

Thanks for the add!

If your MUD is on the I3 network, Tricky has a few bots that post mud/sports/news/etc news to a particular channel, which you could easily use as well.

My log page *could* provide this, but it would be more efficient to do it from the channel logs directly, and also more reliable since mine is just on my home network (very little upstream bandwidth).