[MUD-Dev] In-Game Languages

Michael Hohensee michael at sparta.mainstream.net
Mon Apr 5 02:36:33 CEST 1999


Chris Gray wrote:
> 
> [Eli Stevens:]
> 
>  >It works by converting each of the 26 letters of the English alphabet into
>  >one of the ten characters that define the language.
> 
> This is an interesting technique. Certainly faster than others I've
> heard of. I'm curious as to how you came up with it. Is there some
> linguistic basis behind needing only ten letters? Certainly the full
> 26 aren't really needed, but I'm surprised that only 10 are. Can you
> give some of the "philosophy" behind this, or was it mostly trial and
> error to produce something that works as desired?
> 
> How does someone with the given language skill read the output? Do they
> simply get the untranslated version, and others get the translated version?
> Does this work for written material too? (It could - you would just have
> to have a language flag on all text, and do the translation on final
> output to the player, so that a player could carry around a Dwarvish
> book, and finally read it after learning the skill.)
> 

I didn't mean for this reply to get so long, but it kinda grew in the
writing:

We must be careful in how we implement this, however.  If you're doing a
simple rot-X or substitution code, enterprising players might deduce it
through learning the language, writing one letter in it, and showing it
to an ignorant character.  The player might then write a script for some
client which translates the language on the fly, and that would kinda
ruin the neatness of languages.

One solution to this is to show ignorant players random gibberish
whenever someone speaks, but that precludes the example of writing a
book in dwarvish.  (What sort of book has different letters in it each
time you look at it?)

A better solution would be to store the dwarvish text in plaintext on
the server, and translate it into code for those who can't read it. To
make it harder for someone to deduce this code, make the word-munging a
function of the numerical version of the character's name.  This makes
it next to impossible for someone to produce a way to cheat the system,
and has another added bonus of doing a little RP enforcement:

Boffo, who cannot read dwarvish, has a dwarven sword with the words
"hwjel ahofi" inscribed upon it.  This is a unique sword, and if anyone
stole it, he'd recognize it based upon the inscription, even though he
cannot read it.  Suppose this sword is stolen by Buffy, who runs off
with it and shows it to Bubba, who happens to be run by the same player
who runs Boffo.  Bubba is also ignorant of dwarvish, and can't read the
inscription.  If the player saw "hwjel ahofi" on it, however, he'd know
that it was Boffo's sword, and might take some inappropriate action. 
But since Bubba's name is different from Boffo's, he sees something
else, like "klsj ewilhf", and doesn't suspect anything.

The only drawback to this would be that players couldn't sound out the
foreign words to one another with any degree of consistency: "Hey Bubba,
what's 'kahas' mean?  It's written on this sword." (Bubba, instead of
seeing "kahas" sees "najs", and begins to lose his sense of immersion). 
It also prevents Bubba from copying down these foreign words, which he
should be able to do.  This could be solved by a slightly more complex
system:

Each language translates cleartext letters into multi-letter
combinations which do not generally exist in english.  Which combination
is assigned to which letter depends on the character's name.  The goal
is to make sure that no combination of cleartext letters can create a
remotely english word.

If we are dealing with multiple languages, divide the letter-combination
space into as many chunks as you have languages.  Then use the
character's name as a method for picking letter combinations out of
these spaces to correspond to cleartext letters.  If we use combinations
of three or four letters, this should work for a few languages.  Note
that nonalphanumeric characters should be given the same form in each
language, for reasons which will become apparent in the example below.

Check each word that the player says to see if it fully matches a
possible word in some language unknown to that player.  Do this with the
following C pseudocode:

struct each_word
{
	int language;
	char *cleartext;
};

for (each word in string)
{
foreignword = FALSE;

if (word can be evenly split into chunks of N letters)
{
	foreignword = TRUE;

	for (chunk = chunk#1;lang = language chunk#1 belongs to;
	     chunk != NULL;
	     chunk = chunk->next)
	{
	if (language chunk belongs to != lang)
	  foreignword = FALSE;
	}
}

struct each_word clearword;

if (foreignword)
{
  clearword = reverse_translate(word, lang, character_name);
}
else
{
  clearword = make_word(current language of speaker, word);
}
}

We then generate all our output in terms of these "clearwords",
translating them as necessary.  This allows:

Bubba: (speaking Human) "Hey Buffy, what's 'klahs' mean?"

('klahs' is what Bubba sees whenever the word "dumb" appears in
Dwarvish)
(the MUD interprets this input according to the above algorithm, comes
up with the list:

{Human, "Hey"},
{Human, "Buffy,"},
{Human, "what's",
{Dwarf, "'dumb'"},
{Human, "mean?"};

Since Buffy speaks Dwarvish, she sees:

Bubba says, "Hey Buffy, what's 'dumb' mean?"

Buffy: (in human) "It means 'dumb'."

With the addition of some simple tags, Buffy could have said:

Buffy: (in human) "It's a complement, you my friend, are
<dwarvish>dumb</dwarvish>."

And Bubba would see:

Buffy says, "It's a complement, you my friend, are klahs."

As you can see, the fun never ends.  By now you've noticed why I
stipulated that nonalphanumeric characters should have the same
translation string in all languages, since they serve for nonverbal cues
(emphasis, tone, timing) which should be apparent to all characters.  If
you want to implement a *really* alien language, you can give it
different translation strings for some letters like !,?, etc.  You can
even make the distinction between being able to read and speak a
language in this manner, by specifying written dwarvish as being a
different language than spoken dwarvish.

Other effects:

Player #1 plays Bubba and Boffo, and neither of them speak or read
dwarvish.  Bubba has, however, seen a lot of dwarvish script, and the
player can usually recognize dwarven inscriptions when Bubba sees them. 
When that same player plays Boffo, however, these same inscriptions look
different, and if Boffo hasn't seen a lot of dwarven inscriptions, the
player won't be able to recognize the language while playing Boffo.

Boffo can decipher elven writing, but cannot understand spoken elvish.  

<Insert cool realistic example here>


Cons of such a system:

More CPU overhead
More bandwidth requirements for foreign words.

These really aren't so bad.  Given modern computing power, the CPU
overhead for such a system shouldn't be too horrible, and the bandwidth
increase due to the tripling or quadrupling of the amount of foreign
text transmitted over the network shouldn't be too much of an issue. 
It's not like we're transmitting 12k of text on a regular basis. 

There you have it, my design for a MUD language system, devised on the
fly.  Does anyone see any flaws/room for improvement in this system?

Michael Hohensee
michael at sparta.mainstream.net
http://pages.nyu.edu/~mah248/


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev




More information about the mud-dev-archive mailing list