Nick Gammon said:
For example, you asked why I didn't use ZMP - well I might ask "why doesn't anyone use it?".
This is a very good question. I think that it comes down to two main points:
- Elanthis couldn't push the protocol as a de facto matter because he doesn't write a popular client. MXP for instance gained some traction simply because zMUD and then MUSHclient supported it -- and I would imagine that you implemented it because Zugg was implementing it, and it made sense to do so for that reason.
- Elanthis wasn't willing to evangelize to client authors to convince them to implement it.
Now for what it's worth I don't view ZMP as inherently superior, and this Lua protocol has a very marked advantage of being able to send structured data. (ZMP is "flat" only; you have lists of parameters but you can't pass a table or list as a parameter.)
I wouldn't say that years went into ZMP itself, mainly because Elanthis didn't really push it beyond the initial concept. It came up again recently on MudBytes as a protocol, but it's hard for a bunch of server authors to work on something without client cooperation (and a lot of people don't really know how to write stuff for clients). And indeed until miniwindows, it was hard to find clients that supported subwindows in the first place.
Nick Gammon said:
I am hoping that the end product here will, at the very least, be enough knowledge for me to put forwards a design proposal that is not just theory, but demonstrably works in showing something like:
<stats, etc.>
I find that the really hard part comes when trying to generalize this. It's "relatively easy", from a protocol's standpoint, to design something for a particular MUD. The semantics are clear: you don't have to worry that everybody means something similar when they speak of a group of players, or mobs in a room, or even what a room is in the first place! But anyhow, the work here is mainly in getting the client to display this information; it's not easy to do that, especially if you don't have the power of miniwindows backing you up.
I think that it is, honestly, somewhat hopeless to try to create a definition of semantics that covers every MUD out there. You run into serious trouble even with relatively obvious differences like room-based vs. coordinate-based.
The advantage to communicating presentation is that the MUD can simply decide what an appropriate interface is. The disadvantages are pretty obvious too and we've discussed them before.
It might come down to having packages of sorts for various kinds of MUDs. Or, mixing presentation and data. You can communicate half-data/half-presentation fairly easily kind of like HTML: you send structured data, calling things tables, rows and columns in tables, etc., and tagging them with what kind of table/row/column they are. The client can then present this stuff how they feel like.
Contrast the above with some very generic "this is inventory: obj1, obj2, obj3".
I think that the bulk of the work here is in identifying interface concepts (gauges, tables, maps, etc.) and then figuring out what typical mappings are. You can perhaps give presentation hints, so that a client that implements basic GUI elements can still present stuff, while a client that wants to do something special can do whatever it feels like.
Even though it's difficult to ontologize all possible MUD data, in the end of the day there aren't that many ways to actually structure things. You have primitives, lists, maps, graphs. So a protocol that purports to address this general problem should let you structure data in this way, while preventing namespace collision. Then if people want to do things differently, that's fine. |
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2
3
4
5
6
7
8
9
10 11
12
13
14
15
16
17
18
19
20
21
22
23
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top