I just gave you a list of things that are easy with graphics but difficult with text. How would you address those?

Yes, graphics aren't best for everything. But it's unclear to me why you aren't saying the same thing about text.

It was just an answer to the question of "why 3D games don't use telnet," which is as big a strawman as I can see, for the very reason you point out. But it's still a fun answer.



But you're using TCP, which retransmits dropped packets.

Right, but my point is that for the level of graphical support I provide, I want packets to be retransmitted if dropped. Because if they weren't, I'd be forced to keep retransmitting them whether they'd changed or not.

Actually, that's a really interesting problem. Let's say you're sending a packet that contains the health of the player (only). It gets transmitted. Meanwhile, your player gets thumped by an ogre and loses some health.

Now, it turns out that the original health packet was not acknowledged. Under TCP, it's retransmitted. This is despite you now having new, more up-to-date information about the player's health. Is it not a better design to use UDP, drop the original health packet forever, and transmit the newer data?

I think we are misunderstanding each other. Mostly beacuse I am not an english native speaker I guess.
I never said text was better than graphic or best for everything. (Text is obviously not the best way to give a description of a room to a player as a simple image would give even more and precose information in a second). I said that text is almost limitless in the message, and can even says thing that cannot be graphically possible in the first place. A simple example: you may implement so there is no actual physical limit to how many players can fight each other. (Or more probably not implement any limitation in the first place). Graphically you can do that if you remove collision, but then it becomes an ugly visual mess.
And suspension of disbilief is way more easy to achieve with text than graphically. As you rely on interpretation of the reader instead of fillling him with your vision.

But it is a slow media. Indeed.

There was an interesting article some 12 years ago about X-Wing vs. TIE Fighter, one of the earlier multiplayer games over the internet with large numbers of players. They developed a quasi-reliable protocol on top of UDP that let them pick and choose which packets actually needed to be reliable and which could be discarded. This is hardly an uncommon idea these days, though.

Positional information is a great example of this, even more so than health, because it tends to change far more frequently. Most of the time, there really isn't that much point in getting any other positional information than the most current. (The linked article discusses this a bit more.)

Oh absolutely. I'm sure that this is pretty much a solved problem as far as most online games go. It's an undiscovered country for muds, though, for a lot of legacy reasons.

To drag this back on topic, I still feel that telnet, even in the "limited" fashion that Quixadhal says we use it, is an incredibly useful tool if: a) you are the designer of a mudding client that aims to cater for many disparate muds, or b) you are the designer of a mud that aims to cater for many disparate clients. Even down to the point of using it as a simple enabling layer for Custom Reporting Application Protocol #244 ™. I'd say that covers a lot of ground. I'd probably go so far as to say all relevant ground: if you're writing a mud for one client, or a client for one mud, what do you care about standards?

I don't see telnet as holding muds back. If anything, it's enabling them to live for now. But, as the department of redundant departments department might write: for things to become standardised across clients and muds, to drive the technology forwards, there need to be standards. It's one of the reasons I had high hopes for MudStandards: at last, a breeding ground for ideas, a repository for specifications and reference implementations. Didn't happen.

In the mean time, MSDP, MSSP, etc., are good, independent efforts and I applaud them. What's next?

Well it would be faster, but it would also be less reliable. I'd need to manually handle packet loss, message ordering, duplicated data, congestion control, etc.

Well… yes. You'd be using UDP's unreliability as a feature, granting you access to a lossy transport medium in order to elide the retransmission of stale data. Naturally, you'd have to build protocol around it, and you'd need co-operation from the client.

I find I'm intrigued by that RoD Plugin, KaVir, will that work for any Smaug/SmaugFUSS based MUD?

You can also use a UDP stream for positional updates solely. A vast majority of MMO data being transmitted is that. Especially if you track direction and a z axis.

Well, for some definitions of "faster", at least… the packets wouldn't exactly go faster (yes, I am aware that the TCP header is bigger). The interesting difference is in the change in throughput under error conditions; there's no change in latency.


Yup. It's not that different from implementing a subset of TCP, except that you pick and choose which packets to retransmit rather than requiring ACKs for everything.

It'll work on any mud that supports MSDP. I've used it for a GodWars mud as well.

An earlier discussion on UDP:
[link=post]44278[/link]

I'd say it's quality graphics that's holding back the graphical games from doing anything spectacular. The average MMO has a 99.9% hand drawn static game world.

I'm still of the opinion that a general purpose physics + dynamic description engine would put MUDs back ahead of MMOs, as it'll be a while before a graphical game can create believable images from scratch. The big question is if there's anyone left with enough time and skill to do it.

Sorry to go meta on you, but I'm really glad to see this kind of discussion going on. :biggrin: I'm writing a next-gen MUD client, and it's great to read everybody's points of view.

Nothing to see here, carry on…

I'm not quite sure what you mean here, can you give some more information or maybe some examples of the kind of thing you're talking about?

Perhaps something similar to this.

You're not writing anything you bum, at least not on Jon.com!!! :( :( :(

If I was interviewing a programmer for a position with the 3d MMO studio I work for, I would know they weren't qualified when they began discussing client-based 2D UIs for MUDs..

If you don't understand why Telnet is not suitable for driving 3D games, at least understand that nobody uses it for such. Search on Google or whatever it is you do to get caught-up on unfamiliar topics. You won't find one.

The #1 result for "Telnet 3D" on Google is a project hosted on UselessCreations (dot) com and certainly isn't a 3D MMO that uses telnet for networking.