Newbie question about coding IF in general
Lelah Conrad
Do you think it is best to go through and write up all the objects and
rooms first, before you make them -do- anything? In other words,
write the code for the more static stuff first, and then add the code
that makes things happen? Now that I have a general story plot and
outline, I thought that I would start by coding locations, people,
objects and then later do verbs and other more complicated stuff.
(I'm working in TADS, but didn't think this question was specific to
TADS particularly.)
Lelah
"I know nothing except the fact of my ignorance." Socrates
Dancer
Everybody who is (more or less) successful at it (that is have produced
games at all) that I can remember giving advice on this matter (that's a
lot of conditionals, I know) has said: Write everything down first.
If you're the right type of person, I imagine you can sit down, and just
start coding a game, without any clear idea of the plot, or places or
objects or challenges (I refuse to call them puzzles anymore. I think we
have to escape the idea of puzzles to some degree) and produce a nifty
piece of IF.
If you're not the right type of person (and I daresay ninety-nine point
ninety-nine nine's percent of us are not) then you should probably work at
it from the perspective of the common engineer or programmer. Write down
your outline. Then write down all the component bits. Look at how they fit
together. Look at ways to improve them. Work out the simplest,
lowest-energy design. Then write it. If you design it carefully enough,
the writing part is easy. Making something that fits together properly and
completely in the first place is a _lot_ harder.
D
Lelah Conrad wrote:
--
Did you read the documentation AND the FAQ?
If not, I'll probably still answer your question, but my patience will
be limited, and you take the risk of sarcasm and ridicule.
Andrew Plotkin
Lelah Conrad (lco...@lane.k12.or.us) wrote:
> Do you think it is best to go through and write up all the objects and
> rooms first, before you make them -do- anything? In other words,
> write the code for the more static stuff first, and then add the code
> that makes things happen? Now that I have a general story plot and
> outline, I thought that I would start by coding locations, people,
> objects and then later do verbs and other more complicated stuff.
> (I'm working in TADS, but didn't think this question was specific to
> TADS particularly.)
I start writing with the first room, write and code everything there, go
on to the second room... and proceed through the whole game in the order
that the player sees it. The first thing I write is the intro text and
the last thing is the game-over text.
I've been called nuts before, however.
(One advantage is that it's easier for me to make the narrative hang
together. If I refer to something earlier in the plot, it's probable (not
certain) that I've already written that part of the plot. And so on.)
(Also, I just like working on one thing at a time. If there's a long
delay between writing the description of a room and writing what goes on
there, I may forget to follow up on something in the description.)
It's probably going to be true that static descriptions take a minority
of your work time; verbs, actions and responses take far more. Does that
change how you look at the problem?
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Adam Cadre
Andrew Plotkin wrote:
> I start writing with the first room, write and code everything there,
> go on to the second room... and proceed through the whole game in the
> order that the player sees it. The first thing I write is the intro
> text and the last thing is the game-over text.
For what it's worth, I do much the same thing, except since all my
game ideas tend to revolve around plot trees, I tend to resolve a
given branch all the way to the end before moving onto another. So
I'll write the intro text first, then everything that leads up to the
first big plot divergence, and then code everything for choice #1
before having anything to do with choice 2, 3, 4, 5 or 69105. And of
course that goes for any subsequent choices as well; after reaching
the game-over text for one set of choices, I'll go back and code the
next game-over for what would have happened if the player had done
something differently two minutes earlier before worrying about what
would have happened had the player done something differently in the
first couple of moves.
Urgh. Did that even parse?
-----
Adam Cadre, Anaheim, CA
El Page del Me: http://www.retina.net/~grignr
Channel 31337 News: http://www.retina.net/~grignr/31337
"There is this guy named Adam Cadre that I've got to talk to about
making me eat my own daughter." --Marrissa in "Marrissa's Revenge"
Joe Mason
In article <34E112C5...@brisnet.org.au>,
Dancer <dan...@brisnet.org.au> wrote:
>objects or challenges (I refuse to call them puzzles anymore. I think we
^^^^^^^^^^
Good word. I like it.
Joe
LucFrench
>> I start writing with the first room, write and code everything there,
>> go on to the second room... and proceed through the whole game in the
>> order that the player sees it. The first thing I write is the intro
>> text and the last thing is the game-over text.
>
>For what it's worth, I do much the same thing, except since all my
>game ideas tend to revolve around plot trees, I tend to resolve a
>given branch all the way to the end before moving onto another. So
>I'll write the intro text first, then everything that leads up to the
>first big plot divergence, and then code everything for choice #1
>before having anything to do with choice 2, 3, 4, 5 or 69105. And of
>course that goes for any subsequent choices as well; after reaching
>the game-over text for one set of choices, I'll go back and code the
>next game-over for what would have happened if the player had done
>something differently two minutes earlier before worrying about what
>would have happened had the player done something differently in the
>first couple of moves.
>
>Urgh. Did that even parse?
Which are you refering to, the plot tree, or the plot tree?
Thanks
Luc French
Brent VanFossen
Sorry if this has been posted twice. It didn't make it to my server:
On Wed, 11 Feb 1998 04:31:25 GMT, erky...@netcom.com (Andrew Plotkin)
wrote:
>I start writing with the first room, write and code everything there, go
>on to the second room... and proceed through the whole game in the order
>that the player sees it. The first thing I write is the intro text and
>the last thing is the game-over text.
>
>I've been called nuts before, however.
>
>(One advantage is that it's easier for me to make the narrative hang
>together. If I refer to something earlier in the plot, it's probable (not
>certain) that I've already written that part of the plot. And so on.)
This is the way I work, at least at first. But some features get
added later as I think of them. And I'll go back and pretty up the
prose--my initial descriptions may not be the most eloquent.
Another advantage is that it's easier to try to debug if you work
solely on one location at a time. I know everything I just did, and
can try every inane thing I can think of that might be affected by my
new code. If weeks go by and I come back and add something later,
it's harder for me to remember to check everything.
Brent VanFossen