Interactive Fiction Patterns Thread

This page contains (parts of) postings from a thread on news:rec.arts.in-fiction, about the use of InteractiveFictionPatterns for creating InteractiveFiction. They have been edited slightly for clarity.


MarnixKlooster posted on 8 May 1997 to news:rec.arts.int-fiction, slightly edited...

Some time ago I started to learn object-oriented analysis, design, and programming. Fortunately, only a week or so later someone pointed me to "DesignPatterns" by Gamma et al. (the GangOfFour). For the uninitiated, this book describes solutions for recurring design problems in object-oriented systems. This book turns out to be very useful for any OO developer, because it presents a lot of design experience in a very structured and practically applicable way. (For more information on patterns in software engineering and in general, aim your favourite Web search engine at "Patterns Home Page" and fire -- there is also a patterns mailing list, and perhaps even a newsgroup.)

Then, this morning, I woke up with this thought: would it perhaps be possible and useful to write down a set of patterns for IF authors? At first glance the following commonly-made distinction seems to make sense:

Note that many IF patterns are language independent, and I expect many to work for non-OO IF languages too.

Do IF patterns limit creativity of IF authors? I don't think so. As JimCoplien wrote: "Just as a dressmaker tailors a pattern to an individual customer, and perhaps to a specific event where the dress is to be worn, so designers must be creative when using patterns. Patterns channel creativity; they neither replace nor constrain it." Good patterns are such that there are many possible implementations. By adopting a pattern the IF author simply reuses a proven solution in a particular context.

If anyone would try his/her hand at this, I suggest beginning with simple patterns such as Two-way Transporter. Other sources of ideas are the XYZZY "Tales from the Coding Front" articles, the recent what-types-of-puzzles-are-there discussions right here, and the several existing guides to writing IF (GKW's 36 plots!).

Am I just rambling here? Trying to solve a non-nail problem with this new hammer I found?


StephenVanEgmond replied that same day (again slightly edited, comments in square brackets)...

This isn't such a a bad notion -- patterns appear everywhere in development. As many have noticed, there are patterns to be found in the fiction side of IF (and I've been trying to capture the really essential ones at http://www.truespectra.com/~svanegmo, based on news:rec.arts.int-fiction discussions and some of XYZZYnews' articles) and there's every reason to expect them to occur on the coding side as well.

In fact, many of the storytelling techniques can lead to patterns in the technical design of the game: a segmented game, for instance. GrahamNelson? Professor Moriarty [BrianMoriarty?]?

Design patterns are inherently observational in their development: people eventually notice that certain patterns recur in their designs and then they write them down. Maybe we need a larger source base to be able to start doing that.


In response to MarnixKlooster's question "Would it perhaps be possible and useful to write down a set of patterns for IF authors?", LucianSmith said:

I heartily agree. Just reading some of the stuff about patterns crystalized some thoughts that have been gestating in my head about scope for some time now. I think they'd be more appropriate for a separate post, so I'll mention them there.

Generally, though, I think that Inform (and, presumably, TADS, though I know nothing about the latter) acts as a kind of 'pattern language'--Graham has thought about the different patterns needed to write a piece of IF so that we don't have to. Rooms, exits, doors, characters, display, etc.

And, to a large extent, I think that the Designer's Manual functions well as a discussion about those patterns. Even though I'm sure Graham didn't have 'patterns', per se, in mind when he wrote it, he conforms to many of the standard sections of a pattern. (from ~bradapp: Name, Problem, Context, Forces, Solution, Examples, Resulting Context, Rationale, Relationships, and Known Uses.)

Question: Could the DM benefit from a careful consideration of these concepts? My inclination is to say no: if it ain't broke, don't fix it. However, perhaps a supplemental document/reference work would be handy. Hmmmm,...

Am I just rambling here? Trying to solve a non-nail problem with this new hammer I found?

I think these concepts are very applicable to IF. The only problem I see is that of the effort it would take to organize such a project. As much as this has fired my imagination, I must say that I know I could never be the driving force behind it. I'd be willing to contribute, though,...


AndrewPlotkin? (a.k.a. Zarf) adds:

Generally, though, I think that Inform (and, presumably, TADS, though I know nothing about the latter) acts as a kind of 'pattern language'--Graham has thought about the different patterns needed to write a piece of IF so that we don't have to. Rooms, exits, doors, characters, display, etc.

This is definitely true. There are also design patterns -- recall my post a few days ago about ways to design puzzles which might be solved by brute force.

My only reservation is that we must be careful that nobody views an IF pattern catalog as complete. We're constantly coming up with new ways to do things, each of which (after a few attempts and variations) can be written down as a pattern. One of the purposes of "The Space Under the Window" was to demonstrate how far we from knowing all the possible IF patterns. :)
CategoryIntFic
EditText of this page (last edited May 28, 1997)
FindPage by searching (or browse LikePages or take a VisualTour)