09 Feb, 2014, quixadhal wrote in the 81st comment:
Votes: 0
It's a shame nobody has tried to tackle this issue to find a comprimise.

For example, it's pretty trivial to track if a player has ever visited a room before, and indeed how many times they've been there. That, itself, is a somewhat useful metric to see what areas are popular, and what paths people take to get between them.

Most MUD's have a "look" command that shows you the player's environment. Typically, it shows you the room name and description, whatever objects (or decorative fake-objects) are there, the exits, and any other players or npcs. In many games, the function that is called by the look command is also implicitly called when you enter a rooom.

Since many players do indeed ignore the room description once they've seen it (assuming they ever read it at all), but in these days of crazy bandwidth, many of them don't bother to turn on brief… maybe a smart thing to do would be to create an implicit_look() function that gets called when you enter a room. It could easily check to see how many times you've been there before, and if more than some threshold value, only show you the room description if it has changed since the last time you saw it. You'd still get the list of things in the room, but the room name would usually be sufficient for the player to know where they are. You could easily use MD5 checksums to determine if the room description had changed.

As long as the players are made aware of this, and know they can always type "look" to see it, it seems like a good replacement for the brief command, entirely. You could even make the threshold value settable by the players, so they can control how often they see the whole text. A default of 3 seems reasonable, but some people might only want 1 or 2, and others might want dozens, or to disable it entirely.

I suspect people using text readers would really benefit from this.
09 Feb, 2014, plamzi wrote in the 82nd comment:
Votes: 0
quixadhal said:
It could easily check to see how many times you've been there before, and if more than some threshold value, only show you the room description if it has changed since the last time you saw it.


Easily? I can't think of an easy way. Using persistence to track who all has seen each individual room and using checksums to detect room description changes seems like a clear-cut case of over-engineering to me.

There's really no good way to tell if someone has actually read a room description or not. If you have 'brief' mode and you have a way for people to read individual room descriptions even with brief on, I think that's plenty.

If you are really worried about bandwidth, you can be much more efficient about it. Examples include compression, and not showing room descriptions when you detect that people are 'speedwalking' through anyway.
09 Feb, 2014, quixadhal wrote in the 83rd comment:
Votes: 0
It's incredibly easy to track what rooms a player has visited. The simplest way is to just keep a mapping of room pathnames (or vnums, if you're a dikumud) to visitation count in the player object. A typical MUD has 5000 rooms, so 5000 integers on one side, and 5000 fairly short strings (or integers, for a dikumud) on the other… add a bit of overhead, and 12K per player? Big whoop. How much RAM does your server have?

No, you can't tell if the human being has actually read it… you also can't tell if they're playing or watching their bot script playing, nor can you tell if they're watching TV while spamming the "kick" command. It's irrelevant. The point is, you walk through the room a few times, and if you didn't read the description then, you probably won't read it at all, unless some quest tells you that you should.

I don't like brief mode, because it eliminates ANY sense of exploration. How many players turn on brief mode and then ever bother to look at the descriptions at all?

Bandwidth is also not really an issue… again, 2014. How much text gets spewed at you? 2K/second? So, if you have 40 players, that's 80K/second… so, maybe 800Kb/sec, about the same as a high quality mp3 stream, or a low quality youtube video?
09 Feb, 2014, plamzi wrote in the 84th comment:
Votes: 0
quixadhal said:
Bandwidth is also not really an issue… again, 2014. How much text gets spewed at you? 2K/second? So, if you have 40 players, that's 80K/second… so, maybe 800Kb/sec, about the same as a high quality mp3 stream, or a low quality youtube video?


If bandwidth is not an issue to you (it isn't to me), why go through all this trouble to begin with?

If a player has any kind of motivation to read a room description (such as when looking for a clue to get to something they want), otherwise, they won't. Trying to create a smart mode that serves room descriptions only when they *might* want to read them, to me that's a solution to a non-existing problem.

quixadhal said:
12K per player? Big whoop


It's not about memory, or bandwidth, or the overall complexity of the task. It's about wasting limited resources on "a feature" that is likely to annoy about as many people as it pleases. I can think of about a thousand better things you can do in the same time and with 12K per char. How about storing locations that chars have explored, not to decide whether to serve the room description, but to allow them to speedwalk back to it from their current location?
10 Feb, 2014, Idealiad wrote in the 85th comment:
Votes: 0
plamzi said:
If a player has any kind of motivation to read a room description (such as when looking for a clue to get to something they want), otherwise, they won't. Trying to create a smart mode that serves room descriptions only when they *might* want to read them, to me that's a solution to a non-existing problem.


If you can intelligently suppress descriptions, that's a lot less spam a player has to deal with in backscroll.
10 Feb, 2014, quixadhal wrote in the 86th comment:
Votes: 0
What makes you think it's a non-existing problem? Have you ever asked people if they'd like such a thing? Have you taken note of how often people read (or don't read) descriptions by noting how quickly the move through the rooms? You're making just as big an assumption as I am.

Also, don't make me laugh by claiming "limited resources". My minecraft server, idle, takes more resources than a half dozen muds with players/bots running around them.

And sure, why not ALSO allow speedwalking to previously visited locations? As long as the data is there, I see no reason not to make full use of it. :)
10 Feb, 2014, Splork wrote in the 87th comment:
Votes: 0
We have been tracking this data for years and use it to display "Explorer" boards both inside our game and on our website . We probably have nearly 30k hand written rooms ( 3-5 sentences each ) which need to be visited several times before that room is learned. We have about 25-30 players average a day and it really uses no resources at all.

We have tied this feature into other aspects of our game too but the idea mentioned above seems a bit overboard to me. Most of our players simply toggle on brief mode, as mentioned many times here, and play away. When new areas are put in-game, old areas changed, or new quests added our players toggle brief mode off and read the descriptions again.
10 Feb, 2014, plamzi wrote in the 88th comment:
Votes: 0
Idealiad said:
If you can intelligently suppress descriptions, that's a lot less spam a player has to deal with in backscroll.


Sure, and the operative word is 'intelligently'. We already suppress room descriptions when we detect that the character is walking through fast. To me, that's a lot more intelligent than trying to guess whether someone has read a room description after seeing it 3, 4, 5 times, etc.

quixadhal said:
What makes you think it's a non-existing problem? Have you ever asked people if they'd like such a thing? Have you taken note of how often people read (or don't read) descriptions by noting how quickly the move through the rooms? You're making just as big an assumption as I am.


Actually, I have. And I've implemented a number of features related to room descriptions to improve UX, features that I believe are simpler and more efficient than what you're proposing. My observations are specific to a hack'n'slash game, of course. But it is a general rule of UI design that if you can't guess intelligently what the user wants, you should just give them the tool to get what they want when they want it.


quixadhal said:
Also, don't make me laugh by claiming "limited resources". My minecraft server, idle, takes more resources than a half dozen muds with players/bots running around them.


If you think I'm talking about hardware resources, you are arguing with yourself (and making yourself laugh, which I think is good :).

quixadhal said:
And sure, why not ALSO allow speedwalking to previously visited locations? As long as the data is there, I see no reason not to make full use of it. :)


The reason I add something in the first place matters a great deal to me. That way, I end up having more features that actually improve the end user experience. I would in a blink add location saving to ease movement (already done), or/and as means to encourage people to explore (like Splork did). And now that I have it, I will definitely leverage it to add a number of other features. It's just that what you are describing is not on my list. Let's just say you haven't convinced me.
10 Feb, 2014, quixadhal wrote in the 89th comment:
Votes: 0
Heh, well, if you meant resources in terms of development resources… the resources used in this discussion thread far exceed those necessary to implement such a thing in either the LPC mudlib or DikuMUD codebases I use.

Literally, add a mapping (hash array) to the player object, add a line of code to the code that runs when you enter a room to increment that room's entry in the mapping, add a line in the part that shows the room description to have it skip display if that number is > N. If you're on a DikuMUD, I guess you also have to add a few lines of code to load and save the entry in the player file. Oh yeah, I'm sure you have to fiddle with memory management too, because… C. :(

Am I missing something? Is it somehow more complex than that?
10 Feb, 2014, Hades_Kane wrote in the 90th comment:
Votes: 0
Speaking from the perspective of a player, even after I've read every description in an area (or let's say game, for the sake of argument) I've never turned on brief or filtered out the descriptions. A few extra lines of text per room has never bothered me, and in fact, I tend to be able to use the descriptions themselves as visual clues as to where I am, from color patterns, length of the descriptions, or even the shape of the block of text.

Of course, as with any "feature" like automatic filtering out of descriptions, it should be made optional for the ones who want to use it, but I've never been the type that would.

Filtering out unnecessary combat spam when fighting in a group or fighting multiple enemies, however, would be a different story altogether…
10 Feb, 2014, plamzi wrote in the 91st comment:
Votes: 0
quixadhal said:
Heh, well, if you meant resources in terms of development resources… the resources used in this discussion thread far exceed those necessary to implement such a thing in either the LPC mudlib or DikuMUD codebases I use.


Don't worry, I got a lot done while we were debating :)

And let's not forget that we post on forums not just for ourselves, but also for posterity. I think it's always useful to argue over which features are worthwhile and which are not–we're never going to all agree, but there will be takeaways from following the discussion.


Hades_Kane said:
Filtering out unnecessary combat spam when fighting in a group or fighting multiple enemies, however, would be a different story altogether…


Statistically, in a hack'n'slash game, combat spam is a much bigger issue than movement spam. I've tried to mitigate all kinds of spam, and fights are definitely a tough nut to crack. I think because you want to retain a sense of dynamism, and you definitely don't want people to miss out on important information. Matter of life and death, unlike room descriptions :)
10 Feb, 2014, quixadhal wrote in the 92nd comment:
Votes: 0
Room descriptions CAN be a matter of life and death, if you fail to read the clues about the level 9001 dragon that lives in the cave you're blindly walking into on brief mode… *grin*

However, mentioning combat spam does make me think a bit.

If you are using a "smart" client, you could send structured data out and thus put combat messages into a format more like what MMO's do. By that, I mean you use different fonts and colors (and possibly graphics) for things that matter more. When playing a game like WoW, for example, regular damage to you shows up as numbers floating over your head that gradually drift upwards and fade out. Critical hits show up in a BIGGER FONT, and with an exclaimation point… and they also linger on the screen longer. Various status debuffs (poison, slow, etc) show up as +debuffname, usually also with an icon, slightly off to one side.

In a text MUD, you can't quite do that…but in a smart client, you COULD make a combat subwindow that make use of it the same way, using the same level of control, or if the client isn't that smart, utilizing multiple columns to show normal, critical, status damages. If you're using telnet with ANSI support, you could divide up the screen and place such things in their own location, much the same way.

I'm actually really surprised nobody really uses the full control code set. I mean, it's a terminal type… presumably mushclient and friends report themselves as "mushclient" first, and then ANSI further down the road.
11 Feb, 2014, plamzi wrote in the 93rd comment:
Votes: 0
quixadhal said:
…maybe a smart thing to do would be to create an implicit_look() function that gets called when you enter a room. It could easily check to see how many times you've been there before, and if more than some threshold value, only show you the room description if it has changed since the last time you saw it. You'd still get the list of things in the room, but the room name would usually be sufficient for the player to know where they are.


quixadhal said:
Room descriptions CAN be a matter of life and death, if you fail to read the clues about the level 9001 dragon that lives in the cave you're blindly walking into on brief mode… *grin*


Player: I just walked blindly into the Mean Dragon's cave. Is it supposed to be so easy to walk in there and die?

Admin: Well, maybe you should have read the room description in the room before.

Player: Looking at my logs. I have brief off and I still didn't get the room description. Bug?

Admin: Well, that's because you've seen that room description 3 times, and you have your threshold set at 3.

Player: Huh? I was fighting minions, and I didn't even know such a setting exists.

Admin: It's really a great feature meant to help you, you know.
11 Feb, 2014, quixadhal wrote in the 94th comment:
Votes: 0
So, how does any normal player happen to wander into the enterance room to the Mean Dragon's cave, on THREE seperate occasions, and in all three times not notice the information provided to suggest NOT going further into the cave?

No, seriously. I could certainly see them missing it once, but what kind of player explores that way? Would you not expect someone to either ignore the descriptions and dive right into the cave on their FIRST visit, and then on wondering why they died, they'd check their logs and see the "Warning: Mean Dragon ahead, run away!" message? Or, alternatively, they'd notice the message and turn around, and NOT enter the cave at all.

What player logic would make them revisit the enterance on THREE seperate occasions, and in all three cases fail to notice the warning, but on that FOURTH instance, they wonder if maybe this time they should take that one extra step?
11 Feb, 2014, quixadhal wrote in the 95th comment:
Votes: 0
plamzi said:
Player: I just walked blindly into the Mean Dragon's cave. Is it supposed to be so easy to walk in there and die?

Admin: Well, maybe you should have read the room description in the room before.

Player: Looking at my logs. I have brief off and I still didn't get the room description. Bug?

Admin: Well, that's because you've seen that room description 3 times, and you have your threshold set at 3.

Player: Huh? I was fighting minions, and I didn't even know such a setting exists.

Admin: It's really a great feature meant to help you, you know.


But, if you want a strawman to keep your strawman company…

Player: I just walked blindly into the Mean Dragon's cave. Is it supposed to be so easy to walk in there and die?

Admin: Well, maybe you should have read the room description in the room before.

Player: Looking at my logs. I have brief on. You mean room descriptions might actually be useful for gameplay?

Admin: …

Player: Boy, it's too bad there wasn't some setting to let me only see NEW room descriptions. I hate having to have all that extra spam scrolling by, but I also don't like getting killed because I didn't see something in the description.

Admin: Huh, well, I'd code something like that, but nobody else has ever requested it, so it must not be a feature anyone would want.

Player: …
12 Feb, 2014, Tyche wrote in the 96th comment:
Votes: 0
Do people play World of Warcraft in brief mode in order to avoid being spammed by scenery?
12 Feb, 2014, Runter wrote in the 97th comment:
Votes: 0
Tyche said:
Do people play World of Warcraft in brief mode in order to avoid being spammed by scenery?


Not really a good analogy. Players there are successful even with video cards that don't properly render scenery. For important details, like is there a level 9001 dragon in the next room, there's an interface for that which doesn't really include the fine details of the vines growing up the side of the cave walls.

I think the fallacy here is a false dilemma between room descriptions or knowing nothing about your surroundings.

I would argue you could have no room descriptions yet adequately describe things the player can interact with. I prefer as a mud player to leave brief mode on and have more rich, dynamic (and brief) descriptions of things I may interact with.

I mean, if a player wants to know fine details, even in world of warcraft, they have to manually examine an item, character, surrounding and they get back a text description.
12 Feb, 2014, Idealiad wrote in the 98th comment:
Votes: 0
That's an excellent point Runter, and I've long thought a mud with no room descriptions would be pretty interesting (we talked about it way back at Mudlab – http://mudlab.org/forum/viewtopic.php?t=... , my nick there was MessrO).
12 Feb, 2014, quixadhal wrote in the 99th comment:
Votes: 0
Tyche said:
Do people play World of Warcraft in brief mode in order to avoid being spammed by scenery?


Actualy, yes they do!

The equivalent of "brief mode" for a graphical MMO is to turn down all the graphics settings to improve performance. And yes, there are even third-party addons for WoW to toggle between two sets of graphical settings… one that looks pretty for wandering around doing quests, and one that optimizes for performance while doing raids where timing is critical.
12 Feb, 2014, plamzi wrote in the 100th comment:
Votes: 0
Idealiad said:
That's an excellent point Runter, and I've long thought a mud with no room descriptions would be pretty interesting (we talked about it way back at Mudlab – http://mudlab.org/forum/viewtopic.php?t=... , my nick there was MessrO).


Coincidentally, that's what I'm going to try to do for the text-based UI in my node.js project. I'd like to present a very "strategic" default view, with only the kind of information that has utility. If people want atmosphere and eye candy, they can choose to play the game via the web interface, which will visualize their environment.

I'm not sure I'll ever get to the point of burying important clues inside room or item descriptions–it seems that nowadays casual players expect important information to be in a place where they can re-read it if needed, e. g. in their quest description. Maybe a few places here and there, to reward people who pay attention to detail…
80.0/128