Re: Potential new IF author needs advice


10 Nov 1995 22:20:51 GMT

In article <boognish-0911950047330001@ts36-7.wla.ts.ucla.edu>,
Chris <boognish@ucla.edu> wrote:
>Hi there. Now, I know I'm gonna get scolded for this, but here goes...
>(putting on flame-retardent jumpsuit) I have a fairly decent idea for an
>IF game and have it more or less mapped out in my head. Only problem is,
>I have NO idea how to program, and quite honestly, little desire to
>learn.

This is going to sound harsh, but it is no flame, just some honest advice:
if you truly have no desire to learn to program, then IMNSHO you'd be better
off writing a novel.

This is based on my experience with my own and other people's games.

Sure, there are authoring systems that are hyped as being for the
non-programmer, such as AGT. My experience is that games produced with
these systems are decidedly inferior to games produced with TADS or
Inform. Usually, this is attributed to an inferior parser; however, I think
the reason is much deeper than that.

In any reasonably capable authoring system, including TADS and Inform, you
can get along fine for quite some time without any real programming, but
just "filling in forms". In the Inform case, for example, you can just
copy rooms and objects from the example games and substitute your own
names and descriptions, and it will work just fine: the library will
handle everything for you.

This works fine up to a point. The problem is that when letting the
library do all the work, you're relying on somebody else - the library
author - having anticipated all the possible things that can happen in
your game. No library author, not even Graham Nelson, can think of
everything.

When you reach that point - you want an object that behaves in just a
wee bit too complex a manner for the "fill in forms" method to work -
you can either give up, and try to get away with simpler behaviour
(which is a pity, but will often work. FOr example, if it's the parser
that's too limited, you could get away with "drop cushion. drop vase"
rather than "put the vase on the cushion." However, sometimes this
doesn't work, and it almost always detracts from the playability of the
game).

Alternatively, you could program the system to behave as you like.
What makes some systems better than others is that you can easily
program them to do what you want. These systems (i.e. TADS and Inform)
seem more complex to the beginner, but the complexity is there for a
reason.

> I've browsed the manuals for TADS and Inform and have become
>disheartened by the idea of all painfully menial code-learning and
>scripting I'd have to go through to design my game.

It's not that bad. Really, it's not that bad at all. You can write
maybe 900f a simple TADS game with hardly any programming at all.
By the time you reach the last 10, you'll probably have become so
immersed in TADS that you'll find that learning to program it isn't
nearly as difficult or boring as you thought.

>I've even dismissed
>ALAN (from what I've heard, the easiest authoring program) as too complex
>for my patience.

Again, sorry if I'm sounding harsh, but if you're that impatient, you
really should try some other genre. Writing IF requires *loads* of
patience, no matter how you do it. To paraphrase Euclid, there is no
royal road to IF.

>Does this mean that I'll
>just have to buckle down and learn the stuff?

To put it frankly: yes.

But take heart: programming is _fun_. Immensely fun. You may not think
so now, but once you get started on your game you'll have a lot more
motivation than you have now.

>Btw, I have a Mac.

An excellent choice, as long as it's decently fast and you have a good
text editor. Writing IF in MacWrite or TeachText isn't very fun at
all. I can recommend a shareware editor called Alpha.

>
>the reluctant programmer,
>
>Chris

Magnus (an enthusiastic programmer)