Quote:
3. A output window re-write.
Good luck with doing that. The current output window design is pretty tightly integrated into how a lot of things are done (for example, style runs, MXP hyperlinks).
It is also optimized for speed of adding to, scrolling, and drawing.
Flashing text is probably moderately easy to do - as for inlining images, well that would take a lot of work.
Quote:
"One character sent per keypress" method.
Do you really want to go back to the old methods here? One of the main reasons that was abandoned was speed. A typical packet might take 200 milliseconds to traverse from the client to the server (that is, 1/5 of a second). If all it contains is a single keypress (one byte), then it is an inefficient use of network resources for a start (as there is a packet header on every network packet). The TCP/IP packet header size is around 20 bytes, so using 20 bytes to deliver a 1-byte payload seems inefficient to me.
Plus, add up those latencies and typing something like "hi there!" (10 bytes including the newline) would take 10 x 200 ms to send (2 seconds), plus the 2 seconds you are waiting for the server to echo each character. And that is just network latency, you would need to add to that server "lag", if it wasn't ready to echo each character the moment it arrived.
The whole point of sending stuff in blocks is to minimize the delay. A 80-character room description which takes 1/5 second to send is acceptable. It isn't acceptable if the 1/5 second applies individually to each of those 80 characters.
Quote:
one reason muds tend to stagnate is not that its impossible to come up with good ideas, but rather that you are stuck with what the "client" you use to connect with supports
Putting aside the problems that MMORPGs (like World of Warcraft) pose, as a highly-addictive alternative, I suggest if you want to come up with better client support you would move forwards in your design, rather than back to what was used in 1980.
One idea I had, and this would be a rewrite of both server and client, would be to combine the ease-of-use of graphical MMORPGs, with the comparative ease of development of a text-based MUD.
For example, a custom client could have portions of the window dedicated to things like inventory lists, maps, mini-maps, quests, what the character has equipped, and so on. There might be sub-windows for chatting, etc.
Then, rather than sending a character at a time, you might design custom messages (eg. using XML format, or Lua format) to send things each way, rather than having to parse pure text.
For example, using Lua data structures as a guide, moving from one room to another might look like this:
action="move" room=1234 mv=22
That is, we are telling the client we have moved, what room we are now in, and our new movements points value.
Then the client might not know the description for room 1234, so it might request:
action="getdesc" room=1234
The server might reply:
action="roomdesc" room=1234
description=[[
You are before the cathedral's altar. Those of ill luck or poor faith often
come here to pray to their God for guidance, or chance. An aisle leads back
south through the cathedral, while a large public board lies to the west.
]]
roomname="The Cathedral Altar"
exits={"s", "w"}
mobsinroom={5566,8877}
objectsinroom={6543,6432,6546}
Now the client, if it didn't know the description for the mobs, or objects, might request (and subsequently cache) their descriptions.
This sort of thing would make scripting at the client end a lot simpler. Rather than having to try to parse (and guess) what each line means, they would have clear-cut protocols.
|