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...

...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._________________

You could always try writing the adventure using Inform. 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...)

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._________________

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..._________________

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.

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!)_________________

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

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)

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum