13 Feb, 2014, Ssolvarain wrote in the 101st comment:
Votes: 0
quixadhal said:
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.


That's more a matter of people having low end PCs, which is an entirely different circumstance here. No one's going to turn on brief because it's overtaxing their… anything.
13 Feb, 2014, plamzi wrote in the 102nd comment:
Votes: 0
Ssolvarain said:
That's more a matter of people having low end PCs, which is an entirely different circumstance here. No one's going to turn on brief because it's overtaxing their… anything.


When you look at motivation, the similarities are more than the differences.

People turn down their graphics so they would be able to see the important stuff when it happens and react faster, without their senses being flooded by fluff that has no strategic value at the moment. The same motivation drives people that turn on "brief".

You can easily imagine a 3D game whose maxed out graphics bring down *any* existing home PC to its knees. In that game, I suspect that everyone would take their graphics down a notch rather than roam around at 3 FPS just so they can enjoy its breathtaking beauty. Unless roaming around is the only thing to do in the game, people will tone it down to a point where their gameplay doesn't suffer.

By the same token, you can imagine a MUD where each room has a 100 line description, not a single line of which is important to read. Of course, you'd want to turn off the automatic feeding of that text, or you'll be missing out on stuff that actually matters to gameplay.

Bottom line is, in any game, people will try to figure out the things that make them a better player. Sometimes, this means they would turn their graphics settings up a notch, e. g. when exploring, so they can see further and anticipate danger better. At that time, they'll take the performance hit in exchange for being able to see mobs further out. The equivalent in a MUD would be honeycombing long room descriptions in search of an essential clue that you know is hidden there, even if you normally "hate" to read descriptions.
13 Feb, 2014, quixadhal wrote in the 103rd comment:
Votes: 0
Ssolvarain said:
That's more a matter of people having low end PCs, which is an entirely different circumstance here. No one's going to turn on brief because it's overtaxing their… anything.


Actually, that's not true. I played MUD's back when they first came out, and most of my time was spent on vt220 terminals. On an 80x24 display with no scrollback, room descriptions could indeed be quite taxing. Couple that with a 2400 baud modem, and brief mode was required unless you wanted to pre-type your movement commands and HOPE nothing aggressive jumped you in the next minute.

plamzi said:
People turn down their graphics so they would be able to see the important stuff when it happens and react faster, without their senses being flooded by fluff that has no strategic value at the moment. The same motivation drives people that turn on "brief".


Yep, there are even specific settings on most graphical MMO's to only disable some of the more annoying apsects. In a boss fight, you have between 4 and 40 people all firing off their abilities as fast as they can, trying to defeat the boss, and keeping all the various adds under control, and the boss itself doing all kinds of crazy moves that you have to dodge or otherwise react to. Pretty much every spell or ability has particle effects that draw pretty glowing animations as they go off.

So, many MMO's have a specific setting to disable (or limit) particle effects from other players, JUST to help with those kinds of situations.

That's why I think a smarter, more context aware, version of brief might be useful. I don't think most players hate room descriptions, but they do hate having to read them over and over again, and especially when it gets in the way of finding game objectives.

plamzi said:
You can easily imagine a 3D game whose maxed out graphics bring down *any* existing home PC to its knees. In that game, I suspect that everyone would take their graphics down a notch rather than roam around at 3 FPS just so they can enjoy its breathtaking beauty. Unless roaming around is the only thing to do in the game, people will tone it down to a point where their gameplay doesn't suffer.


Actually, you don't have to imagine it! Download Everquest 2. It's now free to play. The game came out in 2004, and thus the engine was probably coded in 2000-2002. At that time SOE gambled that multi-core processors wouldn't make it to home desktops for at least 6-8 more years, and that the single-core CPU speeds would continue to rise as they had been up to that point. A friend of mine who used to work there said they created the game under the assumption that about 2 years after launch, people would have 8GHz single-core CPU's, and so that was the target architecture.

As a result, unless you have a liquid-nitrogen cooled system, even a top-end machine is still going to run at <6GHz per core, meaning you still won't get 60fps with everything cranked up. :)
13 Feb, 2014, Ssolvarain wrote in the 104th comment:
Votes: 0
quixadhal said:
Actually, that's not true. I played MUD's back when they first came out, and most of my time was spent on vt220 terminals. On an 80x24 display with no scrollback, room descriptions could indeed be quite taxing. Couple that with a 2400 baud modem, and brief mode was required unless you wanted to pre-type your movement commands and HOPE nothing aggressive jumped you in the next minute.


So what was it like when god was head builder, owner, and implementor?

I hear you and Jman got into it, once.
27 Apr, 2014, hitsuzen wrote in the 105th comment:
Votes: 0
Room descriptors are the "graphics" of your MUD. If you don't got no graphics then what the fuck are you wasting your time making a MUD for. MUDs are virtual worlds; if you don't care to create one for your players I don't see why they would have any motivation to stay. Or are people so enamored with the WoW mentality that if a game lets you farm rats ad nauseum players will flock to it?
28 Apr, 2014, Omega wrote in the 106th comment:
Votes: 0
I actually find a lot of people with screen readers (normally used by blind people), descriptions help invite them into a an immersive world. But outside of them, there are people who enjoy reading, its why a lot of people still play muds, they enjoy the interactive story, and letting their imagination tell the story as if they were reading a book, not watching someone's else imagination at work. Of course thats just my opinion on the matter.
01 May, 2014, Nathan wrote in the 107th comment:
Votes: 0
I find myself in the enjoys reading category, as I've noted elsewhere in this thread. Similarly, there is still the issue of a game just having a ton of cookie cutter unimaginative descriptions. The problem is the same as with no description, at least for me, in that it can destroy the immersion and sense of space to walk through an area such as a forest in which each room has a completely identical description. For me the world is a vast empty blank space without room descriptions, but what you choose to put into them has to have an almost narrative quality as it shouldn't tell you how/what you see since that's internal to the player/character and imposes some limit on you. Although I suppose some careful application of that might allow you to make the room appear somewhat differently to different players (if there's no light or it's raining or your games has vision limitations and glasses or something like that).

I have seen a few games, especially those with color, that embed the names of objects in the room that you can look into the description and color code them which is perhaps a bit obtrusive, but allows them to avoid a list of things in the room which can be anti-immersive. It has a similar effect to highlights or cursor changes in point and click adventure games.
01 May, 2014, quixadhal wrote in the 108th comment:
Votes: 0
I actually wrote some LPC code to do this. :)

varargs string format_desc(string raw, int terminal_width, int leading_indent_width, int inner_indent_width, string *highlight, string highlight_color) {
string result = "";

string *paragraphs = rexplode(raw, "\n");
string leading_indent = "";
string inner_indent = "";


if(undefinedp(terminal_width) || terminal_width < 10) {
object tp = this_player();

terminal_width = 75;
if(!undefinedp(tp)) {
int sw = tp->GetScreen()[0];

if(!undefinedp(sw) && sw > 0) {
terminal_width = sw;
}
}
}

if(!undefinedp(leading_indent_width) && leading_indent_width > 0) {
leading_indent = sprintf("%-*.*s", leading_indent_width, leading_indent_width, " ");
}
if(!undefinedp(inner_indent_width) && inner_indent_width > 0) {
inner_indent = sprintf("%-*.*s", inner_indent_width, inner_indent_width, " ");
}

for(int i = 0; i < sizeof(paragraphs); i++) {
string p = paragraphs[i];

result += (i != 0 ? "" : "");
result += leading_indent + implode(explode(sprintf("%-=*s\n", terminal_width, p), "\n"), "\n" + inner_indent);
result += "\n";
}

if(!undefinedp(highlight)) {
if(undefinedp(highlight_color)) {
highlight_color = "%^BOLD%^%^YELLOW%^";
}

foreach(string h in highlight) {
string tmp = "";

tmp = replace_string(result, h, highlight_color + h + "%^RESET%^", 1);
if(tmp == result) {
if(strsrch(h, " ") != -1) {
string *words = explode(h, " ");

for(int i = 0; i < sizeof(words); i++) {
string t = replace_string(h, " ", "\n", i+1, i+1);
tmp = replace_string(result, t, highlight_color + t + "%^RESET%^", 1);
if(tmp != result) {
break;
}
}
}
}
result = tmp;
}
}

return result;
}


So, for example, in the Dead Souls mudlib, the function SetLong() sets the long description displayed for the room, and the SetItems() function sets a list of "extra or detail descriptions", which are things you can look at for more detail, but aren't actual objects you can manipulate. I wanted these detail items to be highlighted so it's clear what you can look at, and what you can't… but didn't want them to be listed seperately.

Thus,

SetLong(format_desc(
"The common room of the Griffin's Tale is a quiet place.\n"
"A long table fills the center of this warm and comfortable "
"room. A bright and servicable bar occupies the east and "
"south walls, almost entirely. A warm fireplace fills the "
"north wall.\n"
"A solid, if somewhat beaten, oak door leads out into the "
"street to the west. An open archway leads past the fireplace "
"and into the kitchen northwards. To the east, a set of double "
"doors leads deeper into the inn. Along the south wall, sits "
"a smaller door.",
width, leading, inner,
({ "long table", "bar", "fireplace", "oak door", "archway", "double doors", "smaller door" })
));


With width set to 90, leading set to 4, and inner set to 0, it looks like:

Quote
The common room of the Griffin's Tale is a quiet place.
A long table fills the center of this warm and comfortable room. A bright and servicable
bar occupies the east and south walls, almost entirely. A warm fireplace fills the north
wall.
A solid, if somewhat beaten, oak door leads out into the street to the west. An open
archway leads past the fireplace and into the kitchen northwards. To the east, a set of
double doors leads deeper into the inn. Along the south wall, sits a smaller door.

Obvious exits: north, south, east, west


As it happens, the multi-word door names are actual doors, but they also have detail descriptions because I prefer players to be able to look at the doors, not just try to look THROUGH them. :)

Obviously, you could change the color of the highlighting, or even extend it to allow different colors for different kinds of things. I prefer to leave NPC's and actual objects as seperate lines, because embedding them in the description requires you to write logic into it to avoid unhappy situations where the descriptoin tells you about an oak barrel that isn't there because another player smashed it a few minutes ago.

EDIT: Just as a side note. The width is hard-coded in this case. I planned to eventually get the terminal width and try to figure out a formula for how much of it to use. Why not just use the full width? Well, it looks silly. My terminal is 192 columns wide… if you make room descriptons fit to the terminal width, the vast majority of them end up being one or two lines, often with paragraphs that don't even fill a single line.

Remember, most MUD's write descriptons under the assumption the player has an old 80x24 vt terminal. While I hate using a fixed width, I also want it to look reasonable without artifically bulking it up (which people on small terminals woudl hate). I think the best idea is a curve, where if your terminal is small, it uses the full width, but if it's wide, it will try to use more of the width only for longer descriptions, while keeping short ones at that 80 column mark.
02 May, 2014, Nathan wrote in the 109th comment:
Votes: 0
I wrote some code for my stuff that just takes a whole unsegmented description and goes through it as individual words, building up a line until it reaches the limit or when adding another word would exceed the limit and then sending that line. That way it scales loosely to any line width. Unfortunately it's only used for descriptions, but the idea seems sound to me. With some care the same approach could be applied to the word that doesn't fit, using a dash to break the word and put the rest on the next line. Then you could let the player define the width to use.

From the sounds of it, your method would be to use a minimum of 80 and then some fraction of any additional space. To be fair, 80 characters works well for descriptions since there can't be more than a sentence and a half in that space and so you don't have to move your eyes left and right as much. Additionally, there's the issues of the text being stuck to the left border of the client in most cases.

As to your barrel example, I imagine you'd have a dynamic description that built onto a static one to indicate items in the room, and you'd set your code up to either change the bit about the barrel to indicate it's destruction or only relate information about intact objects.
02 May, 2014, wifidi wrote in the 110th comment:
Votes: 0
Limited visibility exists in text MUDs: "Someone" or "something". Where's "somewhere?". Vague room descriptions make sense when it's dim: e.g. dusk, a bit before sunrise or a full moon at night, or bright: e.g., looking close enough at a star 8 light minutes away, or when its foggy or smoky. No room descriptions make sense when its dark, too bright, or in thick fog or smoke, etc. Technically "It's too dark/bright to see anything." is a room description, though not the one written for the room. Add the feature of facing, where north moves the character forward in the direction they're facing, and navigation at night or in some extremely lit area could get really cool. Murk++ has the perfect name for visibility enhancements. Imagine noticing someone try stepping behind you to backstab you because you were facing each other, or not noticing because you were facing the same direction and the backstabber entered second? Eventually a purist can say, "I've got your limited visibility right here…" and put an item inside a bag.
02 May, 2014, Nathan wrote in the 111th comment:
Votes: 0
I think facing is an interesting idea, but you need a game which says some notion of a coordinate system or at least a decent system that can track relative position. Then you have the problem of finding an intuitive way of changing which direction you're facing (cardinal directions, x degree increments, full 1-degree resolution across 360 degrees?) that isn't overly tedious.

For example, changing pc/npc facing when they interact (how that works with more than one interacting pc, who can tell) or setting a facing direction depending on which direction you enter the room from (e.g. going south to another room would leave you facing south). I had thought about a 'facing' or 'face' command, but in most cases you want to reduce actual use of such a command to a minimum, preferring actions to leave you facing a certain direction. If you did something like 'go <object/thing/?>' in a system of the sort noted at the top then you could be automatically face toward that object. To backstab someone, effectively mind you, I imagine you'd need to sneak behind them and then attack. The game code should handle auto facing as much as possible. We're not even talking about what sort of combat yet, either.
02 May, 2014, Ssolvarain wrote in the 112th comment:
Votes: 0
quixadhal said:
Quote
The common room of the Griffin's Tale is a quiet place.
A long table fills the center of this warm and comfortable room. A bright and servicable
bar occupies the east and south walls, almost entirely. A warm fireplace fills the north
wall.
A solid, if somewhat beaten, oak door leads out into the street to the west. An open
archway leads past the fireplace and into the kitchen northwards. To the east, a set of
double doors leads deeper into the inn. Along the south wall, sits a smaller door.

Obvious exits: north, south, east, west


I like how this looks, and how it was implemented. As a builder, I find it appealingly simple to use.
03 May, 2014, quixadhal wrote in the 113th comment:
Votes: 0
As far as facing goes… it's pretty simple to have the player automatically face 180 degrees away from the exit they used to enter the room. If they walk in from the south, they are obviously going to be facing north unless they specifically change that by "face east", or interacting with an object that's positioned near a wall, or as they are leaving via an exit that isn't north.

So, if your game implements facing, you might print the Description(North) when they walk in. If they type "east" to leave via the east exit, check to see if Description(East) would be different, and if it is you might print that difference as they're leaving… or make another decision like aborting the move to draw attention to it.

You could even implement a seperate DescriptionDifference(North, East) that would tell the player in a short sentance what they noticed as they turned East. Your builders will hate you, just like they'll hate you if you implement day/night, summer/winter, or anything else that makes them take 40 times as long to finish their rooms… :)
03 May, 2014, quixadhal wrote in the 114th comment:
Votes: 0
Ssolvarain said:
I like how this looks, and how it was implemented. As a builder, I find it appealingly simple to use.


You're welcome to use it, if you like. If you improve upon it, please let me know. :)
04 May, 2014, wifidi wrote in the 115th comment:
Votes: 0
Facing introduces the Wolfenstein 3D sprites problem among others. Actually getting chars to face NSEorW is as simple as making a character variable called facing with a value of 0 through 3, then taking player input as a directional subcommand that modifies facing. When they type north, they go the direction they're facing, etc., and it's possible e.g. to make diagonal keys mean "change direction and move in that direction". It's cool walking around with relative north though not that fun that I've experienced. Definitely would add more things for a room to be.
I'm going to start a thread on four new types of visibility: "stark (white, can't see anything else)", "bright (vague descriptions)", "dim (vague descriptions)" and "darkened (dark, can't see anything)". I'm convinced smart programmers can figure out code faster than me and get cracking.
04 May, 2014, donky wrote in the 116th comment:
Votes: 0
Ssolvarain said:
quixadhal said:
Quote
The common room of the Griffin's Tale is a quiet place.
A long table fills the center of this warm and comfortable room. A bright and servicable
bar occupies the east and south walls, almost entirely. A warm fireplace fills the north
wall.
A solid, if somewhat beaten, oak door leads out into the street to the west. An open
archway leads past the fireplace and into the kitchen northwards. To the east, a set of
double doors leads deeper into the inn. Along the south wall, sits a smaller door.

Obvious exits: north, south, east, west


I like how this looks, and how it was implemented. As a builder, I find it appealingly simple to use.

Looking at it, I wonder why the extra items aren't embedded in the text with a simple markup, to make it even easier.

"A [long table] fills the center of this warm and…"
04 May, 2014, Nathan wrote in the 117th comment:
Votes: 0
quixadhal said:
As far as facing goes… it's pretty simple to have the player automatically face 180 degrees away from the exit they used to enter the room. If they walk in from the south, they are obviously going to be facing north unless they specifically change that by "face east", or interacting with an object that's positioned near a wall, or as they are leaving via an exit that isn't north.

So, if your game implements facing, you might print the Description(North) when they walk in. If they type "east" to leave via the east exit, check to see if Description(East) would be different, and if it is you might print that difference as they're leaving… or make another decision like aborting the move to draw attention to it.

You could even implement a seperate DescriptionDifference(North, East) that would tell the player in a short sentance what they noticed as they turned East. Your builders will hate you, just like they'll hate you if you implement day/night, summer/winter, or anything else that makes them take 40 times as long to finish their rooms… :)


Of course. There is no reason you can't show the ordinary description in the absence of ones for different facing (just in case the builder was lazy or forgot them). Ideally the you'd have a dynamic description system which could handle both of those, with perhaps some static description information along with stuff that changes dependent on who/what is in the room.

wifidi said:
Facing introduces the Wolfenstein 3D sprites problem among others. Actually getting chars to face NSEorW is as simple as making a character variable called facing with a value of 0 through 3, then taking player input as a directional subcommand that modifies facing. When they type north, they go the direction they're facing, etc., and it's possible e.g. to make diagonal keys mean "change direction and move in that direction". It's cool walking around with relative north though not that fun that I've experienced. Definitely would add more things for a room to be.
I'm going to start a thread on four new types of visibility: "stark (white, can't see anything else)", "bright (vague descriptions)", "dim (vague descriptions)" and "darkened (dark, can't see anything)". I'm convinced smart programmers can figure out code faster than me and get cracking.


It's not that it's hard to store that data or change it, it's just hard to make it relevant and reduce the tedium of manually changing which direction because in real life you just adjust it and in a graphical game you have arrow keys and a high degree of control over the direction. That last part is difficult to emulate in a mud and of little worth unless you have, say, ranged weapons with at least some level of pseudo-physics. It's a nice idea, but there's not a whole lot of point to including it if there's no in-game purpose/reason for it and if the player can't experience direction/be subject to it beyond being told what direction they are going then it is a total waste of time.
04 May, 2014, quixadhal wrote in the 118th comment:
Votes: 0
donky said:
Ssolvarain said:
quixadhal said:
Quote
The common room of the Griffin's Tale is a quiet place.
A long table fills the center of this warm and comfortable room. A bright and servicable
bar occupies the east and south walls, almost entirely. A warm fireplace fills the north
wall.
A solid, if somewhat beaten, oak door leads out into the street to the west. An open
archway leads past the fireplace and into the kitchen northwards. To the east, a set of
double doors leads deeper into the inn. Along the south wall, sits a smaller door.

Obvious exits: north, south, east, west


I like how this looks, and how it was implemented. As a builder, I find it appealingly simple to use.

Looking at it, I wonder why the extra items aren't embedded in the text with a simple markup, to make it even easier.

"A [long table] fills the center of this warm and…"


Two reasons. The first one isn't that big a deal, but suppose you later go edit the description, or add a new detail. Will you always remember to go through and add new markup if that word or phrase happened earlier? Sure, not all that likely, but that's one. :)

The other depends on what you mean by markup. If you mean just simple brackets or something, I guess that's fine. Personally, I don't like the way that looks, as to me brackets imply editorial ammending. Highlighted color doesn't break the text flow so much, but other people may react in the opposite way. OTOH, if you mean actual markup tokens, then you have to retro-fit the existing system to handle them.

Part of the reason I did it this way is that the LPMUD already is going to have those words (and phrases) as the keys to another mapping that gets passed to create those detail descriptons anyways. Right now, it's hard coded, but you could probably replace that with

keys(GetItems())


or something similar to make it fully automated.
05 May, 2014, KaVir wrote in the 119th comment:
Votes: 0
wifidi said:
No room descriptions make sense when its dark, too bright, or in thick fog or smoke, etc.

Sight is only one of the five traditional senses. Even if it's pitch dark, there's no reason why you can't include other information in the description.

Nathan said:
If you did something like 'go <object/thing/?>' in a system of the sort noted at the top then you could be automatically face toward that object. To backstab someone, effectively mind you, I imagine you'd need to sneak behind them and then attack.

You've just described how I handle it. Facing is primarily used for backstab, although it does also apply to a few other attacks (e.g., a ranged attack hitting the back instead of the chest when the target is facing away from you).
07 May, 2014, wifidi wrote in the 120th comment:
Votes: 0
So true. Room descriptions could be filtered per kind of sensory information. Maybe builders can hash tag sentences or sophisticated enough code can filter raw room descriptions. Getting it that right might draw players and separate the coders from the hackers. I was hoping to get away with a simple mod that revolutionizes MUDs forever. There is something to be said for the simplest code/idea that many people somehow still choose to play. My imagination often writes checks my coding skills can't cash, so to speak, or I can accomplish the result by putting blinders on and getting 'er done without coding it for the long run.
100.0/128