MMapper as a Service

[nschimme]

@waba4mume has been playing around with the idea of having a web-based mapper in https://github.com/waba4mume/play-mume/tree/mapper. I agree that this seems to be the best way to get additional users but perhaps we should think about it from a service perspective. What if we could do the MUME what Google Maps did to Earth?

I propose that we instead simplify the mapper client to just poll metadata like the current location and surrounding rooms from a MMapper server. This unlocks an possible future bonus of built in Group Manager support, per-character memory of doors, and a centralized map that is updated by a group of core cartographers.

An alternative idea to having a web client is also a mobile native client. However, given how keyboard-centric MUDs are I never truly see tablets or cell phones being truly MUME-capable devices. As such, web is probably still the best way to move forward.

[waba4mume]

A few comments:

• Rendering pre-digested surroundings information would certainly help any web-based mapper performance issue one might encounter (not that anybody verified that yet...).
• Security: Given the horror in mm2's source code, I'd be very cautious about running a public service based on that code.
• Be careful with further development of Group Manager: as awesome as it probably is for XP, it is illegal in PK situations as already noted in mm2 and for some smobs as per "RULES ABUSE" § 4. And I doubt most players bother to turn it off when they ought to. I should probably implement it in MUME instead.
• Per-character door memory: Yes! Although in my plans of MUME-side support for that, I have it per-account. I think people will just bypass such a limitation if they have to relearn all doors for every character. Related: I'd very much prefer if the maps distributed with mm2 didn't include secrets, see File > Export base map. New players need something left to explore...
• Centralized map: Is that collaborative editing or just centralized distribution?
• Mobile MUDding: What would be the added value of a native mobile client vs. web? Players need to be connected when playing anyway, and we can store settings etc. in the browser. If I had the time for this, I'd redesign the web UI and try creative CSS media selectors to display common commands over the text like the defunct Blowtorch did. It could be enough for a quick MUME fix while on the go (chat, mild XP).

[teoli2003]

Beside the sheer size (and complexity) of such a project (I'm afraid of any side project that cannot be broken in pieces of about 40 hours of work max), a few comments:

"a centralized map that is updated by a group of core cartographers." Working on a project with a large contributor base (~1000 unique contributors/month), this open the can of worms of the contribution process and the governance problem (who can edit the centralized map, do we want a review mechanism?, one or several maps managed by teams, …). Also more and more projects tend not to build contribution mechanism themselves (it is a huge amount of work) but tend to rely on 3rd-party (wiki for publish-without-formal-review, or github for review-before-publish). The publish-without-formal-review paradigm seems difficult (I for sure wouldn't people to touch my map without me approving the changes) and the review-before-publish doesn't scale to frequent small changes (like I expect for a map).

"Group Manager"…"it is illegal in PK situations" Also I would like to stress the point of @waba4mume about rules abuse. I would like to keep MMapper2 safe: If you don't activate the group manager, you are always following the rules. I even would like to see it outside MMapper2, as an add-on or as an extension of the MUME protocol (with MUME enforcing the rule about 'you are in a PK situation').

I think 'MMapper as a service' is a solution; we should clearly identify the use cases we want to improve there, so that we can compare this with alternative solutions.

[nschimme]

Good points from both of you. Let's simplify the scope then to get a working minimum viable product!

MMapper, in my experience, has three primary users/uses ordered by popularity:

1. Online Players who wish to role play and/or PK
2. Cartographers who wish to organize the world
3. Offline Players who wish to explore risk-free

I propose we eliminate Offline Players right off the bat because this feature doesn't require a hosted service. Additionally, let's eliminate the Cartographer users from the first iteration because this is a significantly smaller portion of the entire MUME community. As such, we will focus primarily on Online Players and try to build a minimalistic web-based mapper and client for newbies to play on.

---

Other points:

• Rendering pre-digested surroundings is something that I have successfully prototyped using web sockets that serialized the current OpenGL viewport as a PNG to the browser. This clearly wouldn't scale but with a tiling approach should be doable.

• I thought about this some more and I figured that the simplest way to build a centralized map would be the server only allows 1 map. Long term (not in the first iteration) we can think about having maps be skinned or introduce different ways or organizing the same map with infomarks, placement, etc.

• Security is something that we can address by reducing scope and eliminating cartographers from the first iteration. This makes web clients read-only and we package the map along with the server.

• I agree with @waba4mume that Group Manager is something that should slowly be moved over to the server side. I am thinking that making group management easy and centralized would incentivize people to not cheat (think Netflix and piracy). This also gives us more fine grained control over it and PK.

• Per-character door memory can be account based. I thought about how we should manage security and figured since MMapper as a Service would simply use MUME identities as a way to figure this out. We can grab this metadata from the character on the first info account list or have MUME pass it to us through some special XML field on log in.

[nschimme]

I'm going to take a look at how I can render a MMapper map into tiles similar to this guy using z/x/y coordinates to identify each tile. I'll be able to then emit the current z/x/y position of a MUME character over Web Socket to an HTML5 browser which needs to then select which z/x/y corresponding tile to display in its <canvas> tag. I already have some basic Web Socket and client code here: https://github.com/nschimme/MMapper/tree/client2

P.S. I have some concerns about the latency of being able to move around this map but we'll tackle that at one step at a time.

[nschimme]

I managed to resurrect my old code and get it playing alongside the Javascript mud client. Performance sucks because its literally serializing the entire OpenGL viewport each time. I haven't had a chance to break everything into tiles yet. Will update once again when I make more progress.

[nschimme]

I've been thinking about this some more and discovered Leaflet which is used by the OpenStreetMaps project. There has even been some work on using it in a real-time fashion which could be close to the behavior that we want.

I imagine what we'll want to do first is then export a MMapper2 map as OpenStreetMap tiles. Secret rooms could be handled as separate layers that are only displayed as needed but that's probably much further down the road.

It also looks like they have a lot of plugins to draw from!

[nschimme]

This is necessary anymore now that Waba has made his mapper public