Port of text adventure games to SCI

[Collector]

Here you go, minus demos and things like the Hoyle games:

Codename- ICEMAN    - 234
Conquests of Camelot - 226
King's Quest 1 SCI    - 146
King's Quest 4      - 159
The Colonel's Bequest   - 244
Leisure Suit Larry 2   - 118
Leisure Suit Larry 3   - 124
Police Quest 2      -   98
Hero's Quest      - 291
Quest for Glory 2   - 247
Space Quest 3      - 113

As I suspected, the QfG games required the most. And without counting actual numbers of scripts in specific games, later SCI games seem to have a limit of 65,000, in addition to the fact that they split the scripts (SCR) from the heap management (HEP).

[gumby]

So on average 181 scripts per game.  I think on average I'm probably quadruple that number.

[gumby]

So, I've figured out how to handle the grammar/parsing conversion.  It's interesting: the way that Inform & the Sierra interpreter parse is in a very similar fashion.  The only difference that I can see (on the surface) is that Sierra's interpreter allows for a maximum of 3 parts, whereas the Inform let's you use as many parts as you want; each command is ultimately broken into a maximum of 3 pieces, however it let's you 'chain' multiple commands together.

Here is an example of a grammar segment in pseudo-inform:

Code: [Select]

Verb 'attack' 'fight' 'hit' 'hurt' 'injure'
    * animate(in_room,on_ground) 'with'/'using'/'thru'/'through' weapon(held,carried,have) -> Attack

This can be easily rewritten as:

Code: [Select]

(if(Said('(attack,fight,hit,hurt,injure)<(with,using,thru,through)/*/*'))
      AttackSub()
)

The only difference is Inform's ability to use attributes of objects as part of the parse (animate, weapon) - but typically these are also handled in 'preactions' or at the beginning of the action (in this case, 'Attack' is the action being called).

The way that the Inform language names the three parts are 'verb', 'noun' and 'second' (in that order).  The same names apply equally well in SCI as well - in fact I think it assists in understanding just what should go in each section of a Said()

[gumby]

I've got Zork bootstrapped into using the decompiled logic.  It's correctly parsing all the input commands and calling the correct handling procedures.  Most of the 'simple' commands work, where the called procedure is just generating a single Print(), but the more complex ones are still full of bugs.

But it's definitely working!

[gumby]

Update:

The Print() output was previously all 'ad-hoc'.  You'd type a command and it would throw multiple print statements to the screen before ultimately returning the input back to the user, which makes good sense when your application is printing characters to a console window, but looked pretty silly in SCI.  I ended up queuing up all the printed output by appending everything to a string, and then when the command returned, flushed the output to the screen with one Print().

I've successfully implemented 'object properties'.  This was quite difficult - basically the Inform language allows for any object to have any property & that they can be changed throughout the progress of the game.  A torch might have a property of 'flammable', but once it's burnt out the object would not have the property any more and it would be removed.  My first attempt was to define each object (rooms and all) as having a property of each referenced property within the game.  This ended up being 350 objects with 70 properties each, causing heap errors.  The problem is also that the object/property combination was fairly sparse; most objects did not need most properties.

The solution:  I created a text resource for each property - 70 text resources.  The index within each text resource corresponds to an object number, the value is the value of the property (sometimes boolean, sometimes other values).  This only works to represent the initial state of the objects.  Then I created a list, which contains any 'state changes' to the object/property combinations.  So my logic is to check the list first for the referenced property/object value & if it doesn't exist then go to the text resource.

[Cloudee1]

It sounds like everything is really starting to come together. Hopefully I'll get to play Zork soon

[gumby]

Update:  I've spent the last week updating Zork with the 'robust parse' techniques that I've posted about in the past, which is helping bridging the gaps between SCI and zMachine.

Using the 'The Zork Psychological Test' (http://hunternuttall.com/blog/2010/03/the-zork-psychological-test/) as a test plan, I've got my parse success rate to 73% (56 out of 76).

Still a long way off, plenty of heap errors & still cannot leave the first room.

[gumby]

Based on the Zork Psychological Test, I'm only failing 2 or 3 tests and these I will probably not fix them in the near future.  Inputs like 'drop all' don't work, you'll have to take/drop objects individually.

Moving between rooms works for most cases, and the heap errors have been mitigated.  Manipulation of the 'object tree' is somewhat broken, so taking/dropping objects sometimes makes them disappear completely.  I suspect this has to do with object 'sibling' relationships, but not certain yet.

As soon as I can debug one last movement scenario & correct the object tree code I'll upload and you guys can see how it's shaping up.

[Cloudee1]

Read the psychological test, pretty amusing really.

It sounds like you are getting real close to be there Gumby. Are you going to know what to do with yourself when you finally stamp this project done?

[gumby]

I doubt I'll ever be done with this project

I've uploaded a new version.  As indicated, nearly all inputs from the psychology test work.  You can score up to 44 points (out of 350).  Navigating between rooms works correctly as well as interacting with objects (picking up, putting down, viewing in inventory, etc).

Some objects are still 'invisible' (there but can't be readily seen), I think this is a bug in handling 'supporters' - the kitchen table for example is classified as a supporter, supporting several items on it's surface that don't make themselves readily apparent to the player for some reason.

Heap errors are still quite common, so don't be surprised when you run into them.

Cloudee (or Doan) please replace the existing Zork demo that I uploaded eons ago with this latest version.

[Cloudee1]

The game has been loaded onto the fan games page and is now ready for scrutiny.

I know the feeling about never being done, I looked at spongebob the other day and realised that I started it back in 2004.

[gumby]

I've finally resolved my serious heap issues with Zork.  I was tracking property state changes for objects in a Set (a subclass of the Collect class).  Somehow, the Set code would freak out under some circumstance and eat half my heap in a single call to it (from 16K to 8K).

I tried to isolate what the problem was with the Set code, but couldn't.  I even set up a simple template game to see if I could figure out, but I couldn't reproduce it (no heap issues arose).  Within Zork, I examined my Set after the heap was decimated and the Set appeared fine.  So it wasn't like I was inadvertently adding a thousand items to the set, or even adding nodes into the set that were ridiculously large - I was just add tuples of integers, my set had only two nodes in it.

I switched the code to use arrays instead of the Set and now the issue is gone.  I'm a little irked because I've been trying to alleviate this heap issue for over two years now.  I woke up this morning convinced it was indeed the Set code that was causing the issue, ripped it out, and within a half hour had an array equivalent coded up and working perfectly.

[Cloudee1]

Excellent work. Sometimes all it takes is the willingness to scrap an idea and try a new one.

[gumby]

Cheating is implemented!

I've augmented the 'alt-debugging' in the main script to do some pretty cool things, inspired (okay, technically ripped) from the Perl Rezrov project (see http://search.cpan.org/~edmonson/Games-Rezrov-0.20/rezrov).

Now we can teleport to any room, which admittedly was already in the main script but I needed to modify it slightly to support Zork.  I added another debug command for showing all the rooms on screen with their corresponding number so the user doesn't have to guess.

Additionally, I did the same thing for obtaining any object in the game with a debug command, and did another debug command for showing all the objects on screen (just like the 'show rooms' debug command).

Finally, I added debugs for manipulating object properties.  One command give the 'light' property to any object (just in case you forgot your lamp!). Another weaponizes any object.  You can now kill the troll with a leaflet or any other object you choose (note: the combat code isn't working yet with the troll, but you can inflict damage on yourself).   I'm considering showing all the property numbers on-screen like the rooms & objects, and then creating a more generic object/property manipulator, but I'm not sure going this far is really necessary.

There are a couple more cheats that I'm going to probably implement (remove weight constraints of objects & making containers able to hold an infinite number of objects), but for now this seems sufficient.

[gumby]

Combat is partially working.  Currently the only enemy that is 'fightable' is the troll (due to hardcoding of the villain) and he doesn't fight back.  But he takes damage, occasionally is disarmed or is knocked unconscious, and can be killed.