Draft Specs for a new IF platform
rgrassi
requirements.
(Working Name of Tool to be discussed and agreed).
We'll need to setup a CVS server, i presume (sourceforge?).
My first requirements are:
1) Language indipendent engine
1.1) Game World Abstraction (Flat File DB?, Database?)
1.2) Dictionary Abstraction (Flat File DB?, Database?)
1.3) Grammar Abstraction (Flat File DB?, Database?)
1.4) Player Input Abstraction
2) OS indipendent
3) Multiplayer gaming
3.1) Client Abstraction (Browser Based, IRC, Telnet)
3.2) Gaming style player-based (p&c, parser)
4) Multiauthoring
Let's start discussions.
If all goes well this post could fix a cornerstone.
Rob
rgrassi
---------------------------------------------------------------------------------------------------------------------------
1) Language indipendent engine
With this i mean that the engine should perform its task without
considering specific input/output grammatical language structure. A way
to obtain this result is to let the engine work with a meta-language
(or esperanto?) and resolve the issue to "localized interpreters" which
convert the input/output text.
1.1) Game World Abstraction (Flat File DB?, Database?)
Classes, Objects, Relations and Behaviours shouldn't be 'hardcoded'.
Behaviour of objects and relations should be easily overridden by
acting simply on the "Exposed Game Model" instead of the source code.
1.2) Dictionary Abstraction (Flat File DB?, Database?)
"Names" and "Synonyms" shoud be language indipendent and converted by
the engine into the player language dinamically.
1.3) Grammar Abstraction (Flat File DB?, Database?)
Grammar rules, articles, gender convertion, prepositions, etc... must
be handled by the "core engine" in a language independent way, then
must be converted and displayed into the player language dinamically by
the "localized interpreter".
1.4) Player Input Abstraction
The "localized interpreter" will perform all pre-parse stuff and will
manage and replace the command giving the input to the core engine for
the correct action to be performed.
---------------------------------------------------------------------------------------------------------------------------
2) OS indipendent
---------------------------------------------------------------------------------------------------------------------------
3) Multiplayer gaming
3.1) Client Abstraction (Browser Based, IRC, Telnet)
With this i mean that the player should be able to play the game with
the preferred client. Multiplayer gaming must be ensured, independently
from the client.
3.2) Gaming style player-based (p&c, parser)
With a given client, multiple gaming style must be allowed. Point&Click
(resolving to hidden command line input to ensure compatibility),
parsing, vocal commands, Cyoa-Styled (for novice players, for instance)
---------------------------------------------------------------------------------------------------------------------------
4) Multiauthoring
Concurrent authoring must be allowed.
---------------------------------------------------------------------------------------------------------------------------
Cheers,
Rob
ChicagoDave
Ah yes, here it is...quite raw:
http://www.ifwiki.org/index.php/Building_a_new_interactive_fiction_system
But I suppose this is more of a general article and really meant to be
a design article...
Maybe you could start a requirements page....Requirements of an
Interactive Fiction System
I'll start with an outline for a generic world model...
- World Model
- natural abilities
- map building
- standard compass rose (N, NE, E, SE, S, SW, W, NW, UP, DOWN,
IN, OUT)
- doors
- lock and key
- other non-standard location bridging techniques
- scenery items
- described
- referenced
- altered states
- interactivity
- movable items
- described
- referenced
- altered states
- interactivity
- non-playing characters
- described
- referenced
- altered states
- interactivity
- multiple players
- cross-referencing
- turn manager
I could go on...but this is just a thought....
David C.
ChicagoDave
this is so hard to get your brain around...
Author's View
In the author's view we concern ourselves with giving the author the
ability to build a map and to describe the environment.
Programmer's View
In the programmer's view we concern ourselves with giving the
programmer the ability to articulate the map and environment
description into functioning components.
These two views must overlap effectively for the world model to
function properly and for the author and programmer to as simply as
possible do their work.
It almost seems like the author's view is a script and the programmer's
view is source code.
I doubt the author has any care for the code view. They're strictly
interested in describing the place where their story takes place and
the logical (in natural language) interactivity of the story
location(s).
The programmer however requires both views so that they can implement
the descriptive texts and the natural lanuage logic into code.
David C.
ChicagoDave
http://www.ifwiki.org/index.php/Requirements_of_an_Interactive_Fiction_Development_System
David C.
rgrassi
I'll update it when i can, but i think discussion, at the moment is on
defining a really new way of thinking how to play and write an IF.
Rob
ChicagoDave
DC
David Thornley
rgrassi <rgras...@gmail.com> wrote:
>I think it's time to start discussions for a new IF platform gathering
>requirements.
Um, why? What don't you like about existing platforms? Looking
at the points below, it seems like you want multiplayer capability,
and that opens a very large can of very wriggly worms. I'd say
it's worth wrestling with on its own rather than as part of another
project.
Not to mention, what do you mean by a platform? The language or
the virtual machine? What do you mean by language-independent?
>2) OS indipendent
>
How independent? Should it run on a PDA?
>3.2) Gaming style player-based (p&c, parser)
>
Not all games will work well in either style. How about games where
the verb list constitutes a spoiler? (I used it as such in Scott
Adams games, back when I had my TRS-80.)
>4) Multiauthoring
>
Again, this is a big topic. It's already possible to collaborate,
as shown by numerous IF games with more than one author. Do you
know what those people found annoying, and what they could have
used?
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
rgrassi
> >I think it's time to start discussions for a new IF platform gathering
> >requirements.
> Um, why? What don't you like about existing platforms?
The things for which I'm making requirements... :)
> Looking at the points below, it seems like you want multiplayer capability,
> and that opens a very large can of very wriggly worms.
Not only. I want language abstraction, too (on the server side) and
other things I'll specify when my thoughts consolidate.
> Not to mention, what do you mean by a platform?
An IF development application.
> What do you mean by language-independent?
I mean that a game is developed in the language of the author and can
be played (with very few effort of localizations) by everyone. The
player types the command in his/her native language and the program
"processes" the action and returns the results to the player in his/her
native language.
> >2) OS indipendent
> How independent? Should it run on a PDA?
Yes.
> >3.2) Gaming style player-based (p&c, parser)
> Not all games will work well in either style.
It's up to the player.
The "platform" should support these feature.
Rob
Uli Kusterer
"rgrassi" <rgras...@gmail.com> wrote:
> I mean that a game is developed in the language of the author and can
> be played (with very few effort of localizations) by everyone. The
> player types the command in his/her native language and the program
> "processes" the action and returns the results to the player in his/her
> native language.
Hi Rob,
How many languages do you speak? If the only language you speak is
English, then forget about this project now. If you only speak two
languages or so, I'd guess it depends on what languages these are. E.g.
most "European" languages descend from a few common languages, so are
very similar. Put really different languages like Finnish, Japanese or
any Indian language into the mix and it gets exponentially more
complicated.
What you are talking about is machine translation. This in and of itself
is a very complicated topic linguists have been working on for the past
decade or so, and it's very involved.
To put it in simplified language (because I don't want to repeat 5
years of "Linguistics 101" lectures here), there is no one-to-one
relationship between words in two languages, which is why you usually
see at least two words listed in a dictionary as being equivalent to the
original one.
This, in turn, means that the computer has to have *some way* to pick
the right word to translate an English word into. To pick the right one,
the computer would actually have to understand the sentence, which means
you'd need artificial intelligence (real AI, not just the comparatively
crude "AI"s you have in today's computer games.
And finally, once you have that, all you'd have would essentially
equate to the language skills of the average ten-year-old. But since
most IF is written as literature, with lyric phrases, quotes and plays
on words, you'd effectively have to build the ability to write good
prose into your translator, along with a database of all the texts that
the original author of the game may have quoted, so it can pick the
correct translation the player will recognise.
As a simple example:
"Here's looking at you" is
1) a quote from "Casablanca"
2) literally means "I'm keeping an eye on you"
3) is a way of toasting to someone before a drink
Translate those to German and you get:
1) Luckily, "Casablanca" has the same title in Germany, but had it been
from "Mighty Joe Young", the German title it was released under would
have been "Mein Freund Joe" ("my friend Joe")
2) "Ich hab' Dich im Auge"
3) That would be "Prost" or "Zum Wohl" in German ("to your health").
So, which translation, #2 or #3 would the computer pick? How would it
know that #2 is an option without including the whole Webster's? And if
this is an allusion that is supposed to be a hint about the *place*
Casablanca in the end, then how would someone playing the translation
know that for a movie with a different title?
So, unless you have a solution that millions of linguists and software
engineers haven't come up with in the last decades to solve this problem
already, you should be aware that this single bullet-point in your
outline alone is a project in and of itself. Just thought I'd let you
know.
Cheers,
-- Uli Kusterer
http://www.zathras.de
Uli Kusterer
"rgrassi" <rgras...@gmail.com> wrote:
> With this i mean that the engine should perform its task without
> considering specific input/output grammatical language structure. A way
> to obtain this result is to let the engine work with a meta-language
> (or esperanto?) and resolve the issue to "localized interpreters" which
> convert the input/output text.
I just realised: Since you wrote "Esperanto" I assumed you were talking
about natural language. Maybe you meant programming languages here?
Due to the limited vocabulary and rather strict syntax of most
programming languages (compared to natural language), translating
between those would be possible. The problem in that case would be that
you'd effectively have to write a full parser for all languages that you
accept as input, then translate them into an intermediate form that you
need to design in a way that it can express everything these languages
can express (and which you will have to radically change if one of your
supported languages gains a new feature you didn't expect).
The output is generally very straightforward. The only problem is if,
e.g. a certain language has a limit on the number of objects, or on the
amount of memory used or so... because your intermediate form would
either have to include *all* limits of all your applications, or it
would have to use tricks to get around some limits. And for those limits
it can't work around (e.g. hard memory limits on a PDA), the translation
would simply fail.
So, this still isn't trivial, but at least it's a project that has been
fully researched.
Just trying to make sure you know what you're getting yourself into.
-- Uli
http://www.zathras.de
Uli Kusterer
> 1.1) Game World Abstraction (Flat File DB?, Database?)
>
> Classes, Objects, Relations and Behaviours shouldn't be 'hardcoded'.
> Behaviour of objects and relations should be easily overridden by
> acting simply on the "Exposed Game Model" instead of the source code.
>
> 1.2) Dictionary Abstraction (Flat File DB?, Database?)
>
> "Names" and "Synonyms" shoud be language indipendent and converted by
> the engine into the player language dinamically.
>
> 1.3) Grammar Abstraction (Flat File DB?, Database?)
>
> Grammar rules, articles, gender convertion, prepositions, etc... must
> be handled by the "core engine" in a language independent way, then
> must be converted and displayed into the player language dinamically by
> the "localized interpreter".
These points sound like some of the stuff Plugh and I discussed for the
open-source successor to Plugh! (http://plugh.info/). We didn't go into
too much detail there, but we talked a little about an internal model.
Of course, that model would include dictionary terms and even some info
(like the gender of an object and whether it's a plural word). I
wouldn't use a completely separate dictionary here, but a dictionary
view for the game author might really come in handy.
Cheers,
-- Uli
http://www.zathras.de
Uli Kusterer
> 3.2) Gaming style player-based (p&c, parser)
>
> With a given client, multiple gaming style must be allowed. Point&Click
> (resolving to hidden command line input to ensure compatibility),
Technically, it'd be easier to go the other way round: You need an
internal representation (some data structure) in which you store a
command once it's been parsed. So, for point-and-click adventures, you'd
simply bypass the parser and have the display and click-handling code
directly send a data structure like:
<action>
<task>open</task>
<directobject>front_door</directobject>
</action>
or so...
> parsing, vocal commands, Cyoa-Styled (for novice players, for instance)
Most of these options (except voice commands, which can be handled as a
variant of text input) would actually depend on what game you're
playing. For the typical parser-controlled IF-Game, CYOA wouldn't really
be suitable, as the number of actions possible at any one point in the
game would be daunting to a newbie. You'd have to actually mark up a
subsection of the commands to make them show up in a CYOA-game (and
prevent pointless or unimportant ones from doing so).
So, I'm not sure you want to specifically support all of these variants
as separate variations to play one game with.
In general, I think to ensure the size of your project remains
manageable, you should really decide what you want it to be:
1) An IDE that focuses on *creating* a game for other interpreters,
using other compilers
2) An Interpreter that offers lots of different ways for controlling
games (here you'd probably want to use an existing interpreter for an
existing language and extend it)
These two alone are a lot of work. If you want to create a universal
interpreter, compiler *and* IDE, you'll have a *lot* of work ahead of
you. Just ask the authors of Inform, TADS or HUGO how long it took them
to create their systems. And if you look at what those do and what your
plans for your system are, you'll notice that yours is substantially
bigger than those.
Uli Kusterer
Uli Kusterer <wit...@t-online.de> wrote:
> As a simple example:
>
> "Here's looking at you" is
>
> 1) a quote from "Casablanca"
> 2) literally means "I'm keeping an eye on you"
> 3) is a way of toasting to someone before a drink
>
> Translate those to German and you get:
>
> 1) Luckily, "Casablanca" has the same title in Germany, but had it been
> from "Mighty Joe Young", the German title it was released under would
> have been "Mein Freund Joe" ("my friend Joe")
> 2) "Ich hab' Dich im Auge"
> 3) That would be "Prost" or "Zum Wohl" in German ("to your health").
>
> So, which translation, #2 or #3 would the computer pick? How would it
> know that #2 is an option without including the whole Webster's?
Ooops. meant: How would it know #3 is an option.
John W. Kennedy
> 1) Luckily, "Casablanca" has the same title in Germany, but had it been
> from "Mighty Joe Young", the German title it was released under would
> have been "Mein Freund Joe" ("my friend Joe")
And "Casablanca" might easily have been "They All Come to Rick's", which
might or might not have been rendered as "Sie kommen alle zu Ricks". (I
hope I got that right; I haven't needed to write or speak German in 40
years.)
One might also point out such famous problems as:
"Time flies like an arrow."
"Fruit flies like a banana."
"Count flies like an entomologist."
or
"It's a pretty little girls school."
or
"My mother said nothing about the dragon, but pointed out that one
could not say 'a green great dragon', but had to say 'a great green
dragon'." -- J.R.R. Tolkien
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
David Thornley
>> >requirements.
>
>> Um, why? What don't you like about existing platforms?
>
>The things for which I'm making requirements... :)
>
possible to play at least zcode games from a web interface, for
example. Some of the requirements strike me as being very
complicated.
>> Looking at the points below, it seems like you want multiplayer capability,
>> and that opens a very large can of very wriggly worms.
>
>Not only. I want language abstraction, too (on the server side) and
>other things I'll specify when my thoughts consolidate.
>
Do you want to allow players to play in different languages?
>> What do you mean by language-independent?
>
>I mean that a game is developed in the language of the author and can
>be played (with very few effort of localizations) by everyone. The
>player types the command in his/her native language and the program
>"processes" the action and returns the results to the player in his/her
>native language.
>
I think you're seriously underestimating the difficulty here. It
isn't that difficult to rewrite every complete message in another
language (well, theoretically, since poetic language doesn't translate
well). For anything involving combining pieces of text, you have
complications. The system has to know how to plug them together, and
may have to make changes in some of them. For example, in many
languages the verbs change slightly (often at the end) so they
agree with an arbitrary gender or case of noun.
Nor can you necessarily count on the form of user input. Different
languages have different ways of saying things.
>> >3.2) Gaming style player-based (p&c, parser)
>
>> Not all games will work well in either style.
>
>It's up to the player.
No, it depends on the game.
>The "platform" should support these feature.
>
It's often necessary to do that with a commercial application, but
IIRC the right thing to do there is to design the GUI first and
then translate it into the keyboard methods, because doing it in
reverse can be a real pain.
This means that you are effectively saying that people who use
the system design point&click adventures that can be played with
a text interface, and that's a rather different approach.
You may decide that you don't care about the games that would be
adversely affected by this, but it looks to me like you're
more interested in wandering off into something that isn't
considered mainstream IF.
Kevin Forchione
news:KYvyf.449$451...@fe08.lga...
> Uli Kusterer wrote:
>> 1) Luckily, "Casablanca" has the same title in Germany, but had it been
>> from "Mighty Joe Young", the German title it was released under would
>> have been "Mein Freund Joe" ("my friend Joe")
>
> And "Casablanca" might easily have been "They All Come to Rick's", which
> might or might not have been rendered as "Sie kommen alle zu Ricks". (I
> hope I got that right; I haven't needed to write or speak German in 40
> years.)
>
> One might also point out such famous problems as:
> "Time flies like an arrow."
> "Fruit flies like a banana."
> "Count flies like an entomologist."
> or
> "It's a pretty little girls school."
> or
> "My mother said nothing about the dragon, but pointed out that one
> could not say 'a green great dragon', but had to say 'a great green
> dragon'." -- J.R.R. Tolkien
Lol! And think of the confusion when we replace typing with speech
technologies... I suspect all IF of the future would be comedies.
--Kevin
rgrassi
could ask for a 'monster'.
Nevertheless i think that we should'nt overestimate.
Achievable targets, at the moment, could be:
1) Manage ALL the text generated from the engine 'externally' to the
program itself (that implies for instance, default responses, SIMPLE
grammar constructions (article, gender, etc...)
2) Accept only SIMPLE inputs from the player (Your examples do not
apply to IF, fortunately, because 'complex' input of commands is ALWAYS
converted to simple commands by the (pre)parsing libraries. Complex
commands are an illusion, in today IF.) I'm talking about natural
language but with IF standard conventions. In theory, the textual
representation of what can be done with a "point & click".
Anyway, I'll write a document with some of these ideas in and will
publish it, waiting for your comments.
In the meanwhile, discussions are welcome.
Rob
rgrassi
> Okay, but some of the requirements are already met.
Yes. Some pieces of the whole architecture I have in mind exist.
What is missing is one 'shared' vision.
> >Not only. I want language abstraction, too (on the server side) and
> >other things I'll specify when my thoughts consolidate.
> Do you want to allow players to play in different languages?
Yes.
> The system has to know how to plug them together, and
> may have to make changes in some of them. For example, in many
> languages the verbs change slightly (often at the end) so they
> agree with an arbitrary gender or case of noun.
I know very well this problem because in Italy we have to localize
libraries.
>> It's up to the player.
> No, it depends on the game.
The game itself could be a masterpiece if played in the standard mode
or a bu**shit if played in CYOA-Like. What I'm saying is that the
system should support the two types of playing (if the author wants to
support them, obviously) and the player could switch from one type to
another seamless during playing.
> It's often necessary to do that with a commercial application, but
> IIRC the right thing to do there is to design the GUI first and
> then translate it into the keyboard methods, because doing it in
> reverse can be a real pain.
Yes, that could help.
> This means that you are effectively saying that people who use
> the system design point&click adventures that can be played with
> a text interface, and that's a rather different approach.
What I'm saying is that 'current' IF can be represented (and played)
with a p&c approach.
> You may decide that you don't care about the games that would be
> adversely affected by this, but it looks to me like you're
> more interested in wandering off into something that isn't
> considered mainstream IF.
"Mainstream" IF is, imho, just a 'textual' representation of what can
be achieved in other ways. I'm interested to let the player choose
his/her preferred way, starting from the assumption the 'text' must
retain the fundamental the fundamental role of narration and
description. I'm revolving about the 'interaction' part. Does it really
need to be done ONLY with 'text' (i.e. parsing a textual command)?
Rob
Jon Rosebaugh
> The game itself could be a masterpiece if played in the standard mode
> or a bu**shit if played in CYOA-Like. What I'm saying is that the
> system should support the two types of playing (if the author wants to
> support them, obviously) and the player could switch from one type to
> another seamless during playing.
I'm not entirely sure why an author would want to support a feature that
turned his masterpiece into a piece of crap. But, then, I'm not entirely
sure why the rest of your new IF platform would be used by anyone,
either, so carry on reinventing the world.
rgrassi
> I'm not entirely sure why an author would want to support a feature that
> turned his masterpiece into a piece of crap.
Ahahah... :)
I see your point.
The problem is, imho, that it's not "HOW" I interact with the game that
makes the masterpiece.
There are many games with a bad "mainstream" implementation that could
have been better played with a cyoa-like style.
Rob
Jon Rosebaugh
Yes, well, I was just quoting your post. The part where you said "The
game itself could be a masterpiece if played in the standard mode or a
bu**shit if played in CYOA-Like."
So, it seems to me that you WERE saying that how you interact with the
game makes it a masterpiece, or at least contributes to it being one.
rgrassi
> standard mode or a bu**shit if played in CYOA-Like."
> So, it seems to me that you WERE saying that how you interact with the
> game makes it a masterpiece, or at least contributes to it being one.
The question is not so simple and I cannot make 'categorical'
statements on that.
It depends mostly about two concepts:
1) How to define "a masterpiece"
and (given that I take the side of a 'subjective' view of masterpiece)
2) How much the *interaction* type can impact on the game itself.
To me, a game is a 'masterpiece' independently from the type of
interaction (we're talking about games of the same type, of course,
we're not comparing Doom and Photopia).
Rob
rgrassi
> To me, a game is a 'masterpiece' independently from the type of
> interaction (we're talking about games of the same type, of course,
> we're not comparing Doom and Photopia).
And from a subjective side.
That's why I'd like the player choose the way he/she wants to play an
IF game.
Rob
Rioshin an'Harthen
> rgrassi <rgras...@gmail.com> wrote:
>>I mean that a game is developed in the language of the author and can
>>be played (with very few effort of localizations) by everyone. The
>>player types the command in his/her native language and the program
>>"processes" the action and returns the results to the player in his/her
>>native language.
>>
> I think you're seriously underestimating the difficulty here. It
> isn't that difficult to rewrite every complete message in another
> language (well, theoretically, since poetic language doesn't translate
> well). For anything involving combining pieces of text, you have
> complications. The system has to know how to plug them together, and
> may have to make changes in some of them. For example, in many
> languages the verbs change slightly (often at the end) so they
> agree with an arbitrary gender or case of noun.
This is not to be taken as a comment on David's comment, but to elaborate
further on it, as well as on what Uli Kusterer has written in other messages
of this thread (where he mentioned Finnish, which I use as an example).
Take for example Finnish (one of my native languages), where nouns have over
a dozen of cases corresponding to the prepositions of other languages,
ownership is marked by suffixes on the nouns, verbs have to follow the
subject, etc.
E.g. "tulen kukkulalle" consists of the word "tulla" (to come) in first
person singular nominative and "kukkula" (hill) with the case ending "lle"
(to, in this instance), meaning "I come to the hill", while "tullet
kukkulalleni" consists of the second person singular potential version of
"tulla" together with the first-person owned form of "kukkula" with the same
"to" preposition, i.e. "You might come to my hill". Or take "tulisitteko
kukkulalleni" - again the same two base words, "to come" and "hill", but
this time meaning "would you (plural) come to my hill", with the verb this
time being in the second person singular ("tul|et") conditional ("-isi")
question form ("-ko").
Given the current standing in linguistics, natural language parsing and
computerized translation, an IF development system supporting automatic
translation between languages would be in deep trouble with any language not
a part of the Indo-European language group (and many languages within that
group). Translations might be somewhat easy to make between germanic
languages, between romanic languages, between slavic languagas... but the
problem turns harder when translating a slavic language to a germanic one
(e.g. Russian to English). It turns still harder when the language of
translation is from a different language family completely, e.g. translating
English (Germanic Indo-European) to Finnish (Finno-Hungarian). Take for
example the consept of the object - Finnish has three cases for objective
forms of the noun, the choice of which depending not only on the noun, but
also on what object-capacity the noun appears in the sentence.
Translating to a language like Finnish is still not as hard as to a language
like Kalaallit Nunaat (Greenlandic Inuit), the difference of which from the
Indo-European languages is even larger.
To recap, this makes it hard to automatically translate anything. Current
computer-based translation into a language like Finnish is rough at best,
with the translating software having to often pick a random translation for
words, since the software does not understand the original sentence (and
even the paragraph, subchapter, chapter, book, piece of IF...) well enough
to be able to provide a translation of it in where the context of the words
in the sentence and the larger structure may lead to different choices of
words to get the same meaning as originally intended.
Then take the problem of poetry in the game, e.g. as clues to puzzles much
further on. Now it's not enough to keep the same meaning as in the original
text - you have to keep the same meter. It's conceivable that the solution
of the puzzle for which the piece of poetry is a clue might depend on the
meter, even combined with e.g. the first letters of words of the piece
dependant on the meter of it. Now, I agree this would be a cruel puzzle, but
it is conceivable. Try to translate that into any other natural language,
and the problem turns unsurmountable - usually so even for a human
completely fluent in both languages.
Many times, such problems would have to be completely reauthored for every
language. Take for instance comic books, where many times the gist of a joke
is the play with words, e.g. in Don Rosa's Donald Duck stories. Translators
of the stories have problems to impart those jokes to readers in a different
language, and reading the original might not open up the joke to someone not
versed in the culture and language of the origin of the joke.
Well, I guess that's enough for now... :)
rgrassi
> To recap, this makes it hard to automatically translate anything.
I know. But text in IF can be:
1) Incoming (from the parser)
2) Outgoing
For 1, we have to filter and constraint the player input forcing it to
a standard grammar.
(and, as i said before, input from IF players are NEVER so complex).
Number 2 can be splitted in
2a) Static text (object description, overridden default responses,
etc...)
2b) Dynamic (i.e. composed statements, 'pronoun' + 'verb' + 'article'
'noun')
For 2a, ALL the text must be in a separate file, with only a pointer to
the localization language to be used.
For 2b, the dynamic text must be assembled in a 'neutral language'
statement and then translated in the localized language. This can
happen in two ways.
2b1) Try an automatic translation (for simple cases)
2b2) Look in an external file for an overridden.
Rob
David Thornley
rgrassi <rgras...@gmail.com> wrote:
>> It's often necessary to do that with a commercial application, but
>> IIRC the right thing to do there is to design the GUI first and
>> then translate it into the keyboard methods, because doing it in
>> reverse can be a real pain.
>
>Yes, that could help.
>
>> This means that you are effectively saying that people who use
>> the system design point&click adventures that can be played with
>> a text interface, and that's a rather different approach.
>
>What I'm saying is that 'current' IF can be represented (and played)
>with a p&c approach.
>
And I'm disagreeing, at least from an artistic point of view.
A lot of current IF would not work at all well with point&click.
It would be necessary to provide a complete list of verbs and
nouns, along with prepositions.
Let's take something simple. In normal IF, I can type "put the vase
on the table" (or, more likely, "put vase on table"). How do we
do this in point&click?
The obvious thing is to have a pictorial depiction of the room, so I
can click on the vase (in an inventory display), and then on the
table. I'm not seeing any other way that doesn't involve simply
clicking on "put", "vase", "on", and "table".
This means that all IF in your system has to come with complete
pictures, rather than (as IF is now), no pictures or some pictures
for illustration. This means that IF in your system requires
considerably different skills from TADS3, since it is necessary
to provide pictures that go along with the story.
At this point, we're talking about a different art form, as it is
the pictures, not the words, that become important. People who are
good at IF as it currently exist will be left out. Emily Short, to
name one, has written some IF I have enjoyed very much. I don't
know how well she can draw or paint.
There is also conventional IF that pretty much can't be done
pictorially. Consider "Anchorhead", for example, or any other
attempt at Lovecraftian horror. Some of what makes Lovecraft's
writing effective is that he knew what to leave out of descriptions.
You can't do that with pictures. Somebody would have to draw or
paint pictures of undescribable horror.
In other words, this is a proposal for an art form that is not
currently covered well in r.a.i-f and r.g.i-f, rather than a
new IF engine.
>> You may decide that you don't care about the games that would be
>> adversely affected by this, but it looks to me like you're
>> more interested in wandering off into something that isn't
>> considered mainstream IF.
>
>"Mainstream" IF is, imho, just a 'textual' representation of what can
>be achieved in other ways.
I disagree. Mainstream IF is an art form of itself, and is conditioned
by its limits. You might as well say that painting in oils is just
an oil-based representation of what can be achieved in other ways.
I'm interested to let the player choose
>his/her preferred way, starting from the assumption the 'text' must
>retain the fundamental the fundamental role of narration and
>description.
If pictures are necessary, then the text does not retain the
fundamental role. The pictures are a lot more work to do, for
most people, and the player will tend to refer to them.
I'm revolving about the 'interaction' part. Does it really
>need to be done ONLY with 'text' (i.e. parsing a textual command)?
>
Without changing the nature of IF, I can't think of an alternative.
There are different ways to enter the command (for example, on my
PDA I can examine any object in the visible text with two touches
of the stylus), but I don't think you'd see that as point&click.
Andrew Plotkin
> Hi Jon,
>
> > I'm not entirely sure why an author would want to support a feature that
> > turned his masterpiece into a piece of crap.
>
> Ahahah... :)
> I see your point.
> The problem is, imho, that it's not "HOW" I interact with the game that
> makes the masterpiece.
From my point of view, as an author, it's *exactly* "how you interact
with the game" that makes the game good or bad. All my game design
starts with the interactions. If I don't know how the interactions
work, I'm not designing interactive fiction. I may be writing a story,
or creating characters or dialogue, *for* some interactive fiction --
but I'm not designing the game itself.
> There are many games with a bad "mainstream" implementation that could
> have been better played with a cyoa-like style.
That's exactly my point! The author needs to choose a model of
interaction which will work for his game, and then design the game
around that model. He *can't* leave that choice to the player.
Or rather, if he does, he has to design the entire game twice. And the
two designs may differ in all sorts of ways, at many levels, if they
are both to succeed. Whole puzzles may have to be thrown out and
replaced.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison
without trial, it's for one reason: they don't feel like it. Not
because of the Fifth Amendment.
Uli Kusterer
"rgrassi" <rgras...@gmail.com> wrote:
> Hi Uli, I understand what you're talking about and I know that my specs
> could ask for a 'monster'.
Good to know you're aware of that.
> Nevertheless i think that we should'nt overestimate.
> Achievable targets, at the moment, could be:
> 1) Manage ALL the text generated from the engine 'externally' to the
> program itself (that implies for instance, default responses, SIMPLE
> grammar constructions (article, gender, etc...)
> 2) Accept only SIMPLE inputs from the player (Your examples do not
> apply to IF, fortunately, because 'complex' input of commands is ALWAYS
> converted to simple commands by the (pre)parsing libraries. Complex
> commands are an illusion, in today IF.) I'm talking about natural
> language but with IF standard conventions. In theory, the textual
> representation of what can be done with a "point & click".
So, effectively you've scaled it down to a new parser then?
> Anyway, I'll write a document with some of these ideas in and will
> publish it, waiting for your comments.
That'd be handy. Because if you're looking for anyone to work with you
on an actual implementation (once you have at least started a little),
they'll need a detailed spec not just of what this will do, but also how
you're doing it, and most importantly, what itch you're trying to
scratch with this.
Because one of the general ground rules for collaborative open-source
projects is that people working on this stuff want to get something out
of their work. And usually, they want to create an application that does
something they need.
David Thornley
rgrassi <rgras...@gmail.com> wrote:
>Hi,
>
>> To recap, this makes it hard to automatically translate anything.
>
>I know. But text in IF can be:
>1) Incoming (from the parser)
>2) Outgoing
>
>For 1, we have to filter and constraint the player input forcing it to
>a standard grammar.
>(and, as i said before, input from IF players are NEVER so complex).
>
for simple IF commands, but there are ways to string them together.
Now, let's take some examples from the language I know most about besides
English, which is Russian.
In Russian, the verb will change inflection depending on the actor. In
fact, it can be colloquial to omit the actor entirely, since the
difference between me doing something and you doing something is caught
by the inflections.
Therefore, your filter either blocks out colloquial language use, to
force it into some particular grammar (like English), or it has to be
able to recognize inflections and what they mean. It has to be able
to recognize different forms of verbs.
I don't think this is trivial at all.
>Number 2 can be splitted in
>2a) Static text (object description, overridden default responses,
>etc...)
>2b) Dynamic (i.e. composed statements, 'pronoun' + 'verb' + 'article'
>'noun')
>
>For 2a, ALL the text must be in a separate file, with only a pointer to
>the localization language to be used.
Presumably this will be handled by the compiler. This is the easy case,
except if the translation is difficult. The translation will of course
have to be done by a human for each desired language, so being able to
play in multiple languages means getting various humans to cooperate.
>For 2b, the dynamic text must be assembled in a 'neutral language'
>statement and then translated in the localized language. This can
>happen in two ways.
>2b1) Try an automatic translation (for simple cases)
>2b2) Look in an external file for an overridden.
>
People have been looking for some "neutral language" for a long time,
and I haven't heard that they've found a good one. Automatic translation
can work for some cases, but it's real easy for that to come off as
semi-literate - if, for example, it misses an inflection. Suppose you
have a canned response like "<actor> doesn't seem to understand what
you said." Having one "doesn't seem to understand what you said"
fragment works well for English but not Russian.
Looking for an override in this case means that the translator has to
put in "Ivan doesn't seem to understand what you said" and "Katrina
doesn't seem to understand what you said", for every NPC in the game.
This doesn't seem practical.
Doing this automatically means that the system output has to be at
least somewhat aware of the grammar for each and every language
being output.
I think this is a much bigger project than you're implying.
Chris Pickett
> Doing this automatically means that the system output has to be at
> least somewhat aware of the grammar for each and every language
> being output.
>
> I think this is a much bigger project than you're implying.
I think for starters just plain-old manual internationalization of
parsers, libraries, and story files would be cool. Even that doesn't
exist, as far as I know.
Chris
Jon Rosebaugh
Well, the Inform library has been translated into Dutch, French, German,
Italian, Lojban, Spanish, and Swedish. Thus, you can make games in all
of these languages. If that's not what you mean, please clarify.
Chris Pickett
> Chris Pickett wrote:
>
> > I think for starters just plain-old manual internationalization of
> > parsers, libraries, and story files would be cool. Even that doesn't
> > exist, as far as I know.
>
> Well, the Inform library has been translated into Dutch, French, German,
> Italian, Lojban, Spanish, and Swedish. Thus, you can make games in all
> of these languages. If that's not what you mean, please clarify.
I didn't know that. Yes, multiple in-place translations of a
game+library+parser are good, but they don't really count as i18n to
me. I actually meant more-or-less exactly what rgrassi was describing.
Below I'm just rephrasing his thoughts.
By i18n (internationalization) I mean systems where the strings are
completely modularized (ick, is that even English?), except when
they're constructed algorithmically, in which case the particular
string-construction algorithms are separated out as well.
In terms of IF, I think what would be cool is support for canonical
input, which is the target of multiple parsers, and canonical output,
which is the source for multiple text generation engines. There would
still be a need to hand-code all the translations for each language.
I guess these are more appropriate tests for what I consider i18n: are
there any games that are actually playable in multiple languages? If
so, can you switch between languages at any point?
Yeah, it would be a lot of work, but I think it's far from intractable
(to be precise: the complexity of i18n is directly proportional to the
size of the game/library/parser/whatever, there's not an exponential
blow-up here).
In general, why should the game state care about whether or not the
player speaks English?
Cheers,
Chris
Andrew Plotkin
> Jon Rosebaugh wrote:
> > Chris Pickett wrote:
> >
> > > I think for starters just plain-old manual internationalization of
> > > parsers, libraries, and story files would be cool. Even that doesn't
> > > exist, as far as I know.
> >
> > Well, the Inform library has been translated into Dutch, French, German,
> > Italian, Lojban, Spanish, and Swedish. Thus, you can make games in all
> > of these languages. If that's not what you mean, please clarify.
>
> I didn't know that. Yes, multiple in-place translations of a
> game+library+parser are good, but they don't really count as i18n to
> me. I actually meant more-or-less exactly what rgrassi was describing.
> Below I'm just rephrasing his thoughts.
>
> By i18n (internationalization) I mean systems where the strings are
> completely modularized (ick, is that even English?), except when
> they're constructed algorithmically, in which case the particular
> string-construction algorithms are separated out as well.
>
> In terms of IF, I think what would be cool is support for canonical
> input, which is the target of multiple parsers, and canonical output,
> which is the source for multiple text generation engines. There would
> still be a need to hand-code all the translations for each language.
I'm not sure if that's what Rob was saying, but if I understand
correctly: You're asking for a clean division between the parser and
the game state, so that the command-recognition part of the game (and
text generation, of course) can be translated without having to dip
into the game-state manipulation.
This is not an inherently bad idea. Which is what they call "damning
with faint praise". :)
Clean divisions are great -- I'm all for that. My argument against it
is just that IF code tends to entangle parsing and game-state code,
because they *go* together. You're writing hundreds of little snippets
of each (I include object properties as "code" here) and the last
thing you want to do is add an additional layer of indirection. I
mean, look at the Inform library. It *has* this clean division: game
state code is in verblibm.h, standard English messages are in
English.h. It's absolutely miserably unreadable.
[ PullSub;
if (ObjectIsUntouchable(noun)) return;
if (noun has static) return L__M(##Pull, 1, noun);
if (noun has scenery) return L__M(##Pull, 2, noun);
if (noun has animate) return L__M(##Pull, 4, noun);
L__M(##Pull, 3, noun);
];
If you tell authors to write their game code that way, they'll run
screaming for the hills. I certainly would.
The other side of this coin is: when you translate a game into another
language, you're spending all of your time on the input and output
stuff. Game-state code is (from your point of view) a few simple nuts
and bolts which the real translation problem is wrapped around. So
"true internationalization", in the sense you are talking about,
doesn't actually make your life any easier.
> I guess these are more appropriate tests for what I consider i18n: are
> there any games that are actually playable in multiple languages? If
> so, can you switch between languages at any point?
No, and no. And those are fair questions; it's certainly *feasible* to
create an IF system that allows that.
But I think those features are more hypothetical virtues than
practical ones. The important thing (and hard part) about a language
translation of a game is whether it exists. Having it embedded in the
same game file, and swapping to it in mid-game, are not that big a
deal.
What I'm saying is, the naive model of "take the English source code,
edit most of it, and then compile with the standard Italian library"
(which is what you'd do in Inform) is actually pretty close to as good
as it's going to get. I don't see a smarter design model as buying you
any real advantages.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
You don't become a tyrrany by committing torture. If you plan for torture,
argue in favor of torture, set up legal justifications for torturing
someday, then the moral rot has *already* set in.
Jon Rosebaugh
> By i18n (internationalization) I mean systems where the strings are
> completely modularized (ick, is that even English?), except when
> they're constructed algorithmically, in which case the particular
> string-construction algorithms are separated out as well.
>
> In terms of IF, I think what would be cool is support for canonical
> input, which is the target of multiple parsers, and canonical output,
> which is the source for multiple text generation engines. There would
> still be a need to hand-code all the translations for each language.
>
> I guess these are more appropriate tests for what I consider i18n: are
> there any games that are actually playable in multiple languages? If
> so, can you switch between languages at any point?
>
> Yeah, it would be a lot of work, but I think it's far from intractable
> (to be precise: the complexity of i18n is directly proportional to the
> size of the game/library/parser/whatever, there's not an exponential
> blow-up here).
>
> In general, why should the game state care about whether or not the
> player speaks English?
For starters, any game which depends upon wordplay, such as Ad Verbium,
will horribly break this system, but I'm assuming you already understand
that.
This could work. If the author wrote the game in one language, manually
translated all her finely-crafted prose into multiple other languages,
and stuck them in routines that would switch between different language
versions as necessary. I believe that Inform is already capable of
handling such a system, if someone wished to do it. I also believe that
this has not yet been attempted, because it would be a great deal of
work, with little benefit. After all, what gain is there to be able to
switch from playing in English to playing in Dutch in the middle of the
game? If a given player knows he speaks English better than Dutch, he is
probably intelligent enough to select the English-language story file
and play that to completion. There is no benefit to embedding multiple
languages in one story file, unless switching between languages itself
constitutes part of the game.
Further, I think you are underestimating the difficulty of creating
language-neutral printing routines. As Rioshin said in a previous post,
"Take for example the consept of the object - Finnish has three cases
for objective forms of the noun, the choice of which depending not only
on the noun, but also on what object-capacity the noun appears in the
sentence." As you add in more languages the game file is supposed to
support, the printing routines for such simple things as "You pick up
the magic lamp and stow it in your knapsack." will get ever more complex.
Lastly, and please don't take this personally, but I think someone who
proposes a system with an implementation barrier of this magnitude
should have to demonstrate a pressing need for it to be taken seriously.
So far, I can't see a pressing need for any of the ideas presented in
this thread.
Chris Pickett
I was actually agreeing with you until I remembered why I think
canonical input and output is a good thing: it (probably) makes model
checking (considerably) simpler. But until somebody demonstrates model
checkability of a large enough game that's admittedly a moot point.
It would also help you maintain text and pointy-clicky versions of the
same game by eliminating code duplication. But then there's your same
point about the modularized i18n problem: this might be better served
by developing the two versions in parallel. I'm just not really sure.
Chris
Adam Thornton
Jon Rosebaugh <jonathan....@mnsu.edu> wrote:
>Well, the Inform library has been translated into Dutch, French, German,
>Italian, Lojban, Spanish, and Swedish. Thus, you can make games in all
>of these languages. If that's not what you mean, please clarify.
Partial Latin translation too. Kinda stalled at the moment.
Adam
Samwyse
> By i18n (internationalization) I mean systems where the strings are
> completely modularized (ick, is that even English?), except when
> they're constructed algorithmically, in which case the particular
> string-construction algorithms are separated out as well.
[...]
> Yeah, it would be a lot of work, but I think it's far from intractable
> (to be precise: the complexity of i18n is directly proportional to the
> size of the game/library/parser/whatever, there's not an exponential
> blow-up here).
"How hard can it be?" I provide an excerpt from "Localizing Your Perl
Programs", by Sean M. Burke and Jordan Lachler, which was included with
my copy of Perl.
A Localization Horror Story: it could happen to you.
There are a number of languages spoken by human beings in this world.
--Harald Tveit Alvestrand
in RFC 1766, Tags for the Identification of Languages
Imagine that your task for the day is to localize a piece of software
someone else in your company wrote. Suppose it's a simple search tool of
some sort, the exact details of which aren't important. Luckily for you,
the only output the program emits is two messages, like this:
I scanned 12 directories.
Your query matched 10 files in 4 directories.
How hard could that be? You look at the code that produces the first
item, and it reads:
printf("I scanned %g directories.", $directory_count);
First you have to look up what %g does--it performs number interpolation
with nice formatting. But then you think about the above code, and you
realize that it doesn't even work right for English, as it can produce
this output:
I scanned 1 directories.
So you rewrite it to read:
printf("I scanned %g %s.",
$directory_count,
$directory_count == 1 ?
"directory" : "directories",
);
...which does the Right Thing. (While looking up %g in the Perl docs for
sprintf, you learned that %s is for interpolating strings.)
But you still have to localize it for all the languages spoken by your
users, and after a little poking around in CPAN, you find the
Locale::gettext module, which is an interface to gettext, a set of C
routines that seem well suited to this task. After some poking around
AltaVista, you find the gettext manual. You browse through the tutorial,
and, following its examples, you start to write:
printf( gettext("I scanned %g %s."),
$dir_scan_count,
$dir_scan_count == 1 ?
gettext("directory") : gettext("directories"),
);
But you see later in the gettext manual that this is not a good idea,
since how a single word like 'directories' is translated depends on
context. In languages like German or Russian, the 'directories' of 'I
scanned 12 directories' demands a different case than the 'directories'
of 'Your query matched 10 files in 4 directories'. The first is the
object of a verb, and the second is the object of a preposition.
So, on the advice of the gettext manual, you rewrite:
printf( $dir_scan_count == 1 ?
gettext("I scanned %g directory.") :
gettext("I scanned %g directories."),
$dir_scan_count );
The boss decides that the languages du jour are Chinese, Arabic,
Russian, and Italian, so you hire one translator for each and ask for
translations of 'I scanned %g directory' and 'I scanned %g directories'.
When they reply, you'll put that in the lexicons for gettext to use when
it localizes your software, so that when the user is running under the
zh (Chinese) locale, gettext("I scanned %g directory.") returns the
appropriate Chinese text, with a %g in there where printf can then
interpolate the number $dir_scan (Locale primarily means a choice of
language, and things that usually accompany that, like character sets,
preferences for expressing numbers (whether one and a half is 1.5 or
1,5), and preferences for sort order, since not all languages have the
same alphabetical order. Since we don't talk about those other
preferences in this article, just think 'language' whenever you see
'locale'.).
Your Chinese translator mails right back--he says both of these phrases
translate to the same thing in Chinese, because, to use linguistic
terminology, Chinese "doesn't have number as a grammatical category"
like English does. That is, English has grammatical rules that depend on
whether something is singular or plural; one of these rules is the one
that forces nouns to take a suffix (usually 's') when there's more than
one ("one dog, two dogs"). Chinese has no such rules, and so has just
one phrase where English needs two. No problem; you can have this one
Chinese phrase appear as the translation for the two English phrases in
the zh gettext lexicon for your program.
Emboldened by this, you dive into the second phrase that your software
needs to output: "Your query matched 10 files in 4 directories." You
notice that if you want to treat phrases as indivisible, as the gettext
manual wisely advises, you need four cases to cover the permutations of
singular and plural on each of $dir_count and $file_count. So you try this:
printf( $file_count == 1 ?
( $directory_count == 1 ?
gettext("Your query matched %g file in %g directory.") :
gettext("Your query matched %g file in %g
directories.") ) :
( $directory_count == 1 ?
gettext("Your query matched %g files in %g directory.") :
gettext("Your query matched %g files in %g
directories.") ),
$file_count, $directory_count,
);
(The case of "1 file in 2 [or more] directories" could, I suppose, occur
with symbolic links in the filesystem.)
This isn't the prettiest code you've ever written, but this seems the
way to go. You mail the translators asking for translations for these
four cases. The Chinese guy replies with the one phrase that these all
translate to in Chinese, and that phrase has two %gs in it, as it
should--but there's a problem. He translates it word-for-word: "To your
question, in %g directories you would find %g answers." The %g slots are
reversed. You wonder how you'll get gettext to handle that.
But you put it aside for the moment, and optimistically hope that the
other translators won't have this problem, and that their languages will
be better behaved--that they'll be just like English.
The Arabic translator is the next to write back. First off, your code
for "I scanned %g directory." or "I scanned %g directories." assumes
there's only singular or plural. But, to use linguistic jargon again,
Arabic has grammatical number, like English and unlike Chinese. However,
it's a three-term category: singular, dual, and plural. In other words,
the way you say 'directory' depends on whether there's one directory,
two of them, or more than two of them. Your test of ($directory == 1) no
longer does the job. And it means that where English's grammatical
category of number necessitates only two permutations of the first
sentence, Arabic has three--and, worse, in the second sentence ("Your
query matched %g file in %g directory."), Arabic has nine possibilities
where English had only four. You sense an unwelcome, exponential trend
taking shape.
Your Italian translator emails you back and says that "I searched 0
directories" (a possible output of your program) is stilted, and if you
think that's fine English, that's your problem, but that just will not
do in the language of Dante. He insists that where $directory_count is
0, your program should produce the Italian equivalent of "I didn't scan
any directories.'' And ditto for "I didn't match any files in any
directories", although he adds that the last part about "in any
directories'' should probably be omitted altogether.
You wonder how you'll get gettext to handle this; to accommodate the
ways Arabic, Chinese, and Italian deal with numbers in just these few
very simple phrases, you need to write code that asks gettext for
different queries depending on whether the numerical values in question
are 1, 2, more than 2, or in some cases 0, and you still haven't figured
out the problem with the different word order in Chinese.
Then your Russian translator calls, to personally deliver the bad news.
Russian, like German or Latin, is an inflectional language; that is,
nouns and adjectives take endings that depend on their case (nominative,
accusative, genitive, and so on; what role they play in the syntax of
the sentence)--as well as on the gender (masculine, feminine, neuter)
and number (singular or plural), as well as on the declension class of
the noun. But unlike other inflected languages, putting a number-phrase
(like "ten" or "forty-three") in front of a Russian noun can change the
case and number of the noun, and therefore its ending as well.
He elaborates: In "I scanned %g directories", you'd expect
"directories'' to be in the accusative case (since it is the direct
object) and a plural, except where $directory_count is 1--then you'd
expect the singular, of course. Just like Latin or German. But! Where
$directory_count % 10 is 1 (assuming $directory_count is an integer, and
except where $directory_count % 100 is 11) "directories'' is forced to
become grammatically singular, which means it gets the ending for the
accusative singular. You begin to visualize the code it'd take to test
for the problem so far, and still work for Chinese and Arabic and
Italian, and how many gettext items that'd take. But he keeps going.
Where $directory_count % 10 is 2, 3, or 4 (except where $directory_count
% 100 is 12, 13, or 14), the word for "directories'' is forced to be
genitive singular--which means another ending. The room begins to spin
around you, slowly at first... And with all other integer values, since
"directory'' is an inanimate noun, when preceded by a number and in the
nominative or accusative cases (as it is here, just your luck!), it does
stay plural, but it is forced into the genitive case--yet another
ending. And because the floor comes up to meet you as you fade into
unconsciousness, you never get to hear him talk about the similar but
subtly different problems with other Slavic languages like Polish.
The above cautionary tale relates how an attempt at localization can
lead from programmer consternation, to program obfuscation, to a need
for sedation. But careful evaluation shows that your choice of tools
merely needed further consideration.
Chris Pickett
> Chris Pickett wrote:
>
> > player speaks English?
>
> For starters, any game which depends upon wordplay, such as Ad Verbium,
> will horribly break this system, but I'm assuming you already understand
> that.
Yes. Saved by "in general". :)
> This could work. If the author wrote the game in one language, manually
> translated all her finely-crafted prose into multiple other languages,
> and stuck them in routines that would switch between different language
> versions as necessary. I believe that Inform is already capable of
> handling such a system, if someone wished to do it. I also believe that
> this has not yet been attempted, because it would be a great deal of
> work, with little benefit. After all, what gain is there to be able to
> switch from playing in English to playing in Dutch in the middle of the
> game? If a given player knows he speaks English better than Dutch, he is
> probably intelligent enough to select the English-language story file
> and play that to completion. There is no benefit to embedding multiple
> languages in one story file, unless switching between languages itself
> constitutes part of the game.
That test for i18n (switching between languages whilst maintaining the
same game state) was not offered because I thought that it was
particularly useful to do so (although I do think it would be cool),
but rather because it seems likely that any game passing it will have
the input and output separated "properly". That's all.
> Further, I think you are underestimating the difficulty of creating
> language-neutral printing routines. As Rioshin said in a previous post,
> "Take for example the consept of the object - Finnish has three cases
> for objective forms of the noun, the choice of which depending not only
> on the noun, but also on what object-capacity the noun appears in the
> sentence." As you add in more languages the game file is supposed to
> support, the printing routines for such simple things as "You pick up
> the magic lamp and stow it in your knapsack." will get ever more complex.
To me your "ever more complex" suggests an exponential blowup. The
cost for adding a new language doesn't actually grow exponentially,
since it doesn't depend (in a bad way) on the number of languages you
already support. Please offer a counterexample if you know one.
I think that it's just one more case for each new language, and all the
cases for a given language can go in one file. A good editor could
probably even do temporary inlining tricks for authoring purposes.
> Lastly, and please don't take this personally, but I think someone who
> proposes a system with an implementation barrier of this magnitude
> should have to demonstrate a pressing need for it to be taken seriously.
> So far, I can't see a pressing need for any of the ideas presented in
> this thread.
So, I can't speak for rgrassi (Rob), but as I mentioned above, before
seeing your message, the primary reason I think it's important is so
that you can reduce the complexity of searching through all possible
game states. Yes, arguing for true i18n in order to achieve this is
probably a bit strange.
Let's say you have a simple "drop_box" action. The input state is
"player_has_box". The output state is "box_on_floor". If you have the
input and output messages woven into the game, then to search the game
state space you also have to search the parser and output library state
spaces, whereas if they are external then it becomes trivial to check
this action (it's just one simple step). There are other things that
make searching the game state space difficult (such as being able to
pick up and drop 20 different objects in 20 different rooms), but I'm
claiming that in addition to dealing with these inherent scalability
problems, having external input and output routines is necessary if one
wants to model check IF games of any useful size.
Of course I also just think that good designs are worth pursuing in
their own right.
Chris
Jon Rosebaugh
> To me your "ever more complex" suggests an exponential blowup. The
> cost for adding a new language doesn't actually grow exponentially,
> since it doesn't depend (in a bad way) on the number of languages you
> already support. Please offer a counterexample if you know one.
Samwyse's post provides an excellent counterexample. Essentially, each
additional language has sufficient special-cases that your code will
quickly grow unmanageable. This may not be truely exponential growth,
but I'm not the one who used that term in the first place.
>>Lastly, and please don't take this personally, but I think someone who
>>proposes a system with an implementation barrier of this magnitude
>>should have to demonstrate a pressing need for it to be taken seriously.
>>So far, I can't see a pressing need for any of the ideas presented in
>>this thread.
>
>
> So, I can't speak for rgrassi (Rob), but as I mentioned above, before
> seeing your message, the primary reason I think it's important is so
> that you can reduce the complexity of searching through all possible
> game states. Yes, arguing for true i18n in order to achieve this is
> probably a bit strange.
>
> Let's say you have a simple "drop_box" action. The input state is
> "player_has_box". The output state is "box_on_floor". If you have the
> input and output messages woven into the game, then to search the game
> state space you also have to search the parser and output library state
> spaces, whereas if they are external then it becomes trivial to check
> this action (it's just one simple step). There are other things that
> make searching the game state space difficult (such as being able to
> pick up and drop 20 different objects in 20 different rooms), but I'm
> claiming that in addition to dealing with these inherent scalability
> problems, having external input and output routines is necessary if one
> wants to model check IF games of any useful size.
I don't know if I'm following your argument here, but it seems to me
that you are exchanging one form of complexity for another. After all,
if you have a specific "drop_box" action, will you not also need a
"drop_amulet" action, and a "drop_brick" action, and so on? Inform uses
a Drop action, which checks a number of things like 'Is the item in the
inventory? Is the player capable of dropping the item? Has the item
asked to override any of this behavior?', and this Drop action "just
works" for almost any sort of object.
solar penguin
>
> The game itself could be a masterpiece if played in the standard mode
> or a bu**shit if played in CYOA-Like. What I'm saying is that the
> system should support the two types of playing (if the author wants to
> support them, obviously) and the player could switch from one type to
> another seamless during playing.
>
I'm not sure this is possible. While in text-input mode, the player
could enter commands that manipulate the game world into a state that
doesn't match anything the CYOA story has been set up for. So what
would happen after switching back to CYOA-mode?
Or must the authors anticipate every possible sate of the game world and
code CYOA options for all of them?
--
___ _ ___ _
/ __| ___ | | __ _ _ _ | _ \ ___ _ _ __ _ _ _ (_) _ _
\__ \/ _ \| |/ _` || '_| | _// -_)| ' \ / _` || || || || ' \
|___/\___/|_|\__,_||_| |_| \___||_||_|\__, | \_,_||_||_||_|
|___/
http://www.freewebs.com/solar_penguin/
** You can kill yourself now because you're dead in outer space. A
reverend investigates extraordinary events at his church.
** This is a predicate of part of the cosmological myths of the
Silmarillion.
solar penguin
>
> Let's take something simple. In normal IF, I can type "put the vase
> on the table" (or, more likely, "put vase on table"). How do we
> do this in point&click?
>
> The obvious thing is to have a pictorial depiction of the room, so I
> can click on the vase (in an inventory display), and then on the
> table. I'm not seeing any other way that doesn't involve simply
> clicking on "put", "vase", "on", and "table".
>
Maybe you could click-and-drag the word "vase" in the IF text output and
drop it on the word "table".
Has anyone tried implementing something like this?
--
___ _ ___ _
/ __| ___ | | __ _ _ _ | _ \ ___ _ _ __ _ _ _ (_) _ _
\__ \/ _ \| |/ _` || '_| | _// -_)| ' \ / _` || || || || ' \
|___/\___/|_|\__,_||_| |_| \___||_||_|\__, | \_,_||_||_||_|
|___/
http://www.freewebs.com/solar_penguin/
** If Feyd wishes, he can stick his favour straight up his gloves in the
mass extinction of the dinosaurs.
** You think you're our secret weapon. We'll unleash you on the
detention level.
Chris Pickett
> Chris Pickett wrote:
> > To me your "ever more complex" suggests an exponential blowup. The
> > cost for adding a new language doesn't actually grow exponentially,
> > since it doesn't depend (in a bad way) on the number of languages you
> > already support. Please offer a counterexample if you know one.
>
> Samwyse's post provides an excellent counterexample. Essentially, each
> additional language has sufficient special-cases that your code will
> quickly grow unmanageable. This may not be truely exponential growth,
> but I'm not the one who used that term in the first place.
I don't see why his post is a counterexample. It just says i18n is a
pain, and that you can do it badly. All I'm saying is that adding a
translation into Russian has the same difficulty if you currently
support just English, or if you currently support both English and
Chinese. It doesn't "quickly grow" unmanageable -- it grows linearly.
It might even be simplified if you already support a similar language.
That saying X in language Y might have complexity depending on Y is
irrelevant. I think, _in general_, that everything one wants to say in
IF can feasibly be said in any language. It's just a new case in a
switch statement for each. The code that spits out English doesn't
need to care about other languages.
files = ...;
directories = ...;
switch (LANGUAGE)
{
case (RUSSIAN):
{
print_f_and_d_in_russian (files, directories);
}
break;
case (ENGLISH):
default:
{
print_f_and_d_in_english (files, directories);
}
break;
}
Anyway, the Inform library has more-or-less already been translated in
this manner, as previously pointed out, so clearly it's not infeasible.
Yes it's painful for programmers, but maybe it could be made better.
The text editor could inline the routines and messages for the current
language to make editing the bits that change the game state easier,
and inline 2 languages side-by-side to make translation easier. It
seems like emacs could be extended to handle this.
> > Let's say you have a simple "drop_box" action. The input state is
> > "player_has_box". The output state is "box_on_floor". If you have the
> > input and output messages woven into the game, then to search the game
> > state space you also have to search the parser and output library state
> > spaces, whereas if they are external then it becomes trivial to check
> > this action (it's just one simple step). There are other things that
> > make searching the game state space difficult (such as being able to
> > pick up and drop 20 different objects in 20 different rooms), but I'm
> > claiming that in addition to dealing with these inherent scalability
> > problems, having external input and output routines is necessary if one
> > wants to model check IF games of any useful size.
>
> I don't know if I'm following your argument here, but it seems to me
> that you are exchanging one form of complexity for another. After all,
> if you have a specific "drop_box" action, will you not also need a
> "drop_amulet" action, and a "drop_brick" action, and so on? Inform uses
> a Drop action, which checks a number of things like 'Is the item in the
> inventory? Is the player capable of dropping the item? Has the item
> asked to override any of this behavior?', and this Drop action "just
> works" for almost any sort of object.
That was just an example, and there's no reason for the programmer to
clone code for each object with default behaviour. Whether or not each
action is explicitly represented in the compiled, underlying model
whose state space you're going to search (that depends on your model
generation and compilation strategy), it's still better to simplify the
input and output as much as possible so that you don't have to search
the natural language processing and generation bits too.
Anyway, you asked for a good reason to do this. I think being able to
find reachability of a winning state in a large enough game is a good
reason. Certainly this has already made it feasible to do in small
games (e.g. Cloak of Darkness). That I still can't do it even with
simplified input/output for a game of reasonable size does make my
reason less good... so I should probably try harder to show that I can.
Chris
rgrassi
interaction and then I'll try to collect posts in a new root.
> From my point of view, as an author, it's *exactly* "how you interact
> with the game" that makes the game good or bad. All my game design
> starts with the interactions.
I agree with you, and that's the author side.
We need to focus better on the player side.
Rob
rgrassi
thinking about.
Just a quick reply.
> That saying X in language Y might have complexity depending on Y is
> irrelevant. I think, _in general_, that everything one wants to say in
> IF can feasibly be said in any language.
Correct.
> Anyway, the Inform library has more-or-less already been translated in
> this manner, as previously pointed out, so clearly it's not infeasible.
Correct.
> Yes it's painful for programmers, but maybe it could be made better.
And consider a multiauthors game in which authors from different
countries can develop the game and release in their countries the same
time.
> Anyway, you asked for a good reason to do this. I think being able to
> find reachability of a winning state in a large enough game is a good
> reason.
The good reason is to separate the "text" from the application.
It is always a good reason.
Maybe, an en_us man doesn't see a good reason.
ALL THE REST of the world maybe will see it. :)
A good reason will be for all of us to work on an unified IF
development environment without develop everyone a single brick of the
wall. Then, localization groups will activate to write the specific
part of libraries.
Rob
rgrassi
> Or must the authors anticipate every possible sate of the game world and
> code CYOA options for all of them?
In part.
I'll post pseudocode in a next post to tell what I've in mind.
Rob
rgrassi
> Let's take something simple. In normal IF, I can type "put the vase
> on the table" (or, more likely, "put vase on table"). How do we
> do this in point&click?
In many ways:
1) Drag&Drop approach (drag vase on table, in the specific case the
relationship is equivalent from the other side, i.e. drag table on vase
will lead to the same command)
2) Click (right-click) on "vase" word, a menu or possible verbs appear
(+ a player input possibile) choose 'Put On', click on "table" word
3) Click on "vase" word, click CTRL+"table" (like you do in all
multiselection in Windows environment), on the second click a list of
possible interactions is displayed.
Rob
Adam Thornton
Which is why Latin.h turned out to be hard.
I took the approach that the canonical form of nouns was the accusative,
and canonical form of verbs the imperative. That's because it's how the
player is most likely to interact:
> TAKE APPLE
is really
> CAPE MALUM
(I cheerfully ignore diacriticals; for purposes of my game, "sumo" and
"capio" are treated as synonyms, if you were wondering).
Things get tricky with NPCs; you can refer to them in the accusative, of
course, but you need the vocative to address them, and you need the
dative in order for them to be indirect objects. For instance,
> GIVE APPLE TO JULIA
is
> DA MALUM IULIAE
But of course
> DA IULIAE MALUM
should work as well. I suppose technically so should
> IULIAE MALUM DA
but I really haven't got a problem with saying that the verb must go
first.
....
Then there's conversation:
IULIA, DA MIHI MALUM
I have NO intention of supporting "ASK JULIA TO GIVE ME THE APPLE."
It all becomes rather complex.
Adam
Uli Kusterer
> He elaborates: In "I scanned %g directories", you'd expect
> "directories'' to be in the accusative case (since it is the direct
> object) and a plural, except where $directory_count is 1--then you'd
> expect the singular, of course. Just like Latin or German. But! Where
> $directory_count % 10 is 1 (assuming $directory_count is an integer, and
> except where $directory_count % 100 is 11) "directories'' is forced to
> become grammatically singular, which means it gets the ending for the
> accusative singular. You begin to visualize the code it'd take to test
> for the problem so far, and still work for Chinese and Arabic and
> Italian, and how many gettext items that'd take. But he keeps going.
> Where $directory_count % 10 is 2, 3, or 4 (except where $directory_count
> % 100 is 12, 13, or 14), the word for "directories'' is forced to be
> genitive singular--which means another ending. The room begins to spin
> around you, slowly at first... And with all other integer values, since
> "directory'' is an inanimate noun, when preceded by a number and in the
> nominative or accusative cases (as it is here, just your luck!), it does
> stay plural, but it is forced into the genitive case--yet another
> ending. And because the floor comes up to meet you as you fade into
> unconsciousness, you never get to hear him talk about the similar but
> subtly different problems with other Slavic languages like Polish.
In case you want to see this from the other side of the fence, an
example of something similar (though not quite as involved) are ordinals
in English, where you have
1st, 2nd, 3rd 4th, 5th, ..., 11th, 12th, 13th, 14th, ..., 21st, 22nd,
23rd, 24th ...
where you'll notice that numbers ending in 1 have "st", 2 have "nd", 3
have "rd", all others have "th", except for those ending in "11", "12"
and "13", which also have "th".
While in Germany, we always just write "1.", "2.", "3." etc... (there is
no "1ste" in German).
Just thought I'd throw that in to make the Russians look less weird to
the English-speaking.
David Thornley
solar penguin <solar....@tiscali.co.THANKS.FOR.NOT.SENDING.SPAM.uk> wrote:
>David Thornley <thor...@visi.com> wrote:
>>
>> The obvious thing is to have a pictorial depiction of the room, so I
>> can click on the vase (in an inventory display), and then on the
>> table. I'm not seeing any other way that doesn't involve simply
>> clicking on "put", "vase", "on", and "table".
>
>Maybe you could click-and-drag the word "vase" in the IF text output and
>drop it on the word "table".
>
extend that much.
Moreover, it fails to distinguish "put vase on table" from "put vase
under table" or "touch table with vase".
Uli Kusterer
"Chris Pickett" <cpi...@gmail.com> wrote:
> That test for i18n (switching between languages whilst maintaining the
> same game state) was not offered because I thought that it was
> particularly useful to do so (although I do think it would be cool),
> but rather because it seems likely that any game passing it will have
> the input and output separated "properly". That's all.
Well, there are many ways to achieve separation between game state and
input and output. They have also been explored quite nicely in software
engineering (take, e.g. the Model-View-Controller paradigm). rgrassi
didn't indicate at all that this was what he was aiming for. In any
case, internationalisation is a worst-case scenario in that case. As the
Russian example showed so nicely, internationalisation involves not only
text and placeholders, but also logic. As such, your code would simply
need different layers, i.e. a language output layer (lo) and a language
input layer (li), a game controller layer (your actual game code) and a
model layer (mo). Then your game would contain code like:
mo_drop( red_ball );
lo_dropped_object( red_ball, current_room );
and the layers would take care of the correct grammar. This is
essentially the same as TADS 3's approach of having one central library
and different add-on language modules (en_neu etc.).
Still, this would only work for the library. Anything else would have to
be translated by you, manually.
-- Uli
http://www.zathras.de
Uli Kusterer
"Chris Pickett" <cpi...@gmail.com> wrote:
> Anyway, the Inform library has more-or-less already been translated in
> this manner, as previously pointed out, so clearly it's not infeasible.
> Yes it's painful for programmers, but maybe it could be made better.
> The text editor could inline the routines and messages for the current
> language to make editing the bits that change the game state easier,
> and inline 2 languages side-by-side to make translation easier. It
> seems like emacs could be extended to handle this.
Actually, most IF compilers have a command that extracts all text from a
game so you can spell-check it, and there are lots of development tools
that would also be able to put them back in afterwards. So, that also
has already been done.
Of course, this'd be a stupid search-and-replace, so you'd still have to
manually adjust the cases where text is assembled by the game
dynamically.
-- Uli
http://www.zathras.de
Uli Kusterer
"rgrassi" <rgras...@gmail.com> wrote:
> A good reason will be for all of us to work on an unified IF
> development environment without develop everyone a single brick of the
> wall. Then, localization groups will activate to write the specific
> part of libraries.
"will activate" makes it sound very easy. :-)
-- Uli
http://www.zathras.de
Uli Kusterer
Andrew Plotkin <erky...@eblong.com> wrote:
> I
> mean, look at the Inform library. It *has* this clean division: game
> state code is in verblibm.h, standard English messages are in
> English.h. It's absolutely miserably unreadable.
>
> [ PullSub;
> if (ObjectIsUntouchable(noun)) return;
> if (noun has static) return L__M(##Pull, 1, noun);
> if (noun has scenery) return L__M(##Pull, 2, noun);
> if (noun has animate) return L__M(##Pull, 4, noun);
> L__M(##Pull, 3, noun);
> ];
>
> If you tell authors to write their game code that way, they'll run
> screaming for the hills. I certainly would.
Well, in defense of the idea, one should point out that this is
probably as much a problem of the syntax used. One could easily rewrite
the above to replace L__M and ##Something with a more readable special
syntax, so people would just write LPull( 1, noun ) or whatever.
> The other side of this coin is: when you translate a game into another
> language, you're spending all of your time on the input and output
> stuff. Game-state code is (from your point of view) a few simple nuts
> and bolts which the real translation problem is wrapped around. So
> "true internationalization", in the sense you are talking about,
> doesn't actually make your life any easier.
This is, IMHO, the main point. I've translated program documentation,
and I've extracted game text. Considering the amounts of text involved
in either, I'd wager Dollars to Doughnuts that the reason so few people
translate games isn't that it's too hard to translate the logic and
track down the text, but rather that it's horribly hard to translate
that much text, and most people with the language skills to pull off the
translation would probably rather write their own games.
This isn't an Anime where you write a Fansub that's effectively ten
pages of text. Interactive fiction often clocks in at more in the
magnitude of 40+ pages, which is, IIRC, the limit where a novel starts
and a so-called "short story" ends.
> What I'm saying is, the naive model of "take the English source code,
> edit most of it, and then compile with the standard Italian library"
> (which is what you'd do in Inform) is actually pretty close to as good
> as it's going to get. I don't see a smarter design model as buying you
> any real advantages.
What I'd say is this: The OP's ideas may be neat features, but they
don't merit designing a whole new system just to get them. What I'd
rather suggest he do is find some existing projects that are closest to
his ideal and contribute to them. E.g. add prettier syntax to Inform,
add a "highlight string literals" and "jump to next literal" command to
a text editor, and maybe a "lock everything but the literals" option so
people can edit text without having to fear they'd total the code.
There are many existing systems that already *almost* do what he wants.
He should help them out. When he does that, he'll have a built-in
developer base that might even help him. When he starts an entirely new
IDE/compiler/interpreter project (as the subject of this thread led me
to believe), he'll have to convince people the project has merit by
first providing everything the others already have (which is the
minimum) before he'd even be able to start on the interesting stuff.
Just my $0.02
-- Uli
http://www.zathras.de
ChicagoDave
the command structure _and_ the language library?
The implementation should be abstracted entirely so that you would have
hooks...
parser.command (standard component)
command.languageType (custom component based on grammatical
differences)
languageType.language (custom component based on actual language)
Is this even possible or would this require the parser to be hugely
complex?
David C.
rgrassi
> > So "true internationalization", in the sense you are talking about,
> > doesn't actually make your life any easier.
It makes life a little easier for "non english" and a little harder for
english.
A good compromise.
> This is, IMHO, the main point. I've translated program documentation,
> and I've extracted game text. Considering the amounts of text involved
> in either, I'd wager Dollars to Doughnuts that the reason so few people
> translate games isn't that it's too hard to translate the logic and
> track down the text, but rather that it's horribly hard to translate
> that much text, and most people with the language skills to pull off the
> translation would probably rather write their own games.
That's exactly what we did (and do) in Italy and in the rest of the
world.
> > What I'm saying is, the naive model of "take the English source code,
> > edit most of it, and then compile with the standard Italian library"
> > (which is what you'd do in Inform) is actually pretty close to as good
> > as it's going to get. I don't see a smarter design model as buying you
> > any real advantages.
You don't catch the design of multi-authors and multi-players playing
concurrently the game in different countries. Imho, it's a radical
change. We should try to think as actual IF applications do not exist,
at least to speculate on possible changes.
> What I'd say is this: The OP's ideas may be neat features, but they
> don't merit designing a whole new system just to get them. What I'd
> rather suggest he do is find some existing projects that are closest to
> his ideal and contribute to them.
Some parts of this 'ideal' architecture are already there and only need
few coding, imho.
> There are many existing systems that already *almost* do what he wants.
Any hint?
I've had a look at Inform, Hugo and Adrift.
Rob
rgrassi
want to support interactions in different possible client types (p&c,
usual parsing, cyoa). What we want to play is:
"PUT VASE ON TABLE"
Object Vase
PointAndClick
(
IconEye
-> Examine () // Redirect to Examine Action
IconHand
-> "Table" -> PutOn (Table) // Redirect to PutOn passing the Table
as as argument
-> NOT "Table" -> PutOn () // Redirect to PutOn passing NULL
-> "" -> Search () // Redirect to Search passing NULL
IconTalk
-> Talk () // Redirect to the Talk Action
)
CyoaLike
(
"Put the vase on the table"
-> PutOn
"Search the vase"
-> Search
"Examine the vase"
-> Examine
)
Actions // This could be similar to current IF tools
(
(Examine -> DoExamine) // Processes the Action in the libraries
(
PutOn
(If SecondObject = "Table" -> DoPutOn // Processes the Action in the
libraries
Else $GenFalseDoPutOn // Redirect to external file message to be
localized
)
)
(Search -> DoSearch) // Processes the Action in the libraries
)
Bert Byfield
"Pseudocode" was invented for non-programmers. It's a government thing, but
it has its uses, if those uses are to write in English what we want a
program to do. (As a formal program spec in a work environment, it is worse
than useless.)
Samwyse
> In article <43ccfd72$1...@mk-nntp-2.news.uk.tiscali.com>,
> solar penguin <solar....@tiscali.co.THANKS.FOR.NOT.SENDING.SPAM.uk> wrote:
>>Maybe you could click-and-drag the word "vase" in the IF text output and
>>drop it on the word "table".
>>
>
> That works, to some extent, for some verbs, but I don't know how you'd
> extend that much.
>
> Moreover, it fails to distinguish "put vase on table" from "put vase
> under table" or "touch table with vase".
Obviously, you drop the word "vase" so that it covers the top or bottom
half of the word "table" to differentiate "put vase on table" from "put
vase under table". As for "touch table with vase", you pick up the word
"vase", hover it over the word table until a list of tooltips appears,
and then release it over the word "touch".
David Fisher
news:11snmqt...@corp.supernews.com...
> In article <1137402360.9...@g49g2000cwa.googlegroups.com>,
> rgrassi <rgras...@gmail.com> wrote:
>>
>>What I'm saying is that 'current' IF can be represented (and played)
>>with a p&c approach.
>>
...
> A lot of current IF would not work at all well with point&click.
> It would be necessary to provide a complete list of verbs and
> nouns, along with prepositions.
>
> Let's take something simple. In normal IF, I can type "put the vase
> on the table" (or, more likely, "put vase on table"). How do we
> do this in point&click?
Not to mention references to things that are not currently visible ("ask
Fred about Amsterdam"), or abstract entities ("tell Fred about
beetmongerism") ...
Certain games work best with conversation menus (which suits point & click),
but some don't at all - part of the enjoyment is figuring out what to talk
about. For these types of games, an explicit list of conversation topics
would either be too short, giving away too much information, or (to prevent
this problem) too long - if there are a hundred or so topics to choose from,
it would be simpler to just type one than to scan through the whole list to
find one that matches what you want to say.
David Fisher
Samwyse
> Jon Rosebaugh wrote:
>> Chris Pickett wrote:
>>
>>>To me your "ever more complex" suggests an exponential blowup. The
>>>cost for adding a new language doesn't actually grow exponentially,
>>>since it doesn't depend (in a bad way) on the number of languages you
>>>already support. Please offer a counterexample if you know one.
>>
>>Samwyse's post provides an excellent counterexample. Essentially, each
>>additional language has sufficient special-cases that your code will
>>quickly grow unmanageable. This may not be truely exponential growth,
>>but I'm not the one who used that term in the first place.
>
> I don't see why his post is a counterexample. It just says i18n is a
> pain, and that you can do it badly. All I'm saying is that adding a
> translation into Russian has the same difficulty if you currently
> support just English, or if you currently support both English and
> Chinese. It doesn't "quickly grow" unmanageable -- it grows linearly.
> It might even be simplified if you already support a similar language.
To use Zarf's favorite word, I think that the complexity is fractal.
Some languages are trivial, some are hideously difficult. That article
that I was quoting went on the describe the author's favored solution,
which is that you keep your strings simple, and each one gets replaced
by a subroutine (which hopefully can be semi-automatically generated).
The downside is that (to follow through to the logical conclusion), you
initially write your prose in a "Me Tarzan" sort of style and let the
library translate your broken English into proper.
solar penguin
> Trying to write pseudocode (sorry, I'm not a programmer).
I'm not much of a programmer either, but there could be a problem in
your system...
> Let's say we
> want to support interactions in different possible client types (p&c,
> usual parsing, cyoa). What we want to play is:
> "PUT VASE ON TABLE"
>
> Object Vase
>
> PointAndClick
> (
> IconEye
> -> Examine () // Redirect to Examine Action
> IconHand
> -> "Table" -> PutOn (Table) // Redirect to PutOn passing the Table
> as as argument
> -> NOT "Table" -> PutOn () // Redirect to PutOn passing NULL
> -> "" -> Search () // Redirect to Search passing NULL
> IconTalk
> -> Talk () // Redirect to the Talk Action
> )
>
Let's ignore the fact that you've forgotten to include things like
"Take" and "Drop". Your IconEye can't tell the difference between
"Examine Vase" and "Look In Vase". (If it's got a long, thin neck then
you wouldn't see inside it just by examining the outside!) Also, your
IconHand->IconTable can't tell the difference between "Put Vase On
Table", "Put Vase Under Table", "Smash Vase Against Table", "Throw Vase
At Table", "Throw Vase Over Table", "Pour Contents Of Vase Onto Table",
etc. Allow different icons for all those actions, and there'll soon be
know room onscreen for anything else!
And why is the table coded as a special case anyway? What if the player
wants to put the vase on the armchair or the boulder? Shouldn't there
be generic PutOn handling for all surfaces?
(And what's with the IconTalk? Why would you want to talk to a vase in
the first place?)
> CyoaLike
> (
> "Put the vase on the table"
> -> PutOn
> "Search the vase"
> -> Search
> "Examine the vase"
> -> Examine
> )
>
And this is where it gets even more complicated. You'd need a LOT more
options to cover all the things the player might want to do with the
vase. Plus, you'd need extra code to enable and/or disable the options
at the appropriate time. e.g. You can't "Put the vase on the table" if
there isn't a table there, and you can only "Pour the contents of the
vase onto the table" once the payer knows the vase isn't empty, etc.
If you offer these options at the wrong point in the game, they could
give away too many clues to the player ("Pour? Aha! The vase has some
liquid hidden inside it!") so they should only be displayed at the right
time.
Add in similar options and conditions for every item in scope and the
list soon becomes unmanageable.
> Actions // This could be similar to current IF tools
> (
> (Examine -> DoExamine) // Processes the Action in the libraries
> (
> PutOn
> (If SecondObject = "Table" -> DoPutOn // Processes the Action in the
> libraries
> Else $GenFalseDoPutOn // Redirect to external file message to be
> localized
> )
> )
> (Search -> DoSearch) // Processes the Action in the libraries
> )
Once again, why is the table coded as a special case? Are you assuming
that the table is the only surface that the players will want to put
vase on? Why can't we put it on the armchair instead? Or the tree
stump? Or (in true Advent tradition) the soft pillow?
No-one would write code (or even psuedo-code) for a real game that was
anything like this. Far better to use sensible defaults rather than
only allow special cases.
Ok, I'll admit it. I'm biased. I'm more into the simulationist side of
IF rather than the storytelling side. You might be happy only allowing
the vase to go on the table because that's the only action that advances
your story. Personally, I wouldn't want to play a game like that, no
matter what the user interface was. Sorry.
--
___ _ ___ _
/ __| ___ | | __ _ _ _ | _ \ ___ _ _ __ _ _ _ (_) _ _
\__ \/ _ \| |/ _` || '_| | _// -_)| ' \ / _` || || || || ' \
|___/\___/|_|\__,_||_| |_| \___||_||_|\__, | \_,_||_||_||_|
|___/
http://www.freewebs.com/solar_penguin/
** We're going to stop the machine with the leg.
** I thought he might be heard in the Rockies.
rgrassi
I am aware that I'm just exposing 'concepts', do not ask for detailed
specifications or for exaustive examples.
I'm just speculating about possible ways to satisfy requirements.
I am aware that "p&c" and "cyoa-like" apporaches will have some limits
and constraints.
For instance:
1) Both could not have and "undo" action (and the action should be
removed or not doable again)
2) In p&c approach (that code was an example) you should either
2a) Force a default verb for the action
2b) Get a verb from the player (for a given clicked object) from a list
or from free input
This things do not exclude the *feasibility*.
Rob
solar penguin
Sorry, Rob. I'm still not convinced. Just look at all the CYOA options
needed to implement a standard IF grammar table in a one-room game with
only two objects. I'm assuming that your system can somehow
automatically weed out obviously irrelevent commands such as "Dig table"
or "Buy vase with table" and only offer actions that are physically
possible in the context of the game world.
Boring Room.
You are in a boring room. There are no exits.
You can see a table and a vase here.
Your options are:
1. Attack or break the table.
2. Attack or break the vase.
3. Blow on the table.
4. Blow on the vase.
5. Taste the table.
6. Taste the vase.
7. Wave your hands.
8. Get the table.
9. Get the vase.
10. Get all.
11. Jump up and down.
12. Jump over the vase.
13. Jump over the table.
14. Listen to your surroundings.
15. Listen to the table.
16. Listen to the vase.
17. Look under the table.
18. Push the table.
19. Push the vase.
20. Push the table to the vase.
21. Push the vase to the table.
22. Pull the table.
23. Pull the vase.
24. Rub or clean the table.
25. Rub or clean the vase.
26. Go to sleep.
27. Smell your surroundings.
28. Smell the table.
29. Smell the vase.
30. Squeeze the table.
31. Squeeze the vase.
31. Taste the table.
32. Taste the vase.
33. Examine the table.
34. Examine the vase.
> 9
Taken.
Your new options are:
1. Attack or break the table.
2. Attack or break the vase.
3. Blow on the table.
4. Blow on the vase.
5. Drop the vase.
6. Taste the table.
6. Taste the vase.
7. Wave your hands.
8. Wave the vase.
9. Get the table.
10. Jump up and down.
11. Jump over the table.
14. Listen to your surroundings.
15. Listen to the table.
16. Listen to the vase.
17. Look under the table.
18. Put the vase on the table.
19. Push the table.
20. Push the table to the vase.
22. Pull the table.
24. Rub or clean the table.
25. Rub or clean the vase.
26. Go to sleep.
27. Smell your surroundings.
28. Smell the table.
29. Smell the vase.
30. Squeeze the table.
31. Squeeze the vase.
31. Taste the table.
32. Taste the vase.
33. Examine the table.
34. Examine the vase.
35. Look inside the vase.
36. Throw the vase at the table.
And so on...
Don't forget, all this is just for two objects. Imagine a full
inventory of objects, each with dozens of options. Plus various exits,
etc.
Ok. So most of the options would just produce a boring "Nothing
happens," message, but the players won't *know* that nothing happens
until they try the actions. There's always the possibility of doing
something silly and finding it worked after all. That's half the fun of
playing IF.
And I've kept it simple by not including meta commands like Save,
Restore, Inventory etc. In practice, you'll need to include them too.
You might think it's theoretically possible to write a game this way,
but in practice, it's not going to produce a playable CYOA. And it
would be too much like hard work for the programmer with too little to
show for it at the end.
--
___ _ ___ _
/ __| ___ | | __ _ _ _ | _ \ ___ _ _ __ _ _ _ (_) _ _
\__ \/ _ \| |/ _` || '_| | _// -_)| ' \ / _` || || || || ' \
|___/\___/|_|\__,_||_| |_| \___||_||_|\__, | \_,_||_||_||_|
|___/
http://www.freewebs.com/solar_penguin/
** And it'll continue to kill his own story of his own malice.
** The spirit wished to be rid of him, and his trainer lies dead on
Dartmoor.
rgrassi
> Sorry, Rob. I'm still not convinced. Just look at all the CYOA options
> needed to implement a standard IF grammar table in a one-room game with
> only two objects.
Switching to CYOA-Like would be:
1) A different way to play the game for a "non novice" player.
2) A preferred way to play for novice players.
In that sense there is absolutely "no need" to duplicate ALL the
possibile interactions building all the possible matrices of actions.
Two ways to solve this issue could be.
A) The author of the game writes only the possible (inter)actions that
a player can reasonably do in the room. This leads to "static" choices
for that room (like paper based CYOA).
B) The author writes a list of predefined interactions which is
displayed (pop-up?, in-line with text?, i don't know) when the player
clicks on an object. In that sense 'granularity of choices' will be
greater and one can control better the choices to be listed (according
to game-state).
> I'm assuming that your system can somehow automatically weed out
> obviously irrelevent commands such as "Dig table"
My system does not exist. :)
I'm trying to understand if it will exist.
Rob
Chris Pickett
> Sorry, Rob. I'm still not convinced.
[...]
> You might think it's theoretically possible to write a game this way,
> but in practice, it's not going to produce a playable CYOA. And it
> would be too much like hard work for the programmer with too little to
> show for it at the end.
I'd really suggest trying out Return to Zork. It's not a perfect game,
but it's got a nice interface for a point-and-click, one that's much
different from what's in the Sierra and LucasArts games. It attempts
to handle the issues you're bringing up.
Basically, the actions available for an object only pop up when you try
to use it, either by itself, or when you try to make it interact with
another object. And of course the list of choices presented is
context-sensitive. As for conversation, you have a tape recorder, for
recording what people say to you and then playing it back to others,
and you can express different emotions during conversation in order to
solicit different responses.
I'm pretty sure you can find it on an abandonware website somewhere if
you look a little. If not, email me and I'll see about making an iso
(have to find someone with the CD first, mine's lost).
Chris
David Thornley
rgrassi <rgras...@gmail.com> wrote:
>Two ways to solve this issue could be.
>
>A) The author of the game writes only the possible (inter)actions that
>a player can reasonably do in the room. This leads to "static" choices
>for that room (like paper based CYOA).
>B) The author writes a list of predefined interactions which is
>displayed (pop-up?, in-line with text?, i don't know) when the player
>clicks on an object. In that sense 'granularity of choices' will be
>greater and one can control better the choices to be listed (according
>to game-state).
>
tacks on a parser so it can be played from a command line? This is
considerably different from designing a conventional IF game.
Look, if you dislike conventional IF so much that you propose a system
with constraints that are going to make it impossible, why are you
writing here?
It seems to me that you want to force every game in your system to
be playable with point&click, CYOA, and text parsers in arbitrarily
many languages. That sounds to me like an incredible amount of work,
guaranteed to make sure that no good games are ever written for it.
rgrassi
> In other words, the author writes a CYOA game, and if he or she likes
> tacks on a parser so it can be played from a command line? This is
> considerably different from designing a conventional IF game.
No, the author writes a conventional IF game and writes 'hooks' for
possible different types of input from the player. Infact, EVERY input
is then passed to the parser routine like if the player has typed on
the command line.
> Look, if you dislike conventional IF so much that you propose a system
> with constraints that are going to make it impossible, why are you
> writing here?
1) I do not dislike conventional, infact I play and write it.
2) I supposed that raif SHOULD host discussions and threads like this.
Or not?
3) Is it really so impossible? I think not. (Furthermore forget about 1
single author building all the game. Group of organized authors can
build the whole thing).
> That sounds to me like an incredible amount of work,
> guaranteed to make sure that no good games are ever
> written for it.
Is it an axiom?
Rob
David Thornley
rgrassi <rgras...@gmail.com> wrote:
>Hi,
>
>> In other words, the author writes a CYOA game, and if he or she likes
>> tacks on a parser so it can be played from a command line? This is
>> considerably different from designing a conventional IF game.
>
>No, the author writes a conventional IF game and writes 'hooks' for
>possible different types of input from the player. Infact, EVERY input
>is then passed to the parser routine like if the player has typed on
>the command line.
>
system, you have to have a sufficiently short list of choices for the
player to consider them all, with the good choices all in that list,
and in a way that doesn't give away puzzles.
For example, in Unkuulia I (or is it II), there is a puzzle involving
the use of a lantern as a heat source, rather than a light source.
Should the appropriate command be in a list of commands short enough
to be usable?
Or, consider the riddle, as found in Beyond Zork and Leather Goddesses
of Phobos. What makes these fun is thinking of the answer, but that
is spoiled if the game has to provide a list of possible answers.
Either there are several plausible answers, so the player succeeds
only by chance, or only one, so the player just reads the list to
solve the puzzle.
I'm not saying that CYOA are necessarily bad, but rather different.
They don't lend themselves to an exploration of conversational topics,
and make lateral-thinking puzzles very hard to implement.
Nor have I found a good way to do point&click, except either by
selecting words from something like a drop-down menu or having
graphics. Selecting words with the mouse is hardly what most people
would call a point&click interface.
So, a game that is to support all three methods of input has to be
restricted enough to be a CYOA and have graphics. This isn't
going to work in general.
>> Look, if you dislike conventional IF so much that you propose a system
>> with constraints that are going to make it impossible, why are you
>> writing here?
>
You know, that came off a lot snarkier than I intended. I apologize
for the tone.
>1) I do not dislike conventional, infact I play and write it.
>2) I supposed that raif SHOULD host discussions and threads like this.
>Or not?
Certainly, but it seems to me that this discussion is rapidly developing
into reasons why some things are exceedingly difficult or impossible.
>3) Is it really so impossible? I think not. (Furthermore forget about 1
>single author building all the game. Group of organized authors can
>build the whole thing).
>
Okay, you've now excluded a very large amount of IF. At least to me,
one of the charms of IF is that a good game can be created by one
person in spare time. If it will be necessary to forget about that,
as you suggest, not only are we changing the nature of IF, but
we run into problems. How are these groups going to be organized?
If they share the exact same artistic vision, that's really nice, but
hardly reliable. If they are a team of equals with different visions,
the game is going to show it. Some games do work that way, but some
will very definitely not. If they are a team with a leader or architect,
then there's the question of what the others are going to get out of
it. They aren't expressing themselves artistically, and they aren't
getting out of this a piece of software they're going to use.
The open source projects I've seen that involve numerous people tend to
produce something that is useful or entertaining for the people involved.
Of all the software I've seen, IF is one of the ones less useful to the
actual developer. If you're one of the Nethack implementers, you
presumably play Nethack. I would think that the people on the XEmacs
project do their work using XEmacs. I can't really imagine enjoying
a piece of IF that I've written in the same way.
>> That sounds to me like an incredible amount of work,
>> guaranteed to make sure that no good games are ever
>> written for it.
>
>Is it an axiom?
>Rob
>
Hardly, but it's getting to be my conclusion. Certainly, if multiple
authors are *required*, there's going to be relatively few games for
it compared to the number for the more conventional systems.
Now, if you want to convince me otherwise, sketch something out.
Right now, I don't care about implementation, since I think the
fundamental problem is in the user experience.
Take a reasonable IF game, or make up a similar situation. Consider
one situation in the game, or a set of related ones. Describe to
me how the point&click interface is going to work from a user
standpoint, and describe to me how the CYOA interface is going to
work, also from a user standpoint. Make sure to provide a variety
of actions similar to those that standard text IF provides.
I really doubt that point&click will work without graphics, and I
don't think the CYOA is going to work at all.
Kevin Venzke
"rgrassi" <rgras...@gmail.com> wrote in message
news:1137610453....@g43g2000cwa.googlegroups.com...
> Hi,
>
>> In other words, the author writes a CYOA game, and if he or she likes
>> tacks on a parser so it can be played from a command line? This is
>> considerably different from designing a conventional IF game.
>
> No, the author writes a conventional IF game and writes 'hooks' for
> possible different types of input from the player. Infact, EVERY input
> is then passed to the parser routine like if the player has typed on
> the command line.
Does this mean you think it should be quite possible and straight-forward
to translate most works of IF into CYOA?
That's an interesting idea. I think it would have to work like this: The
> prompt is replaced by a menu containing those commands (of all
possible commands in the game) that would affect game state.
For this to work I think the IF system needs a couple of things for
sure:
1. The ability to determine whether a command will affect game
state. That's almost the same as trying each command, noting
whether game state changed, and UNDOing.
2. The programmer needs to be able to specify that a command,
despite not affecting game state, should still appear on the menu.
Otherwise the player will never see important error messages
to explain why something is impossible. And in most cases,
EXAMINE wouldn't be an option since it doesn't affect game
state.
3. Maybe the programmer needs to be able to hide options... It
would be annoying to have "remove shirt" and "remove pants"
as options on every menu, even if they do affect game state.
Kevin Venzke
Chris Pickett
> > possible different types of input from the player. Infact, EVERY input
> > is then passed to the parser routine like if the player has typed on
> > the command line.
>
> Does this mean you think it should be quite possible and straight-forward
> to translate most works of IF into CYOA?
>
> That's an interesting idea. I think it would have to work like this: The
> > prompt is replaced by a menu containing those commands (of all
> possible commands in the game) that would affect game state.
>
> For this to work I think the IF system needs a couple of things for
> sure:
> 1. The ability to determine whether a command will affect game
> state. That's almost the same as trying each command, noting
> whether game state changed, and UNDOing.
> 2. The programmer needs to be able to specify that a command,
> despite not affecting game state, should still appear on the menu.
> Otherwise the player will never see important error messages
> to explain why something is impossible. And in most cases,
> EXAMINE wouldn't be an option since it doesn't affect game
> state.
> 3. Maybe the programmer needs to be able to hide options... It
> would be annoying to have "remove shirt" and "remove pants"
> as options on every menu, even if they do affect game state.
I don't like to go on about it, even though I do, since it's still
quite primitive, and hasn't yet met its original goal, but we do have
such a system... you type "query moves" at the prompt and it tells you
every possible action. The programmer doesn't need to do anything. I
suppose there's no #3, but it's easy to add. Actions are already in a
canonical form since we have no parser.
http://gram.cs.mcgill.ca/nfg.php
You're welcome to do (almost) what you want with it. The point up
until now has actually been that "query win" and "query lose" tell you
how to win or lose. Except that part only works for Cloak of Darkness
and things of similar size. A full remake of The Count by Scott Adams
is there too, in CYOA style... feel free to implement an external
parser and then you'll have both true IF and CYOA. Oh yeah the thing
is written in the ugliest Java you ever did see, but at least the class
libraries are exploitable...
I feel like a bit of a broken record. Sorry.
Chris
rgrassi
That's very interesting Chris.
Rob
Gene Wirchenko
[snip]
>Nor have I found a good way to do point&click, except either by
>selecting words from something like a drop-down menu or having
>graphics. Selecting words with the mouse is hardly what most people
>would call a point&click interface.
[snip]
>I really doubt that point&click will work without graphics, and I
>don't think the CYOA is going to work at all.
Point-and-click works just fine on the Web where it is called
"hypertext".
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
David Thornley
Gene Wirchenko <ge...@abhost.us.NOTTHIS> wrote:
>thor...@visi.com (David Thornley) wrote:
>
>>Nor have I found a good way to do point&click, except either by
>>selecting words from something like a drop-down menu or having
>>graphics. Selecting words with the mouse is hardly what most people
>>would call a point&click interface.
>
>>don't think the CYOA is going to work at all.
>
> Point-and-click works just fine on the Web where it is called
>"hypertext".
>
most IF. It would work well with Andrew Plotkin's "The Space
Under the Window".
I think that, on order to argue productively, we need to
establish what the "p&c" interface actually is. I am assuming
something similar to the graphic adventures I've played (and I
haven't played much).
rgrassi
new IF platform supporting the things we're discussing about.
No lines of code, just concepts, in order to produce something that the
other can read and evaluate.
If interested please write me privately, to build a put "team of
specs".
Rob