For someone wanting to learn modern methods of creating a parser based text adventure without needing to learn a new programming language at the same time, would ADRIFT or Quest be a better fit?
I’m leaning towards ADRIFT, as it has a visual tool for adding locations, but other than that they seem fairly similar from the descriptions on their respective websites and what little I have read of the online manuals.
Does anyone who has used both have any advice for choosing one over the other?
I would not recommend Quest right now.
There’s some problems playing its games online, and also, it is an “only Windows” system, so in the end, the only proper way to play its games is via download. That reduces a lot the scope and potential for reach an audience.
You know, there are other systems, and building some basic text adventures are easy in all of them. I would shoot for Inform 7.
I’ve not tried to create games with Quest myself but I have used ADRIFT for a number of years and have been reasonably successful. One of its strengths is that you can create a reasonable game without the need to use any code. But if you want to, in the words of another ADRIFT stalwart, you can get into “rocket science” or clever coding. But you do not need to. It has built in mapping, is easy to find your way around and has a GUI developer. It talks about locations, objects, characters and tasks so is easy to understand. And in the latest version, V5, you can group things together in folders. So, for example everything relating to a location could be put into one folder if you wanted to.
The latest version has fixed a number of the old issues particularly with the parser but its development has stalled a little over the last few years. It is possible to play V5 games online if you post them on the main ADRIFT site but the server that runs them is very unreliable. I’ve not tried the non-windows runner myself but I known people have had issues.
I would personally go for Quest. Both Quest and Adrift have issues with Mac compatibility, but textadventures.co.uk seems to have more traffic on the site and more opportunity to get assistance. I’ve also seen what might be a “beta” (?) of Quest 6 which is all JS in the browser. That might be just a community project though.
Yes, it is a shame that both systems were written in .NET languages and are therefore not very cross-platform, but as I would be using them for learning purposes on a Windows system that isn’t a huge drawback.
It is likely that I will switch to a code based system once I have learned how all the different parts of a game fit together, as I have used a few different programming languages in the past. I’d rather keep the number of new things I need to learn at once to a minimum to start with though.
From what I can gather, it is possible to modify the underlying code for your adventures on both systems, and the program source code is also available (although I’ve never coded in a .NET language).
I believe both Quest and Adrift have their own scripting languages to get under the hood, so you may not need to go to complete bare metal to accomplish things they don’t do. Quest even has “plugins” people have written similar to Inform extensions to accomplish certain tasks like combat.
Yes, both manuals mention using an underlying XML code for each adventure, although it seems to be slightly harder to access that directly in ADRIFT.
Again, XML isn’t something I’ve used, but I have some experience with HTML and SGML.
You could export your creation from ADRIFT (which I guess might be in XML format) and then you could reimport it. Not sure what advantage it would give you though. It doesn’t have a coding language with in it though, the idea is you do everything in the developer.
If you are keen to get your hands dirty and learn code I would go for Inform 7. I’m a non-coder and found it pretty easy to pick up.
Being able to reuse objects, verbs and/or locations could be helpful, as would being able to see more of what is happening behind the graphical interface.
I may want to move on to a code based system once I’ve learned the basics, or I may attempt to create my own, depending on how I get on with the simpler tools.
I have played a bit with Quest but I normally use ADRIFT. As Rotter said ADRIFT does not have a scripting language, so Quest may be more powerful once you learn the scripting language. On the other hand, it is my impression that many of the things you can do in ADRIFT would require scripting in Quest. ADRIFT users can also make modules to each other. For instance, there is a combat module, a money module and a time module which can be imported into your own game.
First of all, there is no system for writing a game which does not require you, at some level, to think like a programmer. The “intelligent” responses of any game are, after all, being simulated by an idiot tin box with zero intelligence. You have to supply that lack, and have to supply it in a logical fashion, so that the responses will be logical. Furthermore, you have to do so in a pernickety detail-obsessive fashion, in order to communicate with said Idiot Tin Box. This style of thinking is the essence of coding, regardless of what language is being used, because until we have full Turing machines, this is the essential problem of interacting with them.
The deep-level problem with ADRIFT is that it doesn’t use the verb + object system. Each command in each room is a separate, unique thing. While this makes it easier to begin a game in ADRIFT, it makes it much harder to make a decent, reasonably playable game, and very easy to make a lousy, unplayable one.
For example, imagine a game: “Farm fries.”
The player has to make some french fries. As humans, we can immediately imagine the necessary situation, but the tin box can’t. So we have to supply it explicitly:
The player starts in the Farmhouse Kitchen, must go out to the Potato Field, pick a potato, then cut it up (with a knife), and drop the pieces into hot oil in the fryer (which is in the kitchen.)
Someone using a system such as Tads, Hugo, Inform (either 6 or 7), Alan etc., or any language which uses the verb + object system: code two rooms, and five objects: the fryer, the knife, the potato, the potato pieces, and the french fries. She codes the potato to respond to the verb “cut” by first checking that the player holds the knife, and then exchanging itself for the potato pieces object. Similarly, she codes the fryer to respond to the player putting potato in it by rejecting the whole potato, but exchanging the potato pieces for french fries. While “put pieces in fryer” would describe the intention, players would be more likely to try “fry potato.” “Fry” is not a standard verb, so she’d have to create it.
The diligent Adrifter also codes two rooms, Farmhouse Kitchen and Potato Field, puts a knife and a fat fryer in the first, and a potato in the second, and has a potato pieces object and a french fries object waiting offstage. He codes a “pick potato” action in Potato Field, and a “fry potato” action in the kitchen. But the “cut potato” action could logically happen in either room, unless the knife is somehow made non-portable. So an Adrifter has to code the “cut potato” action twice. Not much of an additional burden, you’d think. Particularly given that the verb + object system required a whole new verb, which Adrift doesn’t.
But now comes the hard part: making the game robust, and pleasant to play. The author has to think of all the different commands a player might use: “cut potato”, “chop spud”, “slice vegetable” blah blah, to avoid the player having to guess the author’s exact vocabulary, and it’s here that verb+object shines. The language’s structure naturally gathers synonyms for an object into one place, and synonyms for a verb into one place, so it’s easier to correct an oversight.
Now the downside of Adrift’s simplicity comes into effect: you must code all of those synonyms into each action in each room. Trivial in a two room game. In a larger game it’s very easy to think of a synonym, add it to the actions in all the obvious rooms, but forget a few un-obvious ones – and so bugs creep in.
If we now wanted to add another room, say Dining Room, the Adrift coder has to remember to write a “cut potato” action in there, too, whereas someone using any of the verb+object rules doesn’t even need to consider it: the system automatically takes care of the issue of potato cutting everywhere in the game. The larger a game becomes, the more significant this advantage becomes.
To be fair to Adrift, the various versions have tried to address this problem, but it’s a fundamental weakness of the language, and so will always be there to some extent.
I’d say that Adrift’s greatest advantage over other languages was its friendly interface, which hides the fact that you are doing coding by building the language’s logic into it. I still think that if you want to write menu-style conversations it’s very good indeed, letting you concentrate on what the NPC is saying rather than distracting you with all the logical nuts and bolts of needing to tell the Tin Box what to print out next, and that “some french fries” is plural.
Overall though, I’d say that the initial simplicity of Adrift is not worth sacrificing the long-term advantages of a (slightly) more complex language doing a lot of the heavy lifting for you.
For example, here’s the “game” I’ve just described, in Inform 7 code:
"Farmhouse Fries" by "Example"
[Text in square brackets like this, are comments.]
The Farmhouse Kitchen is a room. "Cream painted walls, and a ceiling of heavy oak beams. Against one wall, your new TatoFri 3000 gleams, giving off the scent of hot fat. The door to the east is open, giving you a pleasant view of the potato fields."
The deep fat fryer is scenery in the farmhouse kitchen. The description of the deep fat fryer is "The fat seethes and bubbles, already hot." Understand "hot", "TatoFri" or "3000" as the deep fat fryer. ["deep" "fat" and "fryer" are automatically recognised as synonyms, so we don't need to add them using Understand. Stating that something is "scenery" means it doesn't get described in the room description, and is fixed in place by default.]
A knife is in the Farmhouse kitchen. Understand "kitchen knife" or "blade" as the knife.
The Potato Fields is east of the Farmhouse Kitchen. "Bare hummocked earth, where, before the harvest, many potato plants grew. A rambling farmhouse is to the west."
A thing called a potato is in the Potato Fields.
Instead of cutting the potato:
if the player is not carrying the knife:
say "You've nothing to cut the potato up with.";
otherwise:
now the player carries some raw potato pieces;
remove the potato from play;
say "You cut the potato into pieces.";
Some raw potato pieces are nowhere.
Some french fries are nowhere. Some french fries are edible.
[Cutting is a standard verb, so we didn't need to add it. But "frying" is not something that's natively understood, so we have to create it.]
Frying is an action applying to one touchable thing. Understand "fry [something]" as frying.
Check frying something: [This is the general response.]
say "Frying [the noun] would achieve little.";
stop the action.
Check frying the potato:
say "You can't fry a whole potato: it would still be raw in the middle." instead.
["instead" is a keyword, meaning "stop the action". As you can see, it's more convenient.]
Check frying some raw potato pieces when the player cannot see the deep fat fryer:
say "The deep fat fryer isn't here." instead;
[we could check if the player is in the kitchen, but if we later made the fryer portable we'd then need to edit this check condition.]
Check frying some raw potato pieces:
now the player carries some french fries;
remove the raw potato pieces from play;
say "You toss the uninspiring pieces of raw potato into the seething hot fat. Mastering your impatience, you wait until they've cooked, and then, using a metal spoon, fish out the french fries." instead;
[I know it looks weird putting the game mechanics of frying in the check action: this is because "Frying" is a dummy action and doesn't have separate Carry Out and Report stages. It's not worth creating them when we're only going to allow one object in the entire game to be fried. We could write it as an instead rule -- "instead of frying some raw potato pieces:" followed by the same clauses underneath.]
[okay, it's not a full game unless the player can win it, so:]
Instead of eating the french fries:
end the story saying "Congratulations! You are now entitled to wear the traditional cardboard crown of the French Fry Chef!"
[code ends here]
If you download the current I7 package for either Windows, Mac or Linux, and paste the code above into the “Source” pane, it will compile into a playable game. Of course the package comes with a bunch of well written documentation, but even without that, simply looking at the code above, you can see what each bit of the code does: it’s pretty readable.
But although it looks like English, it’s really a specialised dialect: “Inform 7 English,” if you like. There are some subtle pitfalls: notice for example that “The Potato Fields is east of…” not “are east of…” because “Potato Fields” is a single object of the kind “room”. This goes back to what I was saying at the beginning of the post: there is no system for creating IF where you aren’t programming at some level.
Blush Just realized that the original game as specified would allow the player to fry the potato pieces by putting them in the fryer. However, that’s easily fixed. Add two new instead rules to redirect the behaviour:
Instead of inserting the potato into the deep fat fryer, try frying the potato instead.
Instead of inserting some raw potato pieces into the deep fat fryer, try frying some raw potato pieces instead.
Actually, because Discus has stripped out the tabs, you’ll have to manually reinsert them for each of the rules, dammit. I7, like Python, uses indentation to mark code logic blocks. So, for example:
Instead of cutting the potato:
[TAB]if the player is not carrying the knife:
[TAB][TAB]say “You’ve nothing to cut the potato up with.”;
[TAB]otherwise:
[TAB][TAB] now the player carries some raw potato pieces;
[TAB][TAB] remove the potato from play;
[TAB][TAB] say “You cut the potato into pieces.”;
Check out V5. You will find that you can still make a “Specific Task” that way if you want but you can also make “General Tasks”. So, in your fry example you would create a “FRY OBJECT” General Task containing any synonyms, checks you are carrying something which can be fried and any other logic you need for frying things. Then you can call this FRY OBJECT General Task with a Specific Tasks e.g. FRY POTATO, FRY BACON etc to fry anything you like (which can be run anywhere you choose). Each Specific Task only needs to include logic for the particular usage. But because you have the General Tasks, the game will understand if the player tries to fry his wallet. You can add a suitable, “It is not possible to fry the %object%” as a restriction in the General Task.
I know Adrifters have worked hard to overcome the limitation that I perhaps spent too long describing, but it remains a workaround for something that’s not inherent in the structure of the model world. Unfortunately I7 isn’t a good exemplar, since it seems to have abandoned the Infocom world model. (I thought I7 ran on top of I6 code, but may have been mistaken: I’m half way through reading Graham Nelson’s lecture ATM.) But TADS and Hugo still use containment and logical objects, for sure.
First of all, there is no system for writing a game which does not require you, at some level, to think like a programmer.
I agree. Still some systems are easier to learn than others.
But the “cut potato” action could logically happen in either room, unless the knife is somehow made non-portable. So an Adrifter has to code the “cut potato” action twice.
This is not correct. You only have to code it once. Then it works in all locations. (Note: I have only used ADRIFT 5, not earlier versions)
Sure, you can have a bad parser in ADRIFT if you don’t follow “Best Practice”. There certainly are ADRIFT games made with bad parsers because they are not aware of “Best Practice”. So that is one drawback of ADRIFT: You are not warned if you are doing something which reduces the quality of the parser. But it would take only 5 minutes to explain “Best Practice” to a new ADRIFT user and then the game will have a very fine parser.
Can’t get Adrift to run on my Linux box (and my windows install has temporarily committed hari-kiri) so I’ll shut up.
I should probably mention that I have experience with various programming languages, but not any adventure specific versions, nor any of the languages that the ADRIFT, ALAN, Hugo, Inform or TADS editors and compilers are written in.
I did write a text adventure from scratch on an obscure 8-bit home computer in BASIC more than a few years ago, but I doubt that will help much.
My first objective is to learn how all the different pieces of a game are put together and then to learn what the underlying code looks like. It seems to me that a GUI based editor would be better for this, as the code is hidden until you seek it out.
I took the liberty of editing the code tags in for you! You can put ``` before and after your code blocks, or highlight it and hit the </> button.
Now the indentation is preserved, and you can hit the “copy code” button to copy the code, with proper indentation.
Thanks Matt!
The reason I went to the trouble of writing that example was so that someone uncomfortable with “standard code wrangling” could see how I7 code would look.
While I’m at it, I’d like to add that my remarks were not intended to be “Adrift bashing.” People have dissed the system before, and Adrifters are (understandably) fed up with that kind of thing. Systems don’t produce bad games, bad habits do.
Well, the early part of designing a game is pretty system-agnostic: paper and pencil is actually the best way to think it through and work out how the story is going to lead naturally into certain puzzles, and what those puzzles are going to involve.
If you already know some programming languages, (and especially if you’ve done any Object Oriented Programming) then you’ve got a head start, and will be able to pick up any IF language pretty quickly. You won’t be worried by a “ragged” left margin that seems to bounce in and out without rhyme or reason, or by brackets (within brackets (within further brackets)) or what “strings” are, or how finicky compilers are about syntax – these are the sort of issues that “beginner friendly” languages try to help their users with.
Roger Firth has a website with source code for a simple game “Cloak of Darkness” written out for various systems, so you can compare them:
http://www.firthworks.com/roger/cloak/index.html
Beware though, that this site is fairly old.