Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
In this Discussion
New directions in TADS 3: how to enrich user-text communication in text adventures (Code Critique)
I would like to introduce a code I found on a forum - it allows text adventure authors working with TADS 3 to implement new directions. Basically speaking, it allows us to enrich the input language and thus make the user-text communication in TADS adventures more complex.
Author: Pacian (Great Britain)
Language: TADS
Year: 2007
I've been thinking a lot about how imperative and function-oriented the input language of interactive fiction seems to be. Why don't we broaden it to the extent that writing whole pieces of an IF text could be user's commands?
IF is concentrated on actions and pragmatics - which is a paradox, since it's a very descriptive literature and utterly descriptive games. I believe IF doesn't have to be narrative and action-based, and the presented code gives us a tool to make the language of user's commands unlimited. In fact, it could level with the output language of descriptions and narrative that might change relations between author and wreader dramatically - or even reverse.
I believe constant addition of new commands makes role a wreader significantly more complex and contribute more correlation between the playing instances. Can readers become true co-authors of textual adventures?
The code itself:
//A new direction object
forwardDirection: Direction
name = 'forward'
dirProp = &forward
//an integer to sort this direction
//relative to other directions
//we'd give 'backwards' greater than 8000
//for example, so 'forwards' is always listed
//before it
sortingOrder = 8000
;
//the grammar rule for this direction object
//type 'forward' or 'f'
//to try and head in this direction
//(more synonyms preferable)
grammar directionName: 'forward' | 'f' : DirectionProd
dir = forwardDirection
;
/*
* According to actions.t:
*
* "To make it more convenient to use
* directional travel actions as
* synthesized commands, [we] define a set of
* action classes for the specific
* directions."
*/
DefineAction(Forward, TravelAction)
getDirection = forwardDirection
;
//kill the old 'forward' command.
//The only useful piece of code I found in
//"Relative Direction System for TADS 3" by
//Michael J. Roberts
//(It has been modified)
replace grammar directionName(fore): ' ': DirectionProd ;
Comments
Thanks so much for this example.
Could you link to the source of this code so that we could see the context? Also, is that code truly TADS -- not TADS2 or TADS3? For those not familiar, it might be nice to explain the most minimal way in which something like this could be run -- if I went to TADS downloads what would I install, and where would I add this code?
I'm trying to be sure I'm clear on what you are saying the code does, and what potential you are interested in. This code adds a new recognizable user input keyword, "forward", yes? And are you are suggesting following in the model of this snippet and adding many, many more keywords that TADS / a TADS IF could recognize as a way of expanding the role of the wreader?
I believe it's TADS 3, actually:
http://spacecatrocketship.blogspot.com/2007/09/implementing-new-directions-in-tads-3.html
This code is to be posted in the main source file (the project itself) where all other work with the text is done, I just put it in the end of the page and it works just fine.
So, you just need to install TADS 3 Author's Kit, and start a new project where you can apply this code with any input commands you'd like to see in the piece. Here "forward" is a new recognizable command, correct, and adding more and more keywords this way might not only expand the IF piece vocabulary, but also enhance the wreader's role in building a story, yes.
It is a study in contrasts when the input
returns the output
IF input parsing is usually focused on action/pragmatics. IF output generation is usually focused on compositing rich description. The two things -- the text the player generates about the world that is handled, and the text that the game generates about the world -- are written in different registers for different audiences.
"Forward" is an interesting example. Once that is recognizable an author would probably only have to implement it once for every single room / space / situation / orientation in a work. 1 x situations. But many things, like "ignite" or "soak" or "fold" or "stack" are combinatoric, and need to be considered at the potential intersection of all addressable objects in the game. The problem is not how many code hooks the game can have, but how many inputs can be anticipated and handled correctly, generating a response. This leads to the combinatorial explosion problem in the design of IF (and Adventure Games)... which I know from the interactive writing and game development literature, but which also now has its own TVTropes page). It also might be worth checking out Stephen Granade's "The Evolution of Short Works" from The IF Theory Reader, which isn't about the explosion per se, but does consider the historical rise of more tightly circumscribed works in the mid-1990s -- he also later wrote "Watson Isn’t The Future Of The Interactive Fiction Parser" to argue against the comprehensive interface concept. On the expansionist side, (although for state, not interface) Andrew Stern once had a paper "Embracing the Combinatorial Explosion"
For a code critique, I wonder if it might make sense to look at one or more works in TADS that have either extremely large or extremely small vocabularies, and come at your problem in that way. I'm more familiar with classic examples in other IF languages -- such as Aisle or Savoir Faire, which are two very different approaches to maximizing the handling of diverse inputs.
Thank you! These are very essential references indeed.
I would say we're dealing with a larger issue of polysemy here - natural language has done great job in terms of developing as many meanings as possible out of minimal vocabulary resources. Semiotics also contributed to it, stating that a sign might be always determined by usage and never refer to anything out of context. IF poses this problem clearly and explicitly - we should be capable of fulfilling semantic redundancy as well - if we want to establish a stable contact between input and output.
As I see it, this is being partly undertaken in IF, example - very limited room reference in IF, when room is separated from objects by the ineffectiveness of referring to it. If we treat rooms as objects semantically, we might - to a certain extent - draw a line between the features of certain objects. That's just an example, of course.
Another problem is the clear distinction between what input and output actually do, but it's more of a design problem, maybe. Description and action first and foremost differ syntactically (long and coherent on one side and succinct, disruptive on the other), both, however, rather represent the scene than describe or enable it. In a textual experience, difference between what is seen and what is done is hardly as perceptible as in a visual one, and we could benefit from it, since we are able to make agencies exchange roles basically all the time.
I'll be studying more TADS (and other IF) pieces with various vocabularies to see how flexible those might be in terms of creating new IF experiences. My interests include going beyond narration in IF, shifting from narrative to more plotless texts with blurred boundaries between modalities and works that put more stress on other language functions apart from pragmatics.