Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1398312 Posts in 67585 Topics- by 60903 Members - Latest Member: anastefanescu

January 21, 2022, 06:28:18 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Text adventures
Pages: [1] 2
Print
Author Topic: Text adventures  (Read 11866 times)
SplinterOfChaos
Level 3
***



View Profile
« on: April 18, 2007, 01:16:00 PM »

I don't know how many text adventure fans there are out there, but I want to make one, so does anyone know of a good tool to help, but that allows you to do much of your own coding?

I'm particularly looking for one in Java, the language I'm CURRENTLY learning, although I'd like to know what other languages have as well.
Logged

Caio
Level 10
*****


KAH-yoo


View Profile
« Reply #1 on: April 18, 2007, 02:05:38 PM »

You could try ADRIFT. It's not exactly what you want, but it's still a powerful tool.
« Last Edit: April 18, 2007, 02:07:24 PM by Akhel » Logged
SplinterOfChaos
Level 3
***



View Profile
« Reply #2 on: April 18, 2007, 02:53:46 PM »

You're right, it's not what I'm looking for, although I did note that I'm interested in what options there are needless of whether they're what I want.

Although, I tried to download it and I keep getting errors upon trying to run. I've tried the old versions too.
Logged

Derek
Bastich
Administrator
Level 10
******



View Profile WWW
« Reply #3 on: April 18, 2007, 03:01:27 PM »

http://en.wikipedia.org/wiki/Interactive_fiction

Look at the bottom, under "Interactive fiction development systems." Wink
Logged
SplinterOfChaos
Level 3
***



View Profile
« Reply #4 on: April 18, 2007, 05:30:47 PM »

I thought that I might mention Pyparsing (http://pyparsing.wikispaces.com/). I know I'm the one looking for info, but maybe someone else is too and finds that helpful.

Pyparsing basically simplifies parsing impossibly well, allowing you to create sentence structures and test them against your strings. But it's only good if you are working with Python.

http://en.wikipedia.org/wiki/Interactive_fiction

Look at the bottom, under "Interactive fiction development systems." Wink
Huh. I don't know how I forgot Wiki. Good resource, but I'm still looking for a more Java-native tool.
« Last Edit: April 18, 2007, 05:46:36 PM by SplinterOfChaos » Logged

Chris Whitman
Sepia Toned
Level 10
*****


A master of karate and friendship for everyone.


View Profile
« Reply #5 on: April 18, 2007, 09:28:57 PM »

I don't know much about natural langauge processing, but if you're interested in implementing your own parser you could always look up some information on parsing formal grammars. The simplest methods I'm aware of involve describing a grammar in Backus-Naur form and building parse trees from input phrases, which can be used on very limited sets of English (they are ideal for subject-verb-object forms, for example).

Basically, you run through your input phrase and process individual tokens in terms of lexical categories, like noun and verb, then use Backus-Naur form (or some equivalent) to attempt to build a parse tree based on a system of formal rules. If you can successfully build a tree with one terminal at the root, you have a syntactically correct input and you can process it semantically to get the actual 'meaning' of the instruction.

That's kind of just a really basic rundown on a simple method which is often used to process formal languages, you should be able to find more information on, say, Wikipedia or from a language processing text.

If you're interested in getting your hands dirty with interactive fiction without getting too much into language parsing theory, I'd really recommend checking out Inform 7 (you can probably google it for the web site) -- it's a language which compiles to Z-code* and is expressed using a limited subset of English. For example, to define a room containing an angry midget, you would write something like:

The Midget Room is a room. The angry midget is a person in the Midget Room. The description of the Midget Room is "You are in a room. An angry midget is glowering at you."

That may not be entirely correct, but that's sort of how Inform 7 programs look. You should check it out if you're interested. It's really quite neat.

* Edit: because it compiles to Z-code, compiled games can be played in any program which will execute Z-code, so you don't have to worry about writing parsing code yourself.
« Last Edit: April 18, 2007, 09:33:47 PM by I Like Cake » Logged

Formerly "I Like Cake."
ZombiePixel
Level 0
***


View Profile
« Reply #6 on: April 19, 2007, 06:41:11 PM »

Interesting.  Would you consider the act of typing "PICK UP SHOTGUN" to be meaningful interaction with the game?  Offering action-lists and hyperlinked objects would achieve the same level of control in the game without the need to write a parser and account for incorrect spellings and phrasing.  Or is typing out words the actual fun part of IF?
Logged
SplinterOfChaos
Level 3
***



View Profile
« Reply #7 on: April 19, 2007, 07:05:07 PM »

I'll be sure to Google that, but to be more clear, what I'm looking for is any tool that is NOT a language of itself, but rather (for example) a library of helpful classes, parsing, grammar etc., etc.

I could make my own parser, but Java is a side project of my current life, the main parts being school and mental instability. And the IF is just an experimental side project of my main Java project (trying to make a variable calculator ex: X*X=X^2). I don't have that much time to learn in depth parsing. But if it comes to it, I'll do it.
Logged

Chris Whitman
Sepia Toned
Level 10
*****


A master of karate and friendship for everyone.


View Profile
« Reply #8 on: April 19, 2007, 11:19:57 PM »

Interesting.  Would you consider the act of typing "PICK UP SHOTGUN" to be meaningful interaction with the game?  Offering action-lists and hyperlinked objects would achieve the same level of control in the game without the need to write a parser and account for incorrect spellings and phrasing.  Or is typing out words the actual fun part of IF?

I don't understand how "PICK UP SHOTGUN" wouldn't be meaningful interaction with a game which involved picking up shotguns!

I'm really no expert on IF (or on language parsing for that matter), and it seems that most parsers do tend to accept fairly limited input, but BNF definitions and the other standard methods for parsing language can be extremely useful in that they contain simple ways of addressing the problem domain which might be more complex in other languages.

For example, let's say you had a basic parser which recognized input in the form of "<verb> <noun>", so you could say, "Get shotgun" and it would be accepted as valid input, but say you would like to expand the grammar to be able to give instructions to NPCs existing in the game in the form of "<NPC name>, <verb> <noun>". You could go about hacking up your parsing routines to interpret a new special case using basic string tokenization, but if you were working on a system which could interpret Backus-Naur Form, you could simply add a new lexical category of NPC names and specify a few new productions, and your parser would have a method of identifying "<NPC name>, <verb> <noun>" with a limited amount of programmer effort.

The reason these things exist in the first place is that they are useful tools which reduce the complexity of common problems. Of course, if you know you are only going to ever want "<verb> <noun>" as input, a more trivial parser might be much faster to develop, but a more in depth approach gives you more flexibility in the long run.

I've got a couple of exams tomorrow, but I'll take a look and see if I can find some Java packages for parsing grammars. I'll try to post something tomorrow or Saturday if anything turns up.
Logged

Formerly "I Like Cake."
Chris Whitman
Sepia Toned
Level 10
*****


A master of karate and friendship for everyone.


View Profile
« Reply #9 on: April 19, 2007, 11:30:34 PM »

Actually, come to think of it, the kind of equation solver you are referring to could also use formal grammars to parse equations, so that area of study would be more generally useful to you as well.

Of course, it comes down to some fairly complex stuff that I am not terribly familiar with. I touched on it in a section on compilers in a course I just finished, but I'm hardly an expert. Still, you might find it useful.
Logged

Formerly "I Like Cake."
Madgarden
Level 1
*


C=


View Profile
« Reply #10 on: April 20, 2007, 11:17:07 AM »

Interesting.  Would you consider the act of typing "PICK UP SHOTGUN" to be meaningful interaction with the game?  Offering action-lists and hyperlinked objects would achieve the same level of control in the game without the need to write a parser and account for incorrect spellings and phrasing.  Or is typing out words the actual fun part of IF?

This isn't so simple. Point-and-click, drag-and-drop are clumsy replacements for intelligent experimentation and creative thinking. Certainly obvious actions such as picking up a shotgun is adequate using a hyperlinked interface, and even loading it with an item from your inventory. You can even drag each item in your inventory onto the shotgun before lucking out on one that works with it... but is that what you want for gameplay? Hyperlinking (drag-n-drop etc.) risks giving away the solution to the problem by leading the player with the restricted options available.

Imagine the player examining the shotgun, noticing a tarnished inscription on the barrel, and then polishing it off with her shirt to reveal the owner's name. Try representing more verbs than "use," "drop," or "get" in a hyperlinked interface without making it convoluted and tedious.

On top of all of that, it's much easier to code some more verbs and ways of interaction using a text-based interface than to come up with an intuitive and creatively equivalent GUI/hyperlinked one.

My opinion.
Logged
Chris Whitman
Sepia Toned
Level 10
*****


A master of karate and friendship for everyone.


View Profile
« Reply #11 on: April 20, 2007, 12:21:23 PM »

Using a hyperlinked interface, you pretty much restrain yourself to all the words your high school English teacher told you would cost you letter grades (such as 'using' things in a non-descript sense).

Unfortunately, interactive fiction can just as easily become a game of 'guess the verb,' which is why flexible parsing and broad dictionaries are required to widen the subset of correct input out of the many possible permutations of phrasing English can offer. E.g., "Get shotgun," "Get the shotgun," "Take shotgun," "Pick up shotgun," and "Retrieve shotgun," would probably be considered equivalent, and should all function in basically the same way.
Logged

Formerly "I Like Cake."
SplinterOfChaos
Level 3
***



View Profile
« Reply #12 on: April 20, 2007, 02:56:00 PM »

I was thinking that the parser should be extremely simple and don't see why there would be a need to go fancy with "hyperlinking' andstuff like that. Maybe just require that every sentence have a verb and an optional noun depending on the verb (the parser would assume words like n, north etc. are interchangeably nouns or verbs). Just maybe two or three functions for parsing: extractVerb(), extractNoun(), extractOther().

That way, one could write "get shotgun" or "shotgun get" and I could ignore grammar errors. And sentences like "give Jack shotgun" or "take shotgun from Jack" (from is ignored) would be as simple as getting the verb (give or take), the noun (shotgun) and the special which would be optional (Jack).
Logged

Madgarden
Level 1
*


C=


View Profile
« Reply #13 on: April 20, 2007, 03:46:50 PM »

Unfortunately, interactive fiction can just as easily become a game of 'guess the verb

Yes it can, but that's bad game design, not a fault of text adventures. Smiley Equate this to unfairly hard platformers, quarter munching shootemups, etc.
Logged
Chris Whitman
Sepia Toned
Level 10
*****


A master of karate and friendship for everyone.


View Profile
« Reply #14 on: April 20, 2007, 05:08:11 PM »

That way, one could write "get shotgun" or "shotgun get" and I could ignore grammar errors. And sentences like "give Jack shotgun" or "take shotgun from Jack" (from is ignored) would be as simple as getting the verb (give or take), the noun (shotgun) and the special which would be optional (Jack).

Regardless of whether you go with a fancy technical version, the important thing is to make sure that the subset of English you are parsing is sufficient for your needs.

I mean, before you think about ignoring prepositions, consider the difference between "Give Jack the shotgun" or "Give the shotgun to Jack." Same meaning, separate noun orders. If the latter is parsed as "Give the shotgun Jack," which is interpreted as giving Jack to the shotgun, and the player simply receives the message, "I don't think it would want that," then he will be awfully confused.

You could consider that only things could be given and only people could be recipients, but then you might have trouble with an exchange like:

Give the dog a dog toy.
Give the dog to the dangerously armed clown.

Whereas a BNF production like:

<giving> ::= Give <recipient> <gift> | Give <gift> to <recipient>

Would automatically parse both forms as syntactically equivalent and allow you to attach the correct semantic information to the resulting parse tree without really putting in any additional work.

You can use a simplified parser, and depending on what you're doing, it may be fairly appropriate, but you will most likely end up with some weirdness at some point, and if you need to expand the parser at a later date -- to understand the difference between "put the quarter on the vending machine" and "put the quarter in the vending machine," for example -- then you may find it exceedingly difficult to do so once a fair bit of coding has been done.

Ultimately, if it works well enough for you it works well enough for you, and I wouldn't worry about it. Just be aware that more complete solutions already exist, although they can be fairly complicated.
Logged

Formerly "I Like Cake."
Chris Whitman
Sepia Toned
Level 10
*****


A master of karate and friendship for everyone.


View Profile
« Reply #15 on: April 20, 2007, 05:13:24 PM »

Yes it can, but that's bad game design, not a fault of text adventures. Smiley Equate this to unfairly hard platformers, quarter munching shootemups, etc.

I think it's more the fault of the unique control scheme in text adventures.

To my knowledge, no other system of game interaction has a similar many-to-one mapping which assigns multiple (potentially thousands) of distinct player inputs to a limited set of actions. Even chopping out ambiguities and without attempting to take into account the difference between inputs like, "Take the chocolate from Bob" and "Seize the chocolate from Bob with great aplomb, laughing maniacally" you're still looking at a hell of a lot of options. Even cutting the input down to the simple pidgin normally accepted leaves a lot of ambiguity.

Obviously all kinds of games have their respective design issues, I'm just talking about some which are specific to text adventures.
Logged

Formerly "I Like Cake."
SplinterOfChaos
Level 3
***



View Profile
« Reply #16 on: April 20, 2007, 05:48:04 PM »

Quote
I mean, before you think about ignoring prepositions, consider the difference between "Give Jack the shotgun" or "Give the shotgun to Jack." Same meaning, separate noun orders. If the latter is parsed as "Give the shotgun Jack," which is interpreted as giving Jack to the shotgun, and the player simply receives the message, "I don't think it would want that," then he will be awfully confused.

Hm. Seems like something that should have just jumped out at me. Oh well. I guess what I'd do then is (the verb class instance) "give" would look for two nouns and in the order they are given.

Although what exactly does BNF mean? This is really unfamiliar territory to me; I don't even know what a tokenizer is.
Logged

Madgarden
Level 1
*


C=


View Profile
« Reply #17 on: April 20, 2007, 06:21:46 PM »

Hm. Seems like something that should have just jumped out at me. Oh well. I guess what I'd do then is (the verb class instance) "give" would look for two nouns and in the order they are given.

Although what exactly does BNF mean? This is really unfamiliar territory to me; I don't even know what a tokenizer is.

Don't worry about BNF, you don't need it. Parsing for text adventures is pretty simple stuff. You can even have words like "to" be optional parts of the sentence. A tokenizer basically just scans through your sentence and breaks into the relevent parts... VERB, OBJECT, SUBJECT. The easiest thing to do is start with a simple two-word parser first, eg.

> GET SWORD
> OPEN DOOR
> KILL TROLL

Then, you can expand it to support an optional subject, another object, etc.

> SWING SWORD AT TROLL
> PUT SWORD ON TABLE

Finally, support some optional sugar if you want:

> PUT THE SWORD ON THE TABLE
> PICK UP THE LAMP, SWORD, AND SKULL
> GO NORTH, WEST, SOUTH, DOWN

You can pretty much do all of this with simple left-to-right parsing with some states and lists. No need to make it complicated with BNF or other formalities. Start simple and expand it to where you need it.
Logged
Chris Whitman
Sepia Toned
Level 10
*****


A master of karate and friendship for everyone.


View Profile
« Reply #18 on: April 21, 2007, 08:08:25 PM »

Hm. Seems like something that should have just jumped out at me. Oh well. I guess what I'd do then is (the verb class instance) "give" would look for two nouns and in the order they are given.

Although what exactly does BNF mean? This is really unfamiliar territory to me; I don't even know what a tokenizer is.

A tokenizer parses a string and splits it up by tokens, usually whitespace, it has no idea what is a verb or a noun or even a legitimate word. It used to be the de facto method for basic string parsing in Java (I mean, in the early days of Java, back when I was actually doing classes in it), but it is now deprecated in favor of Java's 'regular expression' library.

Regular expressions are currently the preferred method of parsing strings in Java. I'd recommend looking them up if you plan to do any string parsing at all. They look complicated, but in fact they are very simple, they are just a method of identifying arbitrary patterns in strings.

For example, the regular expression:

\b[a-zA-Z]+\b

matches out all individual words consisting only of alphabetical characters.

The simplest way to use regular expressions to break out text in Java is to use the String.split() method:

String[] String.split(String regexp)

which splits a string based on the specified regular expression and gives you back an array of all the resulting substrings. It's like the tokenizer, but the tokens are specified in terms of regular expressions, so the code:

String someWords = "Here are some words."
String[] splitWords = someWords.split("\\W");

ought to yield the array:

{"Here", "are", "some, "words"}

Since \W, or \\W as it's written in a Java string is the regular expression code for any non-word character, such as a space or tab, this splits the strings up around the whitespace.


BNF, or Backus-Naur Form, is a language used to describe a type of formal grammar called a 'context-free' grammar. A formal grammar consists of a vocabulary set, two sets of symbols (a terminal and non-terminal set) a series of replacement rules, called productions, which define all strings which can be generated using that grammar.  For example, the productions:

S -> AB
A -> a | aa
B -> b | bb

begin at the start symbol S and can generate the strings "ab", "aab", "abb" and "aabb". Backus-Naur form is simply a particular method of writing productions which is commonly used because it is easy to interpret computationally. You don't necessarily need to use it, but it's good to understand how productions contribute to parsing. For example, the Backus-Naur form of a really simple English-like grammar with a small number of words could be:


<article> := "the" | "a"
<noun> := "dog" | "cat"
<verb> := "runs" | "swims"
<adverb> := "quickly"
<noun phrase> := <article> <noun>
<verb phrase> := <verb> | <verb> <adverb>
<sentence> := <noun phrase> <verb phrase> "."

Which would produce the sentences "the dog runs.", "the dog swims.", "a dog runs quickly", "the cat swims quickly", etc. Repeatedly applying the productions of a grammar results in a 'parse tree.' or a tree where the root is the start symbol and the leaves are a series of 'terminals,' or symbols which cannot be replaced using any rules in the grammar. A non-terminal is any symbol which is not a terminal.

Parsing comes down to taking input and determining whether or not it can be generated by the grammar in question. Using the above productions, the input "a cat runs." would be given the green light but "runs the quickly cat." would fail. The two methods of parsing a string to see whether it can be generated using a given grammar are top down and bottom up.

Top down parsing begins at the start symbol and attempts derive a valid parse tree which matches the input. Parsers like the LL parser work this way, by attempting to match the left most input symbol to the left-most symbol on the result side of a production, starting at the root of the tree and working its way to the leaves. For example, a top down parser for the above grammar would begin analysis at the <sentence> level and try to work its way up on the left hand side of the parse tree to match the first word of the specified phrase.

Bottom up parsing begins at the leaves and attempts to combine terms from the input into productions, working down towards the start symbol. This kind of parsing is also called shift-reduce parsing because it functions by dropping symbols on to a stack and reducing them when the values on the stack match a production rule.

Like the above poster mentioned, both of these can be implemented as state machines. Of course, depending on the type of state machine in question, your state tables might end up being huge. For simple machines, a simple left to right top down approach would be sufficient. Here's some pseudocode:

1. Is the first word a verb? If so, go to state 2.
2. Is the second word a noun? If so, go to state 3.
3. Are there remaining letters? If not, process phrase, otherwise go to state 4.
4. Is the next word a preposition? If so, go to state 5.
5. Is the next word a noun? If so, process phrase (with preposition).

That covers you for "Eat food" and "Give food to man," although not for intransitive verb commands, like "Sleep," or intransitive verbs with prepositions, which would require a few additional states.

Instead of 'starting small and working up,' decide exactly what kinds of phrases you are going to cover and write explicitly how they are going to be assembled and from what kinds of words. That way you can code once, it will function to specification, and you will have a lower chance of introducing bugs.
Logged

Formerly "I Like Cake."
ravuya
Level 7
**


Yip yip yip yip yip


View Profile WWW
« Reply #19 on: April 21, 2007, 08:10:34 PM »

Oh man, I go to tigsource to take a break from studying for my compiler construction final. :D

I assume a lot of people use lex/yacc for their text adventure's parser generation, although it looks like the new version of Inform damn near looks like natural language processing.
Logged

Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic