Why is writing your own parser so much fun?
Branko Collin
When you read this newsgroup regularly, you cannot but notice that
when people (mostly newbies, I guess) declare they are writing a game
and its parser at the same time, usually forming an integrated whole,
they get discouraged by regulars who tell them it is much easier to
use one of the development tools already available.
In another thread I mentioned that I have yet to release an IF game,
which is strictly speaking not true. In my TRS-80 and C-64 days, I did
release a game or two among friends, and got pretty far in writing
some other games. The common factor of these games, as opposed to
games I did not get far in writing, was that I did not just write the
game, but I also wrote and coded the parser at the same time.
This got me thinking. Why is writing your own parser so much fun?
People will probably suggest that I am more the programmer type, but I
would have to disagree strongly. I am not very good at programming,
and although I can enjoy it, I still see it mostly as a way to a
means. The reason I program is because there are computing tasks that
I would like to be able to do, but there is no software that lets me
do them: the proverbial itches that need scratching.
I then realised (always keeping in mind that introspection is the
worst way of finding out what moves people) that it is not so much the
programming of the parser that I like, but using the development tools
that I dislike.
Now this is strange, because these tools really are good. What makes
me dislike using them so much?
My guess is that when you are writing a game and a parser in one, you
are constantly aware of the restrictions of your gaming environment.
However, if you are writing a game using one of the existing
development tools (TADS, Inform, &c.), it is like you are a kid in a
candy store and know no limits. You just start having fun without
looking at the consequences, which will, however, soon become
apparent.
The first game that I started writing in Inform was one that I had
already designed in my C64 days, but never got around to implementing.
I started embellishing all the room and object descriptions, only to
find out that now I had to test for every possible action that the
Inform library allowed the player to do on every piece of scenery I
had put in.
Had I written my own parser, it would have been almost certain that
the player would not have had so many options. Technically, I could
have ripped a lot of possible interaction out of the Inform version,
but I know that you should not fuck with user expectations, so I could
not.
In other words, rather than 'just' knowing your programming language
inside and out, in the case of all the wonderful development tools (I
say this without sarcasm, I still do believe they are wonderful) you
have to know the playing environment as well, which means you will
have to know a lot more about your sofisticated and sometimes complex
development tool than just which command goes where. In the case of
Inform it probably helps enormously if you know the library inside and
out. But what is the fun in analysing the library if what you want to
do is essentially a writing task, not a programming one? Strangely
enough, in my case, programming in Inform becomes forces me much more
to be a programmer type than if I wrote my own parser.
That is why I understand and sympathise with the people that announce
writing their own parser to their game.
(I still will try and grasp Inform, though, it will just take much
longer to give birth to my first game.)
--
branko collin
col...@xs4all.nl
Sneed the Sort of Crazy
"Branko Collin" <col...@xs4all.nl> wrote in message
news:3901ba9a....@news.xs4all.nl...
> I then realised (always keeping in mind that introspection is the
> worst way of finding out what moves people) that it is not so much the
> programming of the parser that I like, but using the development tools
> that I dislike.
>
> Now this is strange, because these tools really are good. What makes
> me dislike using them so much?
>
> My guess is that when you are writing a game and a parser in one, you
> are constantly aware of the restrictions of your gaming environment.
> However, if you are writing a game using one of the existing
> development tools (TADS, Inform, &c.), it is like you are a kid in a
> candy store and know no limits. You just start having fun without
> looking at the consequences, which will, however, soon become
> apparent.
It's simply a matter of what the author can, or chooses to, hold in his or
her head at one time. Those who use a particular system a lot (and
regularly) feel pretty much as comfortable with it as you did with your
homebrewed system--the reason being that they are familiar enough with their
environment that they know what is and isn't possible and then how to go
about the things that are. As a consequence, the development system becomes
integrated with the whole project in the author's mind in the same way that
yours did with you. It's only a matter of scale: those who've basically
mastered the big, "complete" systems are just you writ larger.
(This is in no way intended as some kind of backhanded putdown, btw. It
simply reflects the fact that others apparently put more time and effort
into learning their development system than you care to. I was once in the
same boat, and in truth I find myself returning to it constantly as I take a
few weeks or months off and then have to relearn or remember this or that
aspect of Hugo. The thing is, the exact same thing would happen to me even
if I had written Hugo myself.)
Think about it. What is a Hugo, or a TADS, or an Inform, but just your more
modest system multiplied a bit?
--Sneed the Sort of Crazy
aka Cardinal Teulbachs
Branko Collin
Yep. I started again a few days ago (actually, after posting the
message you respond to) for the nth time, and the fact that I had
tried to program Inform several times before made it a lot easier.
Once I started programming objects that were less than trivial, I
started having fun too. (A small pond can become very big very
quickly: I can put my hand in it, but put something very light like a
leaf on top of it, I can see stuff lying at the bottom, but also my
reflection in the surface, it contains water which is always a horror,
even if you refuse the player to drink from it or put it in another
container -- OK, so it is no rope)
I am sorry, I digressed. What I wanted to say is that apparently, at
least in my experience, learning a general purpose programming system,
writing your own parser and your own game at the same time can be more
fun than learning a specific adventure programming system (that
outputs the parser) and writing your own game at the same time.
--
branko collin
but, I should warn you, this is no time for complacency.
no, there are still many things, and I cannot emphasize
this too strongly, /not/ on top of other things. -- monty python
Jonadab the Unsightly One
> It's simply a matter of what the author can, or chooses to, hold in his or
> her head at one time. Those who use a particular system a lot (and
> regularly) feel pretty much as comfortable with it as you did with your
> homebrewed system
Yes, absolutely.
> --the reason being that they are familiar enough with their
> environment that they know what is and isn't possible and then how to go
> about the things that are.
Then some of us get stubborn and decide that what we want to do
ought to be possible, so we change the parser so that it is
possible. This creates bugs, but what fun is programming
without a few of those? That's why Inform is so nice. If
you want, you can screw up the parser any way you like.
--
Forward all spam to u...@ftc.gov
Kevin Forchione
news:3906e7f7...@news.bright.net...
> Then some of us get stubborn and decide that what we want to do
> ought to be possible, so we change the parser so that it is
> possible. This creates bugs, but what fun is programming
> without a few of those? That's why Inform is so nice. If
> you want, you can screw up the parser any way you like.
TADS 3 will provide a level of magnitude more enjoyment!
--Kevin