Adventure game stuff

[Pinacolada]

While I'm not quite another Paul Panks, I am interested in adventure games; how to write them, that is. I've got a back-burner project that will maybe someday get done; I was interested in any articles anyone has on the subject. There was a book called "Golden Flutes and Grate Escapes" or something like that, I'm curious whether it would have any information I don't know already in it.

I'm slowly learning ML on the C64, maybe after I get done with the project in BASIC, I'll convert it over to the C128. That would rock. 80 columns is so much nicer...

Just kind of a preliminary post to guage any interest out there... I keep thinking of remaking my web site that discussed my text adventure project "TADA" (Totally Awesome Dungeon Adventure, based on a GBBS Pro door game called "The Land of Spur"), but I haven't yet. It'd probably go on GeoCities or something. Nothing too fancy. There's a Yahoo group but it's pretty much useless. I need to put some more effort into documenting my ramblings so people can contribute if they want.

~ Pina ~

[hydrophilic]

I've had an interest in adventure games since back in the day when examining the code for some of Infocom's text adventures.  I never could figure it out.  The quality of their text interperter always impressed me as it was superior to others I'd played.

I can't volunteer to help now because I'm juggling a few projects of my own at the moment.  But if you have questions regarding ML or code in general, post away and someone here will help you out.

Have you tried any of the adventure writer programs like
 Adventure Construction Set (E.A.)
 Adventure Creator (Spinnaker)
 Adventure Interpretor (?)
 Adventure Writer (?)

I know I haven't although I've been tempted.  I've always enjoyed the adventures that mix some graphics and action in with the text.  Favorites include Pirates! and Maniac Mansion (although they are extremely light on text input).

Several adventures appeared in the disk magazines back in the day.  I remember one called Apartment of Mystery.  It was in BASIC and was fun to play and to hack.

TADA sounds interesting.  I hope you can make it available to us.

[Pinacolada]

I love Maniac Mansion! I don't think I've ever gotten all the endings. I want to run the story arc where you mail off the Purple Tentacle's record to the record company. I read about that possibility somewhere long ago...

It'd be really neat if we could create SCUMM-like games on the C64. I know there's SCUMMVM (which I downloaded for Debian Linux the other day, we'll see if I get a chance to play Beneath a Steel Sky and Flight of the Amazon Queen some point this weekend, or next). I guess SCUMM is just an ugly hack anyway, and it's hard to reverse engineer.

Yeah, there is a web site that goes into detail on the Infocom VM specs. I thought it was rather interesting how they compressed the text. That is one thing I was thinking of implementing, eventually, to save some space. One room description file is about 400 blocks (uses a REL file to skip around from room to room, but that wastes space)...

http://www.ifarchive.org/indexes/if-archiveXinfocomXinterpretersXspecification.html

That's the directory in question. Lots of interesting stuff.

I wrote an assembly version of a mostly-working INSTRing function (works great for 1 character matches, returns the last character of the match on a multiple-character match) in I%. I thought that was pretty good for a beginner

I need to tidy up the archive and make it so you can actually run the game as a cohesive unit; that's been sort of a stumbling block. I'm working on the module loader portion (a technique borrowed from a Compute! article), figuring out how much memory to allocate at startup is kinda tricky. 50 blocks is too much, the two programs collide. I'll figure it out; I want to put more work into it this weekend too.

Anyway, babble babble. I'll keep working on cleaning TADA up; maybe someday I'll have a very very alpha release. I've been working on the stupid thing (off and on, mostly off) for like... uh, 10 years or more. Lazy! Tsk.

Oh, I do have a copy of ACS. Slow, but fun to play with. Haven't tried the other programs...

Apartment of Mystery... wow, that could've been my apartment a few years ago

[nikoniko]

I'd love to see someone port one of the open-source Z-machine interpreters over to the C128, as that would allow one to play zillions of text adventures that have been created by adventure enthusiasts in the last decade or so. And the latest version of the Inform development system, which compiles to Z-machine code, is just brilliant, making it easier than ever to design rich, interactive masterpieces.

SCUMM, while originally being designed on the C64, would be pretty challenging to adapt, especially with most SCUMM games being 256 colors and expecting several hundred kilobytes of memory to work with. Then again, didn't some 32-color versions get released for the pre-AGA Amigas? Anyway, it'd still probably be easier to port games individually than to develop a general-purpose interpreter.

I'm slowly working on an interpreter for Sierra AGI games (it always annoyed me that they were never ported to the Commodore 8-bits), and trying to fit such in 128K of memory is pretty challenging, especially when I'm working in C and don't want to have to convert more than a handful of routines to assembly. While I used to be pretty competent in assembly programming, I discovered while working on a recent game compo project that I am not any more. Plus I'm busy with another project and don't want to spend too many hours on this one. I'll either succeed in C or have to admit defeat.

Don't know if it will help, but you may wish to take a look at some scanned adventure development books that are online. Ira Goldklang's TRS-80 site has 8 adventure-related books, and AtariArchives has a book called Creating Adventure Games on Your Computer. They probably all assume development in BASIC, and I doubt any of them go into creating complex Infocom-like interpreters, but maybe you'll find some inspiration for your own game.

[PhotoJim]

There is a program at the IF Archive that will make .d64 disk images out of Infocom game data files.  It turns out you can also make disk images from some compiled Inform game files too.  (I think .z8 games won't work but .z5 will - it's been a few years since I've played with it.)

Another cool thing - you can run the games on the C128 in native mode, in 80 columns!  If I recall, the disk is even bootable.

Learn Inform - don't reinvent the wheel.  The cool thing about using Inform is that the game will be playable on other ZMachine ports and, very likely, on the C64 as well.

I always thought it would be cool to have a VIC-20 interpreter too but that belongs on Denial, not here.  

[nikoniko]

Wow, had no idea there was a utility to convert .z5 files to play on C64/128! Don't know how I missed the news of that one. I knew about being able to extract Z-files from .D64s, as I ran across that back in 1996 or '97, but don't recall there being a way to do the opposite. This would be great for adding 80 column support to all the older Infocom games that never supported it. Just extract the data, then process it to new disk images. Beautiful!

[Pinacolada]

I remember reading about the natural language Inform program. I want to try it out at some point; the reason I'm doing this as a home-brew adventure is because I want people to add to the adventure, like a MUD. I want a standalone version where people can trade maps, and a version on my BBS. Eventually.

I put in some work on the module loader over the weekend; it now loads modules. It processes the startup program, drops into the main loop, and accepts commands. Inventory works; I just need to get an object database file cooked up so we can list objects from external files, not DATA statements (which won't work unless the DATA statements are in the "main module" anyway).

Basically lines 1000- stay in memory at all times, and lines 1-999 are loadable. Pretty slick. Keeps all your variables, too.

My parser won't be much. Looks for spaces, assumes the second word is a parameter to the command, and if not supplied, lists objects you can use the command with which are in the room.

I've seen that Inform converter program, I never considered writing anything in Inform before. I downloaded ADRIFT instead, seems okay.

I will definitely have a peek at those books. Ira has scanned "Golden Flutes and Great Escapes"... someone once told me that was a very good book.

[Gumpy]

I'm slowly working on an interpreter for Sierra AGI games (it always annoyed me that they were never ported to the Commodore 8-bits), and trying to fit such in 128K of memory is pretty challenging, especially when I'm working in C and don't want to have to convert more than a handful of routines to assembly. While I used to be pretty competent in assembly programming, I discovered while working on a recent game compo project that I am not any more. Plus I'm busy with another project and don't want to spend too many hours on this one. I'll either succeed in C or have to admit defeat.

The big trouble would be the AGI animations of the characters walking around, etc... on the PC, and other machines, they were simply drawn on the bitmap screen, but since the VIC II chip has stupid "card" restrictions (IE no more than 3 colors plus the background in an 4/8 block in multi color mode) when you draw the character walking around, it will mess up the background, and I don't think you could use sprites, because most things would be too big to be put in sprites.

[nikoniko]

Yeah, I recently considered multiplexing VIC sprites to allow more than 8 sprites on screen, building animated characters that way, but keeping track of it all while things move around -- and ensuring that no more than 8 sprites try to cross a single raster at once -- is too much of a pain. I can understand now why Sierra never bothered with the Commodore 8-bitters. As such, I've gone back to the 80-column chip, since with that I can do unrestricted 16-color 160x132 on NTSC, more on PAL, and theoretically might be able to do 160x200 with some trickery.

[Pinacolada]

I might put together some sort of runnable package this weekend if i get the time. Meanwhile I have some C64 asm code to pick over, an INSTRing sort of program, over on Jeff Ledger's forum (http://jledger.proboards19.com/index.cgi)... has a bug in it. If I get this fixed, we can expect to see release .00000001

I'll put it on my Yahoo GeoCities page, I guess, since the Yahoo group I have set up is rather onerous about letting anyone join.

Oh, and the AGI interpreter sounds cool, not to disregard it.

[nikoniko]

Hey, that's great news. Glad to hear things are coming along on version .00000001.

Don't know whether this is a good fit for you, but here's an INSTR routine I found somewhere. Unfortunately I didn't record where it came from, but I'm pretty sure it was written by an Apple II programmer. All I have is the name Bob Cederlof. I'm more or less going to quote it as is, with a brief analysis afterward. When I originally saved it, apparently I chopped out the Apple II stuff, so if you're wondering why the labels skip a few numbers, that's why.

Code Select Expand

         LDX #0        
   .2     LDA MAIN.LENGTH  ; See if substring is longer than the amount of string remaining to search
          CMP KEY.LENGTH
          BCC .8           ; Our substring is longer, so we're done
          LDY #0
   .3     LDA (KEY),Y
          CMP (MAIN),Y
          BNE .6
          INY
          CPY KEY.LENGTH
          BCC .3
          INX              ; Sets X to hold position of match
          JMP .DONE      
   .6     INC MAIN
          BNE .7
          INC MAIN+1
   .7     INX
          DEC MAIN.LENGTH
          BNE .2
   .8     LDX #0           ; X holds 0 for no match
   .DONE  do whatever
Some definitions:

MAIN holds the address of the source string being searched, KEY holds the address of the substring being searched for. Then you have the length of each stored respectively in MAIN.LENGTH and KEY.LENGTH.

At the end of the routine, the X register will hold 0 if no match was found, or it will hold the position of the match.

Analysis:

.2 Basically, first the routine checks to see if the number of characters in our substring is greater than the amount of string left to search. If so, it quits with no match.

.3 MAIN and KEY are compared.

If they don't match in this position, go to .6 where we advance one character further into MAIN.
If they do, check to see if there is more KEY to match.
If there is more KEY to match, go back to .3 to check the next character of the KEY against the next character of MAIN.
If there isn't more KEY, we have matched our whole substring. X is incremented to reflect our match position, then we get out of here and jump to .DONE.

.6 We increment our pointer to the source string to move to the next character position. If the low-byte changes to 0, we also increment the high-byte.

.7 X is incremented to prepare for a possible match on the next string comparison. The length of our source string, which is being used as a counter so that we know if we've compared all characters, is decremented. If we're not at 0, go back to .2. If we are at 0, there's no more string to look at.

.8 We reached the end of our string with no matches, so load X with 0.

.DONE  X holds 0 if no match, or contains the position of the match. Do whatever you need to do with that information.

[Pinacolada]

Thank you for that info, nikoniko It sure does look shorter than my version. I thought it was pretty good for a beginner, but I can sort of see the grace with which that was written. I'll take a closer look at that when I get home, but thank you!

The analysis helps tons, too.

I'll probably stash the X register somewhere, then assign I% to it... we'll see. Maybe I'll get this figured out tonight, that'd be awesome! :cool:

The "who all helped" list is getting longer, and that's a good thing

[Pinacolada]

There, I've made an update to my home page where you can download a copy of TADA:

http://geocities.com/sym_rsherwood/

There's some real basic (haha) instructions there on what to do. There's another thread going on in Jeff Ledger's forums, too:

http://jledger.proboards19.com/index.cgi?board=ssocc&action=display&thread=1169152475

I'll check both places, and email is encouraged if you have questions (I'm not that great at getting docs together...), comments, criticisms (even "This sucks, and you're crazy" would be welcomed... I think...) :skratta:

Oh yeah, and I did get the ML working! Thanks tons, nikoniko.

[hydrophilic]

4.32 Megabytes, zipped!  That's a lot for a 'game' that doesn't run. :lol:

I'll play around with it.  I always love editing character stats.  Final Fantasy 8 is one of my favorites: make the girls hit like monsters or the guys cast devestating spells.  Hehehe.  Loads of fun.

[nikoniko]

D'oh! Bandwidth limit exceeded.

Check your PMs for a message from me. I have a better option for you than Geocities.

[Pinacolada]

Yeah, a lot of that space is taken up by a few penciled GIFs of a map level I designed. I need to convert that to some sort of grid, but I'm not sure what to make the grid with.

There's some redundancy in the archive, too. I chip away at it when I can. If anyone spots something obvious, let me know. I've probably developed a blind eye to it.

Put some work into TADA yesterday, broke some existing code (isn't that always the way it works?) in the "t.main" file; but the goal is to get map level 1 working so we can list room descs, monster/item/weapon/food, and exits (which can be hidden, or a few other things). That'll be a good start.

Monster and item list generators work now.

Not sure how much work I'll be able to do this weekend, but things are slowly coming together. Very, very slowly. Sorry if you had certain expectations and the game didn't do much of anything... I guess I shouldn't really release it until things somewhat work.

Well, hang in there, things will get finished. I guess the player editor is the one thing that's mostly complete. There's some sections that need to be finished yet, but you can load, edit *most* stats, and save so far.

nikoniko: thanks.

[Pinacolada]

*bump*

Wow, I forgot about this thread.

There has been some activity in programming the game; I've moved over to Linux since then and can compress the individual disk images with .gzip now. VICE will attach .gzipped disk images, just no write support; so if you want to save stuff back, unzip the disk images.

I am working on a duplicity of sub-projects; I don't have web space right now (well, except at www.retrogradebbs.com; my BBS project is back online via telnet, too: telnet://dragonseye.dyndns.org:6400)

Real Life sucks.

If there is any interest in seeing the progress, just reply to this thread and I can email you the stuff, it isn't that hard. I might also consider reactivating my Yahoo group...

[hydrophilic]

I'd be interested (sent you a PM).  With the character editor and item lists working, that just leaves the maps and rooms, right?  I've been wanting to make an adventure game for a while but don't have a good story and not enough time lately.   So many projects right now I can't spend enough time with my Commie

Although I don't have a story, I have plenty of ideas about how it should/could work.  Like the world map should be very visual.  Somewhere in complexity between Ultima I and Final Fantasy XII.  (I give myself lots of wiggle room).  In towns I'd like lots of character interaction.  With both traditional Zork text and with Maniac Mansion pointer interface.

And shopping.  I liked the way Pirates! had its own little econmy in each city that varied the price/availablity of goods based on region and current conditions (embargo, war, natural disasters, etc.).  I don't know how much our little 8-bit could handle, but I'd like to have several NPCs in towns through the world constantly executing there own AI script.  Of course these would turn it from more of an adventure to a simulation... a good balance would be needed for playability.

Like in one city you could have a knight preparing to battle some fierce dragon while another town has theif preparing to rob the nearby King's castle.  Then if you traveled to these locations you team up with them or perhaps oppose them (like signup as a mercenary for the King).  These events would play out if you don't participate and of course there would be consequences...

Too many ideas not enough time.

Anyway, nice to you've made progress and not given up.

[airship]

I had an old Ohio Scientific Challenger 1P (Commodore PET clone) with only 4k of RAM. I wrote a dungeon crawl game for it with separate monster list and dungeon map files. The monster lists I created by hand, but the dungeons were generated by a separate program, then saved to cassette tape. Writing that dungeon map program was one of the most fun and successful projects of my young programming avocation. It was actually more fun to sit and watch it generate a dungeon than it was to play the game.

/nostalgia

Please return to your regularly scheduled thread.

[hydrophilic]

I'm guessing you don't have that map generator anymore?  I really enjoy games that create a random map like Impossible Mission and Parasite Eve.  Although I've beaten both of those games numerous times, they're still fun to pick up and play today because the layout is different every time.  MANY other games just sit around collecting dust/rust because they're not nearly as much fun once you know the world layout.

Another must-have feature.  Thanks for the idea!

If you want a non-technical read about adventure games, I recommend The Craft Of Adventure.  Its about 96K or 31 printed pages.  Lots of ideas in there...

[airship]

Unfortunately, just about all of my old 8-bit programs bit the dust long, long ago.

I seem to remember that I started with a random maze generator that put a full character block in alternating horizontal and vertical spaces, so you had a grid of background and windows of 'dungeon'. Then I can't remember if I generated random rooms first, or a dungeon maze first. One or the other. Then I placed monsters and treasures using a simple algorithm based on room size, plus some random monsters in the halls.

Anyway, like I said, it was fun to watch and it created surprisingly sophisticated dungeons. By tweaking the parameters for how many rooms, maximum and minimum size limits, monster density, etc., you could get quite a bit of variety.

When it came time to play, I just displayed the map in background color, then switched each cell to foreground color as I moved, resolved any encounters, and if I was still alive, allowed opening the treasure. Very simple, but it was my favorite game for awhile because, as you say, it was different every time.

[Pinacolada]

  Not sure how to incorporate multiple authors into the same quote, so I'll just do it in my trusty copy of EditPadPro (shameless plug). Great editor, tons of useful features, works under WINE in Linux...

> Re: Adventure game stuff « Reply #17 on: May 13, 2008, 10:06 pm »

> I'd be interested (sent you a PM).  With the character editor and item lists
> working, that just leaves the maps and rooms, right?  I've been wanting to
> make an adventure game for a while but don't have a good story and not enough
> time lately.   So many projects right now I can't spend enough time with my
> Commie

  Cool. Thanks for the feedback! I'm glad someone is interested. Although with things being in the rather unplayable state they are (ie, not enough of the game is finished; sure, you wander around the map and toggle a few options, and you can go into the "Wall Bar & Grill," for example), many routines just haven't been debugged enough to be usable. Combat, inventory management, and most of the major commands aren't written yet. I have the source code to the original game though, and as soon as I finish rewriting the programmer's reference guide to that Apple BBS package, it should make transitioning the script language it used to the Commodore much more easier.

  What I've got so far of the ref guide is in /docs/apple.

  Character editor is mostly for if/when I port this over to my BBS, honestly. For some reason games of that type always included a character editor, so why be different? Besides, it's sorta fun...

  But there is still tons to do. Items are good, but I have to write the logic in using them, and their various interactions with other things (spells, monsters, etc) in the game... there are lots and lots of ways you can use various items, all expressed in this script language (called ACOS, for Advanced Communication Operating System)... some commands there are no equivalents in Commodore BASIC, hence using ML:

  * instring function (thank you, Mr. Hart)
  * the "module loading" routine (courtesy of an issue of Compute!'s Gazette)
  * Input Any (from either Dave Moorman or Jim Butterfield, can't remember
        whose code ended up in the final build); I would like to add a "skip carriage return" flag since getting a byte that happens to be #13 truncates the string, and I don't want that; each field in the character stats REL file is exactly 234 chars long, no more, no less. I'm a bit stymied about how to do so...

  About the story: After the player wins "The Land of Spur" portion of the
  game, I was thinking of letting them loose on a "build your own world" kind of thing (like a MUD, only single player); we could share maps and stuff, maybe...? So maybe you could contribute to it, if you wanted. I'd like that.

> Although I don't have a story, I have plenty of ideas about how it
> should/could work.  Like the world map should be very visual.  Somewhere in
> complexity between Ultima I and Final Fantasy XII.  (I give myself lots of
> wiggle room).  In towns I'd like lots of character interaction.  With both
> traditional Zork text and with Maniac Mansion pointer interface.

  Now that sounds ambitious! I like that idea. Except, how would you accomplish both at the same time...?

> And shopping.  I liked the way Pirates! had its own little econmy in each
> city that varied the price/availablity of goods based on region and current
> conditions (embargo, war, natural disasters, etc.).  I don't know how much
> our little 8-bit could handle, but I'd like to have several NPCs in towns
> through the world constantly executing there own AI script.  Of course these
> would turn it from more of an adventure to a simulation... a good balance
> would be needed for playability.

  Oh, of all the... stop stealing my ideas. I thought about a script language years for TADA (well, the whole Apple BBS and TLOS is written in a script language) years ago, but I just lack the know-how to do this. I'm just an ML beginner...

> Like in one city you could have a knight preparing to battle some fierce
> dragon while another town has theif preparing to rob the nearby King's
> castle.  Then if you traveled to these locations you team up with them or
> perhaps oppose them (like signup as a mercenary for the King).  These events
> would play out if you don't participate and of course there would be
> consequences...

  Ooo... neat idea! So things going on in unseen quarters would definitely have an affect on the game....

> Too many ideas not enough time.

  Tell me about it. :/

> Anyway, nice to you've made progress and not given up.

  No, not giving up on it, just on hold thanks to Real Life... :/
  Thanks again for your positive feedback. I'm intrigued to find out what you thought was interesting. How much code did you look at? Was the archive overall too big to understand? etc

  ---

  And now, because I'm too lazy to make multiple posts... here's airship.

> I had an old Ohio Scientific Challenger 1P (Commodore PET clone) with only 4k
> of RAM. I wrote a dungeon crawl game for it with separate monster list and
> dungeon map files. The monster lists I created by hand, but the dungeons were
> generated by a separate program, then saved to cassette tape. Writing that
> dungeon map program was one of the most fun and successful projects of my
> young programming avocation. It was actually more fun to sit and watch it
> generate a dungeon than it was to play the game.

  Oh wow, I didn't know there was a PET clone... Now your game sounds pretty
  neat... how about some rough sketches of what it might have looked like...?
  I'm terribly curious...

> Please return to your regularly scheduled thread.

  I for one don't mind the additional input; it makes things more interesting.
  Thank you.

  ---

  And back to hyhydrophilic:

> I'm guessing you don't have that map generator anymore?  I really enjoy games
> that create a random map like Impossible Mission and Parasite Eve.  Although
> I've beaten both of those games numerous times, they're still fun to pick up
> and play today because the layout is different every time.  MANY other games
> just sit around collecting dust/rust because they're not nearly as much fun
> once you know the world layout.

  I've never played Parasite Eve, but I love the idea of a random map...

> If you want a non-technical read about adventure games, I recommend The Craft
> Of Adventure.  Its about 96K or 31 printed pages.  Lots of ideas in there...

  Graham Nelson is my hero. I have that printed out in a 3-ring binder, although
  I haven't looked at it in several years, maybe it's time to refresh my memory!
  I love Inform, the new natural language version kicks some serious butt. But, the reason I'm going with this home-brew deal is because I don't think you can create objects like a MUD; that's really what I want to do in later levels of the game. I *will* have to come up with a scripting engine to handle all the possibilities of object interaction, I shudder to think of all the IF-THENs necessary every time someone comes up with a new object *cries*...

  ---

  On a somewhat related topic, I think I will investigate this thing called CVS, if I understand it correctly it lets you download changes, or merge changes into your "source tree" (which with Commodore BASIC programs would be .prg files...?)

  Then comes the issue of building the disk images. I could write a shell script to command "c1541" to make a disk image, I suppose. That... actually wouldn't be a terrible idea...

  I need a shell script to *.gz all the disk images before emailing the archive to folks...

  hydrophilic (what does that handle mean anyway?

  I am not sure what all has changed since the last time you downloaded the archive. Would it be a bother to re-download the entire archive once more? I did start dating the archives (like "TADA 1-10-06" for example), and like you mentioned, it's just the disk images that are important, I suppose.

  I will work on .gz'ing them up and get them out to you later today.

  I am also interested in hearing more about your 3D game engine. Were you the one who was talking about the Sierra AGI interpreter...?

  ~ Pina ~

Quoting myself:

Yeah, a lot of that space is taken up by a few penciled GIFs of a map level I designed. I need to convert that to some sort of grid, but I'm not sure what to make the grid with.

Dia! *nods firmly* So much has been learned of Linux in the past year... college rocks.

[hydrophilic]

I was thinking of letting them loose on a "build your own world" kind of thing (like a MUD, only single player); we could share maps and stuff, maybe...?

That sounds great.  For developement, we need a map editor which is why Airship's idea got me excited.  It could do all the work   Seriously, I think a map editor would make a nice bonus feature that the player could unlock.  And even if they don't unlock the editor, they could still have the option to import maps others have created when starting a new game; it would be serious cheating to redifine the world in the midst of a game... not to mention error prone!

...In towns I'd like lots of character interaction.  With both traditional Zork text and with Maniac Mansion pointer interface.

Now that sounds ambitious! I like that idea. Except, how would you accomplish both at the same time...?

The idea is to have a pointer to either build simple "verb noun" or "verb noun preposition noun" sentences.  What ever words you click in on would just be 'typed' to the input line.  Or the user could type the commands manually.  With a pointer interface, you can also navigate by simply pointing.  Another idea: instead of clicking on "verb" and then "noun" from menus, the player could click on "verb" from a menu and then click on the "noun" in the scenery.  For example, click "turn on" from a menu and then click the image of a radio in the scene/room.

Of course it might not be practical to have all possible objects rendered on the screen.  In fact, probably no drop-able objects.  If you allowed that, the player could just keep accumulating items and then dropping them in one spot until the scene looked like a big pile of garbage.  On the other hand, it would be a neat hack to allow the player to do such silly things if they choose.

Even though there is a visual component, the game could still produce descriptions of scenes and activities.  Especialy for subtle or non-visual details.  And of course for dialog.

In some ways this would be complex (like the "clicking routine" would have to know when the "sentence" was complete).  In other ways it makes the game simpler.  The Infocom games have a lot of code/data to allow great flexibility in how the user enters commands.  One reason is because the game can't know in advance how the player will describe desired actions.  But with a menu of actions and nouns, the game becomes more compact -- the allowed nouns/verbs stated explicitly.

And if the interface is 'smart' it will remove verb/nouns that are not applicable.  This should save on the large amount of code used in adventure games that say "you can't do that".  Of course this would decrease the funny factor -- a lot of text in Infocom games contains humurous ways to say "you can't do that"

I would like to add a "skip carriage return" flag since getting a byte that happens to be #13 truncates the string, and I don't want that; each field in the character stats REL file is exactly 234 chars long, no more, no less. I'm a bit stymied about how to do so...

The easiest way would be to scan all 234 characters of the string and replace each #13 with something harmless like a space or period.

Code Select Expand


;note 'str' points to adrs-1 of string to scan
LDY #234
loop
LDA (str),Y
CMP #13
BNE ok
LDA #20 ;space
STA (str),Y
ok:
DEY
BNE loop

The alternative is to delete the #13 from the string, shifting all trailing characters 'back down' and then adding a space (or whatever) at the end to keep the length at 234.  I leave that as an exercise. (I've always wanted to say that.)

there are lots and lots of ways you can use various items, all expressed in this script language (called ACOS...

Another scripting language.  I'll have to look that up.  I'm still trying to wrap my head around Inform and the Z-Machine...

I'm intrigued to find out what you thought was interesting. How much code did you look at? Was the archive overall too big to understand? etc

Honestly I never ran any of your code.  There were so many modules and the documention wasn't clear about what worked and what was broken.  I was impressed by the sheer volume.  I liked all the characters you developed.  As I recall you had large item and monster lists too.  You obviously spent quite some time and used a lot of creativity in making them.  I spent several hours looking at that stuff.  Just fascinating.  Of course being able to "play" with that is the ultimate goal so I encourage you.  Keep at it.

I've never played Parasite Eve, but I love the idea of a random map...

That's a game for the Sony PlayStation.  I've got plenty of RPGs for that console, but I'm fairly certain that game is the only one with a random map generator.
But the idea is like Impossible Mission (for the C64; if you haven't played that, do it now).  There are specific rooms in the game they're just scattered about randomly, more or less -- there are some rules that prevent it from being completely random (so you don't get an impossible game for example).

I *will* have to come up with a scripting engine to handle all the possibilities of object interaction, I shudder to think of all the IF-THENs necessary every time someone comes up with a new object *cries*...

It shouldn't need a lot of IF-THENs for new objects.  Just for the verbs that act on the object.  All the other verbs should fall through to the ELSE clause which is the same for all verbs and says "you can't do that".  For special items a new attribute is often required.  For example, if you had a game that consisted of swords, coins, and paper.  Then you introduced a lighter or match.  Then you'd need to create an attribute called 'burnable' and attach it to all your items (in adition to new verbs like 'burn').  Hmm, that is about as much trouble as all the IF-THENs that you fear.  So maybe its ok to cry?

hydrophilic (what does that handle mean anyway?

One who loves water.  Correspondingly, my avitar is the mythical sea serpent, Leviathan.

I am also interested in hearing more about your 3D game engine. Were you the one who was talking about the Sierra AGI interpreter...?

Nikoniko / Michael Hart was working on that. Anyone hear from him lately?

Warning: off-topic rant about 3D engine
The last time I worked on this was about this time last year.  Besides 3D rendering of lines and hollow triangles, it also does filled polygons (solid or with a pattern).  I've spent quite some time to make it fast.  It started forever ago when I tried to find out why Gunship was able to render fast "solid" graphics while Echolon was terribly slow even though it only rendered "hollow" (wire-frame) graphics.

Well I learned a lot.  If anyone wants to see how NOT to write a 3D engine, look at Echelon.  That game tries to be smart/fast by drawing to a buffer with each row $100 bytes after the other (VIC programmers know that bitmaps are built from rows $140 bytes which makes things difficult).  Unfortunately, this buffer can't be rendered (correctly) by the VIC so it all must be copied to the VIC screen for each frame.  I believe the game uses 12 rows so it must copy $C00 bytes (3K) every frame.  That copying process eats way more time than is ever saved by the $100 byte/row trick.  So it is slooooooooooow.

Gunship on the other hand (like all good 3D engines for the Commies) uses two VIC screens.  When the engine finishes drawing one, it tells VIC to show it and proceeds to draw in the other.  No copying saves a lot of time.  Another feature is the solid hills.  This is a neat trick accomplished by a 'quick paint' routine.  The downside is the hills can't have angles greater than 45 degrees and likewise the hellicopter can't roll more than 45 degrees.  Together these ensure that the steepest line will be vertical or 90 degrees.  Otherwise (say an angle of 110 degrees) would cause the paint routine to fail.

For arbitrary filled triangles (or polygons if you want to get fancy) you need a real rasterizer.  This just draws out triangles as a series of horizontal lines, of various lengths, from top to bottom.  My 3D engine has a very efficient horizontal line routine which makes use of the hardware features of the C128.  This enables it to generate solid polygon scenes at rate of about 5 fps.  Terrible by todays standards, but about the same speed as Gunship (which is strictly limited remeber).  This is about 20% to 50% faster than Flight Simulator (which does real rasterization) and is easly 100% faster than the pitiful Echelon.

An interesting note.  I only wanted it to do "solid" triangles but due to a bug, I discovered it could also render patterns just as easily!  Once I had the triangle routine working it became obvious that a polygon was only marginaly more complex so I added that feature.

The problem is clipping.  The code isn't terribly difficult just ugly.  Note a triangle which is clipped usually becomes a higher-order polygon.  In the worst case it will become a hexagon.

Anyway, I severly broke the engine while implementing clipping.  I'm pretty sure now this is due to a bug in the xa compiler not catching redefined variables.  A bug on my part for creating them!  I'll get around to fixing this someday.

Another thing the engine has to do is transform 3D to 2D coordinates.  A straight-forward approach will multiply a 3x3 matrix by a 3-element vector for every point in the scene (and some not in the scene too).  A bad implementation will even transform the same point multiple times.  I really don't understand the tranformation routines in Echelon but it seems to take the simplistic approach.

A better approach (since the matrix multiplication needs 9 multiplies and 6 additions) is to reduce the coordinate transformations.  One way is to only rotate the x,y,and z axes of the object to be rendered and then scale and sum them in various ways to build the points of the object to be drawn.  Done properly this will greatly reduce the number of multiplies.  I've just learned this recently from studying Gunship.  I'm curious how much this will boost performance when implimented...

Using a fast multiply routine helps of course.  None of the games I've examined uses fast multiply.  However the gain of fast multiply in my engine has been lost by the use of floating-point numbers.  Maybe one day I'll re-write it to use integers.

I have high hopes for this engine but right now I'm working on a similar real-world project.  (A commercial application using DirectX / Direct3D.)  So I don't have much time or desire to work on the engine now.

(now I bet you're sorry you asked)

Adventure games are a needed diversion from all that 3D mumbo jumbo.  Looking forward to trying your code.  Character editors = great

[Gumpy]

Yeah, I recently considered multiplexing VIC sprites to allow more than 8 sprites on screen, building animated characters that way, but keeping track of it all while things move around -- and ensuring that no more than 8 sprites try to cross a single raster at once -- is too much of a pain. I can understand now why Sierra never bothered with the Commodore 8-bitters. As such, I've gone back to the 80-column chip, since with that I can do unrestricted 16-color 160x132 on NTSC, more on PAL, and theoretically might be able to do 160x200 with some trickery.

Hey, it's been quite awhile since I've checked out this site, just wanted to know if you ever made any progress on this or not?

[airship]

Random Dungeon Generator

Okay, as near as I can remember, here's how my dungeon generator worked. It's been a lot of years, so if something doesn't make sense it's because of my rusty memory.



First of all, you divide the available space into a grid of isolated squares, like the light blue ones shown. The gap between each row and column is one square wide. Remember this is a text screen, so the grid is basically a screen-size text character grid size minus a line or two for information display. Mine reserved the top line for basic info (name of the adventure, # lives left, etc.), while the bottom line was for encounter info ("It's a ravenous, slobbering Wumpus!", etc. BTW, this descriptive text was stored in the separate manually-created monster/treasure file.)

Then you set a value for the maximum room area, maximum and minimum number of rooms, and minimum and maximum room dimensions. A routine then generates a set of rooms (pink) and places them on the grid, ensuring that there is at least one row or column of squares between all rooms. As each room is placed, one of the covered squares is set as the door for that room (orange). (You could have multiple doors, I suppose, but my routine only allowed one.)

Generate entries and exits for the entire level. In this example, the outside entry is indicated in blue, the stairs up are red, and the stairs down are green.

That's as far as the image above shows. The next thing is to connect all the leftover squares using a simple maze-generation algorithm. The room doors and level entries/exits are also connected as part of the maze.

Then you spread stuff around. Every room gets at least one monster and treasure. Doors can be marked as locked or secret. Random encounters can be seeded in the maze itself. I thought of a lot of cool stuff, and if I remember right I later made it possible for entries and exits to be in rooms instead of the maze.

Anyway, you ran the program and it let you enter your dungeon size, number of rooms, etc., and let you designate maximum and minimum monster and treasure levels for this dungeon, etc. These were placed on the map as letters, which were interpreted during the dungeon run as actual monsters and treasures from an independent hand-created list. You could actually change a dungeon's character-appropriate level just by changing monster/treasure lists.

Finally, the program wrote the dungeon to tape simply as a string of characters that represented the whole screen. At runtime, everything but the entrance was displayed in background color, which would be revealed as you moved around.

Very simple, but it was very effective. Generating a dungeon was super-easy, and I must have had a hundred levels on tape at one time.

For example, a typical dungeon file might have looked something like this:

OOOOO.MmMmMmMmMmMmMmMmE.MmM.M.OOOOOOOOO
OOOOO.m.................m...m.OOOOOOOOO
OOOOO.M.MmM.MmM.MmM.MmM.MmM.M.OOOOOOOOO
OOYOO.m.m.m.m.m.m.m.m.m...m.m.OOOXOOOOO
OOODO.MmM.MmM.MmM.MmM.MmMmMmMmDOOOOOOOO
...m........................m.OOOOOOOOO
MmMmMmMmMmMmMUM.MmMmMmMmMmMmM.OOOOOOOOO
..............m.m.........m............
MmMmMmM.MmMmMmM.MmMmM.MmMmM.MmM.MmMmMm*
m.......m...........m.m.....m...m.....m
MVMmMmMmMmMmM.MmMmMmM.MmMmMmMmMWMmM.MmM
....m...m.....m.....................m..
Mm#.M.OODOO.M.MmM.M.M.MmM.MmM.MmMmMmM.M
m...m.OOOOO.m...m.....m.m.m.m.........m
MmMmM.OOOOZ.MmMmMmMmMmM.MmM.MmMmMmMmMmM


With the following key:
M = original maze square
m = generated connecting maze square
O = room
D = door
. = wall
E = entry
* = stairs up
# = stairs down
U-Z = various monsters

One more important point: to save memory, I actually loaded the map right onto the screen, so there was no data anywhere. With 4K of RAM, you had to do what you could.