Jump to content

Photo

XB Adventure game (no interpreter)

XB TI-99 Adventure Text Vintage Computers

13 replies to this topic

#1 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 10,736 posts
  • Location:Hustisford, WI

Posted Sat May 11, 2013 12:04 AM

So... I spent some time writing and converting the baseball game for the BBS. Now I have another itch--- An XB Adventure game which does not require the Adventure module... Primarily to run on the BBSes as well.

Here's the plan: Come up with the premise, collect input from the members here on Atariage, write the game for the BBS, then get the "go-ahead" from the SysOp(s) to add it to the BBS as a playable door game.

I had started work on a Beryl Reichardt adventure game, but scrapped it when I realized how inefficient the code was... I was able to read a book on Planet-99 which gave some very interesting insights into the development of the Adventure games and it really got me going! The methods described there are fascinatingly simple and straight forward and allow for a TON of stuff to be coded in with minimal duplicate code and minimal program space. Using a string variable array and TWO standard variable arrays is the key to having your map laid out AND having the ability to stock your world with the items you'll need to design the quest as you see fit.

The key to the game is the parsing engine... How does the user communicate with the computer to TELL IT WHAT HE/SHE WANTS TO DO?!?! Well, as we all know, a computer doesn't speak english, and we cannot possibly code in every possible command. Therefore, we create a parsing engine which takes a noun and a verb (two separate string variables INPUT from the user) and attempts to read those from a list of acceptable nouns and verbs in the system. For instance, "OPEN DOOR" contains a verb and a noun. A successful parsing engine would read the noun (to determine if that thing (the door) is in the vicinity) and IF that noun IS legal, read the verb (to determine if the selected action can be performed on the noun)... For instance, "EAT BREAD" is cool if you have bread in your inventory. "EAT DOOR" does not work, even if DOOR is in the current "room." In this case you have a valid noun but an invalid verb to associate with that noun. This is the basis of the parser, and I have a much better understanding of it now than I did two days ago. With Willsy's permission, I will post a zipped pdf file of the book I'm referring to to this thread, once he gets on and allows it. =)

Is anyone interested in participating in this development project? I will not be starting it immediately, as I have some pressing matters at hand writing some music and working with a couple suites... (ASLP by Hully and XB256 by Harry)... I would say that in the next week or two I will be returning my attention to this project.

I just got my PEB set back up tonight and I'm picking up a monitor on Sunday, so I'll be hardware-active again this weekend.... WOOO HOOOO!!!!! That's an exciting thing for me.

#2 matthew180 OFFLINE  

matthew180

    River Patroller

  • 2,626 posts
  • Location:Castaic, California

Posted Sat May 11, 2013 8:53 AM

I'm always interested in support roles, and adventures interest me as well.

As for the design, there are many ways to layout the data, and many ways you can accept input. I think a minimal system would not take a noun-verb pair, but rather just allow the user a fixed set of commands like N, S, E, W, Up, Down, Look, Take, Drop, and Use. The "maze" would be limited to those directions, and your inventory would be limited to one item so using an item is obvious.

Once you start to want more features, the complexity goes up. Also, since adventures are typically based on stories and individual logic puzzles that unlock other puzzles, the games are typically designed as "engines" instead of hard-coded logic for each puzzle and possibility. Also, the line between hard-coded logic and an engine is very thin, and it does not take adding many features to realize a hard-coded logic solution is not going to work.

As with any project, it is best to define the desired features and goals without trying to specify how the solution will be coded. Once you have the scope defined, then start to determine the coding methodology and adjust the features from there.

#3 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 10,736 posts
  • Location:Hustisford, WI

Posted Sat May 11, 2013 11:31 AM

...it does not take adding many features to realize a hard-coded logic solution is not going to work.



I ran into this in my baseball simulation/game. For a simulation, hard coded logic works great... Once it became a "game" with significant user input, that concept fell apart and I had to adjust quite a few elements in order to facilitate the changes in design.

Yes, I like the ideas there. When I get the "ok" from Willsy, I'll post that book on here. It's 89 pages (IIRC), much of which is code. The majority of what you stated above is in there along with a bunch of other stuff. Of course what is NOT in there is tangible and flexible experience... That is what I'm hoping to find here, at the TI programming capital of the universe. =)

I'll put some thought into it for a week or so while I get my hardware back up and going... I'm needing real hardware for a project I'm working on, so my focus this next week is to get a few things accomplished on that side, get some loose ends tied up with the baseball BBS game, and get some music composed...
Any thoughts and ideas you've got, feel free to tack em onto this thread so we can start thinking about structure.

=)

#4 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,435 posts

Posted Sat May 11, 2013 12:23 PM

[/font][/color]

Any thoughts and ideas you've got, feel free to tack em onto this thread so we can start thinking about structure.

=)


When I wrote Murder Motel (online, 25 player BBS game) I used an array to define the possible directions and the room each direction would lead to, 0 indicating an unavailable direction.
DATA N,S,E,W,U,D !order of array
DATA 2,0,0,0,0,0	 !North to room 2
DATA 0,1,0,0,0,0     !South to room 1
Once the array was loaded, I could then modify the room exits/entrances for "special" occurences. If the right action was taken, I could allow the user to go UP to room 3 by recoding the "up" element to point to room 3 as an allowable entry. :) I am fairly certain I also compressed these direction arrays into a string array (6 characters per string) but would need to check the program to confirm. Regardless, the above code is easier to understand :)

I handled inventory and user locations via a string. Each item or person is represented by its position in the string, as one character, which then tells the program where it resides or who is its owner. This was important to conserve space and to quickly identify items in a room. Using POS and SEG$, one can fairly quickly loop through the matching items without needing to test every data element. Strings also provide for quick and moderately efficient storage to disk, important for saving the game state in a multi-player game but perhaps less important for single user adventures.

Common commands like Inventory, Map, Quit are often easy to parse and execute as they are useable in any room. The complexity rises with your strategy and puzzle complexity. If you need to complete five steps in sequence, you need a method to track those steps to ensure the user does them in the right order. Defining the items (door) and verbs (eat) with their possible actions may be one good way to cut down on the parsing and action testing.

Many of the XB games I have encountered are written with a basic parser that relies upon the actions and items being 3-4 unique characters long. Some require you to type the entire word or direction -- I usually avoid these games or modify them to accept shorter phrases ;) The parsing is usually pretty easy to accomplish. Determining the actions based on what your parser finds is where your coding usually requires more effort.

To paraphrase Matthew, knowing what you want to do and the scope of the game is a good first step.

Edited by InsaneMultitasker, Sat May 11, 2013 12:26 PM.


#5 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 10,736 posts
  • Location:Hustisford, WI

Posted Fri May 17, 2013 10:18 AM

This is a nice little gem I found while cruising some BBSes last night. It would take minimal customization to port this to work on the TI and with some creative "find and replace" stuff, could run on Heat Wave or the Reef. Enjoy.

**BTW, you can play this game by telnetting into Telehack.com (or use their browser feature---but what's the fun in that? =)) **They have about 50-60 BASIC programs there which you can play via the built-in interpreter. =)


Spoiler


#6 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,486 posts

Posted Fri May 17, 2013 11:02 AM

Text adventures can be implemented in a variety of ways in BASIC and Extended BASIC.

One technique I read in an old Rainbow magazine (The TRS-80 Color Computer's magazine) was to store your noun/verb sets into very long strings. Then you use the POS function to immediately find out if the noun/verb exists in the vocabulary. If you're going with 4-character limits on noun/verb preciseness, you can just divide the returned position by 4 to indicate a verb/noun match.

I would definitely use strings over numeric variables in a text adventure, especially if you are using the 32k memory expansion. A single character takes only 1 byte, while a numeric variable takes 8 bytes. The amount of extra code to process strings over numerics won't unbalance the code size at all, and while it may run a LITTLE slower, text adventures aren't supposed to be that fast anyway...

Adamantyr

#7 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,435 posts

Posted Fri May 17, 2013 12:20 PM

Text adventures can be implemented in a variety of ways in BASIC and Extended BASIC.

One technique I read in an old Rainbow magazine (The TRS-80 Color Computer's magazine) was to store your noun/verb sets into very long strings. Then you use the POS function to immediately find out if the noun/verb exists in the vocabulary. If you're going with 4-character limits on noun/verb preciseness, you can just divide the returned position by 4 to indicate a verb/noun match.
/snip/
Adamantyr

Great technique. Perhaps very useful together with an ON x GOTO or two. I recall one game that tested words via a loop (slow). What I liked was if the word or phrase was not found, the program displayed some random quip telling the user the request was not understood - in a comical fashion not unlike Infocom. :) Ahh Infocom.

#8 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 10,736 posts
  • Location:Hustisford, WI

Posted Fri May 17, 2013 2:22 PM

:) Ahh Infocom.




Here's some humor for ya...

Posted Image





Posted Image

Edited by Opry99er, Fri May 17, 2013 2:23 PM.


#9 Gemintronic ONLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 9,333 posts

Posted Fri May 17, 2013 2:32 PM

I almost got this to compile for the Sega Genesis. The dialect of BASIC is just different enough to cause problems. Er, then I realised that text input on a joystick isn't going to be fun :)

#10 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 10,736 posts
  • Location:Hustisford, WI

Posted Fri May 17, 2013 2:53 PM

heh... That's awesome. I'd sure love to see it run on the ol' Sega. =)

I don't have time to port it to the TI right now, but it wouldn't be hard... just a few changes necessary

LINES 6130 to 6280 specifically. The handling of the "shooting"

#11 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,641 posts
  • HarmlessLion
  • Location:BUR

Posted Fri May 17, 2013 2:57 PM

On my old game 'Stranger' (http://harmlesslion....ftware/stranger), I didn't use any kind of formal parser at all.. each 'scene' is at a different location in code and the parser just looks for keywords relevant to that area. It means that the input is pretty freeform (both verb/noun and full sentences tend to work as long as the words are present), but you wouldn't want to do a really large story that way. :)


#12 mizapf ONLINE  

mizapf

    River Patroller

  • 3,636 posts
  • Location:Germany

Posted Fri May 17, 2013 6:21 PM

Remembering Infocom ... the parser even recognized object references, something like GET THE KEY AND UNLOCK THE DOOR WITH IT. I think there were different versions of the parser; the earlier ones were less powerful.

I still have the original Zork II, III, and Deadline packages here. There were still a lot of games I always wanted to play but never got them. My absolute favorites were Planetfall and Stationfall. I can still remember the scenes, although they were in my head only.

And, who of you did not hesitate to get the PC games Return to Zork, Zork Nemesis, and Zork Grand Inquisitor?

#13 Bones-69 OFFLINE  

Bones-69

    Chopper Commander

  • 216 posts
  • Location:Australia

Posted Mon May 20, 2013 3:17 AM

The key to the game is the parsing engine... How does the user communicate with the computer to TELL IT WHAT HE/SHE WANTS TO DO?!?! Well, as we all know, a computer doesn't speak english, and we cannot possibly code in every possible command. Therefore, we create a parsing engine which takes a noun and a verb (two separate string variables INPUT from the user) and attempts to read those from a list of acceptable nouns and verbs in the system. For instance, "OPEN DOOR" contains a verb and a noun. A successful parsing engine would read the noun (to determine if that thing (the door) is in the vicinity) and IF that noun IS legal, read the verb (to determine if the selected action can be performed on the noun)... For instance, "EAT BREAD" is cool if you have bread in your inventory. "EAT DOOR" does not work, even if DOOR is in the current "room."

I had some ideas that were working very well with an adventure game I started writing. Right from the start the environment was huge, which probably killed off the later enthusiasm because although everything was working as I hoped - It ended up just going on and on and I ran out of energy. It just never ended! But anyway, because of the size it was always designed to use huge disk files. Because I used a lot of disk access the basic program ended up being surprisingly small.

So anyway... Right from the start I decided to limit commends to one or two words only. The first thing that was checked is that more than one space did not exist in the command. I pulled it right up there so down the track I had some control.

To start, every verb I could think of I put into maximum strings (stored in arrays), in a form like this; V$(A)="#GO-01#GET-12#JUMP-02#KILL-78#OPEN-15#LOOK-03#EAT-32#SWIM-17....etc " And I made the strings as long as possible. To confirm a verb was valid I would search for the term in the strings (I found this better than assigning every verb its own unique array value and searching for a match - especially as the number of verbs grew). The hash prevents finding partial words within other words as I always forced the search criteria by VERB$=HASH CHAR & COMMAND$. The "-" acted as a marker for the end of the word and the 2 digit number gave the verb a value. This value could then be inserted into inventory or objects to create the illusion of a huge response vocabulary . For instance you might say - "eat key". "eat" would be identified as having a value of 32 in this example.

The key would have variables that confirmed things like if it was visible or hidden, if it was steel or plastic, would it burn, would it break, could it be eaten... etc. I stored these values in single strings which I read/wrote to files so the values were somewhat dynamic.

I would create more strings for the environment and ALL objects. For instance you are in a room with the key (every item has its own location value), and attached to the key is a string with stuff that might look like this;
"#12-455#03-322#01-122-#32-555.... etc". In the instance of EAT (32), I would search for #32. When/if found,I would then read the next 3 digits which referenced a disk record where the response could be retrieved. I found this worked very well, it was extremely easy to edit/add/change on the fly.

This is a pretty quick overview of the method I was using.

#14 Bones-69 OFFLINE  

Bones-69

    Chopper Commander

  • 216 posts
  • Location:Australia

Posted Mon May 20, 2013 3:34 AM

>Command me: EAT KEY
>OK.

>YOU BEGIN EATING IT AND START TO CHOKE. YOU SELF HEIMLICH AND PUKE IT BACK UP. YOU DON'T FEEL VERY WELL"





Also tagged with one or more of these keywords: XB, TI-99, Adventure, Text, Vintage Computers

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users