Open source IF format

Technical Development Interpreters
21

Re achaeology: the ZMachine format is so widely documented and so widely ported and available in so many platforms, conceived from the very beginning to BE easily available in any machine, that I think it’s a question already answered.

I’m not a hardcore archaeologist like others are, but I do a fair bit of digging. I can say that in my experience non-executable game files are best - all I need is the interpreter for my machine. Otherwise, I’d need a Mac-emulator for my PC, for instance. It’s not like a Commodore 64 or Spectrum emulator, which are rather light.

22

In case of text file, he/she will have to attack brutely using some ten or twenty odd coding charts. For compiled games, that might be more complicated.
And I will look into your project although I am not sure how much help I will be. I mean, I am not a PhD kind of programmer. I am just 18 and started to code about 8 months ago (got irritated by Java, bored of C, crazy because of Perl and settled on good ol’ Python). Hell, I am struggling to create a decent Lexer (when will I get on Parser? sob) that doesn’t get in a coma whenever I enter ‘both apples’ instead of ‘two apples’ (This is struggling with grammar on a f#*king different dimension. And I thought reading Shakespeare was hard).

23

True natural language processing is very complicated, and no IF system even attempts it. But you still might like to look at the NLTK library for Ptython if you’re interested in that.

24

One point that’s been missing in this discussion of hypothetical archeology is that a simple text representation that is easily understood will work for something like a CYOA-book. (“To look at the cookie, turn to page 54. To eat the cookie, turn to page 48.”) But most IF games contain more complicated logic, and pieces of text put together at the time it is to be displayed, so being able to read the text file would still be a significant step away from being able to run the game.

To pick a very simple example to illustrate my point: How about handling an inventory? What if there are different player characters during the story, each with their own inventories? And then things can be picked up, taken apart, put down… You see that it can easily become complicated, and that’s just looking at a small simple aspect of the thing.

Or take a look at the source code for some existing games, for example Ble Lacuna (Inform 7) or Return To Ditch Day (TADS 3). Those are text files. Could you by looking at them easily get the games running if you didn’t have access to the tools or documentation of the languages? I’d find it a complicated task even if I could look at the documentation. Luckily, we do have source code available for the interpreters for these languages, so future historians will just have to port that to whatever machines they are using.

That is why binary game files are not less preservable than text game files. You still need to know what to do with them, regardless of format.

–

Good luck with your project! It can be a good learning experience for you to attempt. You would probably learn more by studying how the existent systems work (and if you then still want to create something new, you’ll have a much better starting point with all that knowledge), but if dreaming up something from scratch is how you want to spend your time, go ahead. Just do it for fun, and don’t expect to create a masterpiece.

But if what you really want to do is make a game, you really should learn an existing language instead.

–

P.S. I know that my writing isn’t always as clear as I’d like, so I’d like to add that this post is written with the intention of being helpful, and not condescending in any way. If that intention failed, it’s due to my lack of writing skills, so please don’t take it the wrong way.

25

Following is the way I am solving this problem.
The collection of text files is contained in a zip file along with meta-data and such. Whenever a player starts a new game, the content of the zip (which contain game data, customizable grammar rules for parser and such) are extracted in a folder. The convention I am using is:
If ABC is player’s name and xyz is game’s name, then folder’s name is ABC.xyz.
This gives the IF game a feature akin to ‘Profiles’ in other games so that multiple players can play the same game on same machine.
All the mutating data (inventory, etc.) can now be very easily changed- it’s just a matter of editing a text file in that folder. (To understand how the rooms and Items relate and operate, read one of my earlier replies).
I guess the CYOA approach you are reffering to is taken by pyf which stores all the game data in a static XML file. In the model I am making, this just won’t be the issue. Also, because each instance of game will have it own files, we can very easily create a ‘history’ file to make undo more functional (working even if game was exited midway), automatic save and restore and let NPCs retain their decisions and learnt ‘tactics’ even if game was quitted making them more intelligent.

26

My PhD is in biology, not informatics/computer science, so don’t worry about that. Well, the offer’s on the table :slight_smile:
Similarly, if you are interested in going more low-level, my pyIFBabel library needs blorb creation support, which I never got around to.

OK, I’ll stop recruiting now. :stuck_out_tongue:

Regardless, keep going with your project, if only for the learning experience, but, as zarf said, all innovation has come from people building things.

27

I’ve downloaded it to integrate in my project and if I manage to add blorb creation, I’ll PM you.