How do you work?
Darren Holmes
I'm interested in hearing how you work on your IF.
Do you sit down and work out the plot and puzzles on paper then do your
coding, or do you get ideas as you go?
Or do you do a little bit of both, revising your written ideas as you go or
changing your code in mid-stream?
I'm sure there's advantages and disadvantages to both approaches.
Darren
--
Darren Holmes
McMillan
www.thinkup.com
afr...@my-deja.com
"Darren Holmes" <darren.take.t...@thinkup.com> wrote:
> Hello,
>
> I'm interested in hearing how you work on your IF.
>
Firstly, I'm no expert on the subject. But I would suggest that you
should work in whatever manner you most enjoy. Otherwise, you'll never
finish what you've started.
And, whislt planning is important for overall coherence, I found that
once my game world was up and running my ideas for objects and puzzles
changed just from walking around in it. So I would suggest you plan out
your game, work out what your world should look like, and when you've
got comfortable with it don't be frightened to throw all your old ideas
out and start again.
Also, a little rule of thumb I discovered (to my anguish): One day's
coding will buy you about three days bug fixing down the road, so don't
bite off more than you can chew! :-}
<AG>
Sent via Deja.com
http://www.deja.com/
Robb Sherwin
<darren.take.t...@thinkup.com> wrote:
>I'm interested in hearing how you work on your IF.
>Do you sit down and work out the plot and puzzles on paper then do your
>coding, or do you get ideas as you go?
>Or do you do a little bit of both, revising your written ideas as you go or
>changing your code in mid-stream?
Something that might help:
Chris Crawford's long essay on game design is available here:
http://www.vancouver.wsu.edu/fac/peabody/game-book/Coverpage.html
I've been reading through it again, and although it's slightly tainted
towards strategy games, there's some good bits in it regarding how to
approach game creation. If we're makin' games like it's 1980, then his
take on things from 1982 can still help.
Robb
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Robb Sherwin, Fort Collins CO
Reviews From Trotting Krips: http://ifiction.tsx.org
Knight Orc Home Page: www.geocities.com/~knightorc
Hans Persson
> Do you sit down and work out the plot and puzzles on paper then do your
> coding, or do you get ideas as you go?
>
> Or do you do a little bit of both, revising your written ideas as you go or
> changing your code in mid-stream?
So far, I've been working out a (very) rough outline, then started to
code, and changed and added things as things got finished. Most of the
original stuff is probably in there, but also lots of stuff that
wasn't in the original plan.
It's not uncommon to come up with a devious puzzle while coding, and
it'd be a pity not to use it, right? >;-)
Hans
--
+----------------------------------------------------------------------------+
| Hans Persson http://www.lysator.liu.se/~unicorn/ |
| uni...@lysator.liu.se http://www.lysator.liu.se/~unicorn/fandom/ |
+----------------------------------------------------------------------------+
John Colagioia
> Hello,
> I'm interested in hearing how you work on your IF.
> Do you sit down and work out the plot and puzzles on paper then do your
> coding, or do you get ideas as you go?
> Or do you do a little bit of both, revising your written ideas as you go or
> changing your code in mid-stream?
> I'm sure there's advantages and disadvantages to both approaches.
Of course, the short answer is "I don't," given the fact that I've played
around with Inform for several years, now, and haven't actually created a game.
However, what little work I've done uses the approaches that come from the
"recreational programming" I've done outside of IF: Specifically, I write up a
synopsis of what I want to do, a list of interesting things I think need to be
included, and jump into coding, usually handling the overall layout (which I
assume would be the equivalent of rooms and the map) first. The reason I
single out the rooms (and I have done this much a few times) as going first is
that it gives you the opportunity to walk through your "world" early on in
development, which gives a nice sense of accomplishment, I think.
An indication of that sense of accomplishment, by the way: I teach a graduate
course in programming languages at my local university, and I use Inform to
illustrate certain object-oriented programming concepts. I then typically
assign a series of short assignments, starting with the creation of a few
rooms. I have never seen graduate computer science students so excited as when
they hand in that particular assignment--because they got instant feedback by
being able to walk around in their new "game."
Wendy Shaffer
<darren.take.t...@thinkup.com> wrote:
> Hello,
>
> I'm interested in hearing how you work on your IF.
>
> Do you sit down and work out the plot and puzzles on paper then do your
> coding, or do you get ideas as you go?
>
> Or do you do a little bit of both, revising your written ideas as you go
> or
> changing your code in mid-stream?
>
Well, I'm only just now working on my first real game, so I imagine that
my working style might evolve quite a bit. But here's how I've worked
so far:
I start with a rough sort of plot/setting idea. Then I do a bit of
brainstorming, just scribbling down ideas for objects, puzzles,
or anything else that I think I might want to put in the game. When
I feel like I have enough ideas to get started, I sit down, and
start coding.
I like to work on a few rooms at a time. I'll draw a rough map of 3 or 4
rooms, and jot down a list of the most important objects or NPC's that
are found there. Sometimes I'll write a sort of mock walk-through of
what the player might experience playing through that area. (I find
this useful with complicated objects - they're easier to code if I've
already thought about what actions the player might try, and what the
responses might be, in advance.)
After I've got those few rooms coded, I compile the game, and play
around with it. I fix all the obvious bugs, and usually come up with
a few new ideas. When I'm satisfied with that section of the game,
I draw up another couple of rooms on the map, and repeat the process.
---wendy
--
Wendy Shaffer
wsha...@uclink4.berkeley.edu
Read my poem "Icarus" at Strange Horizons. (http:www.strangehorizons.com)
Stark
<darren.take.t...@thinkup.com> wrote:
> Hello,
>
> I'm interested in hearing how you work on your IF.
I personally get really excited by an idea, then do lots of design and
planning. I think of some really clever ways of doing things and start
considering ways to make the NPCs really useful and realistic. I then sit
down for eight hours and code solidly, testing as I go.
The next day, however, I realise that at the current rate of progress, it
would take me three years to complete. I then get bitter and go and play
Unreal Tournament instead of working on the game. I tend to pick up the
code and repeat the above process every three months or so... <grin>
Hope this helps, Stark
P.S. Yes, I really am this bad at working on games! I hope you have more
success...
Jonadab the Unsightly One
> I'm interested in hearing how you work on your IF.
Very sporadically. HTH.HAND.
- jonadab
Kathleen M. Fischer
>
> I'm interested in hearing how you work on your IF.
After years of starting lots of things and never finishing them, then a
few more years of years working diligently on a single game using the
"coding as you go" method without the end in sight, I finally stumbled
on a method that seems to work for me (ie, I finished 2 (yes TWO) games
last year!)
Note: These were short, story games, so this might not work for other
kinds.
I decide what I want to write about, then sit down with Microsoft Word
and start writing. At first it's just a story, told in second person. I
create hyperlinks and bookmarks to wisk me from one part of the story to
next, often times leaving dangling links of things I want to support
later, but don't want to get involved with at the time. I create a
border around related text, and throw different "rooms" and/or "scenes"
on different pages so I can get a good feel for how it will look when
actually running (in Inform)
I find that by creating the entire game in MSW, with all links,
conversations, objects, and rooms described before I touch a SINGLE line
of code, I save myself a lot of extra work.
For one thing, I don't get attached to a particular room, object, or
puzzle just because I spent a lot of time coding it (something I did
before - to the detriment of previous, unreleased games. Anyone want a
great mirror object that accurately reflects what you are wearing
(including layered clothing were some parts are visible and others
aren't) and carrying (only the outide objects, of course) <sigh> What a
colossal time sink THAT was, as in the end the game changed so I didn't
need it. <sigh>)
It also helps to identify plot holes, dead ends, and is GREAT for spell
checking.
I was really surprised how much time I saved just because I avoided the
whole edit/compile/fix/compile/run/get-to-the-spot-I'm-working-on cycle.
It's also much much easier to tweek/refine static text than code like:
print (The)obj;
if (obj has pluralname) print " is ";
else print " are ";
"sitting on ", (the)bigBox, ".";
Ugh.
When I finally finish the story in MSW, doing the programming itself is
actually quite fast - probably because by then, the objects are well
defined, as are their interactive requirements.
For Masquerade I gave myself 2 months to write it, 2 to code it, and 2
to test it (working at about 30-min -> 1 hour per night). Had Real Life
not reared it's ugly head, I think it would have worked out just about
right - as it was, testing got a bit smushed.
Kathleen
--
-- Masquerade (Comp00) - ftp://ftp.gmd.de/if-archive/games/zcode/Mask.z5
-- (but at the moment, it's still in if-archive/incoming)
-- The Cove - Best of Landscape, Interactive Fiction Art Show 2000
-- ftp://ftp.gmd.de/if-archive/games/zcode/Cove.z5
-- Excuse me while I dance a little jig of despair
Daryl McCullough
>After years of starting lots of things and never finishing them, then a
>few more years of years working diligently on a single game using the
>"coding as you go" method without the end in sight, I finally stumbled
>on a method that seems to work for me (ie, I finished 2 (yes TWO) games
>last year!)
>
>Note: These were short, story games, so this might not work for other
>kinds.
>
>I decide what I want to write about, then sit down with Microsoft Word
>and start writing....
[stuff deleted]
>It's also much much easier to tweek/refine static text than code like:
>
> print (The)obj;
> if (obj has pluralname) print " is ";
> else print " are ";
> "sitting on ", (the)bigBox, ".";
>
>Ugh.
I'm not sure how your approach avoids such ugly coding. Is it
that you write out explicitly all the variants for your descriptive
text?
--
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Kathleen M. Fischer
>>
>> print (The)obj;
>> if (obj has pluralname) print " is ";
>> else print " are ";
>> "sitting on ", (the)bigBox, ".";
>>
>>Ugh.
>
>I'm not sure how your approach avoids such ugly coding.
It doesn't avoid the coding of it. It delays the creation of the code until
you are sure you need it, and exactly what it is to say. A large block of
code
like that in an objects description is enough for me to say "Heck, whatever
it
says now isn't really that bad, is it?"
If it was just plain english (in my case) it is much easier to fine tune
until
I get it just right.
>Is it that you write out explicitly all the variants for your descriptive
>text?
Yes and No.
For the most part it avoids it, because such low level routines are only
written to support higher level text. You need it when coding, you don't
need
it when deciding what the table should look like. It's nitpicky code like
that
which quickly make an object a fixture in the game, whether you need it or
not, simply because you spent some much time coding the darn thing that you
can't bear to scrap it. At least that was one of my pitfalls (anyone want a
mirror?).
You also avoid the time wasting edit/compile/fix/compile/run (until you get
to
the appropriate spot)/Drat. That sentance doesn't look quite right./
edit/compile/... cycle.
I do write out complete varients of text at times, or use slashes in my text
to indicate variations to be put in later. For example, in Masquerade at
Hoskins' Field there are various people and critters running around. My text
might look something like:
"You see a child/man/boy/woman/space alien
creeping/crawling/walking/slithering across the grass."
It's quick and easy to write, easy for me to proof read, and later I'll turn
it into the appropriate code... something roughly like:
print "You see a ", random ("child", "man", "boy", "woman", "space alien");
print " ";
print random ("creeping", "crawling", "walking", "slithering");
print " across the grass.";
Which I (personally) don't find as easy to read and is nearly impossible to
run a spell checker on.
Kathleen
-- Masquerade (Comp2000)
-- ftp://ftp.gmd.de/if-archive/games/zcode/Mask.z5
Kathleen M. Fischer
>In article <3A8D...@MailAndNews.com>, "Kathleen M. Fischer"
><greenG...@MailAndNews.com> wrote:
>
>:
>: print "You see a ", random ("child", "man", "boy", "woman", "space alien");
>: print " ";
>: print random ("creeping", "crawling", "walking", "slithering");
>: print " across the grass.";
>:
>: Which I (personally) don't find as easy to read and is nearly impossible to
>: run a spell checker on.
>
>
> You see a -20171 -20168 across the grass.
>
>(You left out the (string).)
Which just goes to prove my point! (no... really)
There I would be, going back into the editor, compiler, editor (as I
probably
would forget a matching ')' somewhere), and running it... just to see if it
looks good. :)
Much easier to develop story text in a text editor, IMHO.
Kathleen (making note to remember large PSUEDO-CODE banner next time <g>)
Marnie Parker
Slowly. Redundantly. Too precisely. Incrementally. After much procastination.
After much soul-searching. In spurts. Now and then. When enthused. When
ambitious. Carefully.
Doe :-) And much too rarely.
doea...@aol.com
Glulx/Glk for Dunces http://members.aol.com/doepage/glkdunces.htm
IF Art Gallery http://members.aol.com/iffyart/
IF Review Conspiracy http://www.textfire.com/conspiracy/
The Tame Computer http://members.aol.com/tamecomputer/
Sean T Barrett
>written to support higher level text. You need it when coding, you don't
>need it when deciding what the table should look like. It's nitpicky code
>like that which quickly make an object a fixture in the game, whether you
>need it or not,
Of my three works in progress:
1. very unfinished, writing the transcript a few rooms
ahead of the implementation at a time
2. in final beta, wrote a transcript of the opening sequence,
the first room description, and then just implemented the
whole thing
3. very unfinished, wrote a transcript without doing any
coding at all, missed the smoochiecomp deadline and
abandoned it
Despite the fact that the only successful one is the one where I didn't
go transcript based, I believe in the transcript approach as well (there
are other factors not described above that influence the failure/success
of each project). I believe in it both for the reasons you give, and
because I've found that there's a different mind-frame necessary to
programming versus writing English text; I find it more effective not
to have to swap constantly back and forth between them. This was even
more true with my item #1, which is written in a language that is
not my primary one, and thus is very slow to even just write as
a transcript.
(I suppose I should argue there are really three separate modes:
designing, writing, and coding, and debugging, FOUR modes...)
>"You see a child/man/boy/woman/space alien
>creeping/crawling/walking/slithering across the grass."
>
>It's quick and easy to write, easy for me to proof read, and later I'll turn
>it into the appropriate code... something roughly like:
>
>print "You see a ", random ("child", "man", "boy", "woman", "space alien");
>print " ";
>print random ("creeping", "crawling", "walking", "slithering");
>print " across the grass.";
Of course, if you used my varying strings compiler extension,
you could just code:
"You see a {%child|man|boy|woman|space alien}
{%creeping|crawling|walking|slithering} across the grass."
or perhaps even better
"You see a {!child|man|boy|woman|space alien}
{!creeping|crawling|walking|slithering} across the grass."
which prevents the random numbers from generating the same
text twice in a row.
SeanB
but I'm not sure why I'm plugging a compiler mod I can't release
Sean T Barrett
>> but I'm not sure why I'm plugging a compiler mod I can't release
>
>improvement here, but I only threw this together in the past week.
Cool! Looks like it can basically do everything my compiler mod
can do, and more (like sequential then random), except for support
for nesting--e.g. "{%one|two|{%three|3}|four}", but that's not
something I use very often.
SeanB
J. Robinson Wheeler
> Despite the fact that the only successful one is the one where I didn't
> go transcript based, I believe in the transcript approach as well (there
> are other factors not described above that influence the failure/success
> of each project). I believe in it [...]
> because I've found that there's a different mind-frame necessary to
> programming versus writing English text; I find it more effective not
> to have to swap constantly back and forth between them.
Transcript-based is definitely how I work, now, especially if there's
a crushing deadline. I can write English text very quickly. I can write
code to print out that English text fairly quickly. Writing code without
that blueprint to work from is much slower, due somehow to the swapping
back and forth process that Sean mentioned. Ineffciency creeps in
somewhere. Brane not like it.
After cranking out three games in a row, with each successive one
allotted only half the development time as the previous, I'm big on
efficiency. I think I've pretty much hit the limit of how speedily
I can turn out a game, though, thank goodness. It just isn't healthy.
--
J. Robinson Wheeler http://thekroneexperiment.com
whe...@jump.net
Roger Firth
news:anson-A5B98E....@news.efortress.com...
> Well, that's not quite the case, I have to confess. There's no option
(yet) to
> prevent the same message being printed two or more times in a row, once it
> gets into "totally random" mode. Which is one of the things I was thinking
of
> when I mentioned "room for improvement". I'll upload it to the archive
after
> I've fiddled with it a bit more.
My rather simpler shuffle.h (available below) does just that.
It never goes into totally random mode; rather, once all the numbers
have been used once, they're shuffled and restarted (omitting the last
once dealt), ensuring that the same value never occurs twice in a row.
Cheers, Roger
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
You'll find my Cloak of Darkness, Parsifal, Informary
and more at http://homepages.tesco.net/~roger.firth
J. Robinson Wheeler
> Here's something that people can actually use. I hope. There's room for
> improvement here, but I only threw this together in the past week.
>
> prand()
> [ and related routines snipped]
>
> HTH. PRAND. Er, HAND.
Hey, neat stuff. I decided that these routines would be just the
thing for a TADS work in progress I'm fiddling with right now, so
I converted your prand() routines to TADS. Can't guarantee they're
bug-free or expertly coded, but prandseq() was working fine for me
yesterday evening.
--=-=-=-=-=-=--
/* print_random_string (prand) routines
Based on Inform routines by Anson Turner
prand()
will print one of the strings at random, but won't print the same
string twice until they have all been printed (at which point it
become completely random). It returns the ordination of the string
printed, e.g., if string 2 is printed, it returns 2.
strand()
works the same way, except it does not actually print anything, but
returns the string. So, you can use strand() calls as parameters to
prand() to have more than 7 strings avalilable: prand(strand([...]),
strand([...])) etc.
prandonce()
prints the strings in sequence, that is, the first time it is
called it prints the first string, the second the second time, etc.
Once all of the strings have been printed, subsequent calls print
nothing (and return nil).
prandlast()
works the same as prandonce(), except instead of printing nothing
once all of the strings have been printed, it keeps printing the
last string.
prandseq()
works the same as prand(), except it first prints the strings in
sequence, then becomes random.
Examples:
"You see a ";
prand( ['child','man','boy','woman','space alien']); " ";
prand( ['creeping','crawling','walking','slithering'] );
" across the grass.";
if ( prand(['You can't possibly lift that.\n', 'Who do you think
you are, Herakles?\n']) == 2 ) question_asked = 1;
if ( prandlast(['You order a pizza under the \'buy now, pay
later\' scheme.\n',
'You can only order one pizza under the \'buy now, pay
later\' scheme.\n']) == 2 )
return true;
*/
#pragma C+
modify global
printed_strings = []
prand_options = 0
;
#define PRAND_SEQUENTIAL_FIRST 1
#define PRAND_HOLD_ON_LAST 2
#define PRAND_RETURN_STRING 4
#define PRAND_DONT_PRINT 8
#define PRAND_NEW_ONLY 16
prand: function;
strand: function;
prandonce: function;
prandlast: function;
prandseq: function;
prand: function( string_list )
{
local ps_temp, val, len, num_unprinted, count, str;
ps_temp = [];
val = 0;
len = length( string_list );
num_unprinted = 0;
if ( len == 0 )
{
say( '\n***Error: prand() call to empty string set\n' );
return nil;
}
for( count=1; count <= len; count++ )
{
local i;
i = find( global.printed_strings, string_list[count] );
if ( i == nil ) // current string has not been printed yet
{
num_unprinted++;
ps_temp += count; // stores index num of unprinted string
}
}
if ( num_unprinted > 0 ) // there is at least one new match
{
if ( ( global.prand_options & PRAND_SEQUENTIAL_FIRST ) != 0 )
val = ps_temp[1];
else
val = ps_temp[ _rand( length(ps_temp) ) ];
}
else
{
if ( ( global.prand_options & PRAND_NEW_ONLY ) != 0 )
return nil;
if ( ( global.prand_options & PRAND_HOLD_ON_LAST ) == 0 )
val = _rand( len );
else
val = len;
}
str = string_list[val];
if ( ( global.prand_options & PRAND_DONT_PRINT ) != 0 )
{
if ( ( global.prand_options & PRAND_RETURN_STRING ) != 0 )
return str;
return val;
}
/* if new, add string to global.printed_strings */
if ( num_unprinted > 0 )
global.printed_strings += str;
say( str );
}
strand: function( string_list )
{
local val;
global.prand_options = PRAND_RETURN_STRING + PRAND_DONT_PRINT;
val = prand( string_list );
global.prand_options = 0;
return val;
}
prandonce: function( string_list )
{
local val;
global.prand_options = PRAND_NEW_ONLY + PRAND_SEQUENTIAL_FIRST;
val = prand( string_list );
global.prand_options = nil;
return val;
}
prandlast: function( string_list )
{
local val;
global.prand_options = PRAND_HOLD_ON_LAST + PRAND_SEQUENTIAL_FIRST;
val = prand( string_list );
global.prand_options = 0;
return val;
}
prandseq: function( string_list )
{
local val;
global.prand_options = PRAND_SEQUENTIAL_FIRST;
val = prand( string_list );
global.prand_options = 0;
return val;
}
--=-=-=-=-=-=--
Kevin Forchione
"Anson Turner" <anson@DELETE_THISpobox.com> wrote in message
> In article <3A92AB41...@jump.net>, whe...@jump.net wrote:
>
> : Hey, neat stuff. I decided that these routines would be just the
> : thing for a TADS work in progress I'm fiddling with right now, so
> : I converted your prand() routines to TADS. Can't guarantee they're
> : bug-free or expertly coded, but prandseq() was working fine for me
> : yesterday evening.
> : /* print_random_string (prand) routines
> :
> : Based on Inform routines by Anson Turner
>
Text-morphing ... hmmm I seem to recall something about this. Oh boy!
No, seriously, you might want to look at TADS library extension:
ftp.gmd.de/if-archive/programming/tads/examples/tmorph.t
This allows you to construct strings, such as
"[|A ball/Balls] of searing flame burst[s/] out of your magic ring,
rebound[s/] off of the ground, and vaporize[s/] the kni[fe/ves] before
[it/they] can reach you."
without having to preface it with a function call.
--Kevin