Game Design in General.
Gerry Kevin Wilson
Well, as interesting as the last week or so of Inform questions have
been, I find myself bored enough to start a new thread. It occurs to me
that probably every one of you knows exactly how I go about writing a
game, but I've yet to hear the slightest on how the rest of you go about
it. Perhaps a little sharing of information is in order? I like to hear
someone besides myself talk about game design every so often. I mean, I
know you're all writing games, so share with the group already. :)
--
<~V~E~SOF~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~>
< RTI T Imagination sold and | ~~\ >
< G O WAR E serviced here. | /~\ | >
<_______________________...@uclink.berkeley.edu__|_\__/__>
John Baker
Kevin Wilson) writes:
>it. Perhaps a little sharing of information is in order? I like to
hear
>someone besides myself talk about game design every so often. I mean,
I
>know you're all writing games, so share with the group already. :)
For my first game, I was trying to teach myself TADS. So I went
through adv.t and tried to use every object at least once and came up
with puzzles that way. I'm sure some of the games' detractors won't be
surprised to hear that. :)
--
John Baker
"What the hell does that mean? Huh? 'China is here.'?
I don't even know what the hell that means!"
- Jack Burton
Christopher E. Forman
: Well, as interesting as the last week or so of Inform questions have
: been, I find myself bored enough to start a new thread. It occurs to me
: that probably every one of you knows exactly how I go about writing a
: game, but I've yet to hear the slightest on how the rest of you go about
: someone besides myself talk about game design every so often. I mean, I
: know you're all writing games, so share with the group already. :)
I've got an article on non-computerized I-F design tools and techniques
coming up in XYZZYnews #4.
--
C.E. Forman cef...@rs6000.cmp.ilstu.edu
Read the I-F e-zine XYZZYnews, at ftp.gmd.de:/if-archive/magazines/xyzzynews!
* Interactive Fiction * Beavis and Butt-Head * The X-Files * MST3K * C/C++ *
Andrew C. Plotkin
> been, I find myself bored enough to start a new thread. It occurs to me
> that probably every one of you knows exactly how I go about writing a
> game, but I've yet to hear the slightest on how the rest of you go about
> it.
First I come up with some nice scenes and images. (For "Weather" it
was... mm... I don't want to get into spoilers, but it was the idea of
seeing the same scenery in different weather and times of day.)
Then I decide to write a game.
Then I come up with the story. Theme, plot, characters, ending (not
that I'm any good at characters.)
Now I need puzzles. I already have the first: figuring out what the
plot is and what the ending must be. (This is always a puzzle. What's
the point of IF, else?) I start dumping out more scenes, writing them
down on a big piece of paper, considering each one in terms of
possible puzzle content. Maybe half of these scenes will make it into
the final draft, most likely heavily altered. However, since I'm
trying to maintain the theme and atmosphere of my story as I create
all of these images, I know the final result will be on the right
track.
As I'm doing this, I start to pick out scenes (and puzzles) that I
like, to be in the final version. Later scenes are shaped with
attention to fitting in with the ones I've chosen. At this point I'm
concentrating on making things weave together, so that nobody notices
how patchwork the whole process is. :)
Eventually I have this huge structure carefully balanced on top of my
head, a little machine with every part working correctly. Then I write
it down, generally as a map or plot diagram with lots of
incomprehensible little boxes.
Then I start implementing.
There is a non-zero chance I've made an error in the design process.
This is likely to be a trivial alternate solution. (It's easy to avoid
the mistake of making an impossible game -- just play it through on
paper -- but it's hard to see every possible combination of actions,
when I just went to all the effort to make everything intertwine.) If
I find an error, usually halfway through programming, I scream and
rend somebody limb from limb, and then start patching. Patching
usually involves throwing away some good stuff in order to fix the bad
stuff. This sucks.
Then I finish implementing.
"Weather" did in fact turn up an error halfway through programming --
in fact, it was the stupid kind -- the game was unsolvable. I did some
hasty scratching on my plot diagram, and nobody's complained that the
seams show, so it must have worked. Heh. (I don't have my notes here,
and I don't remember exactly what the error was. Sorry.)
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
Jamieson Norrish
whiz...@uclink.berkeley.edu (Gerry Kevin Wilson) writes:
[How do *you* design IF games.]
Well, I am probably not qualified to answer this, since I haven't ever
written a IF game, and I'm not really in the process of doing so
(though I have got a game on hold at the moment). But anyway, the way
I started was to think up an overall idea for the game: a sort of
amorphous setting/"plot"/characters combination. Once I've added thet
things I definitely want/need in the game, I start to figure out if
anything else is demanded not by my conception of the game but by what
I've done so far. For example, if the game is set in a house, should I
include some typical "house trappings", even though these are not a
part of the interesting bits of the game that I've designed.
And that's it, really. To be slightly more helpful, I like writing
things down in a somewhat structured format. Like, a description of
the game, the setting, the characters, the objects, the "plots". Also,
after that's done, the more technical details: particular scripts for
characters (not in code, just description), details of any particular
physics that will be needed, and so on. Then, I guess, it's just a
matter of writing all the code.
Jamie
Gerry Kevin Wilson
Jim Newland <76461...@CompuServe.COM> wrote:
>
>WARNING! THE FOLLOWING IS FAIRLY LONG (BUT NOT NEARLY SO LONG AS A
>PSYCH PROFESSOR'S PERORATION, SO TAKE HEART)...
Long perhaps, but certainly interesting.
>Having settled on the plot, puzzles, and etc., I've learned that (at
>least in my case; if anyone disagrees about this method, I'd be
>interested in hearing their comments) its best to code the story in
>"passes." The aim of the first pass is to get a complete, working game,
[snipage throughout post.]
So far, we have a very similar method. First I write the rooms, then I
test the exits, then I dump it to a text file and spellcheck it, then I
go through pulling out every object in every room, for incarnation as
decorations.
>Sorry about that. Ok, after the skeleton game is done and I've beat up
>object as completely as I can, with the sole exception of NPCs'
>dialogue. I pull out my printed copy of the verb library--as well as
>considering any new verbs and commands I have added, of course--and run
>down the list for each object, trying to imagine the various ways an
>item might be used and giving due attention to the various locations in
>the game, since it may seem entirely reasonable to the player to try
>using an object in some very particular way in some particular location
>me the ideal to be strived for in the second pass, even if it is never
>likely to be achieved.
I don't worry about total coverage yet. I try to make sure the puzzles
work at this stage. Later I worry about the frills.
>Finally, after all this, I will make the last pass, in which the major
>task is the consideration of NPC dialogue, encyclopedia entries, and
>the like. In the case of NPC dialogue, my experience has been that if I
>try to "make it up as I go along," I invariably end up with either a
>very dull character or a decidedly schizophrenic one (since I will have
>forgotten by the end many of the particulars of his/her personality
>which I had in mind in the beginning). Also, after the game is more or
Here's the main difference I see. For me, my characters evolve as I go
along, and I add to/edit them when inspiration/the mood strikes me. I DO
have a final consistancy check on NPCs though, to check that they remain
in character. Generally, I have a very distinct personality in mind for
the NPC though, so it isn't too hard.
As for not releasing a game yet, I wouldn't feel bad. I talk the talk,
but I'm still trying to walk the walk. Of course, I'm getting quite
close to doing so, but we'll see.
--
<~~~VERTIGO~~~~~~~~~~~~THE~BRASS~LANTERN~~~~~~ISSUE~1~INCL~W/AVALON~~|~~~~~~~>
< In the irreverent tradition of _The New Zork Times_ comes The | ~~\ >
< Brass Lantern, an informative newsletter from Vertigo Software. | /~\ | >
<___SOFTWARE____________...@uclink.berkeley.edu__|_\__/__>
Jim Newland
>Well, as interesting as the last week or so of Inform questions have
>been, I find myself bored enough to start a new thread. It occurs to
>me that probably every one of you knows exactly how I go about writing
>a game, but I've yet to hear the slightest on how the rest of you go
>often. I mean, I know you're all writing games, so share with the
>group already. :)
WARNING! THE FOLLOWING IS FAIRLY LONG (BUT NOT NEARLY SO LONG AS A
PSYCH PROFESSOR'S PERORATION, SO TAKE HEART)...
Having settled on the plot, puzzles, and etc., I've learned that (at
least in my case; if anyone disagrees about this method, I'd be
interested in hearing their comments) its best to code the story in
"passes." The aim of the first pass is to get a complete, working game,
with all the somewhat extraneous elements like menus and such in place,
but with only the bare minimum of commands required to solve it
included. In other words, I don't try to code for every possible action
the player might take with respect to this or that object, nor do I
provide for any alternate solutions at this point. Anyhow, after I have
this "skeleton" game in hand, I will try to subject it to every kind of
abuse I can dream up in order to anticipate and correct problems which
might crop up during play; I want to make sure that, no matter what I
do later on, the game will be solvable and, for lack of a better word,
"consistent" in its gameplay.
(Whoops! Back up; the above should really be step two. Step one can be
considered a distinct step: I first code up the map, as completely as I
can, with perhaps a few necessary objects but for the most part empty,
so that I can walk through it, critiquing and perfecting the room
descriptions and checking that all the movement directions provide the
proper passage or yield appropriate messages--note: this can also be a
good way to see how best to break up my files, since I can't bear
trying to edit one ultra-long game file and I tend to separate it out
according to some geographical principle. *Then* I move on to what I
described above).
Sorry about that. Ok, after the skeleton game is done and I've beat up
on it a little, I move on to pass two (or three, depending on how
you're counting at this point), in which I go back and treat every
object as completely as I can, with the sole exception of NPCs'
dialogue. I pull out my printed copy of the verb library--as well as
considering any new verbs and commands I have added, of course--and run
down the list for each object, trying to imagine the various ways an
item might be used and giving due attention to the various locations in
the game, since it may seem entirely reasonable to the player to try
using an object in some very particular way in some particular location
(or in combination with some other object) which I hadn't considered
when I first conceived the game (certain objects are particularly prone
to this kind of usage; like ladders, for example). But this doesn't
mean that I actually provide special routines for every possible use of
every possible item; that would be practically an impossible task in
all but the shortest of games. Yet I do try to anticipate and consider
each possibility, so that I (hopefully) don't miss the really important
and reasonable things (or the many opportunities for a good joke which
arise from this fine-toothed-comb treatment). "Total coverage" is for
me the ideal to be strived for in the second pass, even if it is never
likely to be achieved.
Finally, after all this, I will make the last pass, in which the major
task is the consideration of NPC dialogue, encyclopedia entries, and
the like. In the case of NPC dialogue, my experience has been that if I
try to "make it up as I go along," I invariably end up with either a
very dull character or a decidedly schizophrenic one (since I will have
forgotten by the end many of the particulars of his/her personality
which I had in mind in the beginning). Also, after the game is more or
less complete and writ in stone, it is much clearer exactly what the
character's actual role in the game is and what the proper scope of
his/her "knowledge" about things. This isn't to say that I consider it
a cardinal sin to put in a dialogue response during one of the earlier
"passes"; if I come up with a good line, I want to include it before I
forget it. But all things considered, I've found it preferable to code
up my characters' dialogue and behavior (as far as possible) at a
single sitting.
The case of encyclopedia entries (and other similar things) is somewhat
the same, yet the reason for saving the bulk of these for the third
pass is more like the case of any other object in the game. I don't
have a problem with adding entries as I go along, and this is even
preferable, really, since the text of any given entry will be far more
complete and appropriate (both in terms of what is said and what is
*not* said), when I have clearly in mind the actual atmosphere and
conditions of the game which exist at the time the player will be
consulting the encyclopedia--this is always most clear when one is
actually coding and doing the heavy lifting of the game development.
But I think it's advisable to add a separate, dedicated consideration
to this element of the game for completeness' (and again, humor's)
sake, and there's no very compelling reason which ought to prevent this
from being saved until the last.
All that having been said (hey! you still awake out there?), it is a
fact that I have never yet released a game. Why, then, should anyone
pay any attention to what I've said? Well, perhaps they shouldn't. I'm
very far from claiming that my way is best for everyone (or even for
me; I'm open to being persuaded otherwise). On the other hand, I have
four separate games at fairly advanced stages of completion which I
have grown frustrated with and, in essence, junked, because I violated
the "rules" I set out above--or, to put it more accurately, I have
learned this mode of procedure in the school of hard knocks. Now that
I am proceeding on my fifth game in what is, for me, a more orderly and
consistent way, the going is proving very much smoother.
But I'm with Whizzard. I'm interested in hearing the opinions of you
others out there. C'mon, guys, spill it!
Jim Newland
76461...@compuserve.com
Andrew Clover
> It occurs to me that probably every one of you knows exactly how I go
> about writing a game, but I've yet to hear the slightest on how the
> rest of you go about it.
I'm weird! I actually came across the prologue and the solution to it for
my not-at-all-finished game in a dream! In fact I've dreamed of playing
adventure games more than once... is there something wrong with me?
Problem is, I expect this way means you get warped and illogical puzzles.
BCNU, AjC
Peter Pun
here ?
Peter
Magnus Olsson
Peter Pun <72550...@CompuServe.COM> wrote:
>Would some kind of Object Oriented design methodology be useful
>here ?
To give you a straight and simple answer: yes and no. :-)
A piece of IF is a computer system. OOA/OOD/OOP are certainly useful tools
in designing and implementing computer systems.
However, IF is also literature. How do you apply OOD to the task of
writing a story? Possibly, you could think in OO terms about the
interrelations of various plot elements. It's an interesting prospect...
Magnus
Phil Goetz
>A piece of IF is a computer system. OOA/OOD/OOP are certainly useful tools
>in designing and implementing computer systems.
>However, IF is also literature. How do you apply OOD to the task of
>writing a story? Possibly, you could think in OO terms about the
>interrelations of various plot elements. It's an interesting prospect...
>Magnus
Right. Obviously, what we need is neural networks. And fuzzy logic.
:)
Phil Go...@cs.buffalo.edu