Interactive Fiction Competition?

[Ed in SoDak]

See post #10 for the nitty gritty and the submission post is here: http://atariage.com/forums/topic/224499-interactive-fiction-context-entries-submissions/

 

I have a warped idea for a locale/situation which I doubt has ever been done in a text adventure context and some other thoughts on user input.

[+Vorticon]

When's the deadline? I've tried to make a text adventure before and failed. That shows you the extet of my programming skills. I made three half finished TI-99 games, too, but did not know how to finish them. Citybomber, MoonMan, and Knight Moves, which is simply a horse moving around on a chessboard.

 

The deadline is July 1st.

I would suggest checking out the Compute's Guide to Adventure Games book for the TI which can be found here: http://www.hexbus.com/tibooks/ This is a vast collection of TI books compiled by Ernie Pergrem and is currently hosted on Acadiel's site. I hope you can come up with an entry

[+Vorticon]

See post #10 for the nitty gritty and the submission post is here: http://atariage.com/forums/topic/224499-interactive-fiction-context-entries-submissions/

 

I have a warped idea for a locale/situation which I doubt has ever been done in a text adventure context and some other thoughts on user input.

 

Warped is good Looking forward to seeing what you can come up with! I have some interesting ideas of my own as well

Edited April 23, 2014 by Vorticon

[+Vorticon]

I finished fleshing out the algorithm for the text parser today. I have settled on a natural language parser because I think it will enhance the adventure atmosphere.

In any case, it was not as hard as I thought it would be. What it does is expect keywords in a certain order even if other words are interspersed among them. First it looks for a verb, then an actionable object, then an optional preposition (with, into, etc...) and another associated actionable object, and ignores everything else. In my adventure, each location will have a list of expected verbs and objects, and verbs will also have optional associated prepositions and secondary objects, and the algorithm will search these lists as it parses the input sentence.

For example "open the door with the antique key" will translate into open door with key and create a set of verb$="open", object1$="door", prep$="with" and object2="key" variables, at which point the program will be able to select the appropriate action. The same result will be obtained if one types in "open the ornate nicely carved and expensive door with the antique and hard to obtain key". On the other hand, "open door" alone may work fine or may trigger a prompt for more input such as "open door with what?" depending on the room situation.

Tomorrow I'll code in the algorithm and test out its input for various input sentences and see if I can trip it out.

 

By the way, my text adventure will be titled "Eons", and will involve 4 locations and 1 room. Suffice it to say is that it will be a grand romp in space-time

[matthew180]

That is really cool to see the parser broken down like that. Something you might consider is the adjective, i.e. "antique" in your example, might be required if you have more than one of the same object, i.e. two keys, etc. I'm not sure if you want to take it that far, but it might make things more interesting.

[+Vorticon]

That is really cool to see the parser broken down like that. Something you might consider is the adjective, i.e. "antique" in your example, might be required if you have more than one of the same object, i.e. two keys, etc. I'm not sure if you want to take it that far, but it might make things more interesting.

 

Yes, this may become necessary if required by the location and should be fairly easy to graft on. I'm still trying to optimize the structure of the word lists in order to minimize look up time and save memory. Text is really expensive to store in RAM, and I would prefer not to have to use disk files. While I have roughly sketched out the conceptual framework of each location, I have yet to develop the actual script, and I'll tackle that once the parser and word list structure is finalized.

I have never written a text adventure before, and this is really an interesting challenge for me

[+Ksarul]

You can cheat a bit and store it as an array that only uses the first four or five letters of each word you want to use--and then scan the array for your words. That could make for some interesting behavior though if someone uses another wors that uses the stame starting letter sequence at the right wrong point in time. . .

[TheMole]

That could make for some interesting behavior though if someone uses another wors that uses the stame starting letter sequence at the right wrong point in time. . .

 

Qoud erat demonstrandum...?

[+Vorticon]

Acta non Verba working on it.

[matthew180]

You could use a simple hashing routine or something like that (perfect hash) to convert the text lookups into numeric indexes. However in an environment like XB the word-to-numeric routine might take longer than just text searching. Might be something to look into though.

[Ed in SoDak]

I almost instantly regretted tossing my hat in early, but I surprised myself by coding the first screen. I'm as quickly changing it, but it's a start. Rather than fancy programming tricks, since I'm kinda rusty at EXB after 14 years, I'm trying to modularize my code. Repetitive statements will be stored and reused with suitable changes.

 

I coded a few generic DISPLAY AT lines to fill the text window and stored them in an out of the way spot. I bring the appropriate line up for editing with f8, change the generic's line number to where I need it and simply enter the new text. I hope in that way to reduce the tedious typing of how and where to place the text so I can concentrate on the story. I can skip typing all the DISPLAY AT blah blah code and just edit to add new text. I think I'll use 4 or 5 of these to handle the display end of thing and save a lot of repetitive typing.

 

I have the title and premise for my first foray into Adventure programming and that's about it so far. I don't wanna give it away just yet, but I hope I have a little different take on it.

-Ed

[Retrospect]

I've forgotten how to write a parser. I don't even know if I knew in the first place.

This'll be fun.

[+Vorticon]

You can cheat a bit and store it as an array that only uses the first four or five letters of each word you want to use--and then scan the array for your words. That could make for some interesting behavior though if someone uses another wors that uses the stame starting letter sequence at the right wrong point in time. . .

 

Yes, this scheme will definitely introduce the potential for errors in interpretation. Certainly an option if memory becomes very tight.

[+Vorticon]

You could use a simple hashing routine or something like that (perfect hash) to convert the text lookups into numeric indexes. However in an environment like XB the word-to-numeric routine might take longer than just text searching. Might be something to look into though.

 

I have never used hash routines before, so I did some research on the topic and there is some serious math underlying the process. I also got introduced to the Lowenstein function which allows you to guess what the users meant when they misspelled words. All of this could be turned into one mother of a text interpreter, but it will be way overkill for this project Something to keep in mind for a future project...

[+Vorticon]

I almost instantly regretted tossing my hat in early, but I surprised myself by coding the first screen. I'm as quickly changing it, but it's a start. Rather than fancy programming tricks, since I'm kinda rusty at EXB after 14 years, I'm trying to modularize my code. Repetitive statements will be stored and reused with suitable changes.

 

I coded a few generic DISPLAY AT lines to fill the text window and stored them in an out of the way spot. I bring the appropriate line up for editing with f8, change the generic's line number to where I need it and simply enter the new text. I hope in that way to reduce the tedious typing of how and where to place the text so I can concentrate on the story. I can skip typing all the DISPLAY AT blah blah code and just edit to add new text. I think I'll use 4 or 5 of these to handle the display end of thing and save a lot of repetitive typing.

 

I have the title and premise for my first foray into Adventure programming and that's about it so far. I don't wanna give it away just yet, but I hope I have a little different take on it.

-Ed

 

Sounds like you're making good progress here! Your approach is ideal: tackle a small problem at a time in a modular fashion rather than go for the whole shebang in one shot. It's very easy to create spaghetti code with XB otherwise. Matthew180 has written a very helpful utility called TidBit (TI Basic Translator) which allows you to structure you code through the use of indentation and labels. I plan on using it for this project. All you have to do is create your code in any text editor, then paste it into the utility, and out comes proper XB code! TidBit can be found here: http://codehackcreate.com/archives/237

[+Vorticon]

I've forgotten how to write a parser. I don't even know if I knew in the first place.

This'll be fun.

 

Welcome to the club! One thing is for certain: there are many ways to skin a cat here...

[+Vorticon]

So the way I am implementing my word lists is as follows:

 

Each location will have its own DATA statements section, and and there will be one set of master word arrays which will be loaded dynamically when each location is entered by the player. Simple RESTORE statements will do the trick to point to the correct DATA section. Each verb will have associated pointers to the object and preposition arrays, and the prepositions arrays will in turn have pointers to the object array when secondary objects are needed.

For example, if the input sentence is OPEN THE DOOR WITH THE KEY, the parser will generate a verb (open), a primary object (door), a secondary object (key) and a preposition (with) as discussed previously. This is pass 1 and is as simple as checking the input words against the verb, object and preposition lists. Of course, the parsing is immediately stopped if certain key words are not found such as a verb. On pass 2, the primary object will be checked against the object pointer list for the verb. The preposition will then be checked against the preposition pointer list for the verb. Finally, the secondary object will be checked against the object pointer list for the preposition.

At any time during that process, if a required match is not found, then the interpreter will display an error message. Of course, some verbs may not require any specific object or there may be no need for a secondary object, and this will be accounted for. If everything checks out, then a list of IF-THEN-ELSE statements will determine the appropriate action or outcome based on the player input.

 

I'm hoping to have a teaser demo in the next couple of weeks

[matthew180]

I have never used hash routines before, so I did some research on the topic and there is some serious math underlying the process. I also got introduced to the Lowenstein function which allows you to guess what the users meant when they misspelled words. All of this could be turned into one mother of a text interpreter, but it will be way overkill for this project Something to keep in mind for a future project...

I'm a little late with my reply since your latest post indicates you have your word lists worked out. I'll just dump some thoughts though, in case you find something useful.

 

I think your hash research turned up details on routines like MD5 or SHA1? I should have been more clear in what I was referring to. In this case you have a situation of a sparse array, i.e. a limited set of data (words in this case) with a large range of values. It is easier to think of it numerically, so (12, 123, 1234) is a sparse set. There are only three values, yet if you tried to use them as indexes in an array, your array would have to contain more than 1234 elements, but it would be mostly empty.

 

The idea of "hashing" in this sense is to use a "key" (some input data) and transform it into a value that can index an array. The most basic method is to use the modulo of the number of "buckets" (elements) in your storage array. This is actually the worst and one of the weakest hash algorithms, but it is easy to explain and understand. However, whatever hash algorithm is used it is important that any given input always produces the same output.

 

So in this example we have three numbers, so our array has three buckets. So the inputs:

 

12 mod 3 = 0

123 mod 3 = 0

1234 mod 3 = 1

 

Now, we have a problem with the first two inputs since they hash to the same index. This is called a collision and in this case you can modify the input in a consistent way to produce a new bucket index, or you can fall back to a list at that bucket location (this is the most popular method).

 

So if you have a collision at index 0, you would have a list that stores each key that hashed to that index and its value. Hashing would get you to a subset of values quickly at which point you would scan the list. If you find a match then you return the data, otherwise you return a miss.

 

In your case, since you will know your word list up front you can generate what is called a "perfect hash". That is a modified hash algorithm that will always produce a unique hash index value based on any key in your data set.

 

Since your input is text, a popular method of making a hash key is to sum the ASCII values of each character, then using the modulo of the buckets (total number of words you have). You could quickly test the results of this on your word list to see if it would be viable and how many collisions you might have. The other thing to keep in mind is that I assume you are trying to avoid brute-force string searching?

 

Using the DATA statements and RESTORE is probably the most efficient way to store and search the data. But if you hash each word then you never have to store the actual words in the program which will save a lot of room. You know that "run" hashes to a specific value and that it will be a verb. Something else to think about is how are you going to deal with root-words vs endings like -ed, -ing, etc.? I think the term is called "stemming". You need to chop off -s, -ing, -ed, etc. from the input before searching them.

 

Another searching idea I was kicking around would be to have four lists for each type, i.e. verbs, nouns, prepositions, and adjectives. Then use the first letter to jump to a starting point, i.e. RUN would be 'R' - 'A' (82 - 65 = 17) that could be used in an ON GOSUB or ON GOTO (or "RESTORE n" if XB allowed such a thing). Then you would only have to string search in the subset of words that start with that letter.

 

Another thought is to store your words sorted, then you can binary search starting with the first letter, then the second, etc.

 

Any chance you might post your proposed word lists?

Edited April 27, 2014 by matthew180

[+Vorticon]

Great explanation Matt! Definitely clearer than what I have come across so far. I still think it's overkill here though because the word list for each location will be pretty small, and so brute force string searching will be very viable. The same argument goes for your other -very helpful I might add- suggestions.

I have finished the script for the first location, and here is the word list. As you can see, it's pretty tiny.

 

Verbs: open, hide, crouch, lie, look, examine, go, run, inventory, north, south, east, west

Objects: eyes, rock, forest, circle, north, south, east, west

Prepositions: at, to, behind, around

 

I think now I have all the needed elements to start actual coding, and I'm going to put together the first location and post it here for people to play with and give feedback.

[sometimes99er]

For example, if the input sentence is OPEN THE DOOR WITH THE KEY, the parser will generate a verb (open), a primary object (door), a secondary object (key) and a preposition (with) as discussed previously.

I guess one might also have to consider variants of the above. Here's a few examples with Google hits:

 

Use key to open door (4,080)

Unlock door using key (13,500)

Unlock the door using the key (15,500)

Open door with key (19,300)

Open the door with the key (703,000)

 

Also for breaking apart and verifying words in the input sentence the POS function of XB seems pretty relevant. I guess this is so obvious that I'm a fool at even mentioning it ?

 

 

 

100 VERB=POS("OPENHIDECROUCHLIELOOKEXAMINEGORUN...",WORD,1)

 

[+Vorticon]

I guess one might also have to consider variants of the above. Here's a few examples with Google hits:

 

Use key to open door (4,080)

Unlock door using key (13,500)

Unlock the door using the key (15,500)

Open door with key (19,300)

Open the door with the key (703,000)

 

Also for breaking apart and verifying words in the input sentence the POS function of XB seems pretty relevant. I guess this is so obvious that I'm a fool at even mentioning it ?

 

xb pos.pdf

 

100 VERB=POS("OPENHIDECROUCHLIELOOKEXAMINEGORUN...",WORD,1)

 

 

And that is one of the difficulties of text adventures, actually highlighted at length in The Lamp video, which is trying to anticipate the many creative ways players may go about achieving the same result... The trick is here is to design each location so as there are only so many reasonable ways one can achieve an action. In my word list above for example, I have both look and examine which essentially do the same thing. As I was writing the location script, I tried to think of all possible variations and account for them.

As for the POS function, you are right on the money This is how I planned to search the input string and it has the added advantage of rooting out variants of words like plurals, what Matt called stemming. For example, if I search for DOOR in a string using POS, I will get a hit even if the player entered DOORS instead.

[+Lee Stewart]

Also for breaking apart and verifying words in the input sentence the POS function of XB seems pretty relevant. I guess this is so obvious that I'm a fool at even mentioning it ?

...

100 VERB=POS("OPENHIDECROUCHLIELOOKEXAMINEGORUN...",WORD,1)

 

 

Maybe I am also stating the obvious, but I would think you would need to carefully check word order in such a word list to avoid a word combination or a word within a word that would cause a search hit before you expect it. For example, in "DRAGOPENGO", "GO" is found before its intended location. Of course, clever ordering could actually shorten the list: "DRAGOPEN" could be used to manage all three words because each has a unique position.

 

...lee

[matthew180]

That is a very short list. I suppose I am used to working with larger data sets. Brute force is probably the way to go in this case, and you probably can't write anything in XB that is faster than the POS function. A little bit of Assembly would go a long way here, but most likely not necessary.

 

Are you planning on having synonyms? For example, "old" and "antique" to describe the same thing (a "key" in the previous examples).

 

Towards the end of their reign, Infocom had awesome text parsers. Their games were written in a byte-code language that ran on an interpreter, very much like GPL, P-Code, or Java. To port a game all they had to do was port their parser. I bring this up because the Zork interpreter VM is available and might be worth looking into to see how they handled advanced parsing, if only out of curiosity.

Edited April 28, 2014 by matthew180

[+mizapf]

 

Maybe I am also stating the obvious, but I would think you would need to carefully check word order in such a word list to avoid a word combination or a word within a word that would cause a search hit before you expect it. For example, in "DRAGOPENGO", "GO" is found before its intended location. Of course, clever ordering could actually shorten the list: "DRAGOPEN" could be used to manage all three words because each has a unique position.

 

...lee

 

Use a character not allowed in user input, e.g. "§". Then

 

 

100 VERB=POS("OPEN§HIDE§CROUCH§LIE§LOOK§EXAMINE§GO§RUN...§", WORD1, 1)

 

with WORD1 being appended a "§".

[Ed in SoDak]

I'm breaking some rules for parsing player input by going with multiple choice. That reduces it to a "Choose Door #1, Door #2... approach. But I'm maybe also adding some parser input for a "wildcard" factor. Might work for gameplay, might not.

 

Then you get down to the nitty gritty of which course to pursue instead of wrestling with two-word verbiage and syntax.

 

I was always a fail for getting anywhere in any type of text adventure game. My keyboard input always reduced itself to me typing some string of expletives about what I suggested the computer and adventure programmer should do with their key or candle or door or lock or...

Edited April 30, 2014 by Ed in SoDak