Design process?
Cedric Knight
including a new zcode compiler and a Javascript IF system (and a new
walking song). For me, mostly I learnt an unsurprising result: taking
technical contraints or technical ideas and working from them is likely
to make writing an interesting story that much harder.
So my questions are:
Where do you begin in your designing? Where do you call a day on the
designing and begin coding? How can you get feedback on an outline or
design before the coding begins? (Alternatively, how do you avoid
getting attached to 'finished' work so that you don't mind junking or
radically altering most of it?)
What is the germ of your idea? Setting, characters, motif, story or
puzzles? What next? Are many elements abandoned in the design process,
or do you go with the first thing that occurs even if it doesn't fit
with the other design aspects? Do you design player goals
hierarchically or sequentially? Did you decide to do things in this
order, or did one of the elements (e.g. the story) inspire you enough to
determine the rest of the design?
Also - can you give an amnesiac PC motivation? How do you motivate the
player?
A second thing that I think I've learnt is the importance of
'gatekeeper' problems. If you give the players masses of territory to
explore with masses of objects to play with, it's not conducive to
successful puzzle solving (I noted this in my comments on Trapped in
School). So it seems that new possibilities should be fed to the player
piecemeal, with something, e.g. a classic lock-and-key, to prevent
progress for a while to make sure that the player has seen everything in
the earlier scenes. Has anyone found they have had to add elements like
this late in the design?
Lots of questions.
CK
Edmund Kirwan
> So my questions are:
>
> Where do you begin in your designing? Where do you call a day on the
> designing and begin coding?
Wish I had the self-control to design it all before coding. Me, I burn
in at light-speed, trying to code as much as possible while the
ever-so scarce enthusiasm lasts, painting the path for the lead
character into one corner after another, dreaming up ever more
unfeasible solutions to back them out of their corners and convincing
myself that there's really not too great a leap between the last
unfeasable puzzle solution and this one -
And then the enthusiasm runs out. And everything goes quiet. And the
fall begins. And it all looks hopelessly awful (as you mentioned in
your post) and every other IF looks great.
If lucky, I'll have gone so far that to finish it will probably cost
less than the guilt at not finishing it.
> How can you get feedback on an outline or
> design before the coding begins?
Can't/don't/probably should/probably would rob me of that enthusiasm.
I suppose I'd rather write a bad IF than not write a good one, if that
makes any sense. Anything's better than vegging in front of the tv.
> (Alternatively, how do you avoid
> getting attached to 'finished' work so that you don't mind junking or
> radically altering most of it?)
I usually go to the other extreme: how do I work up the strength to
see anything in it worth salvaging rather than junking the whole lot.
> What is the germ of your idea? Setting, characters, motif, story or
> puzzles?
Usually just one event that I'd like to see in an IF (e.g., in a land
of talking cakes, what would the king be like?). (Hence the perennial
crappiness of my WIPs.)
> What next? Are many elements abandoned in the design process,
> or do you go with the first thing that occurs even if it doesn't fit
> with the other design aspects?
I don't care if it's a lightsabre in Oliver Twist, I'll crowbar it in
one way or another. (Hence the perennial ...)
> Do you design player goals
> hierarchically or sequentially?
I'm not sure what a hierarchical goal is. I'm sequential.
> Did you decide to do things in this
> order, or did one of the elements (e.g. the story) inspire you enough to
> determine the rest of the design?
Code everything as I need it, with a smattering of object orientation
to ensure/hope that the next missing piece is easily retro-fitted.
>
> Also - can you give an amnesiac PC motivation? How do you motivate the
> player?
Play on brute force emotion. If you read that your village has been
invaded by the Sai army, who cares. If you go into your house and see
your daughter dead on the floor and a Sai dagger sticking into her
chest, you care just a tiny, tiny, tiny bit more about that than the
text - ooh, say - on a chewing gum wrapper. That's probably all you
can hope for.
>
> A second thing that I think I've learnt is the importance of
> 'gatekeeper' problems. If you give the players masses of territory to
> explore with masses of objects to play with, it's not conducive to
> successful puzzle solving (I noted this in my comments on Trapped in
> School). So it seems that new possibilities should be fed to the player
> piecemeal, with something, e.g. a classic lock-and-key, to prevent
> progress for a while to make sure that the player has seen everything in
> the earlier scenes. Has anyone found they have had to add elements like
> this late in the design?
Yes. You need to find the uncle to with his horse to get away from the
village. You need the winter furs to get over the mountain. Though I
dislike closing doors behind: it's always great to be able - no matter
how far from your village you are, and despite knowing that it will
accomplish nothing - to turn around and bloody-mindedly spend weeks
getting back to your home (now ravaged) and examine something
needlessly.
>
> Lots of questions.
>
Lots. I'm fully aware that you wanted to know how IF should "properly"
be created and I do not do that. So don't read any of this.
ed
Cedric Knight
> "Cedric Knight" <ckn...@gn.babpbc.removeallBstosend.org> wrote in
> message news:<_6MIa.42639$xd5.2...@stones.force9.net>...
[from end of post]
>> Lots of questions.
>>
>
> Lots. I'm fully aware that you wanted to know how IF should "properly"
> be created and I do not do that. So don't read any of this.
Hah. In fact, I didn't mean to give that impression. It was more a
case of asking what works for different people and why, and I also hoped
my questions would be understood in multiple ways. As it happens, my
'methods' resemble yours (but seem vastly different from, say, Michael
Gentry's systematic conceptualizations, which I found in a 5-year-old
post).
>> Where do you begin in your designing? Where do you call a day on the
>> designing and begin coding?
>
> Wish I had the self-control to design it all before coding. Me, I burn
> in at light-speed, trying to code as much as possible while the
> ever-so scarce enthusiasm lasts, painting the path for the lead
> character into one corner after another, dreaming up ever more
> unfeasible solutions to back them out of their corners and convincing
> myself that there's really not too great a leap between the last
> unfeasable puzzle solution and this one -
Don't think about whether this makes any sense, just don't even *think*
about it....
>
> And then the enthusiasm runs out. And everything goes quiet. And the
> fall begins. And it all looks hopelessly awful (as you mentioned in
> your post) and every other IF looks great.
*Every* other IF? Someone else said recently to gain perspective by
playing some of the games that are given one star in Baf's Guide. Good
advice, except when even those seem better....
>
> If lucky, I'll have gone so far that to finish it will probably cost
> less than the guilt at not finishing it.
This attitude also helps explain why people too often give up on a
project after (or sometimes before) first release, rather than producing
"director's cuts".
>
>> How can you get feedback on an outline or
>> design before the coding begins?
>
> Can't/don't/probably should/probably would rob me of that enthusiasm.
>
> I suppose I'd rather write a bad IF than not write a good one, if that
> makes any sense. Anything's better than vegging in front of the tv.
Yes.
>> What is the germ of your idea? Setting, characters, motif, story or
>> puzzles?
>
> Usually just one event that I'd like to see in an IF (e.g., in a land
> of talking cakes, what would the king be like?).
Battenberg, with attitude?
>
>> Do you design player goals
>> hierarchically or sequentially?
>
> I'm not sure what a hierarchical goal is. I'm sequential.
Hierarchical would be having a clear ending in mind, for which A, B and
C are prerequisite, and then some recursive decomposition to allocate
plausible tasks A1 A2 and A3 that are necessary for A. Sequential is
more like 'tag wrestling', trying to thread the plot through all the
decorations and somehow still reach the intended conclusion; works
reasonably well for small games, but probably not for anything longer
than 2 hours.
>> Also - can you give an amnesiac PC motivation? How do you motivate
>> the
>> player?
>
> Play on brute force emotion. If you read that your village has been
> invaded by the Sai army, who cares. If you go into your house and see
> your daughter dead on the floor and a Sai dagger sticking into her
> chest, you care just a tiny, tiny, tiny bit more about that than the
> text - ooh, say - on a chewing gum wrapper. That's probably all you
> can hope for.
Nah, she was just a cardboard cutout anyway. At least being forced to
empathise with a chewing-gum wrapper is original.
Thanks for the reply.
CK
Yoon Ha Lee
Hello! Not that I've exactly done a lot of this, but these were
things that I was also grappling with, and the questions are
definitely things I'd like to keep in mind. :-)
> So my questions are:
>
> Where do you begin in your designing? Where do you call a day on the
> designing and begin coding? How can you get feedback on an outline or
> design before the coding begins? (Alternatively, how do you avoid
> getting attached to 'finished' work so that you don't mind junking or
> radically altering most of it?)
I started with a map, but of course the map is going to get
hideously revised. I actually haven't gotten feedback on an
outline because the one person I'd ask is someone I'd like
to "reserve" as an alpha-tester. Now that you mention it,
however, it sounds like it might not be a bad idea.
Because (I suspect) of my relative inexperience, I find that
at some point I have to stop with a very partial design and
move into the code in order to progress. For the moment, I
think of it as a doubly-recursive process: designing leads to
coding, which leads to more designing, which...
Mind you, if I sat down and designed something completely in
advance I would probably reap benefits from it. But in writing
static fiction, which I've done rather more of, I am incapable
of starting with an outline, and I've tried. I wonder if it
may be a top-down vs. bottom-up approach thing.
As for getting attached to things--I find that letting something
"rest" for a few days and then looking at it later allows me to
ditch whole chunks without (too much) remorse. I can, after all,
always write more chunks. I admit that ditching chunks of *code*
is more painful for me, though. Especially when I am then
obliged to replace it with code that promptly spawns a whole new
nest of bugs.
> What is the germ of your idea? Setting, characters, motif, story or
> puzzles? What next?
Er...this sounds silly, but so far I've started with an opening
paragraph, wondered to myself, "Hmm, I wonder what situation could
arise from the tiny bit of world hinted at in this paragraph?" and
extrapolated from there. It is, I'm afraid, terribly unscientific.
> Do you design player goals hierarchically or
> sequentially?
Could you give an example of hierarchical vs. sequential goals?
> Also - can you give an amnesiac PC motivation? How do you motivate
> the player?
You could maybe:
a) put the PC in a predicament, hinting that his/her/its unknown
past has led to the predicament, and may be the key to its
resolution. (Lots of ways to do this one.)
b) suggest that in fact the PC has very good reasons for having
forgotten whatever it is that's forgotten, and strive to *avoid*
having memories rewoken despite external attemptsto the contrary.
(Actually, I wouldn't mind seeing someone play around with this.)
c) do something else clever that I haven't thought of. :-)
Hope some of this is of help, or conversation-stimulating, or
something.
YHL
Christos Dimitrakakis
> So my questions are:
>
> Where do you begin in your designing? Where do you call a day on the
> designing and begin coding? How can you get feedback on an outline or
> design before the coding begins?
Designing *is* coding. As far as past work is concerned, the only thing I
might salvage are descriptions and then again, I never take them verbatim
from previous work. Puzzles cannot be salvaged and code is rarely portable
enough from game to game. Even code that begins as a core engine
ultimately gets forked into innumerable revisions.
> What is the germ of your idea? Setting, characters, motif, story or
> puzzles? What next?
I usually begin with a story concept, or an original implementation
concept. It always gets me exactly nowhere.
> Do you design player goals
> hierarchically or sequentially?
I have never tried to create a story. So far all my WIPs are based on a
setting and the exploration of a backstory. Thus, there are no goals are
than which the player creates for himself.
> Also - can you give an amnesiac PC motivation? How do you motivate the
> player?
Have you played 'Deja Vu'?
Zachary H.
> designing and begin coding?
Like the other guys, I'd like to say my present project is mapped out
from start to finish, but it isn't. In fact, I've abandoned outlines.
I've even abandoned coding one thing (like geography) before anything
else. Although I have kept to leaving desc blank when nothing
pertinent comes to mind. I code a few rooms and as I think of things
to fill them with, puzzles and items and discoveries come to mind.
About the only thing I have before sitting down, is a notion of the
story's mood and a few character traits I want to associate with
someone.
> (Alternatively, how do you avoid
> getting attached to 'finished' work so that you don't mind junking or
> radically altering most of it?)
I've done it before. Like one of the other guys, after a few weeks of
work, it is hard to stay attached to a work.
> What is the germ of your idea? Setting, characters, motif, story or
> puzzles? What next?
Can be anything, but I am compelled by stories (fact or fiction), so
most of the original motivation comes from something I've read or
watched.
> Are many elements abandoned in the design process,
> or do you go with the first thing that occurs even if it doesn't fit
> with the other design aspects?
If nothing satisfying comes to mind, I will settle for something
initially if it does not clash too bad with what I would like it to
be.
> Do you design player goals
> hierarchically or sequentially?
I really suppose that depends on the amount of pre-production you've
done. It's impossible to create a heirarchy when you have no idea what
should be put above anything else. Who's to say that the can of coke
in the fridge is nothing more than just a can of coke until you've
uploaded your game to the archive. However, it is easy to write
sequentially when you have no idea where you are going. I usually find
it more fun, because in a sense, I get to experience the story in a
similar fashion to the player/reader.
> Also - can you give an amnesiac PC motivation? How do you motivate the
> player?
I think one of the previous posters is correct--even if it is a life
threatening situation, the player (the jaded player) won't really
care. For me, mystery is more of a motivation than situation (i.e.
your character's trapped in a burning house...I can walk away from the
computer and leave him to suffer in there forever. But, if I've just
walked into a room and my wife stuffs something under the couch in an
attempt to conceal it from my view. I'll spend the next half hour
typing every command I can to get her off that couch, so I can see
what she's hiding.) In other words, it is what I don't know that
motivates me...not an emotional attachment to the PC. Games have
motivation already...finishing them. The trick is to make that
enjoyable.
> A second thing that I think I've learnt is the importance of
> 'gatekeeper' problems. If you give the players masses of territory to
> explore with masses of objects to play with, it's not conducive to
> successful puzzle solving (I noted this in my comments on Trapped in
> School). So it seems that new possibilities should be fed to the player
> piecemeal, with something, e.g. a classic lock-and-key, to prevent
> progress for a while to make sure that the player has seen everything in
> the earlier scenes. Has anyone found they have had to add elements like
> this late in the design?
A piecemeal game is easier to design because you don't have to account
for the player wandering to the final room, having never talked to the
innkeeper in the first one. Obviously there are a million lock-n-key
devices to keeping a player in one area (one of my favorites are the
nannies in Trinity in the first part of the game), and I am in favor
of even breaking the fourth wall to tell the player he shouldn't go
out that door just yet. Personally, I'd rather know that than have me
wander an hour on without realizing I forgot to pick up the pack of
cigarettes near the phone. There are game structures that are disposed
to allow free-range (multi-sub-plots that have a weak or loose thread
tying the whole thing together). I think walls and doors focus the
player's attention, which is, in the case of myself, usually all over
the place. I am much more likely to type 'east' in frustration, just
to move on, than tinker with a device for an hour. Perhaps it's a
simple mindset, but after all the RPG and adventure games I've played,
if it isn't obvious how to work it or what makes it work after a few
minutes, then I assume I'm lacking an object or haven't triggered
something in the game.
If you have a weak or non-existent story and lots of puzzles, I would
consider doors to keep the overwhelmed frustration feelings down. If
you have a strong story, with a point by point plot progression, you
probably won't need so many doors as the whole idea is to explore and
seek information.
> Lots of questions.
Oh yea...don't we all.
Michael Coyne
> Where do you begin in your designing? Where do you call a day on the
> designing and begin coding? How can you get feedback on an outline or
> design before the coding begins? (Alternatively, how do you avoid
> [snip]
> What is the germ of your idea? Setting, characters, motif, story or
> puzzles? What next? Are many elements abandoned in the design process,
> or do you go with the first thing that occurs even if it doesn't fit
> with the other design aspects? Do you design player goals
> hierarchically or sequentially? Did you decide to do things in this
> order, or did one of the elements (e.g. the story) inspire you enough to
> determine the rest of the design?
All the ideas for games that I'm working on right now came from short
stories that I had written, or started to write.
With these stories, they usually begin when I envision a scene in my head.
It's usually just one scene, but it's an effective one. I usually don't
know where it comes from, or what the story around the scene is, but it's
the beginning from which I build the rest of the story.
The result of then taking these short stories and building them into an IF
work, is that I'm aware of the created world that exists *outside* of the
parts of it that make it into the IF piece. I believe that
readers/players get a much better experience when they can sense or feel a
well-developed world behind the story.
Regarding the actual creative process, I pretty much start at the
beginning and create the rooms one at a time, complete with descriptions
and scenery as I go. I occasionally need to come back and add items or
tweak descriptions to make things fit with later additions of course, but
usually my first crack at a room comes in its geographical order.
As for puzzles, I usually have a few basic ideas, but I've found that most
of my puzzles flow naturally out of the descriptions of an area. For
example, I was coding a small garden shed and described its lock as
rusted. Then, when writing the "Open" code, I thought, well, it's rusted,
so let's make it rusted shut. Bingo--one fairly simple puzzle that works
within the context of the world and is a logical and believable barrier to
surmount.
All of what I consider the better puzzles in my WIP flowed out of scenery
or description elements that I later thought "Well, I've got x here, why
not use it?". Things that seemed trivial and unimportant at first have
ended up playing a rather leading role.
One item, initially provided for colour in the prologue, and also to give
the player something to interact with so they could be drawn out of the
initial room and into the game proper, ended up giving rise to an item
that the player carries with them through the entire game.
> A second thing that I think I've learnt is the importance of
> 'gatekeeper' problems. If you give the players masses of territory to
> explore with masses of objects to play with, it's not conducive to
> [snip]
I'm in favour of gatekeeper problems in terms of ensuring that certain key
events have taken place before players can reach later portions of the
game. It adds some linearity, but the result is that the author can
better pace the story behind the game if he can make assumptions about
what has happened at certain points. There's nothing worse than writing a
room or object description such as "It looks exactly like the one you saw
in the farmyard earlier.", only to have a player who DIDN'T visit the
farmyard right it and think "What?".
In my WIP (discounting the one-room prologue), the middle game area has 11
meaningful locations (not counting feeder locations such as hallways and
stairwells), and when the player transitions to the next portion of the
game, every location then becomes available.
Anyway, that's my take on this for now. I may have more datapoints once I
complete a game : )
Michael
Sean Don
> [...]
> Where do you begin in your designing? Where do you call a day on the
> designing and begin coding? How can you get feedback on an outline or design
> before the coding begins? (Alternatively, how do you avoid getting attached
> to 'finished' work so that you don't mind junking or radically altering most
> of it?)
Well, I've yet to publish a game; so, I'm compelled to discuss these issues
since I've thought about them so much.
So far I've taken the advice of the TADS Design Manual and decided to design my
game on "pen & paper" first before moving onto the coding/implementation.
I get feedback from the game's second author, my brother. I discuss every new
idea I have with him.
> What is the germ of your idea? Setting, characters, motif, story or puzzles?
> What next? Are many elements abandoned in the design process, or do you go
> with the first thing that occurs even if it doesn't fit with the other design
> aspects? Do you design player goals hierarchically or sequentially? Did you
> decide to do things in this order, or did one of the elements (e.g. the story)
> inspire you enough to determine the rest of the design?
It probably depends on the type of game your making. If you're going to make a
linear puzzle-less game, then a sequential design based purely on a story would
make sense.
Unlike many other IF gamers, the Infocom games (or other classic text
adventures) were not my primary inspiration for wanting to make my own games.
Rather, I plan on making my games like the LucasArts adventures; those include
Day of the Tentacle and Sam N' Max. Alas, since I can't draw, don't know any one
who can, love to write, and love to program, the text-adventure medium was a
better choice than a point-in-click system for my own attempts.
The mentioned LucasArts games were quite non-linear. Hence, a hierarchical
design seems to work a lot better for me.
So far, I've decided that it's best to come up with a fairly *solid* setting. My
first few design attempts had only a theme and a story concept, but no definite
setting; so, the map wound up looking like some sort of Alice in Wonderland
landscape, which made it increasingly difficult to think up coherent puzzles.
So instead, I found that picking an "ordinary" setting takes a lot of the stress
out. It could be a theater, an air-port, a house, a hotel, or even a small-town.
That's about it, your maps made! A theater is going to have a ticket-booth,
maybe a costume room, a bathroom, a refreshments counter, etc. Alternatively, a
small-town is going to have a residential area, some sort of store (eg. a
restaurant, a bar, or a convenient store), some sort of government building (eg.
a DMV, a park, or a police station), some sort of transportation (eg. a gas
station, a bus station, or an auto-motive shop), and maybe a bank or ATM
machine.
Sometimes the game's theme itself can bring creative settings and characters.
For example, in the future in Day of the Tentacle, humans are ruled by
tentacles. That must have lead the authors to the idea of having a "human show"
(like a dog show.) Further, I believe the idea of having an insane guy with his
"stamp collection" must have come from Maniac Mansion (even though I never
played that one much.)
> Also - can you give an amnesiac PC motivation? How do you motivate the
> player?
At this point, I had to come up with a simple motive and background story. It
never really matters to me what the motive is when I play a game, just as long
as the puzzles are fun. The player may need to find a way off a foreign planet,
find a fugitive, become a pirate, or whatever.
> A second thing that I think I've learnt is the importance of 'gatekeeper'
> problems. If you give the players masses of territory to explore with masses
> of objects to play with, it's not conducive to successful puzzle solving (I
> noted this in my comments on Trapped in School). So it seems that new
> possibilities should be fed to the player piecemeal, with something, e.g. a
> classic lock-and-key, to prevent progress for a while to make sure that the
> player has seen everything in the earlier scenes. Has anyone found they have
> had to add elements like this late in the design?
I agree! Nothing motivates me more in a game than something that needs to be
accomplished, an obstacle. Nothing motivates me *less* than a game that depends
primarily on what I call "exploration-motive", endless wondering around and
looking carefully at things with no particular goal in mind.
So far, me and my brother have wound up with the following sort of methodology
for our eventually-to-be-finished game. I had a theme in mind that pretty well
narrowed down exactly what buildings I wanted to see in my game's small-town
setting. Then, I made a rough list of all the primary items that are either
potentially take-able or static in every building and room. Finally, given that
list, I was able to make a list of all possible "lock-and-key" puzzles for every
room. For example, a tree in the park could have a birds-nest with something in
it, or something could be stuck in the branch. Maybe the player needs to get a
metal-detector to find something in a sand-box at the park. Or maybe there's a
ravine that the player needs to find a way across.
Ultimately, I find it to be extremely important that the player start out with
every day generic items, and combine them or use them in creative ways that lead
to more elaborate puzzles, hence the hierarchy.
Here's were the number of possibilities blow up. We start by taking the primary
goals (eg. find a means of transportation out of the small-town; in our case,
the player needs to find a way to fix up a motor bike), and divide it into
sub-primary-goals (eg. find the parts/items necessary to fix up the motor bike.)
Then we try to come up with the most wacky and creative ways possible to solve
those goals given the settings, items, and other lock-in-key puzzles that we've
already mapped. Actually, the best thing to do so far, I've found, is to focus
on trying to link-up the setting's lock-and-key puzzles with the PC's motives
(ie. yeah, that locked locker in the police-station could contain the helmet we
need to be safely thrown across the ravine.) Sometimes the puzzles flow into one
another, other times they stay independent from one another, but it doesn't
really matter, just as long as we come up with something. And, of coarse, the
more creative the solutions the better.
Unfortunately, this process, as rewarding as it may be per puzzle, takes a
really really long time. Fortunately I have my brother to help. We will
eventually finish the game. I'm sure that once my *first* game is done, every
future game I design will be a whole lot easier! Anyhow, if anybody who has
already made a game has any tips, then please let us know!
Thanks,
Sean
Cedric Knight
Christos Dimitrakakis wrote:
> On Sat, 21 Jun 2003 00:44:32 +0200, Cedric Knight wrote:
>
>> So my questions are:
>>
>> Where do you begin in your designing? Where do you call a day on
>> the designing and begin coding? How can you get feedback on an
>> outline or design before the coding begins?
>
> Designing *is* coding. As far as past work is concerned, the only
> thing I might salvage are descriptions and then again, I never take
> them verbatim from previous work. Puzzles cannot be salvaged and
> code is rarely portable enough from game to game. Even code that
> begins as a core engine ultimately gets forked into innumerable
> revisions.
I'm not sure I understand. I wasn't asking about re-use or code design.
I was asking about what is decided on (or written about) the player
experience or story before you code. Sometimes this can be just mulling
over the design when doing something else after the coding has started.
>> Do you design player goals
>> hierarchically or sequentially?
>
> I have never tried to create a story. So far all my WIPs are based
> on a setting and the exploration of a backstory. Thus, there are no
> goals are than which the player creates for himself.
Do you mean puzzle-free IF? And surely a backstory is a story?
BTW Zachary grasped exactly what I meant by 'gatekeeper' puzzles; if the
need for them turns up in beta-testing, it can be hard to ensure that
all the conditions are met befoer the player progresses.
>> Also - can you give an amnesiac PC motivation? How do you
>> motivate the player?
>
> Have you played 'Deja Vu'?
I can't remember.
CK
Gene Wirchenko
>On Sat, 21 Jun 2003 00:44:32 +0200, Cedric Knight wrote:
>
>> So my questions are:
>>
>> Where do you begin in your designing? Where do you call a day on the
>> designing and begin coding? How can you get feedback on an outline or
>> design before the coding begins?
>
>Designing *is* coding. As far as past work is concerned, the only thing I
^^^^^^^^^^^^^^^^^^^^^^
Nope. The two are separate steps. Design is comparable to
coming up with a set of blueprints for a house. Coding is comparable
to building the house.
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
L. Ross Raszewski
> ^^^^^^^^^^^^^^^^^^^^^^
> Nope. The two are separate steps. Design is comparable to
>coming up with a set of blueprints for a house. Coding is comparable
>to building the house.
>
This is the philosophy of hardcore software engineers, and it's a
broken analogy. Design and implementation simply aren't separable in
in software the way they are in architecture. A distinction can be
drawn, but it's nowhere near as hard a separation as the analogy
implies. It's closer to the distinction between writing an outline for
a book and actually writing the book, though even that analogy is
pretty rough. A fully specified design document with no ambiguity *is*
a computer program, whether or not it's expressed in an established
programming language. (If you really want to blow your mind, analogize
design and implementation to willing an action and performing it, then
read some David Hume and watch your brain explode.)
henrik
archive yet, but I have written many games with BASIC in Finnish.
Currently I'm learning Inform and designing my first English game for
archive release, so maybe my answers have even some points of interest
even though I'm not any well known author…
> Where do you begin in your designing?
That varies from game to game. It depends on what kind of a game it
is, so usually I start from the most important and go for the puzzles,
which I design last.
> Where do you call a day on the designing and begin coding?
When I worked with basic, I coded the structure of the parser as I was
designing. One time I programmed over 100 random messages to give if
the parser should fail to comprehend. I might also code descriptions
for the few first rooms or so, but can't go on very thoroughly since I
usually design the puzzles last.
> How can you get feedback on an outline or design before the coding begins? (Alternatively, how do you avoid getting attached to 'finished' work so that you don't mind junking or radically altering most of it?)
I don't. I usually scrap every idea that I get until I one day go
through them and might find something I like. When I write them, I
hate every one of them. If it should happen that I get to design my
idea into a game, it's as it is and I'm not going to change it. If
people won't like it, it's too bad, but at that time I've lost
interest to what they might think of it.
And when the game is finished, it's finished. I don't touch it
after that. I don't want to make a single line of code after it's
done. Except if I receive drastic bug reports. Then I get mad at the
test players.
> What is the germ of your idea? Setting, characters, motif, story or puzzles? What next?
Setting. Setting is the most important to me. If I ran into an
interesting environment, I usually find it intriguing to design a game
to it. Then I start designing the setting and go onto the
character(s). After that I start brainstorming bits and pieces of the
story and finally head on for the puzzles. I have a bad habit of not
thinking about programming while designing, so when I finally start
coding the game, I have to change most of it because of the
limitations of my programming abilities.
> Are many elements abandoned in the design process, or do you go with the first thing that occurs even if it doesn't fit with the other design aspects?
I think of lots of things and take the pieces I like. If they don't
fit the design, I alter the design so that it fits.
> Do you design player goals hierarchically or sequentially? Did you decide to do things in this order, or did one of the elements (e.g. the story) inspire you enough to determine the rest of the design?
Once I've got the setting, characters and the outline of the story, I
ran to the difficulty of designing the puzzles and hints to them. It's
so difficult to me that if I get an idea, I take it and run. So I
don't think of the order.
> Also - can you give an amnesiac PC motivation? How do you motivate the player?
I try to make up a story that is worth telling. And reading of course.
That should motivate the player enough. I don't think that killing
someone close or similar event motivates that much. They are just
fictional characters on the screen. The involvement has to come
through the story. Just like in movies you start feeling for the
heroes if it's well written. One you've made that involvement through
the story, you can start motivating by killing them.
> A second thing that I think I've learnt is the importance of
'gatekeeper' problems. If you give the players masses of territory to
explore with masses of objects to play with, it's not conducive to
successful puzzle solving (I noted this in my comments on Trapped in
School). So it seems that new possibilities should be fed to the
player piecemeal, with something, e.g. a classic lock-and-key, to
prevent progress for a while to make sure that the player has seen
everything in the earlier scenes. Has anyone found they have had to
add elements like this late in the design?
I think it's very important not to expose the world too soon. I you
give 200 rooms with many interesting objects, average player don't
feel it's worth it. There's no chance of solving even one puzzle like
that. You need to expose the world gradually so that the player gets
to know the surroundings. It also brings the motivation.
That also brings us back to the setting. I can't stand games with
"You're in a crossing of caverns, all alike."
And it's important to keep the path open or at least prevent the
player to go into a different section of the game without doing
everything in the previous section. I hate it when I die in the last
room because I haven't done something in the first and can't go back
to it.
henrik
Christos Dimitrakakis
> Christos Dimitrakakis <oleth...@oohay.com> wrote:
>
>>On Sat, 21 Jun 2003 00:44:32 +0200, Cedric Knight wrote:
>>
>>> So my questions are:
>>>
>>> Where do you begin in your designing? Where do you call a day on the
>>> designing and begin coding? How can you get feedback on an outline or
>>> design before the coding begins?
>>
>>Designing *is* coding. As far as past work is concerned, the only thing
>>I
> ^^^^^^^^^^^^^^^^^^^^^^
> Nope. The two are separate steps. Design is comparable to
> coming up with a set of blueprints for a house. Coding is comparable to
> building the house.
>
>
When programming directly from and RFC or other type of rigorous
specification then I could imagine the RFC being the 'design', as in 'what
we want this program to do'. The actual code design, the structure of the
code, is never
visible until you start the implementation. Some people like to do that
using little boxes and lines instead of writing code. However, boxes and
lines are the same thing as writing a skeleton high-level code and empty
classes.
However, writing IF is different because there is no specification. When
writing a game for your own personal satisfaction, there is no previous
intention - no design to follow. Even when there is (such as when you have
an interesting story idea), it frequently changes when problems in
implementing your intentions arise. Furthermore, the act of enriching your
environment with interesting models in your code might make it possible
for you to add new stuff to the game that you would not have thought of
adding before, as long as these interesting models can be used in more
situations that that for which you had originally coded them.
So, there are two things to keep in mind: Firstly, that a code design
involves the creation of different layers of abstraction, one of which
being the actual code. However there is no definite line separating 'code'
from 'design' and in some cases, such as in hardware design[1], they are
one and the same. Secondly, that game-writing is an open ended process in
which the story can drive the coding as much as the coding can drive the
story. It is ultimately up to the author to decide, when writing the
story/description:
For example, if I am writing a room description and I mention how the
sunlight streaks in from the window, the moment I am writing that I might
think "Hey, but shouldn't the description change when it is night?". Right
there and then I must also make a code design decision - or at least keep
in mind that I will have to make it in the future. Not implementing a
general way to handle night descriptions and/or the passing of time and
later having a point in the game where it is necessary for a scene to take
place at night, will force me to either go back and change all those
descriptions that need changing or disallow movement of the player to
places that were designed for the day.
All these arguments are akin to the bottom-up/top-down design debate. Even
the people that propose RFCs do have an implementation in mind when they
are proposing them - they have to propose something feasible, after all.
The process of creation cannot be broken down into design/implementation,
whether this is at the story/game level or whether it is as at the
architecture/code level.
[1] In hardware design you usually create a set of modules, which act like
objects, that communicate with each other in a very specific way. The
initial thing that is created is this inter-communication path. As you do
that you think of the reasons why those modules would work like that. You
write some code for each module to test the general principle of the thing
- i.e. whether certain states of affairs can bring the whole process to a
halt/loop. You might then go down a level and do the same thing for each
of the modules, breaking them into sub-modules. The point here is that the
module specification and intercommunication must be exact from the very
beginning. At any point in the process you can start creating building
blocks from low-level items, however you do not want to waste time to
create a building block that will not be of use. The thing is, that the
design is no different from the implementation, because the lines that you
are drawing between two modules will be actual connections in the real
thing. And if you're just talking about a simulation, they *are* the real
thing.
PM Virgin
First, somebody wrote:
>>>Designing *is* coding.
To which Gene Wirchenko replied:
>> Nope. The two are separate steps. Design is comparable
>> to coming up with a set of blueprints for a house. Coding is
>> comparable to building the house.
Then, Christos Dimitrakakis wrote:
> When programming directly from and RFC or other type of
> rigorous specification then I could imagine the RFC being the
> 'design', as in 'what we want this program to do'. The actual
> code design, the structure of the code, is never visible until
> you start the implementation. [Snip]
> However, writing IF is different because there is no
> specification. When writing a game for your own personal
> satisfaction, there is no previous intention - no design to
> follow. Even when there is (such as when you have an
> interesting story idea), it frequently changes when problems
> in implementing your intentions arise. [Snip]
I feel the need to object. This kind of thinking smacks of traditional
thought -- It appears to me that you have assumed that only 1 person is working
on this game. My current WIP is broken into 3 parts (Designer, Coder, Writer).
This is due to the fact that I am not sufficiently satisfied in my abilities to
Code or Write (though I may be better at each than a random person). As such, I
believe the analogy that Gene presented is, indeed, accurate.
[Caution: The following contained gender biased content - no offense is
implied, I'm just being lazy]
An architect may know how a building needs to be put together on paper, but is
not necessarily qualified to actually construct it himself. Likewise, a
carpenter might be able to read a blueprint, but be unable to make one (or
subsequently correct one) himself. If such a carpenter had a problem, it would
not be a bad idea (at least, in theory) to address his concerns to the
Architect so as to solve the problem without creating dozens more.
PM Virgin
PM Virgin
___________________________________________________________________
Abstinence makes the groin grow hornier...
PM Virgin
First, somebody wrote:
>>>Designing *is* coding.
To which Gene Wirchenko replied:
>> Nope. The two are separate steps. Design is comparable
>> to coming up with a set of blueprints for a house. Coding is
>> comparable to building the house.
Then, Christos Dimitrakakis wrote:
> When programming directly from and RFC or other type of
> rigorous specification then I could imagine the RFC being the
> 'design', as in 'what we want this program to do'. The actual
> code design, the structure of the code, is never visible until
> you start the implementation. [Snip]
> However, writing IF is different because there is no
> specification. When writing a game for your own personal
> satisfaction, there is no previous intention - no design to
> follow. Even when there is (such as when you have an
> interesting story idea), it frequently changes when problems
Gene Wirchenko
>On Tue, 24 Jun 2003 23:13:49 GMT, Gene Wirchenko <ge...@mail.ocis.net> wrote:
>> ^^^^^^^^^^^^^^^^^^^^^^
>> Nope. The two are separate steps. Design is comparable to
>>coming up with a set of blueprints for a house. Coding is comparable
>>to building the house.
>This is the philosophy of hardcore software engineers, and it's a
>broken analogy. Design and implementation simply aren't separable in
>in software the way they are in architecture. A distinction can be
They are. Not totally perhaps, but they can be separated to a
large degree.
>drawn, but it's nowhere near as hard a separation as the analogy
>implies. It's closer to the distinction between writing an outline for
Granted, but I have seen plenty of programs where it was obvious
that the "design" was done at the keyboard. It really shows. Shure,
you may have to adjust a design some when it comes to brass tacks, but
coming up with it whole cloth at the keyboard is asking for trouble.
>a book and actually writing the book, though even that analogy is
>pretty rough. A fully specified design document with no ambiguity *is*
>a computer program, whether or not it's expressed in an established
>programming language. (If you really want to blow your mind, analogize
>design and implementation to willing an action and performing it, then
>read some David Hume and watch your brain explode.)
Sincerely,
Gene Wirchenko
>On Wed, 25 Jun 2003 01:13:49 +0200, Gene Wirchenko wrote:
>
>> Christos Dimitrakakis <oleth...@oohay.com> wrote:
>>
>>>On Sat, 21 Jun 2003 00:44:32 +0200, Cedric Knight wrote:
>>>
>>>> So my questions are:
>>>>
>>>> Where do you begin in your designing? Where do you call a day on the
>>>> designing and begin coding? How can you get feedback on an outline or
>>>> design before the coding begins?
>>>
>>>Designing *is* coding. As far as past work is concerned, the only thing
>>>I
>> ^^^^^^^^^^^^^^^^^^^^^^
>> Nope. The two are separate steps. Design is comparable to
>> coming up with a set of blueprints for a house. Coding is comparable to
>> building the house.
>When programming directly from and RFC or other type of rigorous
>specification then I could imagine the RFC being the 'design', as in 'what
>we want this program to do'. The actual code design, the structure of the
>code, is never
>visible until you start the implementation. Some people like to do that
I was not talking about "code design"; I was talking about
"design" as in the design of the system.
>using little boxes and lines instead of writing code. However, boxes and
>lines are the same thing as writing a skeleton high-level code and empty
>classes.
It depends what kinds of boxes and lines. An Entity-Relationship
Diagram is nothing like the code. A flowchart is though.
>However, writing IF is different because there is no specification. When
>writing a game for your own personal satisfaction, there is no previous
>intention - no design to follow. Even when there is (such as when you have
>an interesting story idea), it frequently changes when problems in
>implementing your intentions arise. Furthermore, the act of enriching your
>environment with interesting models in your code might make it possible
>for you to add new stuff to the game that you would not have thought of
>adding before, as long as these interesting models can be used in more
>situations that that for which you had originally coded them.
So you refine your design. Cycling through designing and coding
is better than trying to do both at once.
>So, there are two things to keep in mind: Firstly, that a code design
>involves the creation of different layers of abstraction, one of which
>being the actual code. However there is no definite line separating 'code'
>from 'design' and in some cases, such as in hardware design[1], they are
>one and the same. Secondly, that game-writing is an open ended process in
>which the story can drive the coding as much as the coding can drive the
>story. It is ultimately up to the author to decide, when writing the
>story/description:
>
>For example, if I am writing a room description and I mention how the
>sunlight streaks in from the window, the moment I am writing that I might
>think "Hey, but shouldn't the description change when it is night?". Right
>there and then I must also make a code design decision - or at least keep
>in mind that I will have to make it in the future. Not implementing a
Right. Now, bringing in design considerations, you ponder
whether it is worth the effort that it will cost in other rooms. If
it is worth it, you often work out some general ways of handling the
issue, rather than adhockery in every room.
>general way to handle night descriptions and/or the passing of time and
>later having a point in the game where it is necessary for a scene to take
>place at night, will force me to either go back and change all those
>descriptions that need changing or disallow movement of the player to
>places that were designed for the day.
Whichever way you go is a design decision. I hold that it is
better to make it a design decision than to make a number of coding
decisions.
>All these arguments are akin to the bottom-up/top-down design debate. Even
>the people that propose RFCs do have an implementation in mind when they
>are proposing them - they have to propose something feasible, after all.
>The process of creation cannot be broken down into design/implementation,
>whether this is at the story/game level or whether it is as at the
>architecture/code level.
To add another way, I usually code loops from the inside out.
After all, you know you want to repeat something, and you usually know
this before you know exactly what circumstances the looping is to
start and to stop.
>[1] In hardware design you usually create a set of modules, which act like
>objects, that communicate with each other in a very specific way. The
>initial thing that is created is this inter-communication path. As you do
>that you think of the reasons why those modules would work like that. You
>write some code for each module to test the general principle of the thing
>- i.e. whether certain states of affairs can bring the whole process to a
>halt/loop. You might then go down a level and do the same thing for each
>of the modules, breaking them into sub-modules. The point here is that the
>module specification and intercommunication must be exact from the very
>beginning. At any point in the process you can start creating building
>blocks from low-level items, however you do not want to waste time to
>create a building block that will not be of use. The thing is, that the
>design is no different from the implementation, because the lines that you
>are drawing between two modules will be actual connections in the real
>thing. And if you're just talking about a simulation, they *are* the real
>thing.
Agreed.
Mark J Musante
> (If you really want to blow your mind, analogize design and implementation
> to willing an action and performing it, then read some David Hume and
> watch your brain explode.)
Dare I attempt to read a work by someone who could out-consume Wilhelm
Freidrich Hegel?
-markm
P.S. Or, by some accounts, *both* Schopenhauer and Hegel.
Christos Dimitrakakis
I don't think so. As the Designer, do you only make your decisions based
on your goals? Do you not take the coding constraints into account? Though
you might not have the actual responsibility to code, you must be able to
(as you say you are) understand more or less how the thing can be
implemented.
From what I observed in my
experience, everybody talked about everything in the design process. There
is no fine line between coding and design - it is just a simple design
hierarchy, in which every tier places constraints on all other tiers.
[snip example]
All distinctions between design and coding are arbitrary, for example here
is another house analogy:
The architect has the same role as the coder. He creates a conceptual
sketch of the house in cooperation with the client. Then he codes the
house, specifying every little detail. Some details don't work out as he
had originally envisioned, but in the end he finishes the blueprint.
Remember, the blueprint allows direct construction of the house without
any further intervention from the architect. The people that construct the
house have the same role as the compiler. No matter which construction
company you get, you'll have more or less the same results. They might
call you up sometimes to ask about specific 'optimizations' such as
whether to use the standard wood or the more expensive stuff. Of course,
if there is an error on the blueprint then the workers should abort and
report it, without guessing.
Edmund Kirwan
> Christos Dimitrakakis <oleth...@oohay.com> wrote:
>
> >On Wed, 25 Jun 2003 01:13:49 +0200, Gene Wirchenko wrote:
>
> I was not talking about "code design"; I was talking about
> "design" as in the design of the system.
Although the above is a pertinent point, it seems that most people
think that design and coding are different things (most, not all).
That being the case, surely the excellent TADS/INFORM etc are coding
tools.
That being the case, are there any IF design tools out there? And if
not, what would they look like? Or are we all back-of-an-envelope
designers?
.ed
Andrew Plotkin
> ge...@mail.ocis.net (Gene Wirchenko) wrote in message news:<3efa22c1...@news.ocis.net>...
>> Christos Dimitrakakis <oleth...@oohay.com> wrote:
>>
>> >On Wed, 25 Jun 2003 01:13:49 +0200, Gene Wirchenko wrote:
>>
>> I was not talking about "code design"; I was talking about
>> "design" as in the design of the system.
> Although the above is a pertinent point, it seems that most people
> think that design and coding are different things (most, not all).
> That being the case, surely the excellent TADS/INFORM etc are coding
> tools.
Fair enough.
> That being the case, are there any IF design tools out there? And if
> not, what would they look like? Or are we all back-of-an-envelope
> designers?
There's a bit of an excluded middle there, isn't there?
I've done a lot of code design, including some very complex projects,
and I've never used code design *tools*. I take notes, with whatever
degree of formality is appropriate. (Not the back of an envelope,
that's too easy to lose.) If I'm working with other people, the notes
may become a detailed design document.
Or are you asking about design techniques, as opposed to software?
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
PM Virgin
> I don't think so. As the Designer, do you only make your
> decisions based on your goals?
broad strokes of how the game should look and work -- I test and edit
accordingly.
> Do you not take the coding constraints into account? Though
> you might not have the actual responsibility to code, you must
> be able to (as you say you are) understand more or less how
> the thing can be implemented.
I understand enough to know what can possibly be done. I may wish to push the
envelope a bit, but I always try to keep it within reach of the Programmer. If
he informs me that the effort required would be exorbative, I re-evaluate the
necessity and, perhaps, come up with an alternate solution.
> From what I observed in my experience, everybody talked
> about everything in the design process. There is no fine line
> between coding and design - it is just a simple design
> hierarchy, in which every tier places constraints on all other tiers.
While that may be true, you must remember that not everyone thinks in the
same manner. While I can visualize the movement through the game in my mind, I
am still unclear as to exactly how to get there (thus the need for somebody
more code oriented).
But, just because there is no fine line between coding and design doesn't
mean there is no line -- because some might make the same argument about design
and prose, and then you'd have coding and prose writing in the same vein.
As I have stated previously, I view the make-up of a game like a body. The
Design is the Bones and Cartilage -- decerning the overall form of the game.
The Coding is the Muscles and Organs -- making sure that the game can move and
work the way it should. The Writing is the skin and fat (and such) --
presenting the game in a fashion more pleasing to the eye, ensuring that people
might interact with it rather that go screaming from the room.
Later,
PM Virgin
_______________________________________________________________
What doesn't kill me, annoys the hell out of me...
The Despoiler
>This is the philosophy of hardcore software engineers, and it's a
>broken analogy. Design and implementation simply aren't separable in
>in software the way they are in architecture. A distinction can be
>drawn, but it's nowhere near as hard a separation as the analogy
>implies. It's closer to the distinction between writing an outline for
>a book and actually writing the book, though even that analogy is
>pretty rough. A fully specified design document with no ambiguity *is*
>a computer program, whether or not it's expressed in an established
>programming language. (If you really want to blow your mind, analogize
>design and implementation to willing an action and performing it, then
>read some David Hume and watch your brain explode.)
As the undisputed "Custodian of Unfinished WIPs" title holder, I'd
love to see more CASE tools to automatically convert my Designs into
Code. (which I definately visualize as two separate stages)
Most of my projects never get past the Design Phase. They consist of a
few maps, a list of characters with personality notes, some object
descriptions, and a State Transition Diagram for the player's
milestone goals. Somehow, I never seem to get around to do the coding,
though.
When I do code IF, I seem to get caught up in the details. For
example, having to come up with a unique response for common
interactions with every single character in the game usually saps all
my enthusiasm.
Luckily, what I am able to code are my Engines. Primitve base classes
to describe common game elements which I can then re-use all over the
place with minimal customization. However, there is a HUGE investment
of time needed to write and test the Engines and I'm anxious to
release some games!
Anyway, the point is that I believe any sort of IF CASE tool would
need to be dependent on the author's personal Engines. Basically, what
I'm talking about is a simple GUI where you insert the map, add a
character, enter basic information about the character, choose a base
class to derive the character from, enter their starting location,
etc... Maybe this tool could even accept the goal transition diagram.
Once everything was entered, you'd press Generate Source Code and
obtain a rough skeletal file that could immediately be compiled into
z-code / TADS gamefile.
_____
The Despoiler
Plugh!
> not, what would they look like? Or are we all back-of-an-envelope
> designers?
Well, there have been many begun and just as many abandoned, over the
years. One or two still flicker on hte verge of life.
I first posted in 1996 proposing such a tool. In 2000 I finally got
the finger out & started coding. If you are developing for TADS, I
expect to go beta "Real Soon Now" (tm).
Use a GUI to draw a map - add rooms, drag them around, connect them
with passgaes, change your mind, delete, rename, till your heart's
content; use multiple maps for a clearer overview; define some NPCs
and objects for your charatcer to interact with; generate error-free
TADS code. I also allow full manipulation of the class tree, class
properties, etc. I am just teaking the vocabulary handling at the
moment, then I reckon it will be design complete.
The goal of the project is to remove the housekeeping from i-f design
& implemntation, to offer consistency checks where viable, to do away
with those blessed pieces of paper that lay around everywhere, saving
that endangered species, the eraser; to handhold newbies, to do the
drudge work for i-f gurus, to generate only compilable code and still
to allow the user to create anything which he could create with a
plain text editor - a darn sight more easilly.
I don't have plot management yet, but that's because I'd prefer it to
be user driven (*) and no-one has yet stated what they expect from
such a feature, nor how it should look.
(*) I prefer it to be user driven, because I know, sure as grues are
grues, that if I just design & code something & present it here, I
will be flooded with with comments about how it really ought to look &
work.
So, please visit http://plugh.info look at the screen shots, download
it & play around with it. Then provide some feedback. What do you
love, what do you hate, what's missing? If you can describe a
funstionality which you would like to see and which I consider
reasonable, then I will undertake to implement it.
Inform coders, take heart, I started with TADS but would like to add
Inform support in a future release, so please give comments too.
Thank you and good night!
A hollow voice says "http://plugh.info"
The Despoiler
>A hollow voice says "http://plugh.info"
Very cool! This is very much the sort of IF CASE tool I was
describing!
And I must take back my earlier statement that such a system would
need to be dependent on the author's personal library of game engines.
Clearly, your tool addresses this, allowing each author to manage
their own custom classes through the IDE. I guess my restriction was
only applicable to any such tool *I* were to develop *myself* ( I'm
very lazy ;)
Alright, so you want some more Plugh design input...
Well, do you understand what I mean by my Goal Transition Diagram? I
don't tend to design my games using the Gatekeeper methodology,
transporting the player through a series of different environments.
Instead, I like the player to return often to the same locations as
the story unfolds.
It seems every game I dream up can be modelled as a Finite State
Machine. Characters / locations / objects in the game universe have
different behaviour depending on the current state of the game, and
different actions or milestones move the game into new states.
My most ambitious projects ( the ones furthest from being coded :\ )
have very complex state diagrams. This is largely due to the
(seemingly) tedious amounts of maintenance code I would need to write,
repeatedly doing the same thing: testing a series of conditions before
allowing / disallowing certain actions.
It would be great if, for example, the CASE tool anticipated that all
my conversation topics depended on the current game state, the
generated code would switch off topic and quip, and state as well.
> ask joe about knife
State A,B: Quip 1: "What about it, inspector?" He asks non-chalantly.
State A,B: Quip 2: "The servants must have removed it..." He says
dismissively.
State C: default: "And just what are you insinuating!" He demands,
growing defensive.
State D,E,F: default: "You'll never take me alive!" He shouts,
suddenly tearing out of the parlour! [ If game in state D, move to
state G else move to state J ]
( Even writing this example was tedious! ;)
Of course, I may be in the minority for this sort of game design...
_____
The Despoiler
Plugh!
> Machine.
> Characters / locations / objects in the game universe have
> different behaviour depending on the current state of the game, and
> different actions or milestones move the game into new states.
>
> My most ambitious projects ( the ones furthest from being coded :\ )
> have very complex state diagrams. This is largely due to the
> (seemingly) tedious amounts of maintenance code I would need to write,
> repeatedly doing the same thing: testing a series of conditions before
> allowing / disallowing certain actions.
>
> It would be great if, for example, the CASE tool anticipated that all
> my conversation topics depended on the current game state, the
> generated code would switch off topic and quip, and state as well.
>
> > ask joe about knife
>
> State A,B: Quip 1: "What about it, inspector?" He asks non-chalantly.
> State A,B: Quip 2: "The servants must have removed it..." He says
> dismissively.
> State C: default: "And just what are you insinuating!" He demands,
> growing defensive.
> State D,E,F: default: "You'll never take me alive!" He shouts,
> suddenly tearing out of the parlour! [ If game in state D, move to
> state G else move to state J ]
>
> ( Even writing this example was tedious! ;)
>
> Of course, I may be in the minority for this sort of game design...
I strongly believe that you are. However, if you can state an FSM
thread & show that a few others work that way, I could certainly
consider adding such a feature to the to-do list.
Are we speaking only of stetes of the whole game (starting/disccoeverd
corpse/arrested, etc) or of states of the various obejcts in the game?