I am quite new to the domain of IF. More specifically; I’ve just met Marvin, seen a Dam made by zorknids and got killed (?) by Galatea when I tried to turn her as soon as game started.
But being the crazy programmer (HEEEHAHAHA), I immidiately jumped to create an game engine to create and play IF in Python. (Yes, I tried Inform7 but the pseudo-english coding made me mad; maybe because I am not a native english speaker.)
Anyway, what actually drove me off the hook was that the standard for creating IF, Z-Code, is not open source in itself. As far as I understand (and correct me if I am wrong), the Z-code’s source is proprietary code of Activision now. And as that was never made public, there’s no way we can properly understand the thing completely by reverse-engineering it alone. Then why not create a new, open-source standard- something analogous to EPUB in e-Books. (I read about Glulx but the wikipedia article wasn’t clear whether the format is open or not). Is Z-code so good in itself that there’s no need to create something new?
Hello and welcome!
Inform 7 is not the only IF system around; others are more like traditional programming languages. There’s one for Python as well. (There’s also PyF which never really took off in any way.)
Well yes, the Z-machine is reverse-engineered from Infocom story files and interpreters, but it doesn’t mean that it isn’t fully understood. It’s very possible that some minor nuances of Infocom’s vision are lost, but in practice the functionality of modern interpreters that support the format and systems that compile to it are fully understood, which is the only thing that matters. Z-machine does have limitations but none of them are because we wouldn’t understand how it works.
It is.
To turn the question around: Why create a new standard? Is there a need to create something new?
Sorry if this seems off-putting, but there’s a repeating pattern where someone comes in and posts “I just discovered IF, and you should all drop what you’re doing and do it this way instead.” It hasn’t worked so far. If you explain how your standard would radically improve something, and why a new standard should be made instead of improving the existing ones, and if you have a good plan on how to implement it in practice, then I’m sure people will be willing to help make it happen.
Ofcourse, I understand your scepticism (I guess the spelling is wrong). I mean, I’ll feel the same way if some n00b dropped in, screaming “IT’S ALL WRONG…RUN,RUN”
I did noticed pyf but I think reading a large IF off a single XML can be, well, quite slow. And anyway, the question isn’t about whether to use Python or C. Neither is it about Tads vs. Inform.
What I was implying is- being a linux user, I am used to ASCII files containing data and scripts which can be edited to heart’s will. A simple windows vs linux tells you that this approach actually works too. Seeing that IF is no more a viable commercial ‘genre’ (exceptions aside), it would be way better to create a easily editable and customizable standard that may push casual players into writing it.
I’m indeed trying to work out a way to give flexibility without compensating speed or verstality. Right now, I’m taking the EPUB-approach (data contained in a zip file) along with storing data in numerous ASCII files.
If you have any tips, I’ll be thankful.
Thanks for reply
I guess my reply was a bit vague. What I meant by using ASCII was using it as opposed to using compiled games. Because that gives the game author whether to keep his game open source or not directly in game (as opposed to making the source available on a blog or IFDB), whether or not to implement DRM (easily, I mean) for commercial release (For the record, I’m against DRMs) and keeping it alive even when the interpreter vanish (Seen a TADS 1 interpreter around lately?). And if I understand it correctly, Z-code doesn’t fulfill any of the above.
Because in the end, it really isn’t the question whether the language to write the games should be plain english or something practically unreadable (aka Perl). The issue is- what a resultant game should be like? Should it be forced into a rut because hey, that’s how it has always been? Or should it evolve with time, absorbing new ideas and changing itself?
[(I am NOT trying to start a flame war, by the way. FLOSS is something I just feel should be given a chance)]
There are already plenty ways to create IF using floss software. JACL is one of them btw. Glulx and GLK are a standard for IF. Inform6 is full open sourced now right? No need to create a new IF system unless you’re curious to do so.
If your interests lie in creating a new IF form or standard, you should do so, if for no other reason than to satisfy yourself. While I know you’re interested in doing this as a FLOSS project, consider the following: since the original patent for the mousetrap, over 4400 other patents for mousetraps have been granted. Only a handful of those designs have stood the tests of time and acceptance.
So, build your mousetrap and see if the world walks, slithers, creeps, runs, flys or otherwise seeks your door …
These are exciting times! You’ve just discovered the most magnificent hobby of all time, Interactive Fiction. For some magical and completely unknown reason, your brain has latched onto the idea of building an IF engine. You see what’s around, but it doesn’t feel right. It feels foreign. Like trying to do magic with someone else’s wand.
So how to proceed? You have vague ideas that you want text files, open source, maybe use Python. But geez, there are so many more requirements where to begin oh no my head is going to explode!
You need to have some way to parse text, so there’s all that study of how to implement some form of natural language parser. And since English is not your first language, you’ll be building a parser that understands, what? Russian? Vogon?
Then the whole world model code…sheesh that’s a lot of work.
And then when you get that stuff working you need to develop some basic libraries for compass rose directions, doors, floors, walls, scenery, basic verbs, and such. That usually takes an IF platform developer years, but you’re young, you can do it.
It might be a good idea to look at the I6, I7, and TADS 3 libraries to see what other people are doing with parsing and world modeling. It could give you some clues as to requirements that may not seem obvious right now.
But keep going! It’s fun to build an IF engine. Ask any of the dozens of us that have tried. (nevermind that we all quit somewhere between “running and screaming” and “i’m bleeding from my eyes and ears!”. Don’t let that discourage you.
David C.
www.textfyre.com
I’m not too sure what the problem is you’re trying to solve. Both the Z-Machine and Glulx are fairly generic virtual machines, and both are open standards. TADS 3 is open source too, but it’s specs aren’t fully up to date. Authors like using Inform and TADS because they like the languages, not because they’re limited to those ones. People have used Python before, and it would be possible to even implement Python in the Glulx VM, but most authors just wouldn’t be interested in that.
The Z-code model (which is shared by Glulx) is to compile source code into a documented binary format. This is nice because the compilers (and source language) can be updated frequently without disturbing the interpreter. The languages Inform 5, 6, and 7 all added features (Inform 7 being a complete redesign) but they all compile to the same Z-code format.(*)
It’s true that we generally don’t think about distributing the source code as part of the game file – it gets hosted on the author’s web site, if at all. However, the current standard is to include the Z-code or Glulx game in a Blorb file; this is just a single-file package containing the game file, metadata, and associated resources (like cover art). If an author wanted to include the game’s source code in the Blorb, that’s perfectly feasible.
It is unfortunate that the TADS 1 interpreter is lost. Distributing source code isn’t much of a solution, though, because the TADS 1 compiler is also lost. (They would be found together, I’m pretty sure, if they’re ever found.)
(* There were some Z-machine spec updates in that time, primarily to deal with Unicode. This doesn’t change my point, I hope.)
DRM is a separate problem. I don’t see how it relates to ASCII or source code, though. An IF DRM solution could equally well be applied to Z-code, Glulx, or any other open-source platform.
Actually, my head isn’t exploding right now, although it may later. I am currently working on the creating a ‘world map’ with all the rooms and such. For that, I attach a number, a name and a description to every room. This data is saved is a ASCII ‘database’ file. Also, if different chapters don’t have many rooms in common, there’s an option to create a different ‘database’ file for every chapter- thus reducing filesize and making it faster to access data. Also, when a new room is created, a ASCII file with name same as the room number is created.
If the user ‘looks’ around when in a room, that particular room’s file opens which contain data about the room’s content (this does seems tricky as wandering NPCs may not be able to wander because of static data saved in files, but a function called everytime the player enters data seems to solve the problem. The only catch, ofcourse, is speed. But that can be solved if NPCs don’t become active unless the player is in a surrounding room (similar to what Bungie did in Halo- all NPCs froze as soon as you crossed a ‘Loading…Done’ point).
When I say english isn’t my first language, I don’t mean I don’t understand any. Only thing I meant was that for me,
room[‘House’]=‘A Nice Place’
is equivalent to
The House is a room. The description is “A Nice Place”
About that parser, can anyone provide me a text file with list of verbs, propositions (on,at,etc.) and adjectives (edible, flammable, etc.) and save me from my herculean labour of “Let’s digest the Dictionary”
I’ll be using the number based system to simplify that, e.g.
Room.North=‘25’
Room.South=None
and such
Thanks
Actually, that’s not quite the scenario. Take, for example, EPUB again. It contains a meta-data file along with mimetype and ncx and such which can only be read by Epub readers. But the book itself is composed of, guess what, HTML files. This means that if some day all Epub reader vanished magically, you still will be able to unzip the file and then convert those HTMLs to a different format (or read them directly in a browser or edit or waltz with them). The same thing holds for android’s APK or java’s JAR files. Reverse-engineering and translating them would be easier than, say, an EXE file (as far as I know; which, I know, is negligible compared to everything. But still.)
Ah, I am sorry. And of course, Glulx can easily have a standard DRM. What I meant was how can we be sure that our DRM won’t interfere with Z-Code, given that we don’t have an absolute knowledge of its intricacies. But yes, it’s not a big issue (a bit idiotic, I agree). Sorry again.
I guess we both are speaking the same thing. Compiling helps in maintaining compatibility amongst Interpreter by being in binary format. But how would an simple ASCII text file will break compatibility is beyond me. Theoretically, an archaelogist a few thousand years from now dig up a hard drive containing the game. Which one will be compatible with even his computer- a compiled binary based game or a interpreted text based game?
At this point the Z-machine is defined by a open specification, and by open-source interpreters – not by the legacy behavior of Infocom’s 1980s code. I’d call it open-source without reservation.
There are fuzzy places in its behavior, but there are fuzzy places in most specs. I say again: An IF DRM solution could equally well be applied to Z-code, Glulx, or any other open-source platform.
They’ll both require functional interpreter software, won’t they?
Interpreted code is easier to analyze, since compilation typically squashes out lots of human-readability. So the student of 21st-century game design practices will prefer the interpreted code. But to play a game, they’re equivalent problems.
Interpreted code vs compiled code is a long-standing argument. There are obviously reasons for every case, and IF has traditionally come down on the compiled side. A new system could go the other way, though.
I think you’re running into circular logic.
What does it even mean to say that EPUB readers vanish? If you can unzip the files and display HTML in a browser, you have an EPUB reader. HTML is also a computer language, albeit a simple and relatively transparent one.
A JAR file is a well-specified package format containing metadata and compiled Java binaries, which must be executed with a Java interpreter. A Blorb file is a well-specified package format containing metadata and a Zcode/Glulx binary, which must be executed with a Zcode/Glulx interpreter. This is not a coincidence – I was thinking of JAR when I proposed this stuff.
Exactly what happened with TADS 1 interpreters. If those games would have been “HTMLs” (you know what I mean), we could have played them in “Browsers” even though we wouldn’t be able to read the “META-INF”. Do you see what I am trying to say now?
And I will like to propose a deuce as I don’t think any meaningful result will come out of this post-war we’re having. I’ll go ahead and try to create a faster, easier and better format. If I succeed, I’ll report it. Otherwise, it’s ‘All Hail The Z-code’ anyway.
On a sidenote, if I get in a problem related to it, can I PM you for a possible solution? (I guess it’s polite to ask)
Undoubtedly true. 
Please do! All our IF progress in the past 20 years – last 35 years, really – is from people building things.
However, I’d rather you post questions publicly rather than sending me email or private messages. Sometimes I’m more busy, sometimes less. And there are many folks on the forum with experience in IF systems. Better you get a range of opinions.
Many people believe that the solution to the archaeologist problem is to make sure that there are interpreters written in Javascript, because if any format is preserved it will be that one. So that’s one big reason for Parchment as well as JSMESS.
On compiled vs non-compiled languages:
These days, if you can build a sufficiently powerful JIT, the difference has closed almost completely. One new development in JS-land is asm.js, a subset of JS which can be JITted very effectively because it doesn’t dynamically allocated any memory and it’s typesafe. It is used as a backend for LLVM, and compressed asm.js source code can even end up smaller than a compiled binary. Many people have asked the asm.js team to use a binary format, but they don’t want to, and I think their reasons make sense.
The disadvantage to that approach for the IF community is that building powerful JITs is hard. Noone has got anywhere near that level of complexity yet! (I’m thinking of relooping etc.)
asm.js is a very low level language. Inform 6 is fairly low level too, in the sense that a lot of its structures are very simply mapped to opcodes, but the Inform compiler is still very complicated. There are a lot of edge cases. Also, the Z-code format includes the object table, dictionaries and more. While none of that couldn’t be represented purely in a source code language, I think it is wise to have them in a binary format. If I were to pick an interpreted language to base a new IF system on I’d probably pick Lua. Lua plus a standard set of IO bindings could be a very powerful IF system - but I don’t think the interest is there.
As Zarf said, the biggest advantage of compilation is that the source code languages can be updated without worrying about needing to update interpreters. Inform 6 has object classes which is a feature the Z-Machine doesn’t know anything about. Inform 7 has regular expressions. Despite our best efforts many IF interpreters (especially bundled ones) are out of date. Using compiled story files means all the new stories can be played on quite old interpreters and usually the only downside is they might be slower than ideal.
JIT will be too complicated for a lone poor soul that is me to create, although thanks for suggestion.
Well, that’s assuming that the archaeologist is familiar with the ASCII encoding. But, since most modern games would be encoded with UTF-8, the task would be even more complicated for him/her. In the end, both the compiled game and the text file will effectively look the same.
Regarding building a JIT compiler, this can make things a bit easier, but yeah, it’s still a large task.
Hey, if you want to participate in writing some IF-related free software in Python, I could use some help with Grotesque. I haven’t had time for the past two years to work on it and there is really a lot to do to bring it up-to-date (fixing some stupid, deep design decisions). Now that I’ve finished my PhD, I’m hoping to get back to hacking on it. Feel free to contact me if you’re interested.