You guys have all played MUDs that utilize some sort of time clock inside the game, but have you ever actually payed attention to it? You're never really forced to sleep at night, so how do you effectively role-play the MUD time without compromising your actual playtime?

And another thing, how do you implement time in a MUD in a way that makes it believeable? Should you just change the room description to say "The stars are out", or do something more? One thing I've always wanted to see is darkness at night, in which you'd have to have a torch out to leave the town, but you'd have to do it in a simple way so as not to frustrate night-travelling players. Or maybe even progressive lighting, in which things become more and more visible or less and less visible depending on whether it's morning or evening.

What do you guys think about MUD time?

I prefer to also base it on the season and weather, combined with the type of terrain you're in - thus while swimming across a lake you might see the moon reflected in the water, while in the forest you'd hear the sounds of nocturnal animals.  For example, this is what you'd see while walking through a settlement at dawn in winter when it's heavily snowing:

You are walking through a settlement, the paved street thick with snow which crunches beneath your boots.  The sun is beginning to rise on the eastern horizon, its red glow barely visible above the settlement walls. Heavy snowflakes fall all around you, caking the rooftops and carpeting the streets.  Your cloak flaps wildly in the wind, providing little protection against the biting cold.

But transform into a wolf and walk through the same settlement during an autumn night while it's raining and you'd see:

You are stalking through a settlement, the paved street feeling cold beneath your paws.  Scattered lamps mounted on the nearby buildings illuminate the darkness.  Flashes of lightning and the rumble of thunder fill the night air, framed against the backdrop of incessant rain which patters against the buildings and the street.

The problem is of course that writing room descriptions rapidly becomes intractable for one of several reasons:

- If you're accounting for day/night, seasons, local weather (sunny/cloudy/rain/snow), you're already at 2*4*4=32 possible room states which could possibly require unique descriptions. Obviously they will often be variations on a theme (that huge tree is still there, but the leaves turn) and therefore easier to produce than 32 unique locations, but you're still going to add a lot of overhead to creating a place. Depending on your game's focus, this workload increase may not be worth the immersion difference.

As a micro-example, you mention transforming into a wolf. This might be a good tool for a game where a large percentage of the player characters are werewolves. It would be a horrible tool for us, where a small percentage of characters (maybe 3-4%) belong to a guild that teaches upwards of 100 possible transformations. #### if I want to rewrite that room description for a (typically human-sized) spider monkey, falcon, wolf, armadillo, etc.

- Some people skirt the above by writing automated room generators, or other tools that vary descriptions on the fly based on game states. The problem there is that while any one room can be made to look very convincing, once you've been through a couple dozen, the patterns tend to become predictable and dry. They also tend to be high on choppy declarative statements, lacking the smooth transitions a human author could do with little effort. We've gotten some good results with narrowly-targeted substitutions (for example, those things at the end of your legs might be feet, hooves, hindpaws, or claws, depending on what type of PC you are), but anything "bigger" tends to be ugly.

How do people address these issues?

Far more than that:

Day/night can be one of night, dawn, morning, afternoon, late afternoon, or evening/dusk.

Each season can be one of start, early, middle or end (eg at the start of autumn you'll see tree leaves turning brown, in early autumn they leaves will all be brown, and in mid- or late autumn there'll be dry leaves scattered around on the ground).

Finally, there are five types of weather: clear sky, light clouds, heavy clouds, rain and thunderstorm (rain becomes snow in winter).

So that would be 6*16*5=480 possibilities for each terrain type - although in practice, I can't think of any which actually use all the possibilities, and the vast majority only use a fraction of them.

It's just a single substition - instead of 'feet', I use '{feet}', and the dynamic description parser swaps it for the appropriate feet type (or footwear, if any). In the case of the falcon, it'd obviously display a different message, as falcons don't walk through settlements - equally if you were mounted, it would take that into account and adjust the description accordingly.

I suppose it probably would...I don't use rooms though, so it's not really an issue.

I've played plenty of MUDs in which you have to carry a torch around at night, but in some of them the torches are a bit of a nuisance.  That's what I meant by implementing them in a simple way.

For instance: automatic torches. Torches that you buy and when you go out at night, they automatically light up without you having to go through a complicated system of commands in order to hold them, get out a tinderbox, lighting them, dousing them before going inside, etc. This would probably hurt some of the Role-playing intensive aspects, but in my mind it would be for the better.

I'm actually pretty sure there's MUDs out there that have done this, but I haven't seen many.

Well in most Diku derivatives you just hold the light, and that's it - if anything, I think it's oversimplified. I never could understand how someone could use a sword, shield and torch (and in many muds, still have space for another 'held' item).

If you're going to the trouble of implementing a decent light source system then you might as well incorporate it fully into the game, forcing the player to swap their weapon or shield for a torch (although the torch itself could be used as an improvised weapon).

Accursed Lands has systems like the ones talked about in the first post. The time of day has a great effect on how far a character can see in the wilderness and what they can do. For instance, moving doesn't require any light at all (pitch blackness conceals all, including room descriptions), but if you want to read, you've got to be in a reasonably well lit room. It can also deal with species that aren't accustomed to light, up to seeing normally lit rooms (to more standard species) as being nearly blindingly bright.

So, in the respect that there's sunlight during the day, but not during the night, yes, time matters quite a bit. The descriptions of nearly all rooms are dynamic (based on time) as well.

Even I'M beginning to wonder what MUDs I've been playing. Somehow I only manage to find the ones with the stuff I don't like.

Expediency. Same reason our games don't put a weight limit on how much players can carry in their inventory and the same reason players eat but never have to pass bodily waste.


Why?

More detail and more realism is sometimes better and sometimes worse, and it depends on what crowd you're targetting. Blanket statements involving "should" and design miss out on the vast potential that exists as a result of wildly different preferences among players.


--matt

Probably true in general, but at least in this case it seems pretty apparent that if you're going to implement lighting, don't oversimplify it like Diku. Make it interesting. That seems to be the real take-home message from KaVir's post.

If the only only way having a light affects you is to allow you to see in dark rooms, you're probably better off without lights or the concept of darkness. All you've done is forced people to make sure their light slot is filled. Much like hunger and thirst in most Dikus, it's more a hassle to players than anything.

I agree completely. However, I think we'd both also agree that there are some things that simply are not interesting to anyone except for a handful of extremely massochistic mudders. For instance, game features whose only impact on a player is as a nuisance (e.g. food/light in most dikus).


Fair enough. I guess there is a distinction here between simple in design and simple in terms of the gameplay it offers. The boardgame Go is simple in design, but offers astoundingly complex, (and interesting to some) gameplay. It seems to me the real issue here is gameplay simplicity. In which case, yes, there is a way to oversimplify something: give it no real gameplay value but still have it exist (i.e. lightsources and food/drink in Dikus).


I'll buy that. However, Dikus don't even allow for this, as most do not allow lights to be turned on/off. In fact, most have permentant lights that never need to be removed, and always supply illumination to your room. They are oversimplified (in terms of their impact on gameplay). They add nothing to gameplay - not even this extremely basic imaginitive component.

I guess the bottom line is that, yeah, things can be oversimplified. Maybe not in terms of their design, but definitely in terms of the gameplay they offer. How light works on most dikus is a great example.

It's not really fair to dismiss the desires of some MUDers because you don't think much of their preferences. By that logic, all text MUDs can be dismissed out of hand given their extreme unpopularity in the wider MUD/MMO world.

Well, no, that's not the only impact. Other impacts include things like gold drains on the economy (if you have to buy food or torches) and increased immersion for some players. You might decide that, in aggregate, more players are being annoyed by this than are being helped, but then, that's just a function of your playerbase. The same logic you're using there would say that all RPIs are just nuisances, since they represent one of the most extreme forms of using virtual worlds (and appeal to very few people compared to virtual worlds based on, say, monster bashing).



To say that food, drink, and light have no value is a bit narrow-minded, with all due respect. As a player, for instance, I always enjoyed having food and drink available and feeling like the game required me to eat. It increased my immersion without rising to the point of irritation. That ideal cost/benefit analysis point is going to be different for nearly every player. What might be overcomplicated to you may be ideal to someone else, and vice versa.


Whether they have an effect on gameplay is worth considering, but gameplay is merely one aspect of participation in a virtual world. I guarantee you there are people out there that enjoy that particular setup. Given the # of people playing virtual worlds, virtually any design decision is going to be appreciated by some players, just like there are people out there who are turned on sexually by almost anything you or I can think of, and a whole bunch of things we can't. It then merely comes down to whom you're trying to appeal to.

Sure, it's oversimplified for you, but your preferences are just that: your preferences. I mean, just about everyone would tend to say that they prefer being able to communicate verbally to not being able to communicate verbally with people. And yet, there is Age of Reptiles, with, at most, a handful of players, and without the ability to use 'say'. For virtually all virtual worlds, including probably theirs (as much as I respect them for doing it), this decision is death. And yet, I know I went there and tried it out specifically because of that feature that would be beyond annoying to 99.999% of virtual world users.

There's more out there in terms of human preference than any of us can really encompass or understand. It's too easy to dismiss what we don't like as 'wrong' and I think it's a tendency to be avoided in the names of both innovation and general acceptance of diversity.

--matt

However, if the 'wrong' line isn't drawn somewhere, we're just doing random, willy-nilly development. This is just as bad for innovation since progress is random. It's also just as bad for general acceptance of diversity, since you'll quickly run out of people to accept the diversity if nothing substanially interesting arises.


I wholeheartedly agree with that. However, the point makes for rather boring discussion. It essentially makes any argument invincible, the conversation ends, and none of us come away any wiser...

I'd say the more interesting approach would be to identify who you're trying to appeal to, and figure out the best way to appeal to them. We haven't identified the target group yet, but given that how most dikus handle lights isn't going to be the best way to appeal to (m)any people, we can say with probabilistic certainty that it is uninteresting - probabily because it is oversimplified.

I will use Merc as an example, as it's the Diku derivative I'm most familiar with, and is the codebase that the majority of todays active Diku muds are derived from.  In Merc, every creature has four hands - one for a weapon, one for a shield, one for a 'held' item (trophy, rock, etc) and one for a light source.  You cannot use your light source slot for anything other than a light, and using a light has absolutely no affect on the rest of your setup.  As such, there is no advantage whatsoever in not having a light - and so, everyone has one.

Some lights in Merc are permanent, while others gradually run out (and cannot be turned off).  The latter reduces the light&dark feature to no more than an inconvenience which typically only affects newbies (who have little enough gold as it is), while the former (permanent lights) renders the light/dark feature completely obsolete.

Either way, the feature adds nothing to the gameplay; instead of going to all the trouble of implementing a light&dark system, the Merc team could have achieved practically the same result just by subtracting a few gold pieces each hour from all players below level 3.


As a counter-example, consider my mud; in God Wars II a humanoid has only two hands, and each is capable of holding any item.  From a combat perspective, this divides your hand setup into the following choices:

1) Pure magic: Both hands are being used for casting spells.

2) Semi-magic (offensive): One hand for spellcasting, the other holding a weapon.

3) Semi-magic (defensive): One hand for spellcasting, the other holding a shield.

4) Unarmed: Fighting with fists, gloves, gauntlets, talons, etc.

5) Weapon: Using a weapon in one hand, the other fighting unarmed.

6) Shield: Using a shield in one hand, the other fighting unarmed.

7) Dual-weapon: Using two weapons.

9) Turtle: Using two shields.

9) Weapon+shield: A weapon in one hand and a shield in the other.

10) Two-handed: One weapon being used in a two-handed grip.

Each of the above have their own pros and cons, providing an wide array of possible tactics.  Bring a light source into the equation and you add a whole range of new options.  Consider for a moment what sort of light sources there are - for example (off the top of my head):

a) Torch: As well as providing light, a torch can also be used as an improvised club, although this will likely extinguish it.  The flame itself can be used to burn, however, providing a good weapon against wild animals and certain undead.  Goes out if left on the ground for more than a short time, although man-made dungeons may have brackets on the walls where the torch can be placed during battle.

b) Glass lantern: Can be placed on the ground during combat, although there is the risk of it being knocked over.  May be hurled at an opponent, with a chance of breaking and engulfing them in fire - but opponents may also target your lantern, making it a potential liability.  May be easily extinguished by the holder and hung from the belt.  May also be lit and hung from the end of a pole.

c) Brass lamp: Much like the glass lantern, but more resilient, rending it ineffective as a weapon but more reliable as a light source.  The lamp may also be reinforced and/or made from stronger materials.

d) Magical glowing items: Weapons, shields, armour and other items might glow as part of their magical bonus.  This power would be at the expense of other magical bonuses, but would allow the character to utilise both hands for other activities.

e) Magic candles: These items could come in a variety of scents, providing bonuses to the party as well as illumination.  A candle that keeps insect swarms at bay could be a life-saver, while others might ward off fear affects or provide other benefits.  An excellent candidate for a crafting skill.

f) Natural illumination: Glowing moss or glowworms could be collected and placed in jars to provide light without the risk of fire.  A wise choice when exploring gas-filled caverns.

g) Night vision: Certain races might have the ability to see in the dark naturally, allowing them to utilise both hands for other activities.  The drawback, of course, is that this ability wouldn't extend to other members of your group/party - although on the plus side, it wouldn't extend to your enemies either.

h) Spells: Certain spells might provide a light source that follows the caster around, or allow the mage to imbue his party with night vision.

i) Pets/servants: That summoned fire elemental who follows you around would be more than just cannon fodder - it'd also be a living torch.  Those without such resources could hire NPCs to act as torchbearers.

If I were to add light&dark support, I'd also be introducing the following options:

11) Semi-magic (lightbearer): One hand for spellcasting, the other holding a light source.

12) Light: One hand holding a light source, the other fighting unarmed.

13) Paired lights: A light source in each hand (think Aragorn vs the ring wraiths).

14) Weapon+light: A weapon in one hand, a light source in the other.

15) Light+shield: A light source in one hand, a shield in the other.

A torchbearer NPC might well use a torch and shield, reducing them to a mostly defensive role, while a typical adventurer exploring a dungeon solo might be more likely to pick a sword and torch, or a sword and lantern with a shield strapped across his back.  Nightvision would suddenly become a really useful asset (as opposed to the completely redundant feature it is in Merc), and a glowing sword would become a coveted treasure.


Like all features, a light&dark system can be implemented well, or it can be implemented badly.  In Merc, the entire feature is reduced to little more than a minor inconvenience for newbies, which is a shame IMO.

Merc does pretty much the same thing with eating and drinking - these are little more than irritating spam for most player - and as a result you'll see many people claiming that such a system should be removed.  My view, however, is that there are few (if any) bad features, only bad implementations.

If a mud lacks the ability to design a creative light&dark system, or eating/drinking system, then sure - remove it.  It'd be better than a bad implementation.  However there's no reason why you can't turn such a feature into a strong asset for the mud, making it an integrated part of the overall game.

Your 'bodily waste' comment is another example of this - as a feature it's inherently neither good nor bad.  Other than being potentially rather tasteless, there is no reason why such a feature cannot be integrated into a mud, other than lack of imagination or technical ability.

Well, again, I'm not interesting in discussing the details of light systems, as they're not relevant to my point. There are enough MERC players out there that I'm sure the system has its fans, and that's all the justification one needs really.

Same with food, and yet I know that I, personally, always enjoyed having to eat, regardless of whether my fellow players did or not. So while it may not add to the gameplay, it adds to the experience (for me, and for others one presumes), of which the gameplay is only part.


And that's your preference. I haven't played your game, but that aspect of it would turn me off as it sounds overly-tedious to me. That's my preference. I enjoy being equipped for dungeoneering, but I really don't want to worry about unwielding and unwielding constantly anymore than I want to worry about wielding/unwielding whenever I want to eat something or whenever I want to do an emote that couldn't "realistically" be done with a sword and shield in hand.

It's all just preference.

--matt

You joined the thread by asking me "Why?" in response to my opinion on light systems...

I'm sure it's the justification many use, but if everyone took that stance there would be no further innovation in the mud community - everyone would be running stock muds. Furthermore, just because a codebase is successful on the whole doesn't mean that all of its features are well-liked or even worthwhile. Take my old GW codebase for example - pretty popular, but full of bugs. I'm sure there aren't many players to enjoy the frequent crashes, and that's certainly not a feature I would encourage others to copy.

I can imagine several ways of designing an interesting food system. I can also see how roleplayers might want the option to eat for RP purposes. I can even understand muds which started out with the standard food system in place and felt they had better things to spend their time on that reworking it.

But in over a decade of mudding, you're the first person I've encountered who's specifically said they enjoyed a system which literally consists of typing 'eat pie' every few minutes to avoid being spammed with 'you are hungry' messages - and I'd have serious concerns about the enjoyability of a game in which that was considered one of the highlights.

But you're missing the point - the way the light source system is designed in Merc makes it a completely redundant feature. Everyone has access to a light source, and there are no drawbacks to having one, therefore Merc might as well not even have bothered with it at all. And if it's just the RP aspects you like, you could just have an item called a 'torch' and the result would be the same.

It would be comparible with implementing dozens of attack spells, then making the lowest level spell the most powerful in all situations - the other spells would become redundant. Or it'd be like making the starting equipment the best in the game - the whole concept of gathering equipment would become obsolete. Or how about giving people more exp for being logged off than they could earn from playing the game - a great way to discourage the players from putting lots of time into the game!

Much of it comes down to personal preference, I agree - but creating a feature which renders itself or another part of the game obsolete is simply poor design, not to mention a waste of time that could be better spent on improving other aspects of the game.

aonean, (sorry if I spelled it wrong) you included RPI in your query. You want to know why light would be interesting or have value.

RPIs are coded with the emphasis on realism. That means if it's dark, you can get lost. If you're carrying a torch in a storm, the torch can go out. Eventually, all torches run out of oil to stay lit. The risk of getting lost in a dangerous area and running into a bad thing (or falling into a pit) is fun, for people who play RPIs. There might be a class of characters who can maneuver around in the dark better than others - this makes that class more valueable in those situations, and gives other character classes a solid reason to want to interact with them.

I believe realism, in an RPI, is a lofty goal and worth striving for. I also believe that playability should always be on the top of the priority list. So you balance realism with playability -

Have torches, but have some other method of lighting a dark room. Have the sun during the day, and moons at night, but also have magick classes that can cast shadows for those who prefer to live in darkness (or who want to trap prey who are lost without light).

As for the day/night thing, I'd rather keep it relatively simple. Have two sets of "outdoor" rooms in the game. Maybe just a single sentence at the end of the room paragraph to differentiate them.

Blah blah blah blah blah, blah blah. Blah blah blah, blah blah blah. Blah blah. Unlit lanterns hang from poles on the edge of the street.

(same paragraph)...blah blah. Lanterns shine brightly from poles on the edge of the street.

And instead of having a different paragraph for each phase of daylight in every single room, have a "weather" system that sends a room echo whenever the sun/moon(s)/wind/storms shift - with the additional "weather" command allowing a player to know what the weather is inbetween echoes.

Another perk this kind of system offers, is that the player can check the weather in the immediate surroundings. If you're in a wilderness area and there's a storm brewing off to the west, you don't have to find out by getting stuck in it. You can look to the west, or type weather west, and learn that the dust is kicking up in that direction. No torch is gonna help you there, but if you're of a class with excellent outdoor maneuverability (or have one in your group), you stand a chance of getting through it unscathed.

Well you'd want to do that anyway (even stock Diku does that) - but personally I think the current weather can also make a nice addition to the descriptions you see when you type 'look', as (at least to me) it makes the world feel less static.

Surely if there's a storm brewing off to the west, you should be able to see it from a pretty reasonable distance away?

I find it much more convenient to show the clouds overhead in a format like this:

<span style='font-family:Courier'>> weather

.. ..oo.. ..
..oo.. ..oo..
oooo.. ....oo..
oo.. ..oo..
.. .. .... ..
.... ..oo.. ..oo.. .. ....oo..
..oo.. ...... .. .. ..oo......OO.. .. ....oo.. .. ....OO.. ..
ooOOoo....oo.. .. .. ......oooo@@oo..oo.. ..oooo.. .. ..ooOOoo....
.. ..ooOO@@OOoooo.. ..oo.. ..oooooo..
@@@@OOoo.... ..OOOOX@OO.... .. ........
@@OOoooo.. ..oooo@@OO..
OOoo.... ....OOoo.. ..
oo.. ..oooo..
..oo.. ......
oo.. ..oo..
.. ....
..
.. ....
..
There's a thunderstorm.</span>

And then later:

<span style='font-family:Courier'>> weather

.. ..oooo.. ..
.. ..oo....
.. ....
..
.. .. ..oo.. ....
.... ..oo..oo..ooOO.. .... ..oooo.. ..
oooo.... .. .. ..oo..oo..OO@@oo.. ..oo.. .. ..OOoo....oo..
OOoo..oo.. .. .. ........oo@@@@OOoo.. ..oooo.. .. ..ooOO.. ..oo..
OO....oo.. ..OO@@OOOOoo.. ..oo.. ..oooo.. ....
oo.. .... ..OOOOooooX... .... .... ..
.. ..oooo.... .. ..
.. ....oo.. ..
.. ..oo....
.. ....
..
..
..
..
..
There are light clouds overhead.
The tide is currently high.</span>

Thus you can see the clouds swirling around and drifting across the sky from a fairly long way away, just as your character would be able to if standing outdoors. You can even predict when a storm is coming in, although because of the way the cloud pattern swirls as well as moves it's not possible to be overly accurate with your predictions.

The ascii things are more a matter of preference. I wouldn't play a game that had them every time I typed "weather." I'm a text kinda gal, and would prefer a textual description of the weather.

A gentle breeze wafts in from the west.

A harsh sandstorm fills the air, swirling in a clockwise pattern.

Torrential rain falls in sheets, mixed with high winds blowing to the southeast.

Stuff like that. Tell me where the wind's coming from, tell me what it's like where I am right now, and maybe tell me if I can at least see where I'm going, if I were to step one or two rooms from my current position.

Just as in real life, I have no idea whether the road is flooded at the end of my street. But, I do know it's raining there. So I can make an educated guess based on the fact that I've experienced this kind of weather in this neighborhood for the past four years. I can decide if I want to risk getting stuck in a flooded road - or if there isn't any risk because it isn't raining hard enough.

If I had just moved in (if I'm a noob), I'd have only basic info, and personal logic to go by. Raining hard here, 2 rooms on a decline toward a valley, hm. Possible flood. I'll stay on high ground til the rain slows, or try to detour around instead of going straight through.

I like it when the text descriptions and echoes tell me the story, and let me add the images in my own mind. Maps are another matter entirely - gimme Visio or give me death!

I prefer textual descriptions as well, and as I've said I use those too - but for some things it's very difficult to provide accurate information purely with words, and weather patterns are a good example. How would you describe a cloud pattern like one of my previous examples, using only words?

Sure, but the two methods aren't mutually exclusive. I've already talked about how I show the weather at your current location, but realistically a player should be able to see the clouds a lot further away than that.

In real life I can look up at the sky and see clouds a long distance away. In my mud I can do the same, seeing clouds several miles away.

But you'd be able to see a big dark cloud moving towards you - and hear the thunder - from a lot further away (unless each 'room' is a few miles across), regardless of how long you'd lived in the street.

Well the weather command effectively shows a 'map' of the sky. Just like a world map can provide a lot of information that's very difficult to describe purely with words (and believe me, I've tried - several of my players are blind) so a display of weather patterns can do the exact same thing.

I myself prefer more in-depth looks at my surroundings.  I like to have detailed visualizations in the rooms I'm in.  But I also understand where you're coming from, sometimes there's just too much text in a room description.  

I think the challenge there is deciding exactly how much of a description light should get, and the amount you mentioned I feel would appeal to a median of sorts of people who are not intensely RP, but who like a little more in-depth description so they know what time it is and whether it's night or day.  As a matter of fact, I've seen some MUDs that don't even differentiate between night and day!  In the end, it probably just depends on your player-base.

These two factors are the reason I would loathe the ASCII clouds KaVir described. I prefer to read detailed descriptions, rather than look at ASCII art, and on top of that, those ASCII clouds generate WAY too much text!

Then perhaps you could answer the question I posed to Jazuela:

How would you describe a cloud pattern like one of my previous examples, using only words?

It's pretty obvious to most people who've seen it, but I'll explain it anyway, using a smaller piece of cloud pattern:

<span style='font-family:Courier'> ..oooo..
..oo....
....
..
.. .. ..oo..
..oo..oo..ooOO..
..oo..oo..OO@@oo..
........oo@@@@OOoo..
..OO@@OOOOoo..
..OOOOooooX...
..oooo....
....oo..
..oo....
....</span>

The '@' represents a heavy thunderstorm, the 'O' is rain, 'o' is heavy clouds, '.' is light clouds and the rest is clear sky. The 'X' represents my current location.

Thus, looking up into the sky you can see that there's a heavy thunderstorm to the north-west, with wisps of lighter cloud swirling outwards from it.

Those might give an adequate idea of the weather at your current location, but they're not going to provide any insight into what the rest of the sky looks like.

So, once more, how would you describe one of my cloud patterns using only words?

That's why I didn't reply..I can't describe something I can't figure out. I have no idea what those ascii symbols are doing, or what they're supposed to represent. They don't look random, but I can't fathom the pattern.

But let's say you're trying to portray clouds coming in from the west, they're rainclouds, and they're chock-full of sand. Typing the word "weather" would return:

Sand-filled rainclouds appear overhead, coming in from the west.

Typing "weather west" would return:

Near west:
The sky darkens to the west, with sand-filled rainclouds looming precariously low to the ground.
Far west:
The sky is completely blackened, obscured by a harsh rainy sandstorm.

or - maybe the storm is coming from the northwest, and the "north" part of it is far, rather than near:

Far west:
Thick dark clouds form overhead from a storm coming in from the north.

Very easy to write, much easier to decipher than an ascii rendering.

Oh, I love Jazuela's suggestion!

However it still doesn't answer my question, and nor have you.

Jazuela's suggestion is fine for the weather system used by the typical stock mud - a simple state machine where weather is either rainy, cloudy, sunny, or whatever. But when you're talking about actual weather patterns you cannot describe them without losing a vast amount of detail, something which is hardly appropriate when the character could realistically just look up at the sky and view the clouds for themselves.

For me, the main purpose of the game world is to facilitate my character's development and the game story's development. I tend to value parsimony over realism, unless there is a very compelling reason to complicate the game play experience. For example, having to urinate/defecate/eat regularly is more irksome then fun. I suppose that learning a weather pattern ASCII mapping system like you describe just doesn't strike me as any fun, and nor do I see the point of going to the trouble of implementing it, so I'm not really able to get excited enough about the concept to give you helpful suggestions.

Fair enough - many people prefer to stick to the 'familiar' features that have been around for the last couple of decades, often finding it very difficult to think outside the box. And everyone has a different sense of what is 'fun' (some people enjoy archaic automated combat systems, for example, while others hate all types of combat). Fortunately there are enough muds out there that most people can find something they like.

However what it still boils down to is that you are not able to describe a cloud pattern such as I utilise, using only words. And the fact that you prefer stock weather systems doesn't really make my situation any easier, because I've no real desire to create a stock game.

Sure I could describe it, if I could see it. If it's visible, I can put it into words. That's what builders DO, afterall.

But the only people who would be remotely interested in actual and precise weather patterns in a text-based fantasy game would be professional navigators, tower control operators, and sea captains where charting out this kind of thing can mean the difference between smooth sailing and crashing into a glacier.

Since I don't know of many (any) games that require that kind of detail, I feel the exercise is not only pointless, but impossible given the fact that I am not a navigator, sea captain, or tower control operator, and have no idea how to read it.

But if I could, I'd have no trouble at all putting it into a nice neat package of text.

I asked you how you would do it, not if you could do it. The fact that you keep dodging around the question with comments like "it's pointless" leads me to believe that you've come to the same conclusion as I did - that such information cannot be reasonably conveyed using text.

Even if you prefer stock weather systems, you could apply the same reasoning to ASCII maps of the world. For those who dislike (or are unable to use) ASCII graphics, a description-based alternative to a geographical world map would no doubt be a very useful and welcome addition - how would you go about doing that?

KaVir, I don't think you are getting their point. You are asking them to engage in some pretty significant game design regarding a feature that they do not feel would be very interesting or useful. They do not appear interested in investing the thought and analysis necessary to come up with an actual system for doing in text what you have done via ascii. To them, it would be a waste of a significant amount of time for no real benefit to them or their point.

It would be like asking someone with no interest in genetics to explain how they would go about creating a pet system that used Mendelian genetics to pass traits along various generations of bred pets. They don't need to know how to do it to decide whether or not they like YOUR method. The fact that either genetics or Mendelian genetics specifically did not interest them might preclude them from wanting to invest a lot of time figuring out how they would do it just to explain why they did not like your method.

Personally, I think your cloud/sky/map thing looks pretty neat and I can totally see the benefits of it. It does indeed convey a lot of information simply and neatly.

That said, there are many people who do not like that sort of thing, and would prefer the information to be conveyed purely via text. I imagine it would be possible to do so, but perhaps you are right and no text implementation could even approach the utility of your ascii method. As it is not a feature I am currently programming (and personally, I'd probably go the ascii route myself) I am afraid I don't have the inclination to figure out a way to do it purely by text either. I hope you aren't disappointed.

Lastly, I wouldn't assume that just because someone doesn't like big ascii maps that they only want stock muds, stock code, or simple, stock weather. Your responses towards those who did not like your ascii map struck me as very presumptuous and defensive.

I do - I understand that they prefer purely textual descriptions instead of ASCII maps and images. However the point I'm trying to drive home is that for certain systems, a textual description on its own is simply not enough to reasonably convey sufficient information for a player to make an informed decision.

Yes, I use textual descriptions for my weather, as well as to show what you can see nearby, but I also provide ASCII weather patterns and world maps in order to provide additional detail.

But if they had criticised me for using such complexity, don't you think it would be reasonable for me to ask "Then how would you develop a system for passing down traits through generations of pets"?

I understand where you are coming from KaVir, but you are asking two non-developers to give you a developer-type answer about an advanced feature that they do not find personally riveting.

Okay now I think I can see what KaVir is asking, thanks to Threshold (who also didn't quite grasp the point but explained the "non-grasping" better than KaVir did).

To me, it is the same as if someone asked me how I would translate Russian to English. I'm not interested in doing it, but IF I was - I would suggest they find someone who knows Russian and English.

It -can- be done. But, I don't know Russian, so I have no idea how I'd go about translating one alphabet into a completely different alphabet. I don't have enough data to start with.

With that cloud thing, I don't understand it. I can't read it, I lack the data. That's why I gave the example I gave. To suggest that *IF* that example explained what the cloud pattern meant, THEN that was how I'd turn it into text. And IF that was what it meant, then turning it into text isn't difficult at all.

Obviously, that isn't what the cloud pattern meant. I have no idea what the cloud pattern means. And as Threshold says, I don't have enough interest in learning precisely what it means to translate it to text. Just like I'm not interested enough in Russian to translate it to English. I just use the clunky standby Babbelfish for that, or I'll ask a Russian who knows English to do it for me.

I already explained: The '@' represents a heavy thunderstorm, the 'O' is rain, 'o' is heavy clouds, '.' is light clouds and the rest is clear sky. The 'X' represents your current location.

Not meaning to sound pedantic, but is this honestly too complex for the average player to understand? Perhaps I've lost touch with the average player (or my faith is misplaced), but I hadn't even considered that any mudder might have trouble understanding it, as long as they knew what each character represented.

But if you started criticising the Russian's translation, wouldn't it be reasonable for him to ask you what your alternative translation might be? That's all I'm doing.

I don't know that I'd say it's too complex, but I do think that it would take some getting used to. Just as when you log into a new game, it takes a while to start translating the information rapidly, looking at that map doesn't immediately make sense. After looking at it for a while, I can interpret it and see the advantage in it.

Advantage admitted, I still have the problem that I don't like ASCII representations of anything in a game. I play text games because I like words. ASCII representations just seem so woefully clunky and...ugly. To me it would be like reading through a great novel to flip the page and find the author had tried to draw a picture of the next scene through ASCII art. Of course, I'm more interested in the textual and roleplaying aspects of a game than the actual gameplay.

All of -that- being said, I'll congratulate you on another impressive feature. Handling weather is a hard thing. When I staffed on Armageddon, realistic weather systems and how to make them an interactive feature for the playerbase (prediction, navigation, cycles, almanac type stuff) came up frequently because weather is such a large part of the game. It would really add to the game if player-based meteorology was a possibility.

Out of curiosity, is it possible to play in that system using variable width fonts? (which tend to play havoc with ascii graphics, tables, etc). I used to solely use fixed-width fonts and then discovered that a fair few of our players were using variable width. I didn't understand it at first and couldn't believe they'd be willing to put up with all the mis-aligned tables and such, but after switching to variable width myself to test it, I found it much more pleasant to stare at all day and use that variable-width almost exclusively now.

--matt