Anyone actually code their own IF's?
Intrud0r
coded their own IF from scratch. I'm trying to duplicate something along
the zork series lines. I'm having trouble finding a good way of
representing objects, and the actuall world it self. I was also
wondering if anyone has any good documents on some simple techniques
that I may apply to my game objects / world. For example, supposing
there is a table in the room, that would be an object, but there is a
book on the table, I'm having trouble trying to define an object as
simple as that, i.e. objects that can interact with other objects etc..
any suggestions to get me on the right track would be great. By the way
this is my first attempt at a complete text adenture game, and I'm
absolutely wanting to use my own C / C++ code, not some higher level
adventure language. Thanks!
Intrud0r
text adventure games. My purpose is to use this experience as a starting
point to other game programming endeavors, in C++. That's why I don't want
to use a high level language such as TADS. I want to focus on my C++ skills,
and just happen to be wanting to start in this genre because I find it more
interesting than writing yet another space invaders/pac man clone. Also, I
plan to implement fighting, and maybe even realtime elements to the game. So
basically I'm still looking for ideas on how I may implement objects, rooms,
characters etc so they may interact with each other as per the example in my
first post on this subject. If I am in the wrong news group, I would greatly
appreciative of a finger towards the right direction. Once again thanks.
Intrud0r
currently reviewing the general structure of the language, as well as the
example games included. It's been a great help so far. There's one slight
problem, which I didn't realize until I looked into the TADS code. I am
relatively new to C++ programming; in fact so new that I haven't even
touched on OOP as of yet. I see a major foundation of these games seems to
require at least a little bit of OOP. Keeping that in mind, I'm continuing
to attempt to work around the situation, duplicating the TADS system, with
my limitted knowledge. My goal is not to write another language, but merely
a working copy of a TADS like adventure game. Anyhow, this seems to be a
pretty cool news group, and I appreciate all the advice and look forward to
contributing in the not too distant future :)
Intrud0r
TADS, Inform or any other high level language, for repeated use. I'm simply
using this medium as a fun way to brush up my C++ programming skills, while
taking a break from the duller examples used in many tutorials, of which I'm
currently studying. Someone made a great little statement in one of the
replies, pardon my memory, but it was something along the lines of IF being
portable in, and even present in many other mediums, even if it isn't directly
obvious. Take any Sierra game, just about any RPG, Wing commander series, Final
Fantasy VII, etc etc. IF is still very dominent out there, it's just evolved,
and I hope to evolve with it, choosing merely to start at it's roots. If I am
to evolve, using graphics, sounds, etc, while essentially still implementing
IF, it's imperative that I learn a much lower level language such as C++ in
contrast to TADS, or Inform. This way I can actually offer something truly
unique, thoroughly original and last but not least something beyond a text
game, that will appeal to the masses, as opposed to smaller cult-like
following. Not only are there more potential people to enjoy my creation, but I
have complete design freedom, using a lower level language to the extent that I
can add *anything* I want.
There are no, pre-imposed medium limitations using C++ as there are with a very
specific language such as TADS. By that I mean it may start off as a classic IF
text game, but may evolve into much more, that's the reason I'm using C++.
Also, I'm no great C++ programmer, but I'm under the impression a lot of people
here seem to think C++ is just too messy for the job, or something along that
frame of mind. I've redone my code about 20 times already, and each time it's
trimmed down and getting neater, from what I can tell it's got pretty much the
complete functionality of a TADS like command parser in a very reasonable
amount of code. Granted I haven't implemented the beef of the game yet, but I
don't imagine it being THAT much more difficult. So hopefully, that will
dispell some of those thoughts. The source code is primitive too, I'm sure more
experienced people in here could probably write the same code far smaller than
mine. Anyway my point is this: using C++ has it's drawbacks, in that a lot more
attention to detail must be paid to aspects taken for granted in a language
such as TADS, a lot of time is needed thinking up technology that the player
probably won't even notice at first, hence reinventing the wheel.
On the other hand, C++ does allow much more artistic freedom, if I want to
change the interface to graphical, I can, If I want display small cinema's
during key points in the story, I can. There's almost no boundries.What does
this have to do with IF you ask, it's IF, with a spin on it, it's IF on
steriods, it's new, improved, and competely original. Perhaps the goal is not
to reinvent the wheel, but merely to duplicate it's good parts, while adding
improvements as they compliment the original design.
Jonadab the Unsightly One wrote:
> > Matthew Amster-Burton <mam...@u.washington.edu> wrote:
> > >
> > > One question, and I'm not going to be the only one to ask:
> > > WHY? What do
> > > you think you are going to get out of using your own
> > > system that can't be done with TADS or Inform?
>
> okbl...@usa.net wrote
>
> > I can't speak for Intrud0r, but
>
> [reasons snipped.]
>
> > It's fair and good to warn someone that they may be duplicating work, but
> > given the traffic in this forum, and the fact that there are two or
> > three new
> > IF systems being planned (possibly more), and the fact that there are
> > probably dozens of IF systems planned every year
> > (most of which never come to
> > fruition, granted), it's probably naive (?) to suggest
> > there's no good reason to build one.
>
> You may have misunderstood him (though not being a mind
> reader I don't know for sure). Sure, there are plenty
> of good reasons to build a new system. There are also
> plenty of lousy reasons. Asking why does not necessarily
> imply that there's no good answer.
>
>
> Yr. Obd't & Humble Servant,
> Jonadab the Unsightly One.
>
> ----------------
>
> One of the many uses for peanut butter:
> 32. If you have pimples spread it on your face overnight
> as an acne treatment to clear up the complexion.
>
> (Need more uses? see http://members.kconline.com/kerr/pb.htm)
>
> Send replies to username@isp, where username is jonadab
> and isp is bright.net
>
> The zerospam.com address works, but you get an ugly confirmation.
Matthew Amster-Burton
> any suggestions to get me on the right track would be great. By the way
> this is my first attempt at a complete text adenture game, and I'm
> absolutely wanting to use my own C / C++ code, not some higher level
> adventure language. Thanks!
One question, and I'm not going to be the only one to ask: WHY? What do
you think you are going to get out of using your own system that can't be
done with TADS or Inform?
Matthew
Erik Max Francis
> One question, and I'm not going to be the only one to ask: WHY? What
> do
> you think you are going to get out of using your own system that can't
> be
> done with TADS or Inform?
If someone wants to write an adventure authoring system to better their
own skills or learn more about what's involved, there's certainly
nothing wrong with that. It's not like he can make you stop using
whatever it is you prefer to author interaction fiction, after all.
--
Erik Max Francis, &tSftDotIotE / mailto:m...@alcyone.com
Alcyone Systems / http://www.alcyone.com/max/
San Jose, California, United States / icbm:+37.20.07/-121.53.38
\
I put away my nine, fool / 'cause I'm colorblind.
/ Ice Cube
Matt Kimball
: I was just wondering if anyone here is familar with C / C++ and has
: coded their own IF from scratch. I'm trying to duplicate something along
: the zork series lines. I'm having trouble finding a good way of
: representing objects, and the actuall world it self.
I suggest that you familiarize yourself with the way in which the more
popular IF systems do it. I'm sure that there are ways in which you
can improve on what they do, but their authors have thought through
many things that and you can save a lot of time and effort by at least
looking at how they do things first.
--
Matt Kimball
mkim...@xmission.com
Blake McCurdy
The parser was incredibly difficult, but I got it. Took me two months, be
prepared for some nastiness.
Micah, the man in the pan
Matt Kimball (mkim...@xmission.com) wrote:
: --
: Matt Kimball
: mkim...@xmission.com
--
_______________________________________________________________________
| |
| |
| "So then I said 'No, Juan, it's the rice!!' " |
| |
|_____________________________________________________________________|
Darren Sparrow
There's a great book around called The Games Programming Starter Kit. In it
as well as talking and showing you other games, they give you the basics of
a Zork type game. Don't confuse this with TGPSK v2.0.
Try Amazon.com and see if they still carry a copy, the publishers are SAMS
Publishing ISBN 0-672-30825-8. If its not available then I suppose a plea
here for a copy could be worth a try?
Bradd W. Szonye
>
> I would just like to clarify further, that my intent is not solely to
> create text adventure games. My purpose is to use this experience as
> a starting point to other game programming endeavors, in C++. That's
> why I don't want to use a high level language such as TADS. I want to
> focus on my C++ skills, and just happen to be wanting to start in
> this genre because I find it more interesting than writing yet
> another space invaders/pac man clone. Also, I plan to implement
> fighting, and maybe even realtime elements to the game. So basically
> I'm still looking for ideas on how I may implement objects, rooms,
> characters etc so they may interact with each other as per the
> example in my first post on this subject. If I am in the wrong news
> group, I would greatly appreciative of a finger towards the right
> direction. Once again thanks.
[r*if regulars, please forgive me for the arrogant heresy I'm about to
utter! My intent is to give practical advice, not to offend people.]
I think you're looking in the right place for IF tips, but I suspect
that the level of experience for implementing IF in general-purpose
languages is a bit low here. Speaking specifically of IF in C++, I think
you'll find experts on IF implementation (like Zarf and Ross Raszewski)
and experts on C++ (like um *blush* me), but not much of an intersection
of the two.
I'll probably get flamed mercilessly for this, but.... My general
impression here is that the people who are REALLY good at general
programming and design haven't written much IF; like me, they're more
prone to criticize the problems in current IF (like relatively primitive
development tools and non-scalability) than to actually get to work on
IF. OTOH, the folks who are REALLY good at writing IF seem to have a lot
of excellent amateur talent and scorn the "purists" because, well, their
tools are obviously good enough to get the job done as-is.
[This is getting off on a rant, but there seems to me to be a disconnect
between the professionals and theorists who want to improve the state of
IF development tools, and the mostly amateur group of highly-talented
authors who just want to get the job done. It's unfortunate, and I
realize that snobs like me are just part of the problem, but I don't
know what to do about it.]
Anyway, my POINT--you'll probably find a lot of good advice here on
writing IF specifically, but it's likely to be more of a practical
"how-to do THIS" approach than a more generic "how do I make myself a
better programmer" approach, especially if you're looking to be a C++
programmer rather than a TADS or Inform programmer. You'll find lots of
good generic advice here also on what makes games good or bad, and what
people would like to see in games. But if you're looking to become a
better programmer, I'd recommend following groups like
comp.lang.c++.moderated and comp.lang.c.moderated (in addition to this
group).
All that said, r*if is a WONDERFUL community full of talented and fun
people that I really like hanging out with. You won't go wrong by
becoming part of the community; I've really enjoyed it. But you have to
realize that this is a fairly focused group programming-wise, and you'll
want to supplement your participation here if you want to learn how to
write excellent games in C++ or similar languages.
--
Bradd W. Szonye
bra...@concentric.net
http://www.concentric.net/~Bradds
My reply address is correct as-is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
Andrew Plotkin
> [r*if regulars, please forgive me for the arrogant heresy I'm about to
> utter! My intent is to give practical advice, not to offend people.]
>
> I think you're looking in the right place for IF tips, but I suspect
> that the level of experience for implementing IF in general-purpose
> languages is a bit low here. Speaking specifically of IF in C++, I think
> you'll find experts on IF implementation (like Zarf and Ross Raszewski)
> and experts on C++ (like um *blush* me), but not much of an intersection
> of the two.
>
> I'll probably get flamed mercilessly for this, but.... My general
> impression here is that the people who are REALLY good at general
> programming and design haven't written much IF; like me, they're more
> prone to criticize the problems in current IF (like relatively primitive
> development tools and non-scalability) than to actually get to work on
> IF. OTOH, the folks who are REALLY good at writing IF seem to have a lot
> of excellent amateur talent and scorn the "purists" because, well, their
> tools are obviously good enough to get the job done as-is.
Well, since I was named specifically, and since we're being arrogant...
Actually, I'm a shit-hot general programmer as well as one of the
foremost IF writers of the modern age.
So... what's your point again?
--Z
Actually, I can see what you're saying. When I'm doing Inform programming,
I'm not doing general system design; IF game coding is a pile of hacks.
And I haven't talked much about entirely new development systems here
because I haven't *thought* much about entirely new development systems.
The Inform approach (which is pretty much identical to the TADS/Hugo/etc
approach) is doing what I want, so I focus on Inform and the next
generation of *that* lineage.
I don't scorn the purists, I just have to turn off my elegance instincts
because I want to start coding a game *now*...
But yeah, I won't be contributing much to a discussion of C++ IF
programming. That's why. OTOH, I'd rather lurk in such a discussion here
than have it vanish to a non-IF newsgroup.
I'm also not an expert in C++, because I don't use it much. I'm plenty
familiar with OO programming, though. It's the more arcane reaches of C++
that I haven't dealt with (and these days I think "arcane reaches"
includes 85% of the language. :-)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Darin Johnson
Even if you don't want to use a different language, I *strongly* urge
you to look at some sample TADS and Inform games of moderate
complexity.
The reason for this is that you will then be exposed to the sorts of
problems and solutions that come up when writing IF. It will only
cause you grief if you start out with a naive class hierarchy that
needs constant revisions every time realize it is inadequate.
(of course, and expert OO programmer could design it to be easy to
revise, but I get the impression that you're doing this to gain
lots more practical experience)
For instance, if you do your parsing system wrong, you could end up
with a mess like the Fortran/C version of Dungeon, where you
constantly have huge lists of tests to see if this verb affects that
object, and so forth. With a good design, you can add a precious Ming
vase to the game, without changing the code for the "break" verb.
It's fine to reinvent the wheel, and it's fun. But you don't really
want to reinvent all the problems that go along with it.
Finally, for implementation purposes, I would suggest not going with a
traditional class hierarchy. This is because C++ is not very good for
these sorts of things, as it's too strongly typed and too static.
You're going to find you want to add new properties and methods a lot,
but that will cause lots of type conflicts. Instead, I suggest at
least adding a get/set property list. This way, you can add a
"isLightSource" property without changing any classes, and you can get
that property on any object at any time without regard to where the
object is in the hierarchy. In fact, you may be able to have all
objects, regardless of their logical class, be implemented with only
one physical C++ class. (at the least, that promotes re-use, as you
won't have to redesign the entire system whenever you want to have a
different game)
--
Darin Johnson
da...@usa.net.delete_me
Bradd W. Szonye
>
> > I'll probably get flamed mercilessly for this, but.... My general
> > impression here is that the people who are REALLY good at general
> > programming and design haven't written much IF; like me, they're
> > more prone to criticize the problems in current IF (like relatively
> > primitive development tools and non-scalability) than to actually
> > get to work on IF. OTOH, the folks who are REALLY good at writing
> > IF seem to have a lot of excellent amateur talent and scorn the
> > "purists" because, well, their tools are obviously good enough to
> > get the job done as-is.
Andrew Plotkin wrote:
> Well, since I was named specifically, and since we're being
> arrogant...
>
> Actually, I'm a shit-hot general programmer as well as one of the
> foremost IF writers of the modern age.
Heh, I know that. That's why I named you as one of the IF greats.
> Actually, I can see what you're saying. When I'm doing Inform
> programming, I'm not doing general system design; IF game coding is a
> pile of hacks.
Right, and that's why I say that the best general programmers and the
best IF programmers/authors are not necessarily the same people. You
actually complement my point nicely, and probably more tactfully.
> I don't scorn the purists, I just have to turn off my elegance
> instincts because I want to start coding a game *now*...
Well... straying into the minefield here, but... not to target you
specifically, but there's a middle ground between doing everything in
the purist/perfectionst way (my way unfortunately) and getting it done
*now* (the hot-shit programmer way). The former is too prone to not
actually getting anything done, the latter is frequently short-sighted.
There IS a middle ground, the ability to invest time in developing good
practices while still being productive.
The 'hot-shit programmer syndrome' isn't just limited to the IF world
either, although I think it's especially common here. I see it a lot in
the professional world as well. I personally spend too much time seeking
out the best way to do things and criticizing the shortcomings of
designs, and not enough time putting my expertise to good use. But it
still frustrates me to see the opposite end of the spectrum, the really
talented folks who just aren't interested in advancing the state of the
art or, worse, reject suggestions for improvement because their way is
plenty damn good enough already.
> But yeah, I won't be contributing much to a discussion of C++ IF
> programming. That's why. OTOH, I'd rather lurk in such a discussion
> here than have it vanish to a non-IF newsgroup.
Same here--I wouldn't get any opportunities to bitch and moan if folks
didn't talk about these things here. <grin>
> I'm also not an expert in C++, because I don't use it much. I'm plenty
> familiar with OO programming, though. It's the more arcane reaches of
> C++ that I haven't dealt with (and these days I think "arcane reaches"
> includes 85% of the language. :-)
I have to make a confession here: I'm a 'rules lawyer' and a systems
programmer on a major C++ compiler, so it's my hobby and my job to know
the C++ (and to some extent C) standard inside and out. I probably have
a lower tolerance than most for hacked-together software. It's a real
effort for me to remember that programming is only one aspect of IF,
that many or most IF authors don't really care about software
engineering, and that a crusade to inject lofting engineering principles
into the art is not terribly productive.
Still, I'd like to make whatever contribution I can by raising the
consciousness of the average IF programmer. Unfortunately, that means
that I spend a lot of time banging my head against a wall. All too
often, I hear somebody here say, 'oh just do this, it works' when I've
seen first-hand just how badly "it" doesn't work in practice. Even worse
when I try to enlighten the speaker and am met with disbelief or denial.
It's really very frustrating.
Adam J. Thornton
Intrud0r <intr...@globalserve.net> wrote:
>I was just wondering if anyone here is familar with C / C++ and has
>coded their own IF from scratch. I'm trying to duplicate something along
>the zork series lines. I'm having trouble finding a good way of
>wondering if anyone has any good documents on some simple techniques
>that I may apply to my game objects / world. For example, supposing
>there is a table in the room, that would be an object, but there is a
>book on the table, I'm having trouble trying to define an object as
>simple as that, i.e. objects that can interact with other objects etc..
>this is my first attempt at a complete text adenture game, and I'm
>absolutely wanting to use my own C / C++ code, not some higher level
>adventure language. Thanks!
Magnus Olsson has, but I suspect there's an incompatibility between "first
attempt" and wanting to roll it yourself.
Seriously: try writing a (fairly small) game in Inform or something. Then
you'll understand how Inform does its object classes and things. Once you
know that, then you can much more easily see what you like and don't like
about the approach, and you'll be a lot better equipped to think about how
to attack the problem when you tackle it in C or C++.
Adam
--
ad...@princeton.edu
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman
Adam J. Thornton
Bradd W. Szonye <bra...@concentric.net> wrote:
>I think you're looking in the right place for IF tips, but I suspect
>that the level of experience for implementing IF in general-purpose
>languages is a bit low here. Speaking specifically of IF in C++, I think
>you'll find experts on IF implementation (like Zarf and Ross Raszewski)
>and experts on C++ (like um *blush* me), but not much of an intersection
>of the two.
Zarf.
Dunno how much Graham (anyone seen him recently?) knows about C++, but he
certainly knows his C.
Andrew Plotkin
> > I don't scorn the purists, I just have to turn off my elegance
> > instincts because I want to start coding a game *now*...
> Well... straying into the minefield here, but... not to target you
> specifically, but there's a middle ground between doing everything in
> the purist/perfectionst way (my way unfortunately) and getting it done
> *now* (the hot-shit programmer way).
Oh, you misunderstood my comment.
When I said I was a hot programmer, I *meant* being a purist, a
perfectionist, and clubbing people over the head for taking shortcuts.
When I'm doing Inform coding, I'm not doing shit-hot programming. I'm
slugging out a pile of hacks. Why do you think I'm never willing to upload
the source code? :)
Erik Hetzner
: Oh, you misunderstood my comment.
: When I said I was a hot programmer, I *meant* being a purist, a
: perfectionist, and clubbing people over the head for taking shortcuts.
: When I'm doing Inform coding, I'm not doing shit-hot programming. I'm
: slugging out a pile of hacks. Why do you think I'm never willing to upload
: the source code? :)
: --Z
I'm not much of a computer scientist (in fact, not at all), but I do enjoy
well designed systems. IF programming in general lends itself to hacks.
We're dealing with human input, something that we cannot predict. The
best we can do is too figure out the most likely input we'll be given,
and how to respond. And we print some sort of error on all the rest.
That said, I find that the Inform library itself is too much a pile of hacks.
After all, it ought to handle a lot of generic things, and provide a stable
base on which to write a whole bunch of hacks. :) I hope his all makes
sense.
---- Erik Hetzner ---- drunk up all of my money
er...@cafe.berkeley.edu that I borrowed every time
okbl...@usa.net
Matthew Amster-Burton <mam...@u.washington.edu> wrote:
>
> One question, and I'm not going to be the only one to ask: WHY? What do
> you think you are going to get out of using your own system that can't be
> done with TADS or Inform?
>
I can't speak for Intrud0r, but if someone were to ask me this, I would say:
1. A potentially better parser, built on a different paradigm than
subject-object-direct object.
2. Faster execution.
3. Better screen control, if I want it.
4. NPCs that aren't built around giant case statements.
5. Discrete management of the game's text, separate from the code.
6. A space modeling system that's a little more sophisticated than
stick-and-ball.
7. A system that, once I was done with it, I would know well enough to be able
to add whatever functionality to it that I wanted (graphics, video, audio,
maybe just colored text, whatever).
8. Something to with my spare time for the rest of my life.
It's fair and good to warn someone that they may be duplicating work, but
given the traffic in this forum, and the fact that there are two or three new
IF systems being planned (possibly more), and the fact that there are
probably dozens of IF systems planned every year (most of which never come to
fruition, granted), it's probably naive (?) to suggest there's no good reason
to build one.
[ok]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Darin Johnson
> The Inform approach (which is pretty much identical to the TADS/Hugo/etc
> approach) is doing what I want, so I focus on Inform and the next
> generation of *that* lineage.
I don't find Inform to be similar to TADS at all. The basic concepts
aren't even all that similar. Maybe it's just me and they way I think
about them though. I haven't used Hugo, so I don't know what it's like.
> I don't scorn the purists, I just have to turn off my elegance instincts
> because I want to start coding a game *now*...
Hmm, I rarely do that. Maybe it's because I feel that TADS is
more elegant than Inform, overall (though it has it's ugly sides).
The overall TADS object model is very elegant. I don't want to start
a TADS/Inform war here, but if you're going to abandon elegance,
you might as well use C++.
Although I do think it's possible to compile a TADS like language into
Inform, or Z-Machine (I wouldn't want to code up the parser library
though :-). Don't know if it'd be worth it though.
--
Darin Johnson
da...@usa.net.delete_me
Brandon Van Every
Jonadab the Unsightly One wrote in message <01bdadf5$8be0cc00
>
>The perpetual question is, how likely does a possibility have to be
>to be worth coding.
I don't think that's really the question. It's not abstract slavery to some
unknown and imagined model of probability. It's what you get out of it as
an author, and what you want the audience to experience. You could base a
game on really obscure actions, to reward a player who is like-minded. A
sort of shared in-joke between author and astute audience.
It's about whether you're having fun writing or not. I don't see a reason
to author anything if I'm going to live in the tyrrany of the mundane. Nor
am I going to code a game completely according to common sense. I might
just get inspired some night and write something up that's thoroughly
useless. Somebody might defy the odds and trip on that gem - or lump of
coal - someday!
Cheers,
Brandon Van Every
Brandon Van Every
okbl...@usa.net wrote in message <6ob7mi$pea$1...@nnrp1.dejanews.com>...
>6. A space modeling system that's a little more sophisticated than
>stick-and-ball.
I'm not sure I understand. Are you saying you want to get into 3D computer
graphics, or do you want something a lot less than that? How can it really
be "less?" And, assuming you do get the amount of physical consistency
you're after, what authorial value does it add to the IF experience, IYHO?
Finally, why don't you just write 3D graphical adventure games?
>7. A system that, once I was done with it, I would know well enough to be
able
>to add whatever functionality to it that I wanted (graphics, video, audio,
>maybe just colored text, whatever).
So are you saying you want a small system that would be quickly learned? Or
a large system laden with features? Does your personal goal in either case
suit other people's goals? How would one manage the difference, so that one
size does not have to fit all? You might think these issues are irrelevant,
but they do matter if you want your IF system to have a lifespan beyond your
current interest in it. Many hands *can* make lighter work....
>8. Something to with my spare time for the rest of my life.
I think you need to re-evaluate your career. Really, I mean that in all
seriousness. Why are you pursuing IF only in your spare time, if it means
that much to you? Why not try to turn it into real $$$$$$ and get paid
full-time to do what you love? Of course, you're not going to be able to
sell text adventures straight up, but certainly the principles and practices
of IF crop up in many aspects of entertainment software. And the truly
visionary can always force a new medium upon unsuspecting masses, a
transcendance of previous art... are you our visionary?
>It's fair and good to warn someone that they may be duplicating work, but
>given the traffic in this forum, and the fact that there are two or three
new
>IF systems being planned (possibly more), and the fact that there are
>probably dozens of IF systems planned every year (most of which never come
to
>fruition, granted), it's probably naive (?) to suggest there's no good
reason
>to build one.
I dunno, I thought your statement "most never come to fruition" seemed clear
enough.
As someone who has attemped big spare-time projects before, and been bitten
by them, I think the key question is one of morale. What's your REAL goal?
Do you REALLY REALLY just want to build one of these beasts, is that the
goal? If so, great! Get cracking, and enjoy all the time and even years
you'll spend upon it. There's nothing wrong with wanting to produce some
great work, and having high morale that keeps you sailing onwards forever is
a wonderful way to live.
If on the other hand, you're REALLY just wanting to produce a good piece of
IF, and the technology is merely imperfect and sorta in your way, I wouldn't
advise trying to reinvent everything. You will make far more progress if
you simply accept some limitations and concentrate on your authoring, not
all the underlying technology. Flaws in the authoring environment are often
erased by a human's ability to quickly adapt to them.
There are perfectionists among us who want both to build the technology AND
do the artwork. For some maniacal reason we insist on nothing less. The
truth is, we don't manage to get both jobs done consistently well. Said as
someone who still feels this way about 3D graphics, and who struggles with
it everyday despite the fact I should jolly well know better by now.
Cheers,
Brandon Van Every
Jonadab the Unsightly One
>
> : When I'm doing Inform coding, I'm not doing shit-hot programming.
> : I'm slugging out a pile of hacks. Why do you think I'm never
> : willing to upload the source code? :)
> : --Z
>
> I'm not much of a computer scientist (in fact, not at all), but
> I do enjoy well designed systems. IF programming in general lends
> itself to hacks.
> We're dealing with human input, something that we cannot predict. The
> best we can do is too figure out the most likely input we'll be given,
Yes, and the second most likely, and the third most likely, and the
fourth most likely... We can go to great lengths, but we can never
cover all the bases, just the likely ones.
The perpetual question is, how likely does a possibility have to be
to be worth coding.
> and how to respond. And we print some sort of error on all the rest.
Jonadab the Unsightly One
> >
> > One question, and I'm not going to be the only one to ask:
> > WHY? What do
> > you think you are going to get out of using your own
> > system that can't be done with TADS or Inform?
okbl...@usa.net wrote
> I can't speak for Intrud0r, but
[reasons snipped.]
> It's fair and good to warn someone that they may be duplicating work, but
> given the traffic in this forum, and the fact that there are two or
> three new
> IF systems being planned (possibly more), and the fact that there are
> probably dozens of IF systems planned every year
> (most of which never come to
> fruition, granted), it's probably naive (?) to suggest
> there's no good reason to build one.
You may have misunderstood him (though not being a mind
reader I don't know for sure). Sure, there are plenty
of good reasons to build a new system. There are also
plenty of lousy reasons. Asking why does not necessarily
imply that there's no good answer.
Joe Mason
>example games included. It's been a great help so far. There's one slight
>problem, which I didn't realize until I looked into the TADS code. I am
>relatively new to C++ programming; in fact so new that I haven't even
>touched on OOP as of yet. I see a major foundation of these games seems to
>require at least a little bit of OOP. Keeping that in mind, I'm continuing
I'd definitely recommend getting the OOP stuff first, especially since you
mentioned the biggest problems you had were with object modelling. OO is
a very natural system for modelling in adventure games, and being
comfortable with it is really essential.
Second, don't think of OOP as being a part of C++. C++ is OOP hacked on
top of C, and doesn't give a good general picture of what its about. I
recommend Budd (don't have the year, sorry) as a good book to start you
out. It focuses mainly on theory, using four languages (C++, Objective C,
Object Pascal, and Smalltalk) to illustrate points. The differences
between C++ and Objective C - two different ways to layer OO on top of
basic C - are especially illuminating.
At this stage, think of the adventure modelling situation as an
application to apply OO to. It would provide you a good set of
exercises. I'm sure you'll be able to think up much better examples than
the "flower-shop" ones Budd trots out. :)
(Zork note: Budd is fond of platypi, too.)
Joe
Allen Garvin
I was just wondering if anyone here is familar with C / C++ and has
coded their own IF from scratch. I'm trying to duplicate something
along the zork series lines. I'm having trouble finding a good way
of representing objects, and the actuall world it self.
I imagine lots of us old fogeys attempted adventure games in various
languages during the 80's. I tried first in Basic, several times, but each
was an utter failure. (The lack of recursion, which I had never ever heard of
at the time, made writing a good parser nearly impossible. And the incredibly
simple data structures made in impossible to construct objects.)
Then I had this book about writing adventure games in Pascal, but I never
liked or used Pascal much. In the late 80's, I tried C (on a SunOS
environment) when I learned it, and came up with a reasonably
sophisticated game. You can easily make a pretty good text parser with
lex and YACC. I don't have the source anymore, unfortunately (it was a lousy
dungeon crawl anyway); a tree of object structs is the natural way to
represent objects. I remember each object had an array of function pointers
for reactions to verbs. Saving and restoring was EXTREMELY messy, and I never
managed a general UNDO.
The adventure-game specific languages are too wonderful and portable and just
darned useful for me to desire ever to write another game from scratch.
--
Allen Garvin kisses are a better fate
--------------------------------------------- than wisdom
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil e e cummings
Mark Engelberg
Blake McCurdy wrote in message <6o7oq7$2c1$1...@News.Dal.Ca>...
>I am in the middle of programming my own if game from scratch, with C++.
>The parser was incredibly difficult, but I got it. Took me two months, be
>prepared for some nastiness.
>
>Micah, the man in the pan
Could you please elaborate on some of the difficulties you encountered? I'm
certainly willing to believe that it is non-trivial to code a parser, but it
is not obvious to me what the thorny issues are, and I'm curious to know.
--Mark
okbl...@usa.net
("Why would you wanna do blah-de-blah?") which struck me as having myriad
obvious answers, many of which are raised here every day.
Now, as for your specific points:
[ok]> >6. A space modeling system that's a little more sophisticated than
> >stick-and-ball.
>
J> I'm not sure I understand. Are you saying you want to get into 3D computer
> graphics, or do you want something a lot less than that? How can it really
> be "less?" And, assuming you do get the amount of physical consistency
> you're after, what authorial value does it add to the IF experience, IYHO?
> Finally, why don't you just write 3D graphical adventure games?
To answer your questions in order: -> No. -> I'm not especially interested in
3D graphics, and I don't have any way to quantify "a lot less". -> There are
infinite degrees of gradients between stick-and-ball and "real space"
modeling. -> What it will add remains to be seen, but off-the-cuff, I can
say that a more sophisticated model might handle different areas of the same
room, visibility of one room to the next, and so on. -> While I haven't ruled
that out, or ruled out the possibility of a system that accomodates both text
and graphic adventures, I'm personally more interested in the potentials of
the tet medium.
[ok]7. A system that, once I was done with it, I would know well enough to be
> able
> >to add whatever functionality to it that I wanted (graphics, video, audio,
> >maybe just colored text, whatever).
>
J> So are you saying you want a small system that would be quickly learned?
Or
> a large system laden with features? Does your personal goal in either case
> suit other people's goals? How would one manage the difference, so that one
> size does not have to fit all? You might think these issues are irrelevant,
> but they do matter if you want your IF system to have a lifespan beyond your
> current interest in it. Many hands *can* make lighter work....
Once again, in order. -> You've missed the point. -> You've missed the point.
-> You've missed the point. -> You've missed the point.
The (original) question was "Why would you build your own IF system?" An
obvious answer to that is to have total control and mastery over the system,
like an artist mixing his own paint and making his own brushes (which some
do).
To re-answer your questions: -> A system which each part was sufficiently
modular to be as small as feasible for what it does. -> A system which allows
one to be selective, creative and additive with its features. -> It might
suit some other's goals but I gave up my plans for world domination when I
sold DOS to Bill Gates for $50,000. -> If I were to try to "manage" it, I
would probably work it like Java or Visual Basic, where people could write
components for it through a well documented interface, but beyond that,
caveat emptor. (Cave canem?) Counting on collaboration, especially for
*me*, personally, with no apparent history in the field, would be hubris.
> I think you need to re-evaluate your career. Really, I mean that in all
> seriousness. Why are you pursuing IF only in your spare time, if it means
> that much to you? Why not try to turn it into real $$$$$$ and get paid
> full-time to do what you love? Of course, you're not going to be able to
> sell text adventures straight up, but certainly the principles and practices
> of IF crop up in many aspects of entertainment software. And the truly
> visionary can always force a new medium upon unsuspecting masses, a
> transcendance of previous art... are you our visionary?
See my previous note about hubris. I had forgotten, however, that it is
considered hubris around here (to some) to suggest that things might be better
or just different.
Besides which, it would take away from my full-time job of salvaging humanity,
which also doesn't pay that well, but is more fulfilling in the long run.
> I dunno, I thought your statement "most never come to fruition" seemed clear
> enough.
I disagree. I've started many projects. I've finished a relative few. The
ones that I didn't finish (including some experiments in natural language
parsing and generation) often taught me things that I could expand into
profit making ventures. Going back to "Why just do it in your spare time?"
the honest truth is that I don't.
> As someone who has attemped big spare-time projects before, and been bitten
> by them, I think the key question is one of morale. What's your REAL goal?
[etc]
You're preaching to the choir at this point. It has been said that art rests
not in how high you can raise the craft but in how little you are forced to
lower it.
I'm looking for a system that is built with NPCs in mind. It may be possible
to build a different paradigm into TADS or Inform, or perhaps build some ugly
code that allows the author to creatively override certain things and
otherwise provides certain standard behvaiors that give NPCs more life than
they have now. But that problem itself is big enough that I'm not sure one
gains much by starting with a parser and some object classes.
okbl...@usa.net
"Jonadab the Unsightly One" <jon...@zerospam.com> wrote:
>
> You may have misunderstood him (though not being a mind
> reader I don't know for sure). Sure, there are plenty
> of good reasons to build a new system. There are also
> plenty of lousy reasons. Asking why does not necessarily
> imply that there's no good answer.
>
I thought so, too, and I should have spelled that out, thanks. It was just
something that struck me when I read it.
GLYPH
> If someone wants to write an adventure authoring system to better their
> own skills or learn more about what's involved, there's certainly
> nothing wrong with that. It's not like he can make you stop using
> whatever it is you prefer to author interaction fiction, after all.
Right! Writing my own text adventure engine certainly helped my IF
programming skills. But, even though my parser was smarter than the
default Inform parser, I made the switch to Inform the instant I found
out it existed. I'm slowly mutating the Inform parser to be more like
mine with a series of documented hacks, of which version 3 will be
released this week. (The NPC stuff is almost all documented now,
Gunther!)
The reason I switched to Inform is that anybody with a z-machine
interpreter can play my games. I would suggest to someone wanting to
write their own engine that they might use Inform or Tads, toss the
default libraries, and write their own (like Erik Hetzner is doing).
Same amount of work, nearly the same language (similar to C++), with the
added bonus that it compiles to z-code, so everyone can play it.
- GLYPH
Eric O'Dell
Garvin) wrote:
>You can easily make a pretty good text parser with
>lex and YACC.
I was wondering if anyone had used standard parser tools to build a
parser instead of hand-coding the beast. I'd certainly love to hear
how you did it, as I am contemplating doing something similar.
--Eric
+-------------------------------------------------------------------+
| "I have come a very long way from myself only to realize that |
| identity is a skill and self-betrayal is a habit. Once lost, the |
| former is very hard to regain; once gained, the latter is very |
| hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
+-------------------------------------------------------------------+
Brandon Van Every
Intrud0r wrote in message <35A4EB87...@globalserve.net>...
>What does
>this have to do with IF you ask, it's IF, with a spin on it, it's IF on
>steriods, it's new, improved, and competely original. Perhaps the goal is
not
>to reinvent the wheel, but merely to duplicate it's good parts, while
adding
>improvements as they compliment the original design.
I'm all for those sentiments. But given the tasks you described, what about
Macromedia? That's where all the commercial "slideshow" adventures come
from. And I must admit that panoramas can be used to good effect.
Personally I don't think doing things in C++ puts a game "on steroids," we
have plenty of bad examples in the commercial world to disprove this. For
the inquiring mind, the question is what do you want to do with C++ that's
"steroidal?" As opposed to already available off-the-shelf, presuming
you're willing to cough up the bucks for it?
Of course, there's nothing wrong with fun excuses for learning C++.
Cheeers++
Brandon Van Every
Brandon Van Every
okbl...@usa.net wrote in message <6oe312$56v$1...@nnrp1.dejanews.com>...
>
>[ok]> >6. A space modeling system that's a little more sophisticated than
>> >stick-and-ball.
>>
>J> I'm not sure I understand. Are you saying you want to get into 3D
computer
>> graphics, or do you want something a lot less than that? How can it
really
>> be "less?" And, assuming you do get the amount of physical consistency
>> you're after, what authorial value does it add to the IF experience,
IYHO?
>> Finally, why don't you just write 3D graphical adventure games?
>
>To answer your questions in order: -> No. -> I'm not especially interested
in
>3D graphics, and I don't have any way to quantify "a lot less". -> There
are
>infinite degrees of gradients between stick-and-ball and "real space"
>modeling.
Please elaborate, if you care to. I'm skeptical of your claim that there
are "infinite degrees." I think the minute you put in an X Y Z coordinate
system, you're doing 3D graphics. You can say it's all a nodal containment
graph with cardinal compass directions, but how are you going to keep
spatial consistency in the absence of positions and measurements? And isn't
a containment graph just "stick and ball" anyways?
>-> What it will add remains to be seen, but off-the-cuff, I can
>say that a more sophisticated model might handle different areas of the
same
>room, visibility of one room to the next, and so on.
Visibility sounds like a 3D graphics or DOOM problem, not an authorial
problem, IMHO. What kinds of plotlines, puzzles, or stories could you
pursue with visibility as the key ingredient? That you couldn't do
otherwise?
In any event, good luck. With your NPC focus, it almost sounds like you
want to implement Artificial Life via text.
Cheers,
Brandon Van Every
Trevor Barrie
>> One question, and I'm not going to be the only one to ask: WHY? What do
>> you think you are going to get out of using your own system that can't be
>> done with TADS or Inform?
>
>1. A potentially better parser, built on a different paradigm than
>subject-object-direct object.
What sort of paradigm were you thinking of?
>4. NPCs that aren't built around giant case statements.
I can't think of anything in this area that wouldn't be doable in TADS.
okbl...@usa.net
"Brandon Van Every" <vane...@blarg.net> wrote:
>
> Please elaborate, if you care to. I'm skeptical of your claim that there
> are "infinite degrees." I think the minute you put in an X Y Z coordinate
> system, you're doing 3D graphics. You can say it's all a nodal containment
> graph with cardinal compass directions, but how are you going to keep
> spatial consistency in the absence of positions and measurements? And isn't
> a containment graph just "stick and ball" anyways?
>
I'm not sure whence your obsession with graphics comes. You can have XYZ and
angle of orientation and use the same math without ever drawing or displaying
a single picture.
-> A grunt stands 50 feet from you, its weapon poised to fire.
? MOVE FORWARD
-> A grunt stands 45 feet from you, aiming at you.
-> You hear a noise behind you.
? TURN AROUND
This kind of interaction would have limited use in IF, but probably not *no*
use. The actual format of the interaction would be different, too, I suspect.
Now, when I say "stick-and-ball", I refer to the fact that each room is
logically and completely separate with no spatial information at all. There
are some advantages to this kind of format, but they're probably more abused
(say, to build a maze) than used cleverly.
You could lay out a map with strict accuracy and reduce it meters and
centimeters, if you wanted, but sometimes an author just needs the concept of
"far" or "farther". Or an artificial system of measurement, like, "There's a
waterfall and I want anybody within 60 clicks of the waterfall to be able to
hear it."
You want 3D? How about "high" and "low". If a person is "low" this set of
rules apply (whether they're crawling or they've been shrunk). If they're
high, well, you can take it from there.
> Visibility sounds like a 3D graphics or DOOM problem, not an authorial
> problem, IMHO. What kinds of plotlines, puzzles, or stories could you
> pursue with visibility as the key ingredient? That you couldn't do
> otherwise?
Unfortunately, it *becomes* an authorial problem when I want to have a room
or rooms that look into other room or rooms. It's not impossible to do these
things with stick-and-ball, people do them all the time, but it could perhaps
be made simpler.
I'll give you an example of a puzzle I recently coded: It was a hallway with
three sliding partitions. If all three are open you should be able to see to
the end of the hallway, and also all the areas in-between. Again, it's not
impossible to do this with stick-and-ball--it's not difficult to imagine a
system that had "line of sight" properties (WorldClass comes to mind) which
allowed you to specify what room was visible from where--but if you have a
bunch of areas like this, there might be easier ways to express visibility.
> In any event, good luck. With your NPC focus, it almost sounds like you
> want to implement Artificial Life via text.
One thing that apparently isn't clear is that I was simply answering a
question with a wide variety of hypothetical possible answers. The original
question just struck me as like one of the many "Possible IF improvement"
threads, we have. Indeed, I thought one of the purposes of the group is to
raise possibilities and ideas so that they might be implemented in future
systems (or not, if they don't hold up well under scrutiny).
As for my "NPC focus" and your inferences about what they mean, I'm not sure
why almost *any* attempt to improve *any* area of NPC creation becomes
"solving AI". Look at the recent thread on giving TADS NPC commands. I
suspect it could be simpler without having to solve AI, but it may not be
simpler within the context of TADS or any of the other existing IF platforms.
okbl...@usa.net
tba...@ibm.net (Trevor Barrie) wrote:
> On Sun, 12 Jul 1998 20:52:34 GMT, okbl...@usa.net <okbl...@usa.net> wrote:
>
> >1. A potentially better parser, built on a different paradigm than
> >subject-object-direct object.
>
> What sort of paradigm were you thinking of?
I wish I had all the answers, but what about something that encoded
cause-and-effect (like subject-object), only with recursive layers to express
the indirect nature of the cause-effect relationship?
Bob broke the glass.
Bob broke the glass with the hammer.
Bob ordered Charlie to break the glass with the hammer. (Bob used Charlie to
break the glass and Charlie used a hammer to do it.)
The PC says:
::BREAK THE GLASS
The game comes back and says:
::How do you want to break the glass?
::WITH THE HAMMER
The game comes back and says:
::Looks like you could get arrested for that.
::TELL BOB TO DO IT.
::Bob breaks the glass with the hammer. Alarms go off. A dozen
::policemen train their weapons on Bob.
When you get to the "Alarms go off" section, the code is dealing with Bob
breaking the glass, but also the fact that the PC ordered it. Then it becomes
possible for the programmer to code accordingly based on whether Bob did it on
his own or the PC was in on it.
Part of the idea might include having the ability to use the parser in various
places, and possibly in reverse, so that certain facts (information on game
states) could go from an NPC back to the PC.
>
> >4. NPCs that aren't built around giant case statements.
>
> I can't think of anything in this area that wouldn't be doable in TADS.
>
I'd be the last person to knock TADS. I rather like it, and I think it's a
good tool. But imagine the following:
You have a game that's based around, say, six or seven NPCs, let's make them
immortals, and as their purpose in life they go around trying to kill each
other (impossible because they're immortal, but since they're also insane from
boredom...) and maybe they also do artsy-and-craftsy type things like build
mountains or dig canyons.
What you want to do is implement an algorithm that takes an arbitrary number
of the following factors: how successful the NPC's attempts at creating have
been, how many have been defaced or destroyed, who the NPC thinks did it,
what the NPC's history (which changes throughout the game) with other NPCs
is--take these factors and determine how the NPC is going to respond to a PC
who suggests attacking or allying with another NPC.
Now, before somebody jumps on this as being some kind of AI-complete problem,
I'd like to point out that the above could be done without any kind of text
parsing (avoiding that huge area of difficulty) and that the universe in which
this all happens could be very simple (consisting of, say, mountains, canyons,
NPCs, and spaces for them to put their mountains and canyons).
In other words, one could have a pile of events/actions divided into "GOOD"
and "BAD" and do a lot in terms of making NPCs respond appropriately. But
you have to have access to all the events, and each NPC has to have its own
perception of the events, which has to be changeable.
An engine like this could be built and interfaced into TADS but I don't think
TADS itself would be appropriate for building this kind of DBMS.
Adam J. Thornton
Intrud0r <intr...@globalserve.net> wrote:
>On the other hand, C++ does allow much more artistic freedom, if I want to
>change the interface to graphical, I can, If I want display small cinema's
>during key points in the story, I can. There's almost no boundries.What does
>this have to do with IF you ask, it's IF, with a spin on it, it's IF on
>steriods, it's new, improved, and competely original. Perhaps the goal is not
>to reinvent the wheel, but merely to duplicate it's good parts, while adding
>improvements as they compliment the original design.
Well, there you are, then.
What I would ask:
If possible, keep the your-game aspects of your game separate from the
engine, so as you come up with cool features, you can give
away/sell/whatever the engine, so the rest of us can play with it. That
is, since you're going to the trouble to invent a new storytelling system,
keep the design clean enough that other people who want to tell stories in
new media but aren't that interested in writing a system from scratch can
use it.
Ob. IFrelated musing:
I've recently been wrestling with how to implement verbs in an
object-centric database. In some ways the class structure of my tables
(I'm doing this in PostgreSQL) has an implicit verb model built in: that
is, key_objects implement "unlock" because they're keys, all items
implement "get", "drop", "throw", "give" because they're items. But is
this model scalable, or will I end up with so many tiny tables that it's
cripplingly slow?
Trevor Barrie
>> >1. A potentially better parser, built on a different paradigm than
>> >subject-object-direct object.
>>
>> What sort of paradigm were you thinking of?
>
>I wish I had all the answers, but what about something that encoded
>cause-and-effect (like subject-object), only with recursive layers to express
>the indirect nature of the cause-effect relationship?
>
>Bob broke the glass.
>Bob broke the glass with the hammer.
>Bob ordered Charlie to break the glass with the hammer. (Bob used Charlie to
>break the glass and Charlie used a hammer to do it.)
Which would, if nothing else, make it easy to handle sentences with multiple
indirect objects.
>The PC says:
>
>::BREAK THE GLASS
>
>The game comes back and says:
>
>::How do you want to break the glass?
>::WITH THE HAMMER
>
>The game comes back and says:
>
>::Looks like you could get arrested for that.
>::TELL BOB TO DO IT.
>::Bob breaks the glass with the hammer. Alarms go off. A dozen
>::policemen train their weapons on Bob.
I don't think you'll have a lot of luck getting "it" to work properly in
this example. Figuring out what "it" means in a given sentence is, I
think, the sort of context issue that's the hardest part of natural language
parsing.
>> >4. NPCs that aren't built around giant case statements.
>>
>> I can't think of anything in this area that wouldn't be doable in TADS.
>You have a game that's based around, say, six or seven NPCs, let's make them
>immortals, and as their purpose in life they go around trying to kill each
>other (impossible because they're immortal, but since they're also insane from
>boredom...) and maybe they also do artsy-and-craftsy type things like build
>mountains or dig canyons.
>
>What you want to do is implement an algorithm that takes an arbitrary number
>of the following factors: how successful the NPC's attempts at creating have
>been, how many have been defaced or destroyed, who the NPC thinks did it,
>what the NPC's history (which changes throughout the game) with other NPCs
>is--take these factors and determine how the NPC is going to respond to a PC
>who suggests attacking or allying with another NPC.
[...]
>An engine like this could be built and interfaced into TADS but I don't think
>TADS itself would be appropriate for building this kind of DBMS.
I don't see how TADS would be any less appropriate than any other
procedural or object-oriented language. It would be a fairly complicated
algorithm, of course.
Brandon Van Every
Adam J. Thornton wrote in message <6ofq3f$pnj$1...@cnn.Princeton.EDU>...
>
>If possible, keep the your-game aspects of your game separate from the
>engine, so as you come up with cool features, you can give
>away/sell/whatever the engine, so the rest of us can play with it. That
>is, since you're going to the trouble to invent a new storytelling system,
>keep the design clean enough that other people who want to tell stories in
>new media but aren't that interested in writing a system from scratch can
>use it.
Ah, screw that. Better plan: decide whether you're doing this for yourself
or for others. If for yourself, do whatever you feel is necessary to get
the job done. If you're into clean design, great, have fun. But don't
worry about who else is going to use it, or contribute to it. There's a
very good chance in the real world that nobody else will *ever* use it or
contribute to it. And if they're not helping you out now, why plan for
*their* needs?
I'm saying this as someone who wasted 2 years of his time being an utter
perfectionist about the architecture of my Free3D library, designing it to
run on every conceivable OS ever built. Actually had proof of concept, it
was developed on Linux/X11 and ported by another person to Windoze in 2
days. All sorts of wonderful magic regarding configuration files and
portable C++ templates, yadda yadda. Complete waste of time, in hindsight.
I should have coughed out the whole thing for my own needs in 6 months.
Instead, I think I labored on it for 4 years and never really accomplished
all that much of real-world value, so hell-bent was I on the value of
grandiose publically available freeware projects. Until you've got
something that's actually worth sharing with others, worrying unduly about
structure and portability is a complete waste of time. Many problems can be
tackled better from hindsight than from foresight, even if that means
ripping up a lot of code. And hey, if other people really want it, they can
help you when the time is right.
Not that I'm knocking clean design. Just don't go overboard.
Cheers,
Brandon Van Every
David Rush
> Ob. IFrelated musing:
>
> I've recently been wrestling with how to implement verbs in an
> object-centric database. In some ways the class structure of my tables
> (I'm doing this in PostgreSQL) has an implicit verb model built in: that
> is, key_objects implement "unlock" because they're keys, all items
> implement "get", "drop", "throw", "give" because they're items. But is
> this model scalable, or will I end up with so many tiny tables that it's
> cripplingly slow?
Well, Its hard to really grok what you're doing from this brief
decription, but I'll tell you what I found from doing OO persistence
over a RDB (for an MIS app - we modelled the entire business side of a
hospital among other stuff)
Don't.
Really. Don't.
The richer that your data model is, the worse your performance is
going to get. The simple reason is that you end up having to do a
*lot* of complex joins. The magnitude of the problem will depend on
how much of your OO model detail you represent in the RDB (e.g. if you
want your table structure to mirror your inheritance hierarchy, you're
going to end up paying for it).
RDBs are good cool things that are designed to work well on large sets
of isomorphic objects. Most OO environments comprise many small sets
of polymorphic objects (yes, I do mean sets of sets). This is what is
commonly called the "impedance mismatch" between OO and Relational
Databases.
I guess that I really don't mean to say that you shouldn't use an RDB
for an IF app. But you're going to have to be very careful about how
you model the data in the RDB.
david rush
David Rush
> Trevor Barrie wrote in <slrn6ql3hb...@drollsden.ibm.net>,
> > okbl...@usa.net wrote:
> > >1. A potentially better parser, built on a different paradigm than
> > >subject-object-direct object.
>
> The PC says:
>
> ::BREAK THE GLASS
>
> The game comes back and says:
>
> ::How do you want to break the glass?
> ::WITH THE HAMMER
>
> The game comes back and says:
>
> ::Looks like you could get arrested for that.
> ::TELL BOB TO DO IT.
> ::Bob breaks the glass with the hammer. Alarms go off. A dozen
> ::policemen train their weapons on Bob.
> When you get to the "Alarms go off" section, the code is dealing
> with Bob breaking the glass, but also the fact that the PC ordered
> it. Then it becomes possible for the programmer to code accordingly
> based on whether Bob did it on his own or the PC was in on it.
::Bob points at you and says, "It was all his idea! He had a gun in
::his hand! This is a dangerous place!" Six of the policemen
::subsequently aim their weapons at you.
A *really cool* NPC implementation would allow you to "convince" Bob
to break the glass on his own. (AI-complete...blah blah blah) But this
is more on the NPC question than the parser question.
> Part of the idea might include having the ability to use the parser
> in various places, and possibly in reverse, so that certain facts
> (information on game states) could go from an NPC back to the PC.
So that NPCs could order the PC around and he would slavishly obey?
Woo-hoo! Time for "Stiffy Makane" part 2. :)
> > >4. NPCs that aren't built around giant case statements.
> > I can't think of anything in this area that wouldn't be doable in
> > TADS.
> You have a game that's based around, say, six or seven NPCs, let's
> make them immortals, and as their purpose in life they go around
> trying to kill each other (impossible because they're immortal, but
> since they're also insane from boredom...) and maybe they also do
> artsy-and-craftsy type things like build mountains or dig canyons.
> What you want to do is implement an algorithm that takes an
> arbitrary number of the following factors: how successful the NPC's
> attempts at creating have been, how many have been defaced or
> destroyed, who the NPC thinks did it, what the NPC's history (which
> changes throughout the game) with other NPCs is--take these factors
> and determine how the NPC is going to respond to a PC who suggests
> attacking or allying with another NPC.
This is the sort of thing that a goal-based or rule-based system would
be good for specifying IMNSHO. With some random factors built in such
a thing can look very self-directed. The goal system keeps the NPCs
tracking with the story. This is the sort of thing I'm hoping to do
(although I imagine it will be a while before I have any results, RL
is very crowded at the moment).
> Now, before somebody jumps on this as being some kind of AI-complete
> problem,
Its only AI-complete if the NPCs think its AI-complete :)
> An engine like this could be built and interfaced into TADS but I
> don't think TADS itself would be appropriate for building this kind
> of DBMS.
I think I mostly agree, although I have no clue about the TADS runtime
architecture. I can't even begin to guess how you would tack it on to
the Z-machine. But, in principle, nothing besides performance prevents
you from building these sorts of facilities *in* an existing target
system. However, the performance hit for rule/goal based programming
is pretty high even in native code systems. I can't imagine what it
would be like in a byte-coded environment, unless perhaps "completely
unusable" would describe it.
david rush
--
With fond memories of the troll bridge and the bear....
okbl...@usa.net
tba...@ibm.net (Trevor Barrie) wrote:
>
> Which would, if nothing else, make it easy to handle sentences with multiple
> indirect objects.
>
Indeed. But there are doubtless myriad other improvements that can be made,
not mention infinite improvements that *can't* be made. Trick is, knowing
the difference. ;-)
>
> I don't think you'll have a lot of luck getting "it" to work properly in
> this example. Figuring out what "it" means in a given sentence is, I
> think, the sort of context issue that's the hardest part of natural language
> parsing.
>
One thing I've come to realize is that "there will be casualties". (This
phrase now replaces my former catch phrase of "mistakes were made".) The
thing I think is unrealistic is to assume that a computer parser is going to
be any less confused than a human listener would be.
In this case: "Tell Bob to do it" could cause the parser to go back to the
last verb phrase "break glass with hammer" or, if the context were lost,
"encourage Bob to have sex". Things like that are gonna happen.
> >An engine like this could be built and interfaced into TADS but I don't
think
> >TADS itself would be appropriate for building this kind of DBMS.
>
> I don't see how TADS would be any less appropriate than any other
> procedural or object-oriented language. It would be a fairly complicated
> algorithm, of course.
I'm not a TADS expert but I don't seem to recall much in the way of I/O.
Saving the NPCs memories and experiences as you go strikes me as something
that might be problematic.
okbl...@usa.net
David Rush <ku...@bellsouth.net> wrote:
>
> ::Bob points at you and says, "It was all his idea! He had a gun in
> ::his hand! This is a dangerous place!" Six of the policemen
> ::subsequently aim their weapons at you.
>
> A *really cool* NPC implementation would allow you to "convince" Bob
> to break the glass on his own. (AI-complete...blah blah blah) But this
> is more on the NPC question than the parser question.
>
Hmmmm:
Bob looks at you nervously. "What are we going to do?"
> POINT TO THE JEWELRY STORE WINDOW
Bob looks at the jewlry store window.
> "FRED OWNS THAT JEWELRY STORE, BOB"
Bob says, "Yeah, I know."
> "FRED IS SLEEPING WITH YOUR FIANCEE."
Bob says, "What? How ... ?"
> SHOW BOB PICTURES
Bob looks at the picture, stunned, not realizing they are clever forgeries.
> HAND BOB BRICK
Bob takes the brick and lobs it into the jewelry store window. Six policemen
rush forward to arrest him.
> STEAL JEWELRY
You slip past the window and grab the jewel-encrusted tiara, ignoring Bob's
muffled cries for help.
The parser has to recognize that the subject of most sentences, especially
spoken ones, isn't going to be "YOU", i.e., we're not dealing with
imperatives. We're dealing in data. (The data may be true or not.) In the
above example, the player is giving the NPC data, some of which he knows and
some of which is new, but meant to motivate him toward the PC's desired
action. This could also have been done more traditionally this way:
Bob looks at you nervously. "What are we going to do?"
> TELL BOB ABOUT JEWELRY STORE
You say "Bob, you know that Fred owns that store."
Bob says, "Yeah, I know."
> SHOW BOB PICTURES
Bob looks at the pictures of Fred with his fiancee, stunned, not realizing
they are clever forgeries.
> GIVE BRICK TO BOB
Bob takes the brick and lobs it into the jewelry store window. Six policemen
rush forward to arrest him.
> STEAL JEWELRY
You slip past the window and grab the jewel-encrusted tiara, ignoring Bob's
muffled cries for help.
Hmmm. I dunno.
>
> So that NPCs could order the PC around and he would slavishly obey?
> Woo-hoo! Time for "Stiffy Makane" part 2. :)
>
Heh. I'm going to have to play "Stiffy" since it gets more attention around
here than "Curses", "Spider and the Web" and "Christminster" combined. ;-)
> This is the sort of thing that a goal-based or rule-based system would
> be good for specifying IMNSHO. With some random factors built in such
> a thing can look very self-directed. The goal system keeps the NPCs
> tracking with the story. This is the sort of thing I'm hoping to do
> (although I imagine it will be a while before I have any results, RL
> is very crowded at the moment).
Yeah, I've heard tell of this thing called "RL". ;-)
>
> Its only AI-complete if the NPCs think its AI-complete :)
>
<chuckle> Code an AI-complete system that passes the Turing test by fooling
*itself* into thinking it's intelligent.
> I think I mostly agree, although I have no clue about the TADS runtime
> architecture. I can't even begin to guess how you would tack it on to
> the Z-machine. But, in principle, nothing besides performance prevents
> you from building these sorts of facilities *in* an existing target
> system. However, the performance hit for rule/goal based programming
> is pretty high even in native code systems. I can't imagine what it
> would be like in a byte-coded environment, unless perhaps "completely
> unusable" would describe it.
Except the fact that they aren't *my* system. Mike Roberts owns TADS. The
community owns the Z-machine. I could write a TADS add-on and somehow work
goals into the object model, I guess. This is one of those things that might
be easier if one designed it from scratch and then saw whether or not it could
be shoe-horned into an existing system.
I don't know about "unusuable". Remember, we're dealing with a very small
universe here: The universe of the game. And we're dealing with authors who
are going to limit the number and kinds of motivations the NPCs can have, as
well as the means they use to achieve their goals. We're still dealing with
traditional story ideas (at least in this newsgroup).
HarryH
>I can't think of anything in this area that wouldn't be doable in TADS.
So that's how you do it! And here I thought you'd need knowledge databases,
neural network, natural language processor, and all that hi-tech, exotic
junk. Silly me.
All I need (to code NPC) is a bunch of giant case statements.
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
Doeadeer3
>Date: Sat, Jul 11, 1998 18:30 EDT
>>and experts on C++ (like um *blush* me), but not much of an intersection
>>of the two.
>
>Zarf.
>
>Dunno how much Graham (anyone seen him recently?) knows about C++, but he
>certainly knows his C.
>
>Adam
Another one I could mention would be Adam Thornton, himself. :-)
IMHO it would be a big mistake to presume that there aren't quite a few
"hot-shot" "general" programmers in raif.
:-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain