[General] Turning vague ideas into IF
Vivienne Dunstan
I wonder if people who've written IF games might be willing to share
their tips for converting initial ideas into viable games? I've read the
Craft of Adventure etc., but such guides typically describe authorship
at a more abstract level like which types of puzzles are best. Even the
most relevant guides take as their premise the presence of an idea
that's already fairly fully formed, like Gareth Rees' XYZZY article
"Distinguishing Between Game Design and Analysis: One View". Similarly
Whizzard's Guide throws up dozens of ideas for plots but then glosses a
bit over how the crucial idea is handled/developed: "late at night, or
early in the morning, an idea will hit you" and the advice "write it
down quick, or you'll lose it forever"! That's the first germ of an idea
certainly, but how does the author effectively develop it from there?
How do IF authors go about this? Do you use brainstorming, or scribbling
ideas on paper or in a notebook? Or type up ideas that occur to you? Or
read widely and ponder an idea until you're ready to code? And in what
ways does the coding interact with this initial design stage? Do you
consider ideas in terms of what you know you can code (or might be able
to) or do you design more freely? Does the subsequent coding stage feed
back into the design, throwing up new ideas etc? And does the
development of an IF idea->game become easier with each new game?
Any comments would be welcome. I've had a work in progress for years but
had to put it on the back burner for various reasons. It involves a very
complex story that I'm still working out the best way to tackle (it
would be hard enough for me to write well as conventional fiction, never
mind interactive too!). As an alternative I'm now planning a much
simpler IF game as a first try (in conventional IF: I've coded in MUDs
before). But while I'm working out that idea (before hitting the Inform
coding properly) I'd be interested to hear other people's approaches.
Viv Dunstan
Rexx Magnus
> How do IF authors go about this? Do you use brainstorming, or scribbling
> ideas on paper or in a notebook?
So far, I've done this to begin with as it's far easier to scribble
something out and connect lines up on paper than it is on computer.
If I need to work out a table of required information, then it goes on
computer because I hate writing by hand. :)
> Or type up ideas that occur to you? Or
> read widely and ponder an idea until you're ready to code? And in what
> ways does the coding interact with this initial design stage?
It goes about as far as working out how many objects I might need
initially, and perhaps how locations might need to marry up.
> Do you
> consider ideas in terms of what you know you can code (or might be able
> to) or do you design more freely?
Never. :)
I've only recently started learning inform, so therefore don't know what's
beyond my abilities. I prefer to start off assuming that I can do anything
that I want, then tone it down if it becomes unmanageable, or I feel
incapable of learning how to do it. I'm learning inform as I find out what
tasks I want to perform with it.
> Does the subsequent coding stage feed
> back into the design, throwing up new ideas etc?
Yes, as above. Usually I find out a different way of doing something that
might be less tedious to the player, or more interactive.
> And does the
> development of an IF idea->game become easier with each new game?
One would assume so, as with every learning experience. :)
To email me, visit the site.
Vivienne Dunstan
> > How do IF authors go about this? Do you use brainstorming, or scribbling
> > ideas on paper or in a notebook?
>
> So far, I've done this to begin with as it's far easier to scribble
> something out and connect lines up on paper than it is on computer. If I
> need to work out a table of required information, then it goes on
> computer because I hate writing by hand. :)
Thanks very much for the reply. I'm the same as you re finding it easier
to scribble notes on paper rather than computer. At the moment I have a
book full of ideas for the big work in progress (the hard-to-write one),
and a growing collection of notes for the newer simpler design.
> > Do you consider ideas in terms of what you know you can code (or might be
> > able to) or do you design more freely?
>
> Never. :) I've only recently started learning inform, so therefore don't
> know what's beyond my abilities. I prefer to start off assuming that I
> can do anything that I want, then tone it down if it becomes
> unmanageable, or I feel incapable of learning how to do it. I'm learning
> inform as I find out what tasks I want to perform with it.
Yes that sounds like me as well. I'm still learning Inform (though I've
programmed in MUDs before, using LPC) so I think I'm going to plan along
the lines of what I'd like to do, then worry about implementing it.
Thanks again for the reply. Does anyone else have comments to add here,
particularly those who've designed more than one IF game before and so
might have adapted their design process by experience over time?
Viv Dunstan
ems...@mindspring.com
> Hi all,
>
> I wonder if people who've written IF games might be willing to share
> their tips for converting initial ideas into viable games? I've read the
> Craft of Adventure etc., but such guides typically describe authorship
> at a more abstract level like which types of puzzles are best. Even the
> most relevant guides take as their premise the presence of an idea
> that's already fairly fully formed, like Gareth Rees' XYZZY article
> "Distinguishing Between Game Design and Analysis: One View". Similarly
> Whizzard's Guide throws up dozens of ideas for plots but then glosses a
> bit over how the crucial idea is handled/developed: "late at night, or
> early in the morning, an idea will hit you" and the advice "write it
> down quick, or you'll lose it forever"! That's the first germ of an idea
> certainly, but how does the author effectively develop it from there?
>
> How do IF authors go about this? Do you use brainstorming, or scribbling
> ideas on paper or in a notebook?
I take a notebook with me most of the time and use it for working up
ideas. Usually it also contains some non-IF notes as well (academic
work, other projects, what I need to buy for dinner, that sort of
thing). That way if I happen to see something interesting at the
bookstore or library that gives me an idea, I can make a note. Once
I've started working on something, I keep thinking about it all the
time in the back of my head, and whenever I run across a setting
detail, bit of imagery, coding concept, or funny-looking character on
the bus that seems to fit into the project, I note it down. I remain
in this mode until the game is in beta-testing: you never know when
you're going to need another touch for the setting here or there, so I
don't assume I'm done just because I've started coding.
But those are ideas in general, not *the* idea at the core of a game.
Usually I start from some concept about what the player's experience
should be like, such as, "the player will talk to NPCs, asking
questions and gathering clues until she solves a mystery; the
conversation will work as a combination of ask/tell and menus in order
to make investigation possible".
This determines how the world will be modeled, what kind of story and
puzzles (if any) naturally arise from that, and how the bits fit
together. All of the setting details, plot events, puzzles, etc., are
incidental, and can be discarded and replaced if they turn out not to
be suitable, but the central idea has to be sound. In static fiction
you might start out by identifying your central conflict and the shape
of the plot, but with IF I find it's hard to develop the plot fully
before I've come up with the model of interaction.
That doesn't mean, of course, that the plot doesn't matter, or that
you shouldn't have a good one, or anything like that; but in my
experience, at least, it's fruitless to come up with a great conflict
and resolution if I have no clue how to involve the player in it. At
best I wind up with IF that's an okay static story that happens to
have prompts interspersed in it; at worst, the results are totally
unplayable. Usually I start writing or coding, then hit a point where
the project has become hopelessly muddled because I'm trying to serve
two masters at once -- the interaction and an unrelated plot -- and
the game feels boring and sluggish because it's unfocused. Then I get
sick of the whole thing and quit working on it I have far more dead
projects on my hard disk than I have released games, and I'd say the
majority of them are victims of insufficient clarity at the concept
phase. Your mileage may vary, of course -- some people apparently
*do* successfully approach IF from that direction.
With the interaction concept in hand, I rough out how I'm going to
code it, and also come up with plot events that work with the
interaction. I think that has actually gotten harder for me, not
easier, as I've written IF. I'm not sure whether this is because I've
chosen more ambitious projects, because I'm losing my grip, because I
ran through all the workable ideas I had and went on to the unworkable
ones, or some combination of the above.
Anyway, once I've got all that, the rest is comparatively easy.
Savoir-Faire was probably the most precisely planned of my IF, in the
sense that I came up with the concept, made a list of all the puzzle
ideas I could think of, arranged them loosely according to complexity
so that the pacing suited me, and then mapped out all the puzzles in a
sort of flowchart. And then I went through and coded them all until I
was done. Even so there were some things I threw out in the eleventh
hour, but it was a fairly directed experience.
Anything I do with conversation tends to be more organic: I may have a
general plot direction in mind and some topics for discussion, but the
content of the conversation itself seems to develop during coding.
Don't know if that helps, but there you have it.
David Whyld
> their tips for converting initial ideas into viable games?
>
I've been meaning for a long time to get more organised with my game
writing but I still tend to come back to the old "have an idea, start
writing" procedure. It's worked for the most part and I've been quite
happy with the games I've written, but a few times recently I've been
halfway through writing a new game and suddenly realised that I don't
have a clue where it's going or how it's going to end.
Vivienne Dunstan
> But those are ideas in general, not *the* idea at the core of a game.
> Usually I start from some concept about what the player's experience
> should be like, such as, "the player will talk to NPCs, asking
> questions and gathering clues until she solves a mystery; the
> conversation will work as a combination of ask/tell and menus in order
> to make investigation possible".
>
> This determines how the world will be modeled, what kind of story and
> puzzles (if any) naturally arise from that, and how the bits fit
> together. All of the setting details, plot events, puzzles, etc., are
That's helpful: thanks very much. I hadn't thought so much before
about starting the design with the primary focus on the player's
interactive experience, and then letting that drive the story/puzzle
creation. Often the advice to beginning IF authors assumes an
existing plot and player interaction is thought about afterwards.
> That doesn't mean, of course, that the plot doesn't matter, or that
> you shouldn't have a good one, or anything like that; but in my
> experience, at least, it's fruitless to come up with a great conflict
> and resolution if I have no clue how to involve the player in it. At
> best I wind up with IF that's an okay static story that happens to
> have prompts interspersed in it; at worst, the results are totally
Again that's a useful observation. As a player I strongly dislike IF
that is basically a static story with prompts in the middle of it, and
I want very much to avoid that in the games that I write.
> Don't know if that helps, but there you have it.
It's very helpful, particularly for sorting out the initial idea into a
proper shape by focussing on the player's experience, and then letting
that define the rest of the game, rather than the other way around.
Thanks again.
Viv Dunstan
Vivienne Dunstan
> writing but I still tend to come back to the old "have an idea, start
> writing" procedure. It's worked for the most part and I've been quite
When you say "writing" here would it be writing out e.g. transcripts of
your planned game, or do you dive into full coding at this very early
stage? Because I'm curious about how best to develop the initial vague
idea (probably a very individual thing, with different people having
different approaches) I wonder what form your writing takes.
> happy with the games I've written, but a few times recently I've been
> halfway through writing a new game and suddenly realised that I don't
> have a clue where it's going or how it's going to end.
Do you think you'll be able to contine those games later with more work,
or are those likely to end up as unfinished games? Is the mix of
writing/design for you a form of quick prototyping which might highlight
which games are going to be viable, and which - like these - are not?
Thanks for the reply.
Viv Dunstan
David Whyld
"Vivienne Dunstan" <viv.d...@one-name.org> wrote in message
news:1gfn7uc.14dpyuf1x0oz72N%viv.d...@one-name.org...
>
> When you say "writing" here would it be writing out e.g. transcripts of
> your planned game, or do you dive into full coding at this very early
> stage? Because I'm curious about how best to develop the initial vague
> idea (probably a very individual thing, with different people having
> different approaches) I wonder what form your writing takes.
>
Well I write games with Adrift so the coding side of things doesn't really
enter into it, but aside from that you've got it pretty much right. I've
never produced a transcript yet or even plotted out more than a very vague
idea of what the game is about. I've drawn maps but that's generally it.
In a way I'd like to be one of those people who plot out *everything*
beforehand and know before they even touch the keyboard to enter their first
character exactly what their finished game is going to be like. But I'm too
impatient. I come up with an idea and the desire to start writing a game
takes over and before I know it I've started. Often it goes well. I started
writing one game on the spur of the moment and it actually won a
competition.
Other times it fails miserably. Recently it's failed miserably more than it
did when I first started writing games. As to whether that's because I'm
suddenly turning into more of a perfectionist I don't know. It's
disheartening to work on a game for weeks or even months and then realise
one day that it's not really much good. But not, I guess, as disheartening
as to carry on and finish the game then have everyone tell you how bad it
is. Better to give up with a bad game only you know about than release it
and have everyone know how bad it is.
>
> Do you think you'll be able to contine those games later with more work,
> or are those likely to end up as unfinished games?
>
I intend to finish every one of them, sooner or later. As to whether I will
or not... well, that's a whole different matter. I've got at least a dozen
games I've started over the course of the past year that I'd like to see
finished one day but when I look at what I've written so far the urge to
actually finish them grows less and less. Some I definitely will finish,
others I want to finish... but probably won't.
> Is the mix of
> writing/design for you a form of quick prototyping which might highlight
> which games are going to be viable, and which - like these - are not?
>
I wish. That might be a decent way to decide which ideas are good and which
are bad: make up a dozen game ideas, write each of them for a few days at a
time and at the end decide which are worth continuing with and which aren't.
All you've wasted is a little time.
A.P. Hill
personae for ideas that seem to come to me at odd times, like waiting
in line behind a fat women who obviously spawned from a yeast
infection or putting gas into my electric golf cart.
I usually keep the ideas that make me laugh out loud, scrap the ones
that produces simple 'heh' s. Coding is done on the spot and ideas
can come from laying out the tracks. Most of my red herrings are
done on the spot, I rarely think up of items like that in advance, for
instance, monkey socks.
I tried to biuld on a simple idea and then let my experience in years
of RPG take over. I've said before that rpg experience can really
help your game creation. Writing skills come from writing alot, if
you don't write alot, you will not do so good, I don't write much, I'm
usually fondueing.
A.P. Hill
a.k.a. Terd Ferguson
J. J. Guest
> ems...@mindspring.com <ems...@mindspring.com> wrote:
> > Don't know if that helps, but there you have it.
>
> It's very helpful, particularly for sorting out the initial idea into a
> proper shape by focussing on the player's experience, and then letting
> that define the rest of the game, rather than the other way around.
Emily's writing on IF is astonishingly insightful and truly
inspirational. I read her reply to your post six times, because she
had brought into perfect clarity a fuzzy notion that had been
lingering around the back of my mind ever since I started writing IF.
Having studied film-making, my way of looking at IF has been to view
puzzles as being equivalent to the "conflicts" faced by the central
character in any ordinary narrative - the player's "solving the
puzzle" should be equivalent to the PC's resolving the conflict;
rather than puzzles being something that interfere with or slow down
the plot, they *are* the plot, or rather *plot points*. A big turning
point in the film "Batman" is where Batman works out the combination
that makes the Joker's beauty products deadly. From that point on,
Batman has the upper hand and it's all downhill for the Joker. How is
this any different to solving a puzzle in IF? Despite this, I was
still trying to work out an "overall story" as an omnipotent narrator
rather than looking at "what the player will experience." All IF
should be written from the viewpoint of the player. It's a subtle yet
crucial shift of emphasis.
You should check out Emily's other stuff, the links are on her website
http://emshort.home.mindspring.com/ I particularly enjoyed her article
for Brass Lantern: "Developing a Setting for Fantastical IF".
Vivienne Dunstan
> You should check out Emily's other stuff, the links are on her website
> http://emshort.home.mindspring.com/ I particularly enjoyed her article
> for Brass Lantern: "Developing a Setting for Fantastical IF".
I've read Emily's writings on IF before and found them very helpful too,
particularly her articles about NPCs and conversation systems.
However her posting here has been most helpful to me, containing a very
simple idea, but one that turns the usual way of looking at IF design on
its head, resulting in a radically different approach to game design.
Thanks very much!
Viv Dunstan
Vivienne Dunstan
> Well I write games with Adrift so the coding side of things doesn't really
> enter into it, but aside from that you've got it pretty much right. I've
> never produced a transcript yet or even plotted out more than a very vague
> idea of what the game is about. I've drawn maps but that's generally it.
I hadn't looked at Adrift before (non Windows user) but reading about it
(following your posting) I see that it is the sort of system where you
could very quickly start building up a game in the way you've described.
> > Is the mix of
> > writing/design for you a form of quick prototyping which might highlight
> > which games are going to be viable, and which - like these - are not?
>
> I wish. That might be a decent way to decide which ideas are good and which
> are bad: make up a dozen game ideas, write each of them for a few days at a
> time and at the end decide which are worth continuing with and which aren't.
> All you've wasted is a little time.
I wasn't thinking of intentional prototyping here so much as the
unintentional sort! If you can start writing games so quickly with this
system then perhaps not-so-good designs will show themselves up in that
way, even if you're not intending to use a formal prototyping approach.
Interesting viewpoint anyway. Thanks very much for the insight.
Viv Dunstan
Vivienne Dunstan
> tried to biuld on a simple idea and then let my experience in years
> of RPG take over. I've said before that rpg experience can really
> help your game creation. Writing skills come from writing alot, if
> you don't write alot, you will not do so good,
Thanks for that tip. I suppose it's like any form of writing: the more
practice you have the better/easier it gets, especially if the game is
aiming to be more than just a bunch of blandly described rooms.
I'll just have to get on with this and stop prevaricating!
Thanks very much.
Viv Dunstan
Adam Thornton
>inspirational.
Come on, Jacek. Where are you? Perhaps you're still working up your
lather into a proper foam.
Adam
samwyse
> Well I write games with Adrift so the coding side of things doesn't really
> enter into it, but aside from that you've got it pretty much right. I've
> never produced a transcript yet or even plotted out more than a very vague
> idea of what the game is about. I've drawn maps but that's generally it.
I'm an advocate of writing a transcript.
Part of it is simply mechanical: I can't write good descriptions while
I'm coding. I don't know if it's because different parts of my brainar
involved, or what, but there is, in my opinion, a marked difference in
my writing style if I'm worrying about the placement of quotes, commas
and semi-colons.
The other part gets back to Emily Short's comment about concentrating on
the player's experience. The player will experience the game in the
form of a gradually revealed transript. Writing a transcript,
therefore, better lets the author perceive the player's point of view.
Jayzee
> David Whyld <m...@dwhyld.plus.com> wrote:
>
>
>>writing but I still tend to come back to the old "have an idea, start
>>writing" procedure. It's worked for the most part and I've been quite
>
>
> When you say "writing" here would it be writing out e.g. transcripts of
> your planned game, or do you dive into full coding at this very early
> stage? Because I'm curious about how best to develop the initial vague
> idea (probably a very individual thing, with different people having
> different approaches) I wonder what form your writing takes.
>
I've found it best to separate 'writing' from 'coding' as much as
possible. Otherwise I find myself trying to write the description of the
hall of King Thingumajig and being constantly interrupted with thoughts
of "but what if the player has already foobared the burble? That would
mean ... "
[if switch inserted in description]
"... and of course the player will want to look at the statue of
Pixyprattle IV..."
[scenery object written]
"... bet they'll try to climb it too..."
[Climb: Joke admonition written for the statue.]
[... and the queen's chamberpot.]
"... the hall is old. Should smell musty."
[smell description written]
"... and of course if the guard hasn't been dealt with, then he'll still
be pacing about in the corridor - in full armour."
[Quickie 'cardboard cutout' guard NPC written so I can tweak the daemon
to add sound effects in neighbouring room.]
etc etc
And then when I go back and play through, the actual room description is
less interesting than a store catalogue; just a boring functional
description of a bog standard room with a stachoo and a burble in it
because I've been distracted too much to have had time to imagine myself
into the place.
The only way I've found of writing better prose is to open a
wordprocessor*, write the descriptions/npc conversation or whatever, and
then cut & paste it into the game file. Once I've got the static
description in place, then I futz with it to add the context sensitivity
etc.
An unexpected hurdle was the tense: writing in second person present.
"The hall is...", "You are ...", "The Chamberlain twirls his pomander
thoughtfully."
Part of the reason my early efforts stank so much was because I didn't
feel comfortable writing arty-farty experimental prose.
*wordprocessor because it's the tool I use for writing stories, and also
because writing code with a wp is not a good idea because of the
program's tendency to add extra markup junk.
>
>>happy with the games I've written, but a few times recently I've been
>>halfway through writing a new game and suddenly realised that I don't
>>have a clue where it's going or how it's going to end.
>
A while ago, I got well into a game, then realized that while a human
would know when the story was done, I couldn't think of a way to convey
to the metal moron if THIS and THAT then GAME OVER. (Other than just
ending it an arbitrary number of turns after the last necessary action,
or just wait until the player got bored. Yeugh. Still thinking.)
So that's now one bit of code that I think about in the early stages of
plotting the story: what test will equal GAME OVER?
Richard Bos
> The only way I've found of writing better prose is to open a
> wordprocessor*, write the descriptions/npc conversation or whatever, and
> then cut & paste it into the game file. Once I've got the static
> description in place, then I futz with it to add the context sensitivity
> etc.
Interesting - I do it exactly the opposite way. That is, I generally do
write a couple of words of the starting description, but then I start
planning the logic in its entirety. When I need a bit of text inside the
algorithm, I put in a bit of filler such as "*** open door" or "***
still stuck". I end up with something like
print "You give a nice pull on the door, ";
if (self has locked)
"*** door locked";
if (self has oiled)
"*** still stuck";
give self open;
if (helmet has worn)
print "*** hit helmet";
else {
give player hurt;
print "*** hit and hurt head";
}
_Then_ I go back and fill in all the blanks.
Then again, my WIP isn't going to make the 2004 IF Comp or even the 2005
one if I don't get off my butt and do something about it, so I have to
admit that taking planning advice from me may not be the wisest thing to
do...
Richard
Jayzee
all. I have a growing collection of half-finished projects, each
(hopefully) slightly less inept than the last. :o)
But back on topic...
So do you then extract all the "placeholder text" with spellcheck or
whatever it's called, and then write up the "real" text in an orgy of
purple prosing?
I find that I change the text a lot during the futzing stage anyway -
pruning it down to avoid the dreaded "More" prompt, moving bits of it
out to other sense responses or different objects etc.
One of the things I really like about writing IF is that it punishes
slack writing; there just isn't the screen real-estate to waste. I'm
still learning how to balance atmosphere vs stuff the player *must*
learn, (clues etc) and info the player needs (exits etc).
Gravecat
news:7J0Bc.16909$NK4.2...@stones.force9.net:
> In a way I'd like to be one of those people who plot out *everything*
> beforehand and know before they even touch the keyboard to enter their
> first character exactly what their finished game is going to be like.
> But I'm too impatient. I come up with an idea and the desire to start
> writing a game takes over and before I know it I've started. Often it
> goes well. I started writing one game on the spur of the moment and it
> actually won a competition.
I know the feeling all too well, I have much the same mindset when it comes
to games. This is probably one of the reasons why I've never actually
*finished* anything, despite having started a number of games and then
deciding later that the idea is impractical, boring, or already been done
before.
But hey, you live and learn.
--
Keep on tranglin.
www.planetsomething.com
Richard Bos
> Richard Bos wrote:
> > I end up with something like
> >
> > print "You give a nice pull on the door, ";
> > if (self has locked)
> > "*** door locked";
> > if (self has oiled)
> > "*** still stuck";
> > give self open;
> > if (helmet has worn)
> > print "*** hit helmet";
> > else {
> > give player hurt;
> > print "*** hit and hurt head";
> > }
> >
> > _Then_ I go back and fill in all the blanks.
> So do you then extract all the "placeholder text" with spellcheck or
> whatever it's called, and then write up the "real" text in an orgy of
> purple prosing?
Nope. I do that in place.
> I find that I change the text a lot during the futzing stage anyway -
> pruning it down to avoid the dreaded "More" prompt, moving bits of it
> out to other sense responses or different objects etc.
>
> One of the things I really like about writing IF is that it punishes
> slack writing; there just isn't the screen real-estate to waste.
Yes; hence the snippets are generally small enough to be edited in a
decent (or even not-so-decent) programmer's editor.
Richard