Yeah, screenshot page stunk, but you should have seen the one on some other site, where every large view of the pages was 404. lol The *main* site for the game is down at the moment, so I couldn't link there, where I would hope they had better examples.
In any case, not sure MXP would work better than a protocol specifically meant for it, but any such protocol would still "lock" you into presumed default ideas. Maybe someone would have something *other than* inventory type things? Not sure MXP entities are entirely good enough, but yes, something *similar* would be the right idea. In the best world, I suppose you might want to send a "layout" description, rather than an "entity". The layout would provide how things get placed, along with field names, so data can be inserted where needed. Then any further data sent would reference that "layout" and tell the client what to add/remove from the subfield in that display. You don't get stuck with one size fits all displays.
Now, this **could** probably be done, with some clever manipulation of MXP entities, but its not really designed for that. You could also use the "error" traps that Mushclient has already, which I presume would carry over to the new client, to capture unrecognized tags that "did" support a <layout>some_XML</layout> type data block, then use a plugin to parse the resulting layout/fields to the client GUI. This is a more advanced handling that what I had always envisioned. My own thought had been to do something simpler, like having the user create a .frm type layout, which the plugin could parse in to generate a window, then use normal triggers to do something like capturing the "inventory" when you look at it, and parsing it to display the right icons. Clicking on food, etc., would have its behavior defined by if the event for that icon is trapped, and what the script says to do about it. The only thing that adding a "layout" tag to MXP would really do is provide an inbuilt way to generate the GUI, based on the mud developers version of what it should look like. This is a good idea, since some place like Aeonfalls could have simply designed the GUI elements, provided a plugin to handle data parsing for those elements, then changed the layouts on their end, as needed, instead of doing a client update (or forcing the users to download an upgrade). The client itself could be as generic as TinTin++, and as long as the scripting was available, GUI was available, and MXP, with the added layout functions, was available, you could make it *act* like anything from the current Mushclient to one of these custom jobs.
---
As to your map examples Shaun.. They don't even work in 2D, since they require intentional displacement, and special markers, to show them on the *same* 2D plane. Not only is it unlikely that a mapper could do that very well, it doesn't do anything for you, if you don't have an entire extra display available to put the map on. The reality of text gaming is that, if you want that kind of map, you are **not** going to be using the internal map system to do it. Heck, even the MMOs have entire printed Atlases, since the maps they provide in game are flawed when trying to do this, and that is despite attempts in EQ1 to have a way to auto generate the maps, based on where the player marked the start and end of the path they walked on. It worked, but not well. The new one in EQ2 doesn't even bother.
Fact is, for a text world, **most** maps are going to be limited to a fraction of your screen space, and even if you allow for them to pop open a much larger version, to get their bearings, you **still** can't give them a map that is good enough to cover areas past some X number of rooms from where you are.
Mind you, in your tower example, it might not be impossible to find some way to pop open that bigger map, and thus *see* all 9 levels, stacked one on the other, just like looking at the skeleton of a sky scraper. That could be practical. It might even be possible to mouseover the levels, and thus get them to show up clearer. And, as I said, one useful trick would be to have the path finding system "mark" each room between you and a destination, so you can see where you need to get to. I wish I had an easy way to show what I mean.. |
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2
3
4
5
6
7
8 9
10
11
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top