18 Sep, 2011, Scandum wrote in the 41st comment:
Votes: 0
Tyche said:
I'm creating channels that send data in a home grown format
that uses some of the same principles as BSON (and many many others use).. [data type][length][data bytes]

Having looked at BSON I'm not a big fan of data typing, it's a step above human readable formats; which are somewhat silly when used for machine 2 machine communication. Ultimately data isn't self descriptive, something may be a string or a number but that ultimately doesn't tell you anything, so proper documentation is a must, which is protocol independent.

Channels make sense. I'd rather see [channel][length][data bytes] The only real use I see to a length field is to check for packet fragmentation which currently is a major pain in the ass. Even when dealing with binary data you still need a variable name, making it easier to escape the data then to use a rigid format.

Using the MCCP approach channels could be done using telnet, though it'd be one of those things nobody's going to implement because servers don't really care about client difficulties.
18 Sep, 2011, plamzi wrote in the 42nd comment:
Votes: 0
Baiou said:
It's been years since I've first heard about muds. Is there any new tech for this scene or am I just missing it? I need that new revolutionary thing!


After carefully re-reading the OP, the answer is clearly 'no'.

P. S. The latest revolutionary technology to impact MUDs was called "writing", and it developed about 6K years ago. Lately, the gaming industry has taken a bit of a step back into "pictographs" but we are confident that our superior technology will eventually prevail.

P. P. S. Many people on these forums have a great fondness for "protocols". However, if you google "protocol revolutionary", you will only get a bunch of IT ads.
18 Sep, 2011, quixadhal wrote in the 43rd comment:
Votes: 0
Actually, if you want the last "revolutionary" thing in MUD design, that'd be LpMUD back in 1989? The idea of having the game world itself be fully run-time modifiable code instead of hard-coded in the driver was quite a change. After that… maybe ANSI color? That still hasn't been fully accepted though.
19 Sep, 2011, Tyche wrote in the 44th comment:
Votes: 0
Baiou said:
How far are you along? @tyche


I finished the network layer last December. I'm working on building widgets and interfaces on top of it, mostly based on what my game client and server need.
19 Sep, 2011, Tyche wrote in the 45th comment:
Votes: 0
Scandum said:
Tyche said:
I'm creating channels that send data in a home grown format
that uses some of the same principles as BSON (and many many others use).. [data type][length][data bytes]

Having looked at BSON I'm not a big fan of data typing, it's a step above human readable formats; which are somewhat silly when used for machine 2 machine communication. Ultimately data isn't self descriptive, something may be a string or a number but that ultimately doesn't tell you anything, so proper documentation is a must, which is protocol independent.

Channels make sense. I'd rather see [channel][length][data bytes] The only real use I see to a length field is to check for packet fragmentation which currently is a major pain in the ass. Even when dealing with binary data you still need a variable name, making it easier to escape the data then to use a rigid format.

Using the MCCP approach channels could be done using telnet, though it'd be one of those things nobody's going to implement because servers don't really care about client difficulties.


BSON was developed as a marshalling/serialization format for a database, because they were interested in efficiency.
I believe similar concerns are true for those developing internet games. When you're sending data it's important that the receiver
knows what it actually is. I'm not a fan of guessing what something is.

Implementing channels in a stream again requires a mechanism for partioning the stream. It's actually much easier working with messages than streams.
Runter delimits his messages with NUL and IAC, you delimit your messages with IAC SB MSDP and IAC SE. You are both doing this because
the respective stream-based protocols require it.

I've implemented a channel as a packet routing mechanism. The receiver knows what messages that channel will be used for. It could be a status bar widget in the client, a file transfer, a sound, a stream to a movie player, a roleplaying logger, a mapping application, etc.
19 Sep, 2011, Tyche wrote in the 46th comment:
Votes: 0
quixadhal said:
Actually, if you want the last "revolutionary" thing in MUD design, that'd be LpMUD back in 1989? The idea of having the game world itself be fully run-time modifiable code instead of hard-coded in the driver was quite a change. After that… maybe ANSI color? That still hasn't been fully accepted though.


How about playing a mud over your smart phone thingamajig? That's pretty revolutionary.
19 Sep, 2011, Scandum wrote in the 47th comment:
Votes: 0
Tyche said:
BSON was developed as a marshalling/serialization format for a database, because they were interested in efficiency.
I believe similar concerns are true for those developing internet games. When you're sending data it's important that the receiver
knows what it actually is. I'm not a fan of guessing what something is.

You can't use a variable unless you know beforehand what that variable is supposed to do. If someone sends me JKFLDJSL = 474747432 it's just as meaningless as JKFLDJSL = (unsigned int) 474747432. HP = 12 is just as meaningless as HP = (int) 12 if I have no clue what HP is supposed to do. If I know what it's supposed to do I also know the data type, so why bother sending the data type? (other than efficiency)
19 Sep, 2011, Rarva.Riendf wrote in the 48th comment:
Votes: 0
Scandum said:
Tyche said:
BSON was developed as a marshalling/serialization format for a database, because they were interested in efficiency.
I believe similar concerns are true for those developing internet games. When you're sending data it's important that the receiver
knows what it actually is. I'm not a fan of guessing what something is.

You can't use a variable unless you know beforehand what that variable is supposed to do. If someone sends me JKFLDJSL = 474747432 it's just as meaningless as JKFLDJSL = (unsigned int) 474747432. HP = 12 is just as meaningless as HP = (int) 12 if I have no clue what HP is supposed to do. If I know what it's supposed to do I also know the data type, so why bother sending the data type? (other than efficiency)


Because if you know what the datatype is "supposed to be" you use the right methods to validate what is is right away. Security reasons mostly.
19 Sep, 2011, Runter wrote in the 49th comment:
Votes: 0
appeal to safety
without example given
victory's declared
19 Sep, 2011, Rarva.Riendf wrote in the 50th comment:
Votes: 0
Runter said:
appeal to safety
without example given
victory's declared

Even arguing about the value of using strict data type heh…yeah you can do without, and you have a bigger chance of failing without as well…
19 Sep, 2011, plamzi wrote in the 51st comment:
Votes: 0
Tyche said:
quixadhal said:
Actually, if you want the last "revolutionary" thing in MUD design, that'd be LpMUD back in 1989? The idea of having the game world itself be fully run-time modifiable code instead of hard-coded in the driver was quite a change. After that… maybe ANSI color? That still hasn't been fully accepted though.


How about playing a mud over your smart phone thingamajig? That's pretty revolutionary.


To me, a feature that helps MUD admins reboot the server once a week instead of twice doesn't seem to deserve the epithet 'revolutionary'.

I'm kind of torn on the smart phone thing, though. The mobile phone transformation that took place in the last few years put about a billion new people online, at any time and place. Some say it drove the Arab Spring. It's clearly very significant. As for its impact on MUDs though, has our community benefited by (or managed to take full advantage of) smartphone platforms? I'm not so sure.
19 Sep, 2011, Runter wrote in the 52nd comment:
Votes: 0
Rarva.Riendf said:
Runter said:
appeal to safety
without example given
victory's declared

Even arguing about the value of using strict data type heh…yeah you can do without, and you have a bigger chance of failing without as well…


Lol, okay. The whole reason this is funny, well. I'll explain. Types in JSON are definitive and signed by wherever you got the data from. How is using another format any better for security when it can sign it as an integer or a string, or whatever type it wants too? It's not any different from a security perspective at all. You *still* have to do the *same* type constraints using JSON and BSON.

Just to be clear, there's no difference in the "strict"ness of

"string"

and

(7 byte string)string

. One is more efficient to parse.And that's the very reason the format exists.They both are different notations of the same exact thing. If one is worthy of appealing to fears of insecure code, then both are.
20 Sep, 2011, Ssolvarain wrote in the 53rd comment:
Votes: 0
I made a live-action stock ROM mud this summer.

RIP beastly fido cat
20 Sep, 2011, quixadhal wrote in the 54th comment:
Votes: 0
plamzi said:
Tyche said:
quixadhal said:
Actually, if you want the last "revolutionary" thing in MUD design, that'd be LpMUD back in 1989? The idea of having the game world itself be fully run-time modifiable code instead of hard-coded in the driver was quite a change. After that… maybe ANSI color? That still hasn't been fully accepted though.


How about playing a mud over your smart phone thingamajig? That's pretty revolutionary.


To me, a feature that helps MUD admins reboot the server once a week instead of twice doesn't seem to deserve the epithet 'revolutionary'.


Wat? Not sure how either of the above quoted things has anything to do with rebooting a server. If you were refering to my comment about LpMUD, the concept of coding the entire game in a runtime environment that can be changed on the fly, and where changes are isolated to their own systems – as opposed to hardcoding it in a driver where a single mistake in a isolated system crashes the entire game – to be seems revolutionary. LpMUD may not have been the first, I'll give you that.

If you were referring to phonemudding… what does that have to do with design? That's just people continuing to use the same old TCP/IP sockets (with or without TELNET layered on top) over the internet, just using a tiny screen and perhaps a cellular network. Nothing at all to do with MUD development.

As for BSON and data types….

"O HAI! I CAN HAS INVENTORY DATA?"
"SNARF IT!" – sends BSON object serialization
"O HAI! WAT IS 64-BIT? I CAN HAS ONLY 32-BIT INTEGERS?"

BSON seems like a good thing when you have control of both client and server AND their respective environments, but maybe not so good when your 32-bit PPC client tries to connect to a 64-bit Intel server and exchange binary data.
20 Sep, 2011, Tyche wrote in the 55th comment:
Votes: 0
Scandum said:
You can't use a variable unless you know beforehand what that variable is supposed to do. If someone sends me JKFLDJSL = 474747432 it's just as meaningless as JKFLDJSL = (unsigned int) 474747432. HP = 12 is just as meaningless as HP = (int) 12 if I have no clue what HP is supposed to do. If I know what it's supposed to do I also know the data type, so why bother sending the data type? (other than efficiency)


I use type because I'm not converting strings of digits.
20 Sep, 2011, Cratylus wrote in the 56th comment:
Votes: 0
plamzi said:
To me, a feature that helps MUD admins reboot the server once a week instead of twice doesn't seem to deserve the epithet 'revolutionary'.


My mud ran for 55 weeks without reboot, with random people logging in made coder automatically, and without them managing to crash it.

Even so, I don't think that longer mean time between reboots is what Quix meant, and I'm sorry to say I think you knew that.

I think that the dynamic creative environment afforded by LP and also the other types of mud that allow it such as MOO and the like,
do represent a paradigm shift from the hardcode approach of diku. I think it's certainly in the ballpark of revolutionary, though I
accept there's room for quibble. There's little room, though, IMO, for outright dismissiveness like you've demonstrated. Quix's
point was a good one deserving of a more thoughtful rebuttal than that.

Having said that, I think we'll get in the weeds here with definitions of revolutionary, considering the number of axes to grind
hereabouts. I suggest that the bar should be more reasonable and less epic, and perhaps more along the lines of "next level"
or "leadership in direction". Along those lines I like the ambition and progress made by KaVir, both in his GUI efforts (which
I don't happen to enjoy but appreciate that others do) and his roomless and dynamic gw2. I'm not sure it's quite detailed enough
to handle a GoGo Yubari with her chain mace, but you know, I wouldn't be surprised if it could.

Let's frame this away from "try to impress me" which is dumbheaded and reductionistic, and have this thread be somewhat
constructive with examples of ideas that demonstrate progress in some interesting direction.

-Crat
http://lpmuds.net
20 Sep, 2011, plamzi wrote in the 57th comment:
Votes: 0
Cratylus said:
plamzi said:
To me, a feature that helps MUD admins reboot the server once a week instead of twice doesn't seem to deserve the epithet 'revolutionary'.


My mud ran for 55 weeks without reboot, with random people logging in made coder automatically, and without them managing to crash it.

Even so, I don't think that longer mean time between reboots is what Quix meant, and I'm sorry to say I think you knew that.


I did assume that quixadhal meant time between reboots when you're pushing changes. That's the only practical difference I can think of between a fully debugged Diku server and a fully debugged LPMud one. Surely we mustn't think that all Diku servers crash when "random people" are logging in, or that all LPMud servers stay up for 55 weeks. The reality is that you can have a rock-solid server without a runtime environment, and you can have a buggy/crashy one with. In practice, being able to more easily isolate "structure" and "logic" boils down to certain benefits for the actively developing admin(s), and makes little to no difference in the end user experience.

In my book, a revolutionary change has to have impact on the players of MUDs, it can't just hang around in the lab doing a better job of sorting the Petri dishes. From that point of view, clients that support GUI building and in-app databases seem to have made a lot more difference than any server frameworks. The fact that we agree on the GUI front seems to suggest that those are better candidates for radical progress.
20 Sep, 2011, quixadhal wrote in the 58th comment:
Votes: 0
plamzi said:
I did assume that quixadhal meant time between reboots when you're pushing changes. That's the only practical difference I can think of between a fully debugged Diku server and a fully debugged LPMud one. Surely we mustn't think that all Diku servers crash when "random people" are logging in, or that all LPMud servers stay up for 55 weeks. The reality is that you can have a rock-solid server without a runtime environment, and you can have a buggy/crashy one with. In practice, being able to more easily isolate "structure" and "logic" boils down to certain benefits for the actively developing admin(s), and makes little to no difference in the end user experience.

In my book, a revolutionary change has to have impact on the players of MUDs, it can't just hang around in the lab doing a better job of sorting the Petri dishes. From that point of view, clients that support GUI building and in-app databases seem to have made a lot more difference than any server frameworks. The fact that we agree on the GUI front seems to suggest that those are better candidates for radical progress.


The revolutionary nature of LpMUD's has *NOTHING* to do with crashing or rebooting. The fact that you think that way shows that you don't understand anything outside the Dikurivative world at all. I consider LpMUD's revolutionary because they allow ordinary builders – people who are NOT admins, and don't have access to the source code or a shell on the server machine – to make real creative changes to the way the game works, while it's running, without special powers.

It means the builders can come up with clever things and implement them without needing to rush to the admin/coder to hack it into the driver. It means the players actually see the game as something more than a meat grinder with fancy wallpaper. Back in the day, when MUD's had players, I remember many times a player had a good idea or request, and they would go unanswered or be told that the coder might be able to implement it eventually, because in a DikuMUD, it has to be done by someone with shell access.

If you can't see how getting the players thinking creatively and working WITH the building staff benefits the players, I feel sorry for you. All too many admins think of the players as the enemy. I understand, because to a hardcoded game driver they really seem like it… constantly looking for exploits and consuming content. It doesn't need to be that way.
20 Sep, 2011, KaVir wrote in the 59th comment:
Votes: 0
LPmud predates DikuMUD, it was designed to combine the gameplay of AberMUD with the user-extensibility of TinyMUD. TinyMUD in turn was initially designed to be a stripped-down version of Monster.

I think it's very difficult to define something as "revolutionary", because most mud development is a gradual evolution of earlier ideas.

However what is clear is that the evolution continues. I've been particularly interested by the advances made by mud clients over the last couple of years (eg graphical support added to MUSHclient and Mudlet, as well as new mobile and browser clients), and the adoption by various muds of features that better support those clients (which is why I jumped on the bandwagon).
20 Sep, 2011, Scandum wrote in the 60th comment:
Votes: 0
Tyche said:
I use type because I'm not converting strings of digits.

You're still converting an arrays of bytes.

quixadhal said:
I consider LpMUD's revolutionary because they allow ordinary builders – people who are NOT admins, and don't have access to the source code or a shell on the server machine – to make real creative changes to the way the game works, while it's running, without special powers.

I've seen the standard LpMUD line editor and it made clear to me why LPMuds have done so poorly. One of the first changes I made to TinTin++ was adding support for indented multi-line scripts, because no matter how awesome a language is, if it's unreadable or inaccessible nothing decent will be created.

For LPMud (or any MUD) to be truly revolutionary in that department it needs to create an advanced remote editing environment.
40.0/128