[MUD-Dev] How to handle/display partial language skill
chattemp at ee.port.ac.uk
Wed Jan 19 14:54:36 New Zealand Daylight Time 2000
On Tue, 18 Jan 2000, Joe Kingry wrote:
> We have a very basic way of handling languages on our mud. Currently each
> language has a table of sylables/words and a mapping to a some assortment of
> letters. Each language table of course has a mapping for individual letters.
> When someone says something in a different language, those that can
> understand the language see something like:
[Snip example output and map]
We used an almost identical system on B5 MUSH, a long time ago, and I
believe they still use it to this day. The only different was that we
took mostly pairs of letters which can occur together, and mapped these, ie:
ee -> a
tt -> s
and then a few single letters and mapped them to others, carefully
testing all the time, so that the output from common words had the
'appearance' of being 'foreign'. How you interpret something appearing
foreign or alien is upto you, of course. :)
The obvious point which I would raise about this system (its kinda
negative criticism, though), is that it's not really how it works, and it
breaks down when doing partial representation. Think about a foreign
language for a moment, and you'll find that words change their place in a
sentence (German is notorious for this, among others), some words may
mean three or four things in English, and so forth.
> But how do you handle non 100% skill in a language? I imagine in our case
> with a table that maps various fragments you could do a reverse map of the
> fragment only if you passed a skill check. I've experimented with this with
> varying results. I'm just looking for other ideas at this time.
We used to do this on B5, yeah. There was a slight problem in that you
get double-errors. Ie, Person A has 50% skill, Person B has 50% skill. We
now allow A to speak with 50% accuracy (0.5 probability of getting a
specific letter/letter-pair/phrasing correct), and B to listen with the
same accuracy (0.5 probability to interpret correctly).
As a result, B has an 0.5 x 0.5 = 0.25 probability (25% chance) of
hearing any given set of letters (one translation) correctly. Whereas in
a slightly more sane universe, if I were half-fluent in French, talking
to someone who was also half-fluent in French (assuming no *common*
language), we could both 'dumb down' our speech, point at objects,
gesture, and so forth until we made ourselves understood.
This leaves a potentially very tricky puzzle, but, if you ask yourself
one question first, it becomes easier:
What am I using languages for?
In the context of my most recent MUD project (An LP called Caffeine,
which is currently stagnating very nicely due to my utter lack of online
time beyond the odd email-check), we contemplated some form of language
system, and then decided that all it would do was hinder people in
communicating, in a game where we want to encourage communication and
On B5, the game context was full-Roleplay with very few (next to no)
automated systems, and the addition of languages (given that everyone
shares a common tongue, almost without exception), allowed racial groups
to converse in their 'natural' language, both allowing 'concealed' IC
communication (unless a 'spy' who could understand was present), and
quite simply created some interesting roleplay situations.
However, I would argue that in the latter example, good roleplayers could
do the same without any language code (mind you, that assumes that you
are dealing with good roleplayers who need fewer, *or* more sophisticated
tools, not poor roleplayers who rely on relatively basic, but functional
tools to support them).
Anyway, I feel that I'm digressing.
The best approach (I have not tested this, personally) might be for now
to take a full on 'syllable translation' approach in this ilk, taking
each unique syllable pair (within reason) and changing it, using a
similar algorithm. Perhaps add more complex routines to
change/move/remove ifs, thes, Is, and so forth, just to jumble it up a
little - but remember you are essentially encrypting the text. If you
can't decrypt it at the end, its useless. :)
-- Matt Chatterley
".. You live for the fight, when its all that you've got .."
Jon Bon Jovi; Livin' on a Prayer, as always.
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev