Page 1 of 1

Text adventure writing...

Posted: Wed 16 Jan 2013, 01:37
by starhawk
OK. First things first -- I am patently, deplorably boneheaded when it comes to programming. Please, PLEASE be patient with me! What I know, I kinda know. What I don't know... if what I know is a grain of sand, what I don't is the Atlantic Ocean.

For the purposes of this, assume I'm using Ye Olde QuickBASIC PDS 7.1. Yeah, it's antique. I know. But I can code in it -- sorta. (It's better than the copy of QBASIC on my 386, which is where I started -- in the late 90s!) I'd say that 90-95% of what is in QuickBASIC 7.1 will port over to QB64 (which aims for QuickBASIC 4.5 compatibility) as needed. I'll handle the transition if and when it happens. For now, let's stick to PDS 7.1, since I've a friend there.

OK, now onto the actual relevant stuff...

I have an appallingly-coded text adventure, where the input goes something like this...

Code: Select all

200 PRINT "What do you do"; INPUT$
210 IF INPUT$ = "GET CUP" THEN GOTO 1280
220 IF INPUT$ = "DROP GEM" THEN GOTO 1290
...
Yeah. Not a proper parser, but a really-painful-to-type set of IF...THEN statements comparing the raw input to possible raw inputs. OH DEAR GOD WHY.

Because I can't code a parser. I *can*, however, give myself carpal tunnel syndrome coding a game (thankfully this hasn't happened... yet...)

The best idea I have so far is to have it like this... (pseudocode warning!)

Code: Select all

get [b]INPUT$[/b] from user
if INPUT$ contains "GET" then
     if INPUT$ contains "CUP" goto [line #]
     if INPUT$ contains "BOTTLE" goto [a different line #]
...
if INPUT$ contains "DROP" then
     if INPUT$ contains "FLASHLIGHT" goto [line #]
     if INPUT$ contains "GEM" goto [another line #]
...
...and I'm not sure that works well, either. It does seem rather clumsy. I also don't know/remember how to implement that in QuickBASIC.

There's another problem I have, which can be addressed later... that of Inventory. In a proper game you can pick stuff up and carry it with you. (Imagine that!) In my game, since I can't code for beans, I had a global variable set up for each item with a one-character string indicating if it was in a location (eg "uld" upper ladder room) or in inventory (eg "inv") etc. The GEM in the game had a special condition -- if you d"DROP GEM", such a thing literally happens (SMASH oops), so it had a string for that (eg "brk") that triggered an alternate ending.

I believe what I *actually* need is a thing called an array variable, but I've no idea really how those work or how to set one up.

Having said that... I'd like some suggestions on how to implement a real parser that isn't hopelessly clumsy. It doesn't have to wow people, but I'd like it to be at least halfway to decent ;)

@jamesbond,seaside: I looked at both of your examples. Couldn't really read either one -- jamesbond, yours was about parsing math (I'm horrible with math!) so I'm not sure I could use it anyways. Seaside, I've yet to get the hang of object oriented code, so I'm sorry, I just couldn't understand your example.

Posted: Wed 16 Jan 2013, 01:48
by Makoto
You could always try writing the adventure using Inform. :D That way, all anyone would need to do to play it is grab one of the interpreter programs (from The Interactive Fiction Archive, for example), and play. :) (Though, according to the Inform homepage, you can also create a version that'll run through a website, too...)

Here's an example tutorial: Brass Lantern: Write a Text Adventure With Inform 7

Posted: Wed 16 Jan 2013, 01:53
by starhawk
I appreciate the suggestion, but I'd like to stick to something I already understand a little of, if possible. QuickBASIC and I are already acquainted. Bringing a stranger into the midst right now, complicates that relationship ;)

Besides... I can compile QuickBASIC into an EXE. If I want to make a Linux binary, I can port it over to QB64 --I'm fairly certain that such is a fairly trivial task-- and compile the code in Linux OR Windows. (Mac is out of the question, as a hardware matter -- I only have a MacSE, with neither ADB keyboard nor mouse to be found, and it most certainly will never run OSX!)

Like I said in the OP: let's stick to QuickBASIC PDS 7.1. Please.

Posted: Wed 16 Jan 2013, 04:14
by Makoto
No problem. Just thought I'd throw an alternative out there. :D

Besides, I still haven't gotten around to doing anything with Inform, myself... :shock:

Posted: Wed 16 Jan 2013, 04:43
by starhawk
No worries.

Posted: Wed 16 Jan 2013, 21:45
by starhawk
...anyone else?

Posted: Wed 16 Jan 2013, 22:51
by Keef
Have you looked here?
http://www.petesqbsite.com/forum/viewto ... 1ce8b071a7

Maybe you were signupman?? :lol:

Posted: Wed 16 Jan 2013, 23:39
by starhawk
I don't think I've been to that site... the article on text adventures in that thread is a text file that used to be something else with images, and a lot of info is missing because of that.

I've written the author of the article (after tracking down a working email address) and I hope I'll hear from him soon.

EDIT: got two replies from him. Dead end, article is too old, he doesn't have the images anymore. Back to square one. /EDIT.

In the meantime, if someone can explain to me in simple English (Wikipedia is full of jargon) what an array variable is, how it works, and (approximately) how to use it, that would be amazing. Looks like I may need that for both parser and inventory...

Posted: Thu 17 Jan 2013, 23:51
by starhawk
:(

Posted: Fri 18 Jan 2013, 02:25
by 8-bit
I know it would not be Quick Basic or QBasic, but if you want to get an idea of how to program a parser for a text adventure, you could get hold of a computer magazine with a type-in text adventure program and examine the code to see how it is set up.
Of course, the more sophisticated you make it as far as understanding input, the more is involved.
I still have a number of old Antic magazines that had type-in programs as well as articles on designing and programming text adventures.

Posted: Fri 18 Jan 2013, 02:40
by starhawk
If you can find one of those magazines that tells how to write a parser... I'll pay shipping and a little bit more for it (or you could scan it for me, but then I don't have an excuse to send you money ;) )

I'd LOVE to see that!

BTW, those are probably versions of BASIC for 80s microcomputers, or GWBasic, or... well, probably they're BASIC. Most systems of that era used that language natively. An editor for that language was about half the OS for any given system of that age (the other half being a mechanism for reading machine code off external storage!).

BTW, I've a Tandy MC-10 that I'm going to start using soon -- gots to make the converter cable so that I can hook it up to a cassette recorder first, though. Storage is important!

(Before I had the MC-10, I had a TRS-80 CoCo Model II -- great stuff!)

Posted: Fri 18 Jan 2013, 12:24
by Keef
starhawk

Try looking up 'Just Basic' on youtube - there are several tutorials, including on on arrays. Looks straightforward, although I had to squint a bit...

No, I hadn't heard of Just Basic befor either. I used to do alot of converting old basic listings into HiSoft Basic 2 on my Atari. Never managed anything original though.

Posted: Fri 18 Jan 2013, 21:03
by starhawk
OK -- it'll have to wait till tomorrow, though. My internet isn't what it used to be ;) slow as a dead dog right now...

Posted: Sat 19 Jan 2013, 14:32
by MickJW
Hi all,
starhawk im a member of the QB64.net project that just started to use puppy linux. While researching linux stuff i came across your post. I dont know if you are aware but QB64 has a Win,Linux and a Mac SDL version that is almost 100% QBasic compatible.
If you were to post on the QB64.net web site toy would obtain a lot more assistance. We have a beginners section that this would fit right into. Others have expressed a desire to code text adventure games at our site.
Looking over your psuedo code your ideas are valid but very simplistic. Thats not a bad thing , more likely a very good thing. My suggestion would be to create your parser first. Then move on to creating a dictionary of a small number of recognized words. Then id create a select case structure to process the desired word in action sense. By creating a small simple game you'd get a working model fairly quickly. Then you could expand your dictionary and your select case structure to accommodate your needed actions.
Why select case? If you had the following words and wanted to branch to different sections of code based off these words this would be the difference
Words: PUT, GET, SEE, SAY.
if Word$ = "PUT" then Gosub Action1
if Word$ = "GET" then Gosub Action2
if Word$ = "SEE" then Gosub Action3
if Word$ = "SAY" then Gosub Action4

verses
Select Case "Word"
case "PUT"
gosub Action1
case "GET"
gosub Action2
case "SEE"
gosub Action3
case "SAY"
gosub Action4
end select

The select case is more efficient as it leaves the structure immediately it finds the connection. The if...then are read in sequence regardless if they arent matched. Now imagine that there are 1,000 words to test. Your program would spend a significant amount of time reading thru if...then's even if they arent matched.
MickJW aka (OlDosLover at QB64.net)

Posted: Sat 19 Jan 2013, 16:45
by MickJW
Hi all,
Here is a simple parser i composed in QB64 and tested in QB45.
REM Simple parser
DEFINT A-Z

CONST True = -1, False = 0

DIM AllWord$(1 TO 10)

SCREEN 12

DO
GOSUB GetUserInput
GOSUB PreParse
SLEEP 1
IF NumberOfWords% > 1 THEN
GOSUB ParseSentance
ELSE
PRINT Sentance$
END IF

LOOP UNTIL Done% = 1
SLEEP
SYSTEM

GetUserInput:
DO
LOCATE 1, 1
INPUT "What do you wish to do?"; Sentance$
Sentance$ = RTRIM$(LTRIM$(Sentance$)) ' trim the string to remove leading and trailing spces
LengthSentance% = LEN(Sentance$) ' calculate length of string sentance

IF LengthSentance% = 0 THEN
Leave = False
CLS
ELSE
Leave% = True
END IF
LOOP WHILE Leave = False
RETURN

PreParse: ' calculate number of spaces in the sentance
NumberSpaces% = 0

LengthSentance% = LEN(Sentance$) ' get its length
FOR Letter% = 1 TO LengthSentance%
Temp$ = MID$(Sentance$, Letter%, 1)
IF Temp$ = CHR$(32) THEN NumberSpaces% = NumberSpaces% + 1
NEXT Letter%
NumberOfWords% = NumberSpaces% + 1
LOCATE 3, 1: PRINT "Number of words in sentance are "; NumberOfWords%
RETURN

ParseSentance:

StartOfWord% = 1
EndOfWord% = LengthSentance%

FOR Words% = 1 TO LengthSentance%
TempLetter$ = MID$(Sentance$, Words%, 1)
'PRINT TempLetter$, Words%, StartOfWord%

IF TempLetter$ = CHR$(32) THEN
EndOfWord% = Words% - 1
TempWord$ = MID$(Sentance$, StartOfWord%, (EndOfWord% - StartOfWord%) + 1)
PRINT , , TempWord$
StartOfWord% = Words% + 1
TotalWords% = TotalWords% + 1
END IF
IF TotalWords% = NumberOfWords% THEN
'here last word$ is LengthSentance% - StartOfWord%
END IF
NEXT Words%
TempWord$ = MID$(Sentance$, StartOfWord%, (LengthSentance% - StartOfWord%) + 1)
PRINT , , TempWord$

RETURN

MickJW

Posted: Sat 19 Jan 2013, 17:22
by starhawk
OK, that's got some serious potential. I'll get out my big Que QBASIC* book in a little while and start looking up commands that I don't recognize. The ones that Que won't tell me about, I can open QuickBASIC and look up in there.

The only "bug" that I see in that whole thing is that the word for what I just typed two of, above, is spelled "sentence" ;) sorry, my mother used to be a librarian, a while back. She edits me as I speak!

*QBASIC and QuickBASIC are largely interchangeable, except that QBASIC doesn't come with a compiler.

Posted: Sun 20 Jan 2013, 11:07
by MickJW
Hi all,
Mis spelling is not a bug. LOL. You can look over the QB64 wiki for references and explanations of all the QBasic commands. Here a link ti the wiki. Keep in mind the new QB64 commands ALWAYS have an underscore while the older original commands dont!
http://qb64.net/wiki/index.php?title=Main_Page

Note this is the front page and it contains a section that is "Keywords currently not supported by QB64". http://qb64.net/wiki/index.php?title=Ke ... ed_by_QB64

You could try your old programs in QB64 and if any dont work , notify the creator as he is always looking to improve the backward compatibility with the original language.
MickJW