[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tads3] knowledge / 'seen' / npc knowledge base
- From: "steve breslin" <versim@xxxxxxxxxxx>
- Subject: Re: [Tads3] knowledge / 'seen' / npc knowledge base
- Date: Wed, 10 Sep 2003 22:03:46 +0000
- To: tads3@xxxxxxxxxxx
Mike writes:
You'd still call obj.setKnownBy(actor) and obj.isKnownBy(actor). You could
refactor the interfaces so they become actor.setKnowsAbout(obj) and
actor.knowsAbout(obj), but this seems like exactly the same complexity and
almost exactly the same amount of typing to me; you're still representing a
relationship between an actor and an object.
Yes. I think it makes better sense for the actor object to keep track of
what it knows, rather than the object to keep track of which actor knows of
it; surely this makes an equal amount of sense either way. But taking
another look at the library, the obj.setKnownBy and obj.isKnownBy seem to
perfectly well centralize the 'knowledge' interface. So I'm not complaining
any more about the way the interface is set up.
The existence of the table for a given actor would have to be tested on
every setKnownBy/isKnownBy, though, unless you wanted to give every NPC the
necessary tables in preinit.
Exactly. When we call obj.setKnownBy and obj.isKnownBy, we check the table,
if there is one; if not, we return nil. Or the game writer decides with a
boolean flag whether or not the NPC can learn things. Then setKnownBy and
isKnownBy checks this flag to see if the actor is capable of learning
things.
In the (I expect) more typical case, the extra information won't be needed,
so the author would prefer to omit the unnecessary extra tables.
Yes, many (most?) games don't have other actors. Those which do have much
simpler actors than we're consdiering. I'm beginning to get the feeling that
this would be a good 'optional module,' i.e., one which is part of the main
library, but which is not an essential part of the main library. (One which
can be added or removed manually without effecting the behavior of anything
else.)
I'll think about this a bit more, and maybe come up with some code.
_________________________________________________________________
Fast, faster, fastest: Upgrade to Cable or DSL today!
https://broadband.msn.com