[Design] Keeping a lid on things...

9 views
Skip to first unread message

ravi...@fast.net

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

OK, I-F design theory question...any and all opinions welcomed.

A bit of history: I started designing what I thought to be a small piece of I-
F on paper about eight months ago, with the intention of entering it in the
competition.

I soon realized that its scope (not to mention its subject matter) might make
it unsuitable for the competition, so I continued designing with the intention
of releasing it independantly.

As I said, that was eight months ago.

The past eight months have been, to put it mildly, rather insane on almost
every front of my life. But I've managed to carry around a notebook and jot
down ideas and plans from time to time.

Maybe three or four months ago, I attempted to begin implementing the story.

I quickly became overwhelmed.

I don't know if it's because I'm a perfectionist, but I spent three weeks on
the thing and all I managed to accomplish was to have three rooms and one NPC
that worked in a vaguely believeable manner.

Now, I must add that I was attempting a level of detail I've not seen in most
I-F, including NPC interaction, but I felt completely overwhelmed at the
thought of attempting to write the entire game (which, in reality is quite
short) and continuing at the same pace.

For those of you who recieved an e-mail from me asking about 'reviewing' a
work, I apologize. Now you know why you never got it.

I'm probably going to go back to the thing, eventually. But a few weeks ago I
gave up on the thing and started a new project as a breath of fresh air.

Something short, I thought. Something easy.

No such luck.

Once again, I find myself getting slogging along at a pitiful rate. I've got
another notebook and I've done tons of research (the most fun part, actually)
and I'm all set with puzzles and maps and characterizations and NPC-
interactions and...

...and it's taking forever to implement the damnable thing.

Now part of the problem I'm running into is the 'stetson that works like a
stetson' problem (those of you who read XYZZYNews should know what I mean) ...
trying to implement objects/rooms/NPCs in a manner that doesn't totally
destroy the suspension of disbelief.

I'll make a few rooms, set up the through-line that I want to happen, put
objects, etc...

And then wander around and realize that X affects Y affects Z affects...

You get my drift.

What if the player does this before that thing and then tries the other one?
Or what if he ignores all three and totally messes everything up?

Am I being a perfectionist attempting to cover every possible path? Should
all of that come out in alpha/beta/gamma-testing?

I'm just curious the level of detail others have tried (at least initially) in
designing their own works.

*sigh* Well, back to it. Maybe I can finish a whole FOUR rooms today...

d

The Wildman

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

On 4 Mar 1998 01:11:49 GMT, Wildman's eyes rolled up in his head and
froth dripped from his fangs when ravi...@fast.net <ravi...@fast.net> said
the following fighting words:
[...]

>The past eight months have been, to put it mildly, rather insane on almost
>every front of my life. But I've managed to carry around a notebook and jot
>down ideas and plans from time to time.
I've been carrying around notebooks and jotting down ideas for the past 5-6
years. All I have to show for it is several notebooks full of half-baked
ideas.

>I don't know if it's because I'm a perfectionist, but I spent three weeks on
>the thing and all I managed to accomplish was to have three rooms and one NPC
>that worked in a vaguely believeable manner.

I would consider that quite an accomplishment.

>Now, I must add that I was attempting a level of detail I've not seen in most
>I-F, including NPC interaction, but I felt completely overwhelmed at the
>thought of attempting to write the entire game (which, in reality is quite
>short) and continuing at the same pace.

You need a plan of action. This isn't just the plans for the game, this is
the plans for your coding. A (more or less) step by step coding guide. Give
yourself a deadline for each individual coding task.

>Once again, I find myself getting slogging along at a pitiful rate. I've got
>another notebook and I've done tons of research (the most fun part, actually)
>and I'm all set with puzzles and maps and characterizations and NPC-
>interactions and...
>
>...and it's taking forever to implement the damnable thing.

It usually does. In fact, the smaller the project appears, the longer it
takes to complete. (Too bad you can't design a project that takes no time at
all to complete.)

>Now part of the problem I'm running into is the 'stetson that works like a
>stetson' problem (those of you who read XYZZYNews should know what I mean) ...
>trying to implement objects/rooms/NPCs in a manner that doesn't totally
>destroy the suspension of disbelief.
>
>I'll make a few rooms, set up the through-line that I want to happen, put
>objects, etc...
>
>And then wander around and realize that X affects Y affects Z affects...
>
>You get my drift.

Mmmm... it sounds like you've got your ideas engraved in stone. You have to
be flexible. No project ever turns out as originally envisioned.

>What if the player does this before that thing and then tries the other one?
>Or what if he ignores all three and totally messes everything up?

The old adage goes something like:
Code first. Debug later.

>Am I being a perfectionist attempting to cover every possible path? Should
>all of that come out in alpha/beta/gamma-testing?

There is nothing wrong with a rough draft. Once you get to a point where
it's finished (but far from complete), go through and take copious notes.
Then you can use your notes to work out the bugs. Once your satisfied with
it (even if there's a few things bothering you) release it as alpha. (If
you're shy about your code, give it to trusted friends to alpha-test).

>*sigh* Well, back to it. Maybe I can finish a whole FOUR rooms today...

Here's a better idea. Concentrate on completing one task per day. Write a
single room each day. If you are absolutely sure that the room you just
completed really is complete, go on to another room. In less than two
months, you will have a fairly decent sized map. Continue with this approach
in all the other aspects, and you will soon have a finished product.
Of course, then you have to debug. (And there's _always_ at least one more
bug.)


And come to think of it, my notebooks come in handy whenever I come across
an idea that sounds vaguely familiar. I can take a peek and see if I've
thought of it before. Quite often I find that I'm just rehashing old ideas,
instead of coming up with new ones. On rare occasions I find that the old
idea was actually quite good, and has just been waiting for the right time.

--
The Wildman
-----------
This isn't a .sig file, it's a barren wasteland!

Laurel Halbany

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

On 4 Mar 1998 01:11:49 GMT, ravi...@fast.net wrote:


>I'll make a few rooms, set up the through-line that I want to happen, put
>objects, etc...
>
>And then wander around and realize that X affects Y affects Z affects...
>
>You get my drift.

If you're setting up a through-line, then the player can't do A before
B, or shouldn't be able to. Otherwise, yes, it gets damn complicated.
Have you read Gareth Rees's tutorial with its "Alice in Wonderland"
example? It shows what an astounding amount of code you need just to
make one room and puzzle believable.

That aside--yes, you are being a perfectionist. Don't try to get
*everything* on the first go-round. Code up the major stuff, make it
make sense, and then go back and fill in the details and the what-ifs.
Things you miss will almost certainly be caught in beta-testing.


Gerry Kevin Wilson

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

In article <6di9ol$27o$1...@news1.fast.net>
ravi...@fast.net wrote:

[snip 8 months panic]

> What if the player does this before that thing and then tries the other one?
> Or what if he ignores all three and totally messes everything up?
>

> Am I being a perfectionist attempting to cover every possible path? Should
> all of that come out in alpha/beta/gamma-testing?
>

> I'm just curious the level of detail others have tried (at least initially) in
> designing their own works.
>

> *sigh* Well, back to it. Maybe I can finish a whole FOUR rooms today...

First of all, 8 months is nothing. Don't even begin to sweat it. I could do
8 months standing on my head. (grin) When you are a one man team, and
life gets hectic, simply nothing will get done.

Second of all, unless your game is extremely short and fairly barren, you
aren't going to cover every contingency. I wrote an article on this some
time ago that used an umbrella in an example. The gist was, real life is
infinite. If you try to, soon you too will be able to do 8 months standing on
your head.

I had one last article I meant to write called Length vs. Breadth. It was
going to discuss the adventages of exclusive plot branches vs. length.
There weren't many. Some people really enjoy that sort of thing, as
shown by Adam Cadre's I-0 and the success it has enjoyed. It makes the
game more realistic, and so on. Unfortunately, each exclusive branch in
the plot effectively increases your work by 10-100% depending on how
early the plot branch is and how quickly it converges with the other
branches. Be aware of the amount of work this is and that not all players
are ever going to notice.

Personally, I would only bother if it is a major point of the game, like a
moral dilemma or something that the player is forced to decide upon.
I'm not going to code every floor of a hotel for realism, nor am I going to
implement 20 solutions to a locked door.

But hey, if you want to, and you have the time and inclination to go to
that extremes, go for it. Once you've been working on a game for 3 years
running, I'll show you the secret handshake.

G. Kevin Wilson: Freelance Writer and Game Designer. Resumes on demand.


Andrew Plotkin

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

ravi...@fast.net wrote:

> Now part of the problem I'm running into is the 'stetson that works like a
> stetson' problem (those of you who read XYZZYNews should know what I mean) ...
> trying to implement objects/rooms/NPCs in a manner that doesn't totally
> destroy the suspension of disbelief.
>

> I'll make a few rooms, set up the through-line that I want to happen, put
> objects, etc...
>
> And then wander around and realize that X affects Y affects Z affects...
>

> What if the player does this before that thing and then tries the other one?
> Or what if he ignores all three and totally messes everything up?

Well, this is a good statement of The Problem. (Not just the IF problem:
programming in general.)

> Am I being a perfectionist attempting to cover every possible path? Should
> all of that come out in alpha/beta/gamma-testing?

Yes, you're being a perfectionist. This is the right approach. Never
"leave anything for testing". Testers find errors by stumbling into them.
You know how your code works, and you can check for errors much more
efficiently.

(I may have changed the subject, but I don't think so: things affecting
others things is always a potential error, until you look at the
interaction and decide it works right.)

Let's see...

In my humble experience, you have to consider everything. This means
either looking at each possible interaction, or creating constraints to
handle or wipe out huge swathes of them. We know zillions of ways to do
this: don't give access to A until B has happened, divide your game into
chapters or worlds or timezones, etc, etc.

I think I've instinctively avoided the really wide-open style of game
that exacerbates this problem most. _So Far_, for example, was divided
into worlds *and* had very few takable objects *and* had uncomplicated
NPC behavior.

--Z

--

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

Neil K.

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

ravi...@fast.net wrote:

> A bit of history: I started designing what I thought to be a small piece of I-
> F on paper about eight months ago, with the intention of entering it in the
> competition.

Maybe I should add my little bit of history. I started designing what I
thought to be a largeish-sized piece of IF about six years ago. :) So,
from that point of view anyway, 8 months really isn't so bad.

> I don't know if it's because I'm a perfectionist, but I spent three weeks on
> the thing and all I managed to accomplish was to have three rooms and one NPC
> that worked in a vaguely believeable manner.
>

> Now, I must add that I was attempting a level of detail I've not seen in most
> I-F, including NPC interaction, but I felt completely overwhelmed at the
> thought of attempting to write the entire game (which, in reality is quite
> short) and continuing at the same pace.

Yes, there's definitely a fairly direct relationship between the level of
detail you want to implement and the time it takes actually to write it.
Detail goes up and before you know it, months have gone by.

> Am I being a perfectionist attempting to cover every possible path? Should
> all of that come out in alpha/beta/gamma-testing?
>

> I'm just curious the level of detail others have tried (at least
initially) in
> designing their own works.

Well, here's my take. First, I don't think it's a good idea to rely just
on testing to uncover all the common paths. For one thing, you'll get a
lot of erratic beta testers (I offer myself as a good example of a lousy
beta tester) who will miss a lot of things and the general public will
probably embarrass you by pointing out your more amusing omissions and
mistakes to the newsgroups. For another, even if you get one or two
amazing beta testers (especially ones who always close doors once they've
gone through them, thereby revealing a startling number of bugs - you know
who you are!) that's still one or two people. As the author you should
hopefully have a better sense of the internals and thus should be able to
get the broader strokes better. Testers are good for catching things you
never thought of or for thinking in ways you don't. And of course the more
testers you have the more likely bugs will be detected

Second, detail. I personally enjoy exploratory games with rich detailing.
That's just how I am. So of course when I sat down to write my game in
progress I decided to make it as detailed as I reasonably could. That is,
of course, one of the main reasons that it's taking such an inordinately
long time (longer even than Avalon, for those counting) for me to write
it. And that is a major problem. You can get bogged down extremely easily
and feel like you're making no progress at all. I can really understand
why Whizzard has released a number of short games in the past while.

Third, some of the blame for the ludicrously long gestation period for my
game can be laid purely at the feet of my lack of discipline. Graham
Nelson, for example, has written a remarkable authoring system, several
short games and two very long games in the same period of time that I've
written, well, nothing. My game is certainly more detailed than either
Curses or Jigsaw, but that's little more than an excuse - Graham is
obviously much more focused than I am. So for that reason alone it'd
probably be hypocritical of me to suggest that time management and
self-discipline have a lot to do with writing. Though I could hazard the
suggestion that writing something, no matter what, every day is pretty
important to churning out a work eventually.

Fourth, another aspect may be the planning versus writing theory. Mike
Roberts discusses this idea in the TADS Authors Manual. He explains how
the process of Deep Space Drifter ended up being a painful and protracted
one because he didn't really have the complete game mapped out and
designed when he started programming it. And so partway through the
implementation process all sorts of plot-related problems reared their
foul little heads and he had to rework earlier bits of code, which ended
up cascading into even more problems. I can definitely see how this could
happen, and I suppose I can see it contributing to my own delays. Though
for me my writing (mainly done in code, though I have planned out a lot of
supporting material on paper) has been more a process of slow accretion -
I keep adding and fleshing stuff out as I go along. Just think of my game
as a software stalactite. But if you find yourself rewriting a lot, maybe
you should turn off your computer and design the whole thing on paper if
that works better for you.

Anyway... I don't know... Thing is, for me anyway, I'm not in any
particular hurry. Yes, it's been ridiculously long since I started this
thing. In fact, it's sort of inspired by a desire to achieve something I
wanted to achieve around 15 years ago. But there are no pressing deadlines
looming ahead. I'm confident I will finish the thing eventually, and I'll
finish it when it's right, and it'll probably be the only piece of IF that
I ever write. I have of course gone through periods of self-castigation
and despair at the length of time involved, but I'm past that now. :) This
is a labour of love, (or perhaps a labour of obsession) and if it takes
longer, fine. In fact the possibility has recently arisen of some
interesting ways of extending the game in new, fascinating and deeply
time-consuming ways, and I'm actively exploring them. More fool me,
perhaps.

But enough about me. I suppose my points are, first, that you aren't
alone in this. It's easy to devote a hell of a lot of time to what seems
like a ballooning task. Second, detail is probably a factor. If you're
concerned about the time factor you could always release a slimmer,
sketchier game and leave it at that. You might not be satisfied with that
solution, however. Third, don't despair at the number of different routes
you find yourself facing. Or, if that really bothers you, make deliberate
design decision to restrict those choices, and be ruthless about staying
within those limits. Otherwise you will find yourself taking forever and a
day to write your thing. And fourth, I personally believe that works that
were thought through over a longer period of time often have a richness to
them that quick jottings can't match. The world can become richer and more
alive. Of course, if you find your game becoming staid, depressing and
full of padding, forget I said that. ;)

- Neil K.

--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca

cody sandifer

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

> I'm not going to code every floor of a hotel for realism, nor am I going to
> implement 20 solutions to a locked door.

This is funny, because this is almost exactly what I did.


[spoiler space for Benny/Darlene in Zero Sum Game]

.
.
.
.


***Locked Door Responses programmed into Benny/Darlene***

The door is locked and...

Man/woman hasn't yet run out of the shack
benny kills man/woman and takes key

The player is under the bed
benny has key, unlocks door (benny can take key if left lying around)
benny doesn't have key, leaves

Player is outside shack
benny has key, unlocks door
benny doesn't have key, leaves

The door is unlocked and...

player is under the bed
all goes well

player is in shack
player gets thrown out

player is ouside shack

All this for one Actor on a particular track who doesn't interact with
other moving actors. I can't imagine doing something more complicated --
not without 3 years to kill, anyway.

Mobile actors are fun, though. Just insane to program.

cody

Dancer

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to


ravi...@fast.net wrote:

> OK, I-F design theory question...any and all opinions welcomed.
>

> A bit of history: I started designing what I thought to be a small piece of I-
> F on paper about eight months ago, with the intention of entering it in the
> competition.
>

> I soon realized that its scope (not to mention its subject matter) might make
> it unsuitable for the competition, so I continued designing with the intention
> of releasing it independantly.
>
> As I said, that was eight months ago.
>

> The past eight months have been, to put it mildly, rather insane on almost
> every front of my life. But I've managed to carry around a notebook and jot
> down ideas and plans from time to time.

Life can be like that. That you kept making notes and working on it, even
occasionally is good.

> Maybe three or four months ago, I attempted to begin implementing the story.
>
> I quickly became overwhelmed.
>

> I don't know if it's because I'm a perfectionist, but I spent three weeks on
> the thing and all I managed to accomplish was to have three rooms and one NPC
> that worked in a vaguely believeable manner.

Heh. I _know_. "With Enemies.." is currently growing at the rate of about 40K per
evening coding session (the .Z file is now 112K). I've still got to finish the
basic simulation interfaces, and then flesh out the simulation mechanics itself.
Then there's descriptions (I've got individual object descriptions that run on for
pages of code), scenery....props....lighting...

And this is for a smallish game. Most of the rooms are merely placeholders for the
simulation pieces, and there's only one challenge and no real puzzles. And I
haven't even _started_ on the NPC yet.

> Now, I must add that I was attempting a level of detail I've not seen in most
> I-F, including NPC interaction, but I felt completely overwhelmed at the
> thought of attempting to write the entire game (which, in reality is quite
> short) and continuing at the same pace.
>

> For those of you who recieved an e-mail from me asking about 'reviewing' a
> work, I apologize. Now you know why you never got it.
>
> I'm probably going to go back to the thing, eventually. But a few weeks ago I
> gave up on the thing and started a new project as a breath of fresh air.
>
> Something short, I thought. Something easy.
>
> No such luck.
>

> Once again, I find myself getting slogging along at a pitiful rate. I've got
> another notebook and I've done tons of research (the most fun part, actually)
> and I'm all set with puzzles and maps and characterizations and NPC-
> interactions and...
>
> ...and it's taking forever to implement the damnable thing.
>

> Now part of the problem I'm running into is the 'stetson that works like a
> stetson' problem (those of you who read XYZZYNews should know what I mean) ...
> trying to implement objects/rooms/NPCs in a manner that doesn't totally
> destroy the suspension of disbelief.
>
> I'll make a few rooms, set up the through-line that I want to happen, put
> objects, etc...
>
> And then wander around and realize that X affects Y affects Z affects...
>

> You get my drift.


>
> What if the player does this before that thing and then tries the other one?
> Or what if he ignores all three and totally messes everything up?
>

> Am I being a perfectionist attempting to cover every possible path? Should
> all of that come out in alpha/beta/gamma-testing?

If the player _can_ cock your story up, you should expect them to do so. Like it
or not, people think differently.I might leave a door till last, going everywhere
_else_ first. Another person might choose the door automatically, for whatever
reason. I go left, you go right. I look for something to bribe the troll with or
bypass it. I'd never think of attempting to kill it, under normal circumstances
(if that was the solution, I'd probably need a Big Clue(tm), or the previously
alluded special circumstances):
####

Troll Bridge
Sure enough, it's a Troll-Bridge. Four Trolls are sitting at the table, with
cards, munchies (that are better left underscribed) and wood-louse and moss beer.
Their enormous chairs block the way.

The enormous green troll looks at you over his cards, then nods his excuses to the
others. "One Club", he says to them, reaching for that object. "Be right back with
more munchies." He orients on you, snarling, and advances.

At long last, a chance to use all the skills that Murphy Trollslayer taught to you
for all those years! You feel the pressure of dozens of David Carradine-style
flashbacks. Blood and testosterone sing in your veins.

> KILL TROLL WITH SWORD
(drawing the sword first)
The sword glows with a fierce blue light. You bring the sword up, deflecting the
troll's downward stroke and dance aside.

"One diamond", says one of the trolls at the table.

> AGAIN
You dodge and roll as the troll's next swing brings part of the roof down. You
scramble over the rubble and manage to lance one of it's particularly noissome
boils.

"One no-trump", says another troll.

> AGAIN
The eldritch elven blade goes snicker-snack (because even eldritch elven blades
can have a sense of humour), and neatly decapitates the troll. At the waist,
admittedly, but heck, these guys are big.

"Pass", says the troll, as it expires.


#######
You've got to try to take 'fragility' out of the game path. If a 'reasonable'
(whatever reasonable is) action is performed, it shouldn't completely ruin the
game, unless it can be reasoned that this is so. I'm not saying we should knock
ourselves out to prevent stupidity...

####

> THROW MYSTICAL TREASURE IN CHASM

It is lost to sight.

####
...but issues of priority come to mind. Some people will ignore the lost puppy to
help the granny first. Some people will shoot the gangster before talking to the
blonde. Some people will take the droid containing the battle-station plans with
them to the battle-station, while rescuing the princess, before taking the plans
to the rebels. Some people will eat the dessert course first.

It may look reasonable. It may look obvious. But that's not always enough. Your
plot shouldn't _break_ if people do things differently. It might _end_, but it
shouldn't _break_.

Curses contains some fragility. The calendar and the flowers are an example. I
know four people, personally, who didn't look at the calendar until _after_. (I'm
one of them).

> I'm just curious the level of detail others have tried (at least initially) in
> designing their own works.

I go for enormous detail. Usually most of it is in scenery. I tend to have scenery
objects all over the place. Perhaps five or ten per room. Maybe more, and usually
all doing double-duty for many pieces of scenery. Fortunately, I leave scenery
till last. Except for the start/prologue, anyway, and maybe the first two or three
rooms. I describe those and flesh them out.

They give me the 'feel' to work in. The start room becomes my workshop for the
next few hundred hours, as I implement and test pieces of code.

I have a glassy sort of object that can be broken. In fact, I have a lot of them.
I spent an hour and 84 lines of code on implementing the broken fragments. (Design
choice: If I decide to add a specific environment feature, just about every mobile
object is going to need a huge batch more code, and the player even more).

[There's a tip..environmental factors and player conditions can _seriously_
complicate things (gravity, drunkeness, etc..)]

> *sigh* Well, back to it. Maybe I can finish a whole FOUR rooms today...

Try leaving most of your descriptions and scenery until the end. It's usually the
easiest way. Concentrate on the mechanics. Once you've got those, a bit of
prose-writing and scenery should come fairly easily. I laid out all the rooms in
for "With Enemies..." in about 15 minutes, and wrote the prologue and set up the
first half-dozen room descriptions in the next three or four hours.

The 16 or so hours since then have been filled with mechanics. Mechanics of
complex descriptions, and mechanics of object operations. If I'm not being _too_
optimistic, I figure there's another 40 or so hours of mechanics, and then maybe 6
or so of descriptions and scenery.

D

--
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.

HarryH

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

In article <erkyrathE...@netcom.com>, erky...@netcom.com says...

>I think I've instinctively avoided the really wide-open style of game
>that exacerbates this problem most. _So Far_, for example, was divided
>into worlds *and* had very few takable objects *and* had uncomplicated
>NPC behavior.

So, basically, what you're saying is to make a long game, just make a lot of
short games and group them together?

Why can't you just release it as several small games? Especially considering
games that restrict action A before the player do action B.

-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant


Andy Wright

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

HarryH wrote:
>
> In article <erkyrathE...@netcom.com>, erky...@netcom.com says...
> >I think I've instinctively avoided the really wide-open style of game
> >that exacerbates this problem most. _So Far_, for example, was divided
> >into worlds *and* had very few takable objects *and* had uncomplicated
> >NPC behavior.
>
> So, basically, what you're saying is to make a long game, just make a lot of
> short games and group them together?
>
> Why can't you just release it as several small games? Especially considering
> games that restrict action A before the player do action B.
>

Well, there's a bit more to it than that. Plot coherence, for one thing - just
stringing together a bunch of short scenarios doesn't make a good long story.
They have to be linked together somehow. Also, many of the "sub-games" wouldn't
stand up too well as single, released games, without a great deal of tinkering.
How would "Jigsaw" have fared as up to sixteen small games?

Andy

The Wildman

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

On Wed, 04 Mar 1998 14:02:15 GMT, Wildman's eyes rolled up in his head and
froth dripped from his fangs when HarryH
<har...@iu.net.idiotic.com.skip.idiotic.com> said
the following fighting words:

>So, basically, what you're saying is to make a long game, just make a lot of
>short games and group them together?
Absolutely. That's how good programs are written - in modules. The hard part
then is merely fitting the pieces together.

>Why can't you just release it as several small games? Especially considering
>games that restrict action A before the player do action B.

Playability and entertainment. What makes a game fun is when there are
several puzzles on the way to an ultimate goal. A series of games is when
you have a few "ultimate goals" to be performed in the same setting.

Andrew Plotkin

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

HarryH (har...@iu.net.idiotic.com.skip.idiotic.com) wrote:
> In article <erkyrathE...@netcom.com>, erky...@netcom.com says...
> >I think I've instinctively avoided the really wide-open style of game
> >that exacerbates this problem most. _So Far_, for example, was divided
> >into worlds *and* had very few takable objects *and* had uncomplicated
> >NPC behavior.

> So, basically, what you're saying is to make a long game, just make a lot of

> short games and group them together?

I'm saying that that's *one* way to make a long game. And it's a
particularly easy approach.

> Why can't you just release it as several small games? Especially considering
> games that restrict action A before the player do action B.

Well, there is *some* interaction between the sections, after all. Should
_Jigsaw_ have been released as sixteen short games?

Lucian Paul Smith

unread,
Mar 4, 1998, 3:00:00 AM3/4/98
to

A few thoughts,...

For one, if there's an NPC in your opening scenario, that's going to eat
up a *lot* of time. The Stranger in Edifice took about a month, working
on him a little bit each day, and by the end I was *so* tired of coding up
responses I quit working on the game at all for about two weeks.
Fortunately, it paid off. My other NPCs took less work, but at the
sacrifice of interactivity. You can chat with the others about some
things, but not very many.

I also found that chunking the game into distinct scenes helped a lot. I
could work on a scene at a time, and see real progress as I went along.

Finally, you have to be willing to edit you ideas, and 'kill your babies'.
You might have a great idea that simply won't make it into the final
product. This goes for various incidental methods of interaction, as
well. They player will be just as served by a polite request/reason not
to do something as they will by being allowed to do something pointless,
if not more. In some situations, at least.

-Lucian

HarryH

unread,
Mar 5, 1998, 3:00:00 AM3/5/98
to

In article <slrn6fqq55.4u9.w...@foobar.net>,
wildman-s...@microserve.net says...

>Playability and entertainment. What makes a game fun is when there are
>several puzzles on the way to an ultimate goal. A series of games is when
>you have a few "ultimate goals" to be performed in the same setting.

I think what you describe is something called "rising tension". It's a
particularly effective technique, I admit.

You know, I enjoy both Trinity and Wishbringer. However, I somewhat resent
the mushroom (section) approach. All I did was just go to the mushroom in
sequential order, whereas the distinction is less in Wishbringer. Hence, to
me personally, Wishbringer gives me more satisfaction than Trinity. No
comment on which one is easier to design, write, and program, though. :)

Maynard Case

unread,
Mar 5, 1998, 3:00:00 AM3/5/98
to

In article <6di9ol$27o$1...@news1.fast.net>, ravi...@fast.net writes:
>
> Maybe three or four months ago, I attempted to begin implementing the story.
>
> I quickly became overwhelmed.

This is a very familiar feeling for me. I started to write a big game about two years
ago, and quickly finished the bare bones of the introduction. It took me quite a
while to get that working well, with a reasonable amount of detail, but after about
six months (on and off, mostly off), I was happy with it. I've planned out the plot,
have puzzle ideas and an endgame - even a plot branch or two. It's going to be
enormous. I implement a new section, get annoyed with all the little permutations,
fiddle with it for a while, then leave it and go onwards. Sigh.

> For those of you who recieved an e-mail from me asking about 'reviewing' a
> work, I apologize. Now you know why you never got it.

I have a beta-tester e-mail list. I know that it won't be used properly until at
least June this year, and that would probably be a half-finished version.

I recommend the old walking theory - every step is one closer to your final
destination. Just try not to take a route that makes the journey too long... :)

Maynard

--
m...@dcs.ed.ac.uk http://www.dcs.ed.ac.uk/~mc
3rd Year Computer Science Undergraduate, Edinburgh University
Creator of ATOM

Maynard Case

unread,
Mar 5, 1998, 3:00:00 AM3/5/98
to

In article <34FD17F7...@brisnet.org.au>, Dancer <dan...@brisnet.org.au> writes:

>
>
> ravi...@fast.net wrote:
>
> Heh. I _know_. "With Enemies.." is currently growing at the rate of about 40K per
> evening coding session (the .Z file is now 112K). I've still got to finish the
> basic simulation interfaces, and then flesh out the simulation mechanics itself.
> Then there's descriptions (I've got individual object descriptions that run on for
> pages of code), scenery....props....lighting...

How on earth do you code enough to add 40k each night?

Astounding. I checked my game the other day - since June last year it has become
around 35k larger... :)

HarryH

unread,
Mar 6, 1998, 3:00:00 AM3/6/98
to

In article <EpCLIp.D3s.0.sta...@dcs.ed.ac.uk>, m...@dcs.ed.ac.uk
says...

>Astounding. I checked my game the other day - since June last year it has
become
>around 35k larger... :)

At least yours got larger. Mine is standing still. :(
Lots of plans, zero time.

Dancer

unread,
Mar 6, 1998, 3:00:00 AM3/6/98
to


Maynard Case wrote:

> In article <34FD17F7...@brisnet.org.au>, Dancer <dan...@brisnet.org.au> writes:
> >
> >
> > ravi...@fast.net wrote:
> >

> > Heh. I _know_. "With Enemies.." is currently growing at the rate of about 40K per
> > evening coding session (the .Z file is now 112K). I've still got to finish the
> > basic simulation interfaces, and then flesh out the simulation mechanics itself.
> > Then there's descriptions (I've got individual object descriptions that run on for
> > pages of code), scenery....props....lighting...
>

> How on earth do you code enough to add 40k each night?
>

> Astounding. I checked my game the other day - since June last year it has become
> around 35k larger... :)

I'm a born hacker. I think in code. So, for me, it's a matter of just thinking the
problem through, then I can type it out at 90wpm.

Besides, there's a brutal amount of code and mechanics in it, since it's all a complex
interlocking system.

D

The Glassers

unread,
Mar 7, 1998, 3:00:00 AM3/7/98
to

Maynard Case <m...@dcs.ed.ac.uk> wrote:

> Dancer <dan...@brisnet.org.au> writes:
> >
> > Heh. I _know_. "With Enemies.." is currently growing at the rate of
> > about 40K per evening coding session (the .Z file is now 112K). I've
> > still got to finish the basic simulation interfaces, and then flesh out
> > the simulation mechanics itself. Then there's descriptions (I've got
> > individual object descriptions that run on for pages of code),
> > scenery....props....lighting...
>

> How on earth do you code enough to add 40k each night?
>
> Astounding. I checked my game the other day - since June last year it has
> become around 35k larger... :)

Because he does something called "simulation" that he doesn't explain
and leaves everyone confused and takes lots of code.

--David Glasser
gla...@NOSPAMuscom.com
Check out my new I-F website at http://onramp.uscom.com/~glasser
Or, for a waste of time almost as good as spatch.net,
http://www.geocities.com/SoHo/6028/

Reply all
Reply to author
Forward
0 new messages