Has anyone done a detailed comparison of the different parser-based authoring systems available?
I don’t just mean which platforms they are available on or how easy they are to use, but rather how they work and how practical it would be to port a game written in one system to another.
I’m guessing there is at least some similarity, as Trizbort can export location data to several systems.
Take a look at http://www.firthworks.com/roger/cloak/ .
There’s a lot of similarity, because they were basically all created with the same design goal: “I want to make games like Infocom makes.”
Thanks, but I was hoping for a more detailed comparison which is also less complex than David Welbourn’s Code Compare.
I would like to be able to easily find out whether a feature such as typing “go building” (for example) is supported and whether that is as standard or requires a custom library.
But GO BUILDING is already much more specific than any of the things in Code Compare. If you’re asking for something that specific (and comparatively uncommonly implemented), then there must be thousands of other features that would have to be compared, as well. Realistically speaking, what you’re probably going to need to do is to identify which features are important to the piece you’re designing, then do a Google search for “GO BUILDING Inform 7,” “GO BUILDING in TADS,” etc., and repeat that for each feature.
Parser-based IF has a huge possibility space, and there are many many many things that have been executed in various IF-specific languages at or above the level of the feature you’re imagining you want to compare. I do not believe that anyone has exhaustively compared all of them, even at the level of granularity that GO BUILDING implies. There are just too many things that would have to be compared, and too many systems that would have to be included in the comparison.
On the other hand, if what you’re really wondering is “which IF language should I learn in order to implement this game I’m thinking of?,” and trying to identify features of your intended game in advance that will help you make a productive decision there–then the standard answer is that the major development systems are about a wash for most people writing most types of games. Whichever system you pick will likely have some things that are somewhat easier in that development system, compared to other major options, and some things that would have been easier in other development systems will be a little more difficult. It tends to even out. There is no system that makes everything much much easier without involving some kind of trade-off; if there were, people would more or less all be using that system. That’s not to say that you might not happen to be writing a piece where it just so happens that many things might be easier in one language or another; just that “which computer language should I learn to do X?” is a subjective, complex question that’s is hard to answer without knowing the possible languages involved. It’s a specific case of the general “How do I know how to learn to do X without already knowing how to do X?” problem, which rarely has a neat solution.
But there are some Inform v. TADS comparisons out there that talk about the generalities of both languages, and the best way forward, if you’re wondering which language to learn, is to skim through some of those, use them to make the best choice possible, and then start learning one of them. If you find yourself yearning for features you heard about in the other language once you’ve started, you can always jump ship and go elsewhere.
EDIT. I meant to say more explicitly earlier that there are SOME problems that ARE clearly handled better by one system or another, or for which there are extensions or libraries or what-have-you for various development systems, and some libraries or extensions can of course be better than others. That is to say, if you’re doing a whole lot of something that falls into one of these categories, then it might be worth while to do a bit of research and see whether there’s a clear winner. So, for instance, liquid-mixing is a classic example of such a problem, which gets very complicated very quickly if you want to do anything more than the absolute basics: any development system you might consider will let you have a cup that’s full of coffee, but working in a chemistry (or alchemical) lab where the game needs to predict (say) the resulting color of a potion mixed from six different things in unequal proportions, and needing to be able to get it right, might in itself be a good reason to lean towards learning Inform 7: you can use some of Emily Short’s work on liquid-mixing. Or if your whole piece involves rock-climbing and you need a detailed, realistic implementation of a rope, you might want to look at Linus Åkesson’s emerging language Dialog, which is supposed to make these things much easier (though I have, alas, not yet poked at it and am therefore repeating gossip). Or, if you’re going to be writing a conversation-heavy game, you might want to look around at the conversation libraries available for various languages and pick a language based on which conversation library works in a way that makes sense to you. Fire is another classic examples of things that are very difficult to implement realistically once you go beyond very basic implementations, and if you’re looking for a realistic implementation of burning things, and your game works heavily with this, you might want to look around at what’s involved in simulating a realistic conflagration and how this has been done in various languages.
EDIT to edit the edit. Sigh.
By “go building” I actually meant “go (to a named nearby) location” as in “go kitchen” or “go cave”, with the “go” part being optional.
Colossal Cave Adventure had this feature, as did a number of 8-bit text adventures from the 80s. I don’t remember which specific ones though, unfortunately. “In” and “out” were also often understood as valid directions.
I’m not sure whether this feature would be called “non-compass directions” or “locations as directions”, but all I was hoping for was a table listing features with each being marked as having full, partial or no support for each language.
I would imagine this would take less time to create than Code Compare, as that includes specific code examples for each feature.
The reason I wanted a comparison of languages/systems was that I was thinking of porting Colossal Cave Adventure (and possibly other games) to several of them. I also wanted to find out what features were common across all the systems, to make it easier to design my own games in multiple (IF) languages.
ZILF (ZIL) absolutely does allow that, and it’s easily coded up.
I’ve never used Inform but my guess is that this also will allow that to be coded quite easily.
It’s easily coded in I7, and with only slightly more difficulty in I6. I’m pretty sure it’s similarly easy in Dialog, though I’d need to refresh my memory on how exactly scope-checking works there. Likewise in ZIL (as Adam mentions).
(It’s even possible in ScottKit (or any other system that makes Scott Adams files), but porting Colossal Cave to that would be somewhere between “Sisyphean” and “mathematically impossible”. I wouldn’t recommend that format for anything except historical curiosity.)
In the end, all the major parser authoring systems can support everything in Colossal Cave. Capability-wise, their differences tend to lie in more obscure things like “how well can the parser backtrack when the player gives it a garden-path command?” that won’t matter for Colossal Cave-style games. (For this particular example, Dialog copes much better than Inform does, and I don’t know how ZIL handles it.)
The issue is, every system I can think of supports this, and every one requires a bit of programming for it (it’s not a built-in feature of their libraries). The same is true for the vast majority of IF features.
The fact that Colossal Cave does this (typing the name of a room) means that it’s a traditional exercise in parser customization. The I6 manual mentions the idea here: http://www.inform-fiction.org/manual/html/s30.html
In the I7 manual, it’s example 306, “Misadventure”: http://inform7.com/book/WI_17_10.html#e89
Does anyone know if ADRIFT or Quest support using location names as directions?
I’m guessing that they would be an easier option for learning how text adventures are constructed, but both have a visual map for editing locations and exits.
In ADRIFT if you click on the building on the map then it will automatically calculate the shortest route to get there and move you through each of the locations in between, describing what you see as you pass through them on the way to the building.
It would also be very easy to add a “go location” command that jumps you straight there, perhaps limiting it to adjacent locations or locations in the same region.
Zombie thread says “braaaaaains!”
If you’re looking for something pre-baked, there’s also the Approaches by Emily Short extension.