Design Patterns for implementing IF?
Marnix Klooster
Hello,
Some time ago I started to learn object-oriented analysis,
design, and programming. Fortunately, only a week or so later
someone pointed me to "Design Patterns" by Gamma et al. 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:
* architecture patterns -- How do I structure my work of IF?
This relates to questions like: How do I cope with non-linearity
and/or multiple endings? How can score be assigned? Example:
The Independent Regions pattern describes what the key decisions
are that have to be taken after you decide that your game has
multiple independent regions that the player can work on one at a
time.
* design patterns -- How do I design a certain puzzle or
feature? Example: The Two-way Transporter pattern describes how
to have two-way doors and such; the Modify State On Undo says how
to avoid a brute-force solution to a puzzle by manipulating the
game state on Undo.
* coding patterns (or idioms) -- How can I implement a certain
feature in a specific language? Example (for Inform): The
Multiple Copies pattern describes how I can have as many napkins
as the player would like.
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 Jim Coplien 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 30
plots!).
Am I just rambling here? Trying to solve a non-nail problem
with this new hammer I found?
Groetjes,
<><
Marnix
--
Marnix Klooster | If you reply to this post,
mar...@worldonline.nl | please send me an e-mail copy.
Stephen van Egmond
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 www.truespectra.com/~svanegmo, based on r.a.i-f discussions and
some of XYZZYnews' articles) and there's every reason to expect them to
occur on the coding side as wel
In fact, many of the storytelling techniques can lead to patterns in the
technical design of the game: a segmented game, for instance. Graham?
Professor Moriarty?
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.
Lucian Paul Smith
Marnix Klooster (mar...@worldonline.nl) wrote:
: (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.)
Wow! I like it! I like the concepts discussed here. For those of you
who don't want to fight with their search engine, you can find this page at:
http://st-www.cs.uiuc.edu/users/patterns/patterns.html
From there, I found my way to:
http://www.enteract.com/~bradapp/docs/patterns-intro.html
which was an excellent introduction to patterns.
: 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?
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 thoght 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,...
-Lucian "Lucian" Smith
Marnix Klooster
If you have ideas about IF Patterns, feel free to add them to its page
in the WikiWikiWeb at
http://c2.com/cgi-bin/wiki?InteractiveFictionPatterns
If you never used the WikiWikiWeb before, first go to
http://c2.com/cgi-bin/wiki?FrontPage
and be sure to read WelcomeVisitors, MoreAboutMechanics,
TextFormattingRules, and GoodStyle before adding any text.
Groetjes,
<><
Marnix
--
Marnix Klooster | If you post a reply to a
mklo...@research.baan.nl | News article of mine, please
mar...@worldonline.nl | send me a copy by e-mail.
Andrew Plotkin
Lucian Paul Smith (lps...@rice.edu) wrote:
> Wow! I like it! I like the concepts discussed here. For those of you
> who don't want to fight with their search engine, you can find this page at:
> http://st-www.cs.uiuc.edu/users/patterns/patterns.html
> From there, I found my way to:
> http://www.enteract.com/~bradapp/docs/patterns-intro.html
> which was an excellent introduction to patterns.
I've never taken the time to look at this "pattern" thing before today --
not with respect to software. But, weirdly, I own copies of _A Pattern
Language: Towns, Buildings, Construction_ and _The Timeless Way of
Building_ (discussion of patterns in architecture and city planning.) I
haven't gotten to _TWoB_ yet, but _PL_ is stunningly coherent and
interesting.
> : 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?
> 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 thoght 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. :)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."