I think you might have misunderstood; the idea isn't to start messing with anything related to presentation, it's that instead of having explicit variables for hp, max hp, mana, max mana, etc., you consolidate those into a generic "status" variable, of the form:
FieldValue | <field name> | <current value> | <maximum value>

Given max health rarely changes this would force muds to pump out that stat every time - even when it isn't changed.

What format are you suggestion precisely? Something like: "STATUS" - "HEALTH" "100" "170" and "STATUS" - "MANA" "300" "430" ?

Also keep in mind that a mud that renames movement to stamina would still use the MOVEMENT variable, it's the same thing after all.

Well, it would only get sent when the health changes. But keep in mind that we're only talking about a handful of extra bytes here…

The format I'm suggesting is over ZMP. As I think I've made clear, I have no desire to even think about this done with a brand new format. :wink:

And movement and stamina are the same thing until they're not. I can easily imagine stamina being a fatigue measure, whereas movement can be how many more actions you can take this turn.

This protocol seems entirely redundant (and then badly designed on top of it)

I am seriously starting to wonder if these protocols are really the point of
the proposal of these protocols.




On some codebases it's not that rare. The one I work on can have this change based on level change,
disease, stat bonus (like a potion or curse or special item), spell, etc etc etc. If the data is to be of any use,
it would have to be updated just as frequently as the current health stat, imo.


I'd also suggest that it's hard to get excited about supporting a new thingy from someone who
has such pronounced difficulty accepting adverse opinion as valid. If changes and suggestions
to this new thingy have to go through the NONONONONONO brick wall like MSSP, and are only
accepted when Scandum is removed from the equation, then why bother?

-Crat
http://lpmuds.net

Yes, if you've implemented the Telnet NEW-ENVIRON option, then it is.

I propose we make an MSPP (Mud Server Protocol Protocol), to properly define how we should go about defining MSSP, MSDP, and whatever future MS*P protocols (excepting MSPP) are desired.

Yes, I am being sarcastic, as laid out in Paragraph 13, Subsection 4 of MSPP draft version 0.01.

Now that I've gotten that out of the way…. you do all realize that if even 10% of the effort that has been spent over this had instead been used to make a fully custom client/server library (IE: not TELNET, and maybe not even TCP), everyone could have their cake, eat it too, AND tell me to shove off with the line endings, all in one package? *grin*

Then allow the maximum to be ellided to mean "use last variable." But it's like 2-5 bytes tops for all but a handful of MUDs. Why care at all?

"OH NO MY BANDWIDTH CAP WILL BE HIT IF I SEND THAT OVER AND OVER AND THEN MY MUD WILL SHUT DOWN AND MOMMY WONT LOVE ME ANYMORE AND WILL MAKE ME MOVE OUT OF HER BASEMENT!!!!!!!!!"



Except it's not. I never said "renames it to stamina." I said "uses stamina." Which might do something completely and totally different than movement. A round timer might be used instead of movement points, and stamina may be used as a complement to health, which is pretty common in a lot of game systems. Stamina represents minor damage (wear and tear, bruises, etc.) and health represents debilitating injuries and wounds (huge gashes, broken bones, etc.). Some game systems don't use a separate mana point pool, but combine it in with stamina to represent that casting spells is physically and mentally draining rather than drawing on some other power source. Some game system use multiple mana pools, for different elements or different types of magic.

A small set of predetermined Diku-derived variables means the protocol is only inherently usable by Diku games. If that's all you want to directly support (with a "you're on your own" philosophy for other games) then at least state that in the protocol. Call it the Diku MUD Data Protocol or something. Don't try to claim that you are making a generic system when in reality you're making a system for a very specific set of games with a half-assed roll-your-own approach for others.



Then don't bother. If Scandum pushes his protocol and implements it in tintin, some MUDs will end up using it. Nobody is forcing you to do so.



I actually had such a protocol in the works, and dropped it on the grounds that it would be irrelevant because nobody is going to use it. Coming up with a new protocol is not hard, at all. Writing a library for it (if designed well) would not be hard, at all. Getting people to actually use it would be damn near impossible.

And on a side note, why in hell would you want to use something besides TCP? MMOs and other graphical games use UDP-based protocols only because they involve gameplay that requires instantaneous reaction to visual cues. Even if you had a low-latency protocol link, no MUD could be designed like that anyway because it takes far longer for the human brain to parse a single short sentence than it does to see and identify important points of interest in a picture (and its even easier when its a "moving picture"). You could slap a MUD protocol together over ENet or something but there would be almost no advantage at all and would bring a few disadvantages.

If people are interested in such a protocol, I offer five gems of insight, and it's likely the last I'll bother on the topic unless someone else actually makes a real effort to design such a protocol:

a) make it a non-binary, text-only, line-based protocol… like HTTP, SMTP, IMAP, POP, and just about every other Internet standard protocol. go a step further and mandate things like UTF-8 encoding, UTC for any timestamps, and so on. this in turn makes debugging and developing against the protocol very, very easy even without a complete client, because you can just telnet in to the server and type protocol commands (like I often do with SMTP and HTTP servers for debugging).

b) think very, very hard about contextualizing the data, instead of making just a different display-driver protocol like TELNET. you want to think about sending "a room description" instead of about sending "a line of text." this in turn requires thinking about how to easily include embedded markup in text. XML is designed for such purposes, and a strict subset of XML may be ideal here. using something else is fine, but keep parsing complexity in mind, especially if a custom parser must be written.

c) keep technological requirements low. 99.95% of MUD programmers aren't competent in C (or any other languages), 0.04% of them just _think_ they're competent C, and that last 0.01% has better things to do with their time than implement a 4,000 spec that requires multiple libraries to implement multiple sub-protocols and is filled with easy-to-get-wrong corner cases. overly complex protocols don't get used much, and the few users they have usually get it wrong.

d) extensibility is important but genericness is useless. the protocol needs to be ready to support new ideas and new features without breaking old servers and clients, but the protocol needs to define a solid set of core primitives that most (if not all) MUDs can use right out of the box. e.g. don't do what I did with ZMP.

e) get at least one featureful client and one featureful server on board to implement the drafts as you design the protocol. otherwise any and all discussion on the topic is nothing but theory and guesswork. plus its a lot easier to get people interested in adding support if there's a piece of software out there to actually talk to over the protocol.

In the end of the day, really, it's about Getting Things Done. I think Elanthis's point (e) may very well be the most important. There's no point generating a perfect protocol in a vacuum… in practice, it's likely to go unused and unnoticed, and also be not so perfect after all.

I thought the original reason graphical games used UDP was due to limitations on the number of allowed TCP connections on the server side? That may be mostly a non-issue these days.

There are a few other benefits from using UDP, provided you do your own verification of receipt…. you don't have to worry about preserving connections on "hotboot", you don't have to care about half-open connections or poor support for blocking/non-blocking, and you could extend your game to use graphics, sound, or other content without having to change the network layer at all. You could also have clients sit "connected" for months on end, since there's no actual connection to break.

I doubt any of those are enough to make anyone want to run out and make UDP-MUD, but it's not a totally absurd idea, IMO anyways. :)

It has to do with tolerance of loss. It's ok if the occasional packet gets dropped. In TCP, if something gets lost, the entire stream gets interrupted until that loss is corrected. By writing a loss-tolerant protocol on top of UDP, you can control which losses you accept and which losses you insist upon correcting.

This goes back to multiplayer games like X-Wing vs. Tie Fighter (1997), predating Everquest (1999). I'm not sure that a limit on the number of TCP connections had anything to do with it.

FWIW, I actually do think that UDP is rather inappropriate for a MUD, since the tolerance for loss is very, very low, unlike graphical games where it's ok if you occasionally lose a small position update note. You'd end up reimplementing most of TCP for your entire text stream.

Most graphical games use a number of both UDP and TCP sockets. A socket/port limitation has _nothing_ to do with it.

That's what this thread is for, expanding the variable set.

My point is that you CANNOT define a static set of variables and expect it to work. A data protocol needs to define semantics that allow automatic extension as much as possible. Otherwise you end up with a protocol locked to some predetermined set of MUDs, be it Diku or Diku + some other random bits.

MXP and the like do this in an overly complex way, by requiring all kinds of special tags defining all kinds of extra data, and then using those definitions. ZMP is simpler, but still requires data types to be defined, since I want to support a very wide range of MUD types with the least amount of code possible. MSDP could easily carve out a niche as an even simpler if less flexible protocol, but you're going to need to add a least a _little_ flexibility if you don't want to be tied to predetermined feature sets.

Let's say you define 20 possible status variables. Then clients need to add 20 sets of nearly identical code (for well written clients it would just be the MSDP interface to a generic status bar module). MUDs are still essentially locked to the 20 you define, so they can't easily experiment with new ideas or use uncommon game systems. And there's little reason, because those well written clients will alredy have that generic status module, but MSDP will fail to expose that capability. If the protocol lets status be defined by the MUD, all those problems go away, and there shouldn't be any extra coding burden on anyone; there should be less, honestly. Win-win.

The variables are not to be implemented client side. What the client does is provide the reported variables to the scripting engine, and provide the tools for the client user to construct their own interface.

The variables are merely suggestions for servers wanting to implement MSDP so it's easier for interface scripts to be shared between MUDs.

Aaah. So it's very simply a variable exposition mechanism without any form of required interpretation of the variables. That does put things into slightly better context.

In that case, yeah. Ignore everything I've said. :)

I'm not sure what it means to "implement MSDP" if everything defined by the protocol is just a collection of "[mere] suggestions". Is the protocol just a way of saying "here's a value for this name", and the only guarantee is that the client will somehow tell the scripting environment about it?

If there's no required semantics Scandum, what are the use cases for MSDP that other methods like NEW-ENVIRON do not address?

There's nothing inherently wrong with it. I had debated adding a zmp.var command for the same purposes. If you are of the mind that a MUD should just export raw data and that the client should be highly user-customizable with the UI built by the user for his specific tastes and needs, this is exactly the kind of protocol you want. Nothing wrong with that if that's your thing.

It is entirely different model to ZMP of course which assumes that the user has far better things to do with his time than script up a custom UI and that he just wants to connect and have a ready-to-go UI. No need for wasting time tweaking or scripting around a UI that the developer couldn't be bothered to do correctly from the start. Proponents of the model MSDP embodies would call ZMP's purpose very inflexible and say it takes away user choice.

There are pros and cons to both approaches. I personally would detest being limited to MSDP and I obviously prefer having a "no assembly required" game product. Some families are just different, David. ;)



The answer here is going to be same as why MSSP was needed when there was already NEW-ENVIRON. The answer isn't particularly good, though, so don't expect some keen insight… http://www.mudbytes.net/index.php?a=topi...

summary: Scandum doesn't like NUL bytes because some still-unnamed scripting language somewhere doesn't handle NULs in strings, and he apparently doesn't want to do the parsing in the host C code where the issue is completely irrelevant, so he invented a whole new protocol. Now of course anyone wanting both has to write two very similar yet incompatible sets of code to produce and consume both. Yay.

Sorry Elanthis, I think that's a different question. My point was that a protocol that only passes along values for given names isn't doing anything new and therefore is of dubious utility. It's not that ZMP is guaranteed to always provide semantics: zmp.var would not make semantic guarantees. But the nominal purpose here is to provide some kind of meaning (even if just as a "suggestion") to the variables. Basically, it seems that the protocol is kind of defeating its reason for existence with competing goals.