http://feeds.feedburner.com/~r/mudreading/~3/277420692/rae-on-armag

I recorded a videocast where I talk about ArmageddonMUD. Sanvean of Armageddon has been doing these for awhile and I decided to give it a shot. In this episode (assuming I’m going to do more) I talk about setting up new staff members for the game and an interesting character I played years ago.

Is there anyone else in the MUD community doing these? I’d love to see videos like this about other games!

It is split up into 3 YouTube videos and is about 22 minutes long:

Part 1/3

Part 2/3

Part 3/3

And there is a discussion of the videocast going on here:

Armageddon community discussion on the videocast

http://feeds.feedburner.com/~r/mudreading/~3/263582409/easy-supply-

A realistic economy is a goal of many MUDs. Many of the benefits of a realistic economy can be created with very little work.

Here is a simple supply and demand system. Every time a player buys an item, increase its cost. Every time a player sells an item, decrease its cost.

Voila. Supply and demand. The system works well to make high-demand items expensive and extremely common items cheap. There are just a few tweaks that would keep things working.

Tweak the settings for how much the cost is effected by each purchase or sale. You can’t assign the “right” values deterministically. It depends on your playerbase’s size and behavior, and will change over time.

Consider having the prices normalize gradually over time. That way a surge of unusual activity will be offset sooner, and items that are bought but not sold (such as consumables) will not simply increase in price forever.

Consider a minimum and maximum price. EG, do not allow an item’s cost to change to 50% less or more than its original cost. This is a good approximation of other factors not considered in the system and helps catch flukes before they cause a problem.

To expand on the system a little, keep a multiplier for object types and materials, if you have them. Start at 1. Each time a player buys or sells an item, increase or decrease the multiplier (by a small fraction). Have the multiplier effect all objects of that type or material. Now, if silver longswords are in demand, the price of silver broadswords will increase as well.

To expand on the system even more, keep these set of values separate for each city, region, or whatever granularity is appropriate for your game. Then travelling to a region where an item is more rare will yield a better payoff.

http://www.zalanthas.org/blogs/brideofson/archives/001414.html

Here's a sneak peak at something we're doing for Arm 2:

Currently commands are implemented to perform a specific action or skill in the game. Sometimes other uses or additional complexity that would provide more functionality need to be added to the commands. New commands are created, or command line switches added to access the added complexity. This pollutes the name space with single-use commands, or adds difficult to remember syntax, when the added behavior could be abstracted out to work in multiple other commands using a more natural approach.

Adverbial commands are commands that alter the functionality of existing commands. Most of the existing commands are 'verbs', directing user's characters what to do. Adverbial commands work like adverbial phrases in English, allowing the user to describe how they are doing an action, and providing coded benefits for doing so.

A collection of adverbs would be put together based on multiple criterion: How many commands they make sense with, the amount of complexity reduction they will provide, and the clarity and ease of use they hold for the player base. Each individual command would define what adverbs it supports. Using the adverbs provide coded modifiers or affects to the execution or results of the command for that single execution. Further commands which set the person into a 'mode' of behaving could still be done.

The intention of this is not to remove one-word commands that make sense (such as whisper and sneak), but rather allow a greater flexibility in describing your actions, as well as providing coded benefits to a wider variety of commands without having to come up with a command name that exactly fits the intention of the command.

Example Adverbial Commands

Some examples of adverbial commands and how some commands might respond to them follows.

quietly -- Used in speech related commands, lowering the volume of the speech. Lowering the volume of speech affects how well it could be heard in loud areas, listening skill checks, and if it carries to other rooms. Existing commands such as 'whisper' can be set up as an alias to 'quietly tell'. This could also be used in movement, such as "quietly go east (moving through the shadows)", allowing for a one room sneak. Other possibilities: Opening a door, picking up an item, starting an attack or drawing a weapon.

loudly -- Inverse of quietly, raises the volume of speech related commands. One might need to use this to be heard over others, or in a loud bar. Someone might catch only part of your say, or just an emote that your speaking but it's too loud unless you use this. This could be optionally used as a way to shout rather then the shout command. Other possibilities: Loudly moving to make your presense known, loudly attacking perhaps drawing attention (or other combat effects), or loudly chanting at a critical point in a ritual.

repeatedly -- Keep trying to do something until you succeed (or you determine it's impossible for your skill). It increases the delay proportionately and gives you a highest possible random result on your skill check. This wouldn't be used on skills where failure can result in a bad outcome. Possible uses include: Picking a lock, and searching a room.

in <language> -- Shortcut to allow you to change your language for one speech command. Example: in pig-latin say hello. This might be used in casting, or other communications such as psionics, or writing.

quickly -- Decreases the delay for the skill, but reduces your chance of success. Normally a master in a skill can ignore menial tasks involving the skill. If time is of the essence, they can try and do it quickly, and it increases the difficulty of the task. Possibilities include: drawing a weapon, attacking, shooting, kicking, disarming, getting an object, stealing, casting a spell, climbing, moving instead of run, mounting, or foraging.

slowly -- Increases the delay for the skill, but increases your chance of success. This should only be possible in a non-stressful situation, but the idea is you take your time doing it to reduce the difficulty of the task. Pretty much the inverse of quickly, this can be applied to many of the same commands. Possibilites include: moving, poisoning, casting a spell, stealing, climbing, crafting, picking a lock, stealing an item, foraging or shooting.

ineptly, poorly, adeptly, expertly -- Purposefully degrade your ability in a skill for one performance of it. Removes any chance of skill gain from failure, but can be used as a role play tool. Depending on your actual ability in the skill, you may not be able to use higher levels. You can't use this to increase your skill beyond your current ability. Other possibilities include: Taking a payoff to ineptly guard your boss one time, to downplay one's combat skills, or basically charade. Should give viewers an opposed check to see if they notice the deception.

exclusively -- Specify that you are looking for a specific result, like with forage. Example: exclusively forage for a golden skull.

Syntax

The general syntax for adverbial commands is:

Syntax: <adverb> <command> (pre-how emote) [post-how emote] <body>

Some Adverbial Commands might take arguments themselves (for instance 'in' takes the language to speak in), and would require slightly altered syntaxes.

Output

Each command will decide if it makes sense to show the adverbs used in the output for the command. For instance, 'quietly say' might echo 'You quietly say...' Alternatively, some might not be shown unless some condition is met, such as noticing someone trying to fake poor skill. Others may never show in the output for the command.

Implementation

An 'AdverbialCommand' will be created which will take the name of the adverb to set on the command. Commands that want to intercept an adverb will add a public boolean instance property (getter/setter) for it. When an AdveribialCommand is told to run, it will re-interpret the remaining arguments as a new command. Assuming it gets a new command back, it will use introspection to set the adverb as being used. It will then schedule the new command to run and exit. The new command will have to decide what the result is of the adverb on the command.

If the command does not have a public property for the adverb, the default behavior will be to give an error message 'You may not , try using command-emotes (see help command emotes)'.

So, if a Command wants to handle the 'slowly' adverb, it will add a 'private boolean slowly;' and an appropriate getter and setter for it. The slowly adverbial command will check to see if the command has a boolean setter for the 'slowly' property, and set it to true. When the command is run, it will determine what 'slowly' means for it.

Strict/Permissive Error Handling

There should be a user setting which allows the user to not get told if the command doesn't support a specific adverb, give a warning, but go ahead and do the command anyways.

Multiple Adverbial Commands

Multiple adverbial commands could be combined (for instance, 'in pig-latin quietly say hello'), depending on how this is implemented. If so the system would need to watch for opposing adverbs (quietly vs. loudly, quickly vs. slowly). One solution to this is to have each adverb maintain a list of 'unacceptable' other adverbs that it'll turn off if found.

http://feeds.feedburner.com/~r/mudreading/~3/248081054/hiring-for-m

I’ve noticed that for the last person we hired for Armageddon and for the last person we hired at work, the process was nearly identical. In both cases it was for a developer position. Our process is to say that we are hiring, receive applications with a certain type of information, choose some people to come in for interviews, have interviews that ask the same questions, then send a few offers.

What are the differences, though? That is the part that I find interesting.

Supply and Demand

In the software world, startups and new, exciting companies usually get a lot of attention from job-seekers. There is the chance to learn new and exciting technologies, having a fully stocked soda fridge and expresso machine, and of course the possibility of stock options making you a quick fortune.

In the MUD world, new MUDs are the ones that have to try their damnedest to bring on new staff. MUD forums are always full of posts about the need for coders or builders for a fresh MUD. Why is this?

First, new MUDs have a low success rate. As a hobby, it is very possible that not enough volunteers will be rounded up. Even if the game gets off the ground, its very hard to reach the critical mass where you have enough players for the playerbase to not just disappear during a lull. For MUD administration talent, its a risky move to invest in such a MUD, and many talented folks are more interested in starting their own project.

Most MUDs that are already established hire from within. Players of a MUD are usually very interested in joining the staff of their favorite MUD, so the game staff can remain sufficient even with a fairly high churn.

What can we learn from this? If you are starting a new MUD, be ready to hire through networking rather than forum posts. However, you should take some lessons from the software industry. Make your MUD an appealing place to work. For coders, advertise what cool new technologies you employ. For builders, make sure you have some unique features that are of interest. The competition is fierce, so make sure you answer the question: “Why is it more fun to work on this MUD?”

For established MUDs: Be picky. You probably have a boatload of players who want to help out. Look at the entire pool of potential staff and take the time to really get to know people and their qualifications. We used to hire by invitation, but hiring by an application process has let us consider highly qualified potential staff that had been flying under our radar in the past.

Celebrity Founders

Every heard of Pownce? It is a Twitter like site. Why do I know about it? Only because one of the original founders was known for his involvement in Digg. The world of software entrepreneurship has celebrities. Companies started by such a person get a lot of attention, both by users and by potential employees.

This doesn’t seem to happen with MUDs. New MUDs are likely to come from an average Joe, or an established group making a new MUD that does not need to establish a new staff.

Why is this? First, there seems to be a stigma surrounding leaving your MUD to go make a new one. You would be seen as abandoning your friends there. In the business world, people coming and going is simply a way of life and (usually) no offense is taken. This is infinitely worse if you try to recruit some of your talented friends to get the new project going. Talent poaching is highly frowned upon in the MUD world, even on a small scale. Lastly, people have a strong sense of loyalty to their MUDs. Even if the previous problems didn’t exist, few people want to embark on such a project.

Further, the MUD world doesn’t seem to have celebrities in the community as a whole. MUD administrators are often seen as celebrities in their own game, but players from other games will likely never of heard of them.

One way I’d like to mitigate this is to promote a more far-reaching MUD community. More networking and awareness of what is going on in other MUDs would help anyone who is trying to hire.

I don’t think I’d want to promote higher staff churn. I think the comradery and loyalty that MUD staffs have is a good thing, overall.

When you are hiring for a MUD, make sure to ask what a person’s accomplishments are, in and out of the MUD community. They probably don’t have 4 or 5 MUDs under their belt, but what they say should be interesting.

Expectations

The last difference between real-job hiring and MUD hiring that I’ll discuss is expectations. On both sides of the table.

MUDs are usually a volunteer effort. A staff member’s value is related to how many hours they choose to volunteer. Its obvious that someone who can devote 20 hours a week to a MUD is a great potential helping hand. Someone who has no time to help, no matter how qualified, is probably not going to get hired.

If someone gets hired onto a MUD, then produces less work than is expected of them, this is usually not a big loss. They can linger on as an occasional helper. If they produce no work whatsoever, or completely disappear, they can be taken off the staff list quietly with no incident.

In the world of business there is no such notion. A hire who is not as effective as needed is a major problem. They’re still around every day and drain resources without giving back.

This difference leads to less sense of risk and lower expectations in MUD hiring.

This is a good thing. Staff can be hired with a risk that they won’t work out. Some of these people might turn out great, and if not, the loss is not unbearable. Hires that are an active problem can be dealt with quickly. Be ready to take risks (if there is some reason to think the person may turn out very good) and pay attention to newer staff to see how the risk is paying off.

On the other side of the table, MUD players often expect that working on a MUD will be far more fun than a real job would be. Well, this is probably true, but occasionally there are unenjoyable parts of the job. Any reasonable interviewee for a paid job is ready for this, but far fewer MUD players are. Set expectations early. If someone gets scared by the thought of building an item that someone else designed for them, or talking to a player who has been misbehaving, they probably aren’t a good resource overall.

That’s all for today. As always I’ll leave an open question on the table. What is your best and/or worst hiring experience? From the perspective of either a employer or interviewee. Doesn’t need to be MUD related, but if it isn’t, how might the situation have been different if it was a MUD hiring?

http://www.zalanthas.org/blogs/brideofson/archives/001413.html

Dear Domino,

Will you please give a basic rundown of the commonly known worldwide animals and plants, at least so far as they're decided upon thus far? Failing that, can you tell us which flora and fauna will likely make the transition to 2.arm from 1.arm, and give us a couple new highlights?

Tisiphone

Domino says:

This is a project that Vanth and I started to tear through a few months ago, but we put it on hold until the areas themselves are built. I'd estimate it as about 50% done, and I'm looking forward to a time when I can pick it back up.

Almost all of the herbs and plants that currently exist will be making the transition to Armageddon 2.0, with some alterations to the names and properties of some of them so that we can do away with any IP infringements. Most if not all of them will be fleshed out in regards to possible uses and the folklore surrounding them, and it's likely that they won't act the same way they did in Armageddon 1.0. There are literally hundreds of herb and plant items, and many more will be added as we make sure that each herb has a plant, and vice versa. I would also like to ensure that every plant has a way for PCs to reproduce it, whether by taking a cutting of it, planting seeds, or for the more exotic varieties, something else entirely. Purely "decorative" plant objects should be a thing of the past.

Since literacy will be far more common in Armageddon 2.0, I'm hoping to create IC documentation for players to pursue ingame. The most commonly well-known plants will probably be listed in the OOC documentation, but I want to include some extras for those who want to study the subject ICly, while leaving plenty of room for experimentation and further learning. Imagine reading some bit of folklore about a rare herb that only grows in the high mountains and is sacred to the fuzzy-wuzzies, then sending out an expedition to discover it and experiment with its properties, eventually finding out through trial and error that it's the only known cure to the deadly kankblotch plague - then writing your findings in a book and selling it, forever immortalized as the one who made the discovery. That kind of thing is what I want to make possible.

The same goes for animals, to a large extent. Just as the herbs, all of them have their own separate wiki page with a list of fields to fill out, detailing their habits and habitat. The most common ones will get a blurb in the OOC documentation, and the more detailed folklore and habits should be discoverable IC. I'm not alone in wanting to ensure that each animal type has a place in the overall food chain, and that the food chains for each areas make sense and can be observed and reported by PCs in the game.

More of the animals in 2.0 had to be dropped due to IP conflicts, but there is a slew of new ones, including a few rare creatures that existed in Armageddon 1.0's database but weren't brought into common play for one reason or another. Mounts in particular I'm really looking forward to fleshing out, as we have a host of new types, each of which will be ideal for certain situations and poor choices for others. There will be no "super-mount" like the kank was (may they rest in peace), but there will probably be a couple "average" mounts that can handle most terrain types and situations - just not as well as another more specialized mount might.

Yes, this makes *5* of them now. Every last one of them I've bought in the last 2 years now is dead or dying. I've already turned the previous 4 in for warranty replacement. This one will make the 5th.

After investigating the usual causes for blue screens of death - bad drivers, incompatible software, rogue code, etc - I've come to the conclusion the drive itself is showing the same signs my servers showed before. These things manifest more subtely on Windows boxes and if I hadn't suffered so many failures before I might have missed it entirely.

So once more, Hitachi will save my behind from another big fat mess. And to think, I just put the bloody drive back into a brand new motherboard and CPU and this is the thanks I get. At least the data is still readable so I can take the drive in and use the cloning machine at work.

And again, for the love of God, nobody buy Western Digital! This is just plain stupid!

http://feeds.feedburner.com/~r/mudreading/~3/233546891/three-space

Approximating three-dimensional space is an interesting challenge in a text-based game. It is very easy to create a simple, sufficient model. Complications run the risk of confusing players and piling on the work for builders. I’m going to look at a few approaches, their advantages and disadvantages, and talk about an idea that I haven’t seen used.

The standard MUD approach is to use weight as its only measure of not only weight, but also size. The capacity of a container is judged by how much weight it can contain, and a character’s encumbrance is simply their total carry-weight versus a maximum, generally derived from their various attributes.

This works well in general, and is conveniently simple, but there are a few cases that throw this system off.

First, object shape is not taken into account. In my experience long, skinny objects cause the most weirdness, as the game mechanics don’t see any reason to protest putting a spear in a belt pouch.

Second, objects that vary wildly in density can cause confusion. If a player has a bag that can carry an entire wardrobe of silk they may be suddenly confused when a 7 pound sword cannot fit inside.

I have seen a few attempts to solve the size problem. The simplest is a single “size” field, separate from weight, that is then used instead of weight when determining the amount of space taken up in a location or container. This works well enough as it represents density, but it does not help our spear scenario.

In some cases further size fields are added. In the next step we start to approximate each object as a geometric shape. With two fields, width and length, you effectively consider every object a cylinder. This works well: it is able to represent those troublesome spears, and a cylinder with equal length and width is sufficient for less exotically shaped objects.

The other approach I’ve seen is including a height, width, and length: a cube. In terms of MUDs, the difference between this and the cylinder representation is not extremely great. Generally the most important checks on size involve fitting objects through openings such a door or a chest’s lid. Since such an opening is two dimensional, the smallest dimension does not play into the calculation.

I haven’t seen an attempt to create any more complex representation of size and shape. Allowing an object to be one of various geometric shapes would be maddening for a builder, much less do any calculations with, and the advantages of this level of simulation are unclear.

I’d like to propose a different approach to shape and density. I assume this is not a truly novel idea, but in my experience I haven’t seen it done in a MUD. If you know of a MUD that does this I would be fascinated, so please leave a comment about it!

Lets assume (as I always do) that we want to minimize builder effort and have extremely consistent objects in our game. We will have size and weight, as they are both useful pieces of data, and we are going to use width and height for size, as this is a sufficient representation of shape for our purposes.

The implied field is density. Say we have an object that is 12 inches high, 6 inches wide, and weighs 3 pounds. Approximating its shape as a cylinder, the object’s density is about .0088 pounds per cubic inch. Every object will have a density, based on the builder-supplied height, width, and weight.

An inconsistency has arisen, be it a subtle one. Lets say two builders create iron swords. They approximate the dimensions and weight as best they can, and each value seems appropriate. However, the density for each object is different due to the natural deviation you would expect in such an approximation. In reality, iron, as a substance, has a given density that does not vary so much.

We can remove this inconsistency and reduce builder effort at the same time. Assuming objects have a material type (most MUDs I’ve seen do) we can attach a density rating to each material type. A quick look on Google shows me that the actual density of iron is around 0.284 pounds per cubic inch, so lets use that.

Now, we can figure out everything we need to know simply by asking the builder the height, width, and material of an item. The weight can be determined automatically.

Lets say I create a sword of height 3 feet, width 1 inch, and material iron. A little math on the game’s part tells us that such an item should weigh eight pounds. This is about what a three foot sword weighs in real life!

36 * π * .5^2 * .284 = ~8

This approach sounds good to me, and I’d love to see it used in the future. I’ll leave an open question though: What MUD features might require a more complex representation of size, and how would it be done?

http://www.zalanthas.org/blogs/brideofson/archives/001412.html

Thinking up names is Serious Business.

Domino: I need help thinking up names for the Adevari settlement.

Domino: because corada sounds like a beer.

Adhira: She needs a non-beer related name.

Morgenes: ok, how about: gihness

Adhira: Mor-gihness?

Domino: Grylsch.

Morgenes: or: buhdlyt

Vanth: Pahbzt

Shalooonsh [M40097]: Grylsch...

Morgenes: yes please

Xygax: Lesgihness, Morbass, Blactan

Vanth: High Nakin.

Domino: Xyngling.

Adhira: Ohhh Xyngling!

Morgenes: emgeedee

Vanth: D'Osekis.

Xygax: Never order a black&tan in front of an Irishman, also, if you'll pardon the seeming non-sequitur.

Domino: You guys are hopeless.

Morgenes: ya, Hope died a long time ago

Adhira: Call it Hope!

Xygax: Hefvisen

Adhira: Then it can be like a soap opera town.

Domino: that's actually the best idea I've heard so far. but doesn't really fit their history.

Morgenes: actually looks like Hope didn't die, she just quit playing around 1999

Morgenes: *misses having Hope leave the world of Armageddon*

Tiernan: Hope has forsaken Armageddon

Vanth: make it a 2-word name, like Gol Krathu or Vrun Driath.

Adhira: Haha. That's great.

Adhira: I like the 2-word name idea.

Morgenes: how do you know if you're old staff?

Domino: Now I just need to make a character named Hope.

Xygax: Wow, Hope was a (class edited out)

Morgenes: you remember Hope leaving Armageddon

Shalooonsh [M40097]: Grylsch-Schlaggah

Adhira: Mor Gihness

Xygax: In the (clan edited out)

Xygax: Which explains a lot.

Domino: "Hope has entered the world of Zalanthas in the Gladiator and Gaj tavern."

Morgenes: Moor Gihness

Domino: Hah, that's neat.

Xygax: Hope is a (edited out) woman.

Adhira: She sounds spooky.

Domino: Totally.

Xygax: I wish my dumb cstat code didn't smash keywords.... I should fix that.

Morgenes: apparently Hal didn't think much of her roleplaying

Xygax: I just typed "purge hope", and the game said "Ok."

Domino: Looon, you're my only hope. I need two-word names.

Morgenes: Ok

Domino: *grin*

Xygax: And then I typed it again, and the game said, "I don't know anyone or anything by that name."

Adhira: Hope was Crazy.

Shalooonsh [M40097]: Serious about the Grylsch-Schlaggah... or Omi-Yullara

Domino: Hope was wild.

Morgenes: Beh Eer

Xygax: Yager.

Shalooonsh [M40097]: Gol-Thryzdu

Domino: siiiigh.

Shalooonsh [M40097]: (if the thryzyn have anything to do with it)

Adhira: Vrun Hope.

Adhira: It's an elven settlement,

Adhira: Maybe your delves!

Adhira: Vrun Elan.

Vanth: Dar Hopa

Shalooonsh [M40097]: DOH... Adevari, right! Ha!

Morgenes: Darth Chad

Shalooonsh [M40097]: okay, let me grind something out, gimme a minute, in scene here

Adhira: Or just Elan.

Adhira: That's classy - it has Elan.

Vanth: Hopa Vari.

Shalooonsh [M40097]: Abi'situn could work (Dusk of the Land)

Domino: We're probably going to do away or mostly away with the (edited out), though.

Vanth: Elan Vari.

Xygax: Beerbelly

Domino: I want something that sorta translates into "we're tough motherfuckers, and we've survived the worst, and this place is our rock to cling to."

Domino: So, uh, fit that into two words.

Morgenes: kehgger

Domino: Perfect.

Adhira: Jager Meister

Vanth: Deh Waryurz.

Morgenes: Kanking Heroes

Domino: I'm seriously tempted to blog all this for the players.

Morgenes: Serenity

Vanth: Deh Ayteem.

Vanth: you should.

Morgenes: Mehk Guyer

Tiernan: The Chad is Rad

Domino: Someone duct tape Morgenes.

Shalooonsh [M40097]: Jee eye Joh

Vanth: Bee Esgee

Domino: Dude.

Tiernan: Koh Brawr

Domino: And then I can have an NPC named Jinx.

Morgenes: Bee Esgee Ray Zoor

Morgenes: oh, I know, call it Chuck

Domino: Elan sounds like a possibility.

Morgenes: oooh, or Bob

Morgenes: Planet Bob

Vanth: Bayoh Bob.

Tiernan: What are we making up names for again?

Morgenes: Degobah

Vanth: the Adevari settlement.

Tiernan: Like NPC names or what?

Domino: It's in the northwest tablelands.

Domino: nah, the settlement itself.

Domino: The original name sounds like a beer.

Vanth: the settlement name itself, it was Coruna, then Corada, but they both sound too much like Corona.

Domino: Corona. I mean, Corada.

Morgenes: Coruscant

Tiernan: Whatever you do, avoid apostrophes

Morgenes: Adevaria

Tiernan: Nothing worse that trying to talke about M'Rhgf'hgashs'hgashd'-smith

Vanth: that sounds like an Iron Realms game.

Domino: Planned to avoid em, yeah. Thinking of going with a two-word name though.

Tiernan: Helm's Deep

Tiernan: Oh wait, LotR

Domino: Everyone will shorten it to one name anyway.

Vanth: Ade Lehmon.

Morgenes: use a name generator, there's plenty out htere

Domino: Are there any "allundean" words that translate to "refuge"

Shalooonsh [M40097]: yes

Domino: yeah, and they all suck, but it's a possibility

Vanth: there's an allundean lexicon?

The inordinately young-spirited Shalooonsh [M40097] sends:

"I'll fire you a list of good ones in a moment here"

Tiernan: Milliways

Domino: awesome

Shalooonsh [M40097]: not a whole lexicon, but I believe refuge/safety are covered in the Sun Runner docs, if not I'll configure something

Morgenes: http://nine.frenchboys.net/country.php

Domino: whoa, morgenes rocks.

Domino: Definitely staying away from 'B' names

Morgenes: Utul Marsunas

Morgenes: Iteos Ursor

Tiernan: Nydia

Relleu: that was a weird point in the conversation for me to log in... nine frenchboys.net... definitely staying away from B names!

Tiernan: I googled "latin refuge" and got this hit:

Tiernan: Nydia : NIH-de-yuh : latin "refuge"

Domino: Neat.

Adhira: Wai Tangi

Tiernan: The Chronicles of Nydia

Domino: Good point

Domino: But that would be kinda fun, roll up a scribe

Relleu: I knew a Nidia in school, and I had a Nithia as a student

Domino: Write 'the chronicles of Nydia' and stick it in a library.

Vanth: Ombaal is the (info edited out).

Domino: That's a neat one.

Vanth: and Sejah is (edited out).

Vanth: alternate spelling of Ombaal in same docs is Oombaal

Shalooonsh: in game it's typically Oombaal

Domino: Actually, access to the d-elf tribal documents would be a huge help in writing the Adevari docs, because I want to pull in flavor from all of them, as well as from some of the human tribes, to make up one comprehensive whole.

Domino: A huge mish-mash of previous arm culture, shaken and stirred.

http://feeds.feedburner.com/~r/mudreading/~3/226277456/more-than-mu

I ended up reading this fine blog due to a link from a commenter on this site, and from there started exploring various other types of “Interactive Fiction” (IF), that being a general term for the type of games that includes MUDs.

Its interesting just how isolated the MUD community is. Really, I have had almost no experience with the other types of IF.

For example, I didn’t even know what a roguelike is until I started playing Legerdemain, which was a fantasticly novel experience for me. To a MUDder, this is a graphical, single-player MUD. Graphical only in that there is a colorful ascii representation of your world, and MUD-like only in the similiar set of text-based commands. The biggest draw was the way exploration works, and I only stopped playing when the difficulty started wearing me down. I doubt this will be my last run-in with roguelikes.

Of course, the type of IF that everyone is familiar with is games like Zork (basically a single-player, turn-based MUD), which I did enjoy greatly at some time long past. What’s interesting is that there is still a community for this and new games that are released. And I, someone who has dedicated years of my free time to games that are effectively the same thing, have played none of them.

Assuming I’m not simply daft and that the separation of these communities extends beyond my own personal ignorance, my first response to it is that this is a problem. I want to see communities for lovers of all forms of interactive fiction. If there are any, I want to see what they’re like and why I haven’t heard of them. If there are not, I want to take a shot at creating one.

Getting my feet wet in the roguelike world seems like a good start. I’m thinking about writing my experience on this site, but I don’t have a good feel for if my readers would be interested in hearing about it, since its not MUD-related. But I do think you should be interested! Are you?

http://www.zalanthas.org/blogs/brideofson/archives/001411.html

Based on the feedback from everyone we've made some changes to Tyleki, from how it was when we first announced it.

We've gotten rid of the mindbenders, they're simply outlawed from Tyleki and discovery of one will either result in its death (if the person dealing with it is confident their militia can take it down and that the person actually is a mindbender) or exile (if they're uncertain they can take it on or if they're uncertain it truly is a mindbender). They aren't trusted or accepted by normal people in Tyleki, although a good way to get rid of a competitor, if you can afford it, is to bribe a ruling family member and then accuse the person of being a mindbender.

However with mindbenders gone, we were left with trying to work out a way for the Tyleki ruling families to keep magickers under control. We had considered uniting the three militias into one force, as they'd be more effective that way, however the three separate militias seemed fairly popular. Instead we decided to have a special herb used in a tea that when drunk, limits the ability of a magicker to use their magick (doesn't negate it completely, but does make it more difficult). This herb will be foragable from where it grows, but specific details have yet to be worked out. The tea also has the side-effect of being extremely addictive and also causes changes in the person's physical appearance (which changes are yet to be determined) so that magickers have a harder time hiding.

Also there won't be widespread acceptance of magickers. Instead it will be up to players to decide their opinions on magickers, although most Tylekans would probably consider them to be dangerous to a degree with non-drugged magickers extremely dangerous.

This will help lower the tensions between the ruling families and ordinary citizens a bit as they won't appear to have super weapons pointed at each other.

Unrelated to the above, people were confused with this paragraph:

While only the Council can make laws, they cannot enforce the law and are instead reliant on the founding family guards to do this. In earlier times, the Council had more control over Tyleki. With the recent tension between the ruling families and the townspeople, the families have taken back much of the control from the actual Council.

In a ruling family there are two ways to gain power: become the family's leader or become the family's council representative. The power the Council representatives have within their family differs from family to family, but at their most powerful they have greater control then the family's leader.

The reason for this dual-power is because of a law was passed early in Tyleki history by the Council, that forbids the family leader from also being the Council's representative. This is fertile ground for tension between the leader and representative of a family. Sometimes the two have a power struggle for many years, other times one has dominated the other. In some family's this is more likely then in other family's, because of how the council represntative is chosen within a particular family.

A lot of other questions, comments and concerns were raised on Tyleki, however I'm not sure if this addresses them or not, so please ask again any questions you still have.

Oh and Ovirne from a previous post is a war hero ;)