Re: [Tads3] knowledge / 'seen' / npc knowledge base

["Mike Roberts" <mjr_@xxxxxxxxxxx>]

"steve breslin" <versim@hotmail.com> wrote:
> > I'd probably use a lookup table rather than a vector, since it's much 
> > faster to find a key in a lookup table than a value in a vector.
> I'm not sure I understand. I'm thinking of lookup table like a mapping of 
> keys to values. Do you mean that we'd just be looking for the presence of 
> keys, and never assign values, or assign boolean values for keys? 
> Presumably the key would be the potentially known objects; the lookup table 
> would be specific to the actor?
The keys would be the objects; the values would be arbitrary, as it's the 
presence in the table we care about, much as it's the presence in the vector 
we care about.  The only difference is that testing for presence in a lookup 
table is faster.  The tables would be per NPC.

In practical terms, you'd add an item to a table with 'knowledgeTable[obj] = 
true' rather than 'knowledgeVector.append(obj)', and you'd test for presence 
with 'if (knowledgeTable[obj])' rather than 'if 
(knowledgeVector.indexOf(obj) != nil)'.

> I'm trying to argue for simplifying these interfaces into simple 
> implementation. As far as I can tell these interfaces are somewhat 
> painfully complicated; it would seem easier to provide support for NPC 
> knowledge out of the box.
How would this simplify the interfaces?  It seems to me you'd use exactly 
the same interfaces used now; it's only the implementation that would 
change.  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.

> One good thing about such a simplification is that there's a number of 
> different ways these number of interfaces could be deal with, and it would 
> be nice if different NPC-knowledge-relevant modules were dealing with these 
> interfaces in the same way.
Again, I don't see what you're getting at; the interfaces are such that 
every module dealing with NPC knowledge already gets at the information the 
same way.

> I don't see this as a lot of testing, and only a tiny bit of cpu. Make 
> Actor a preinit object, and check for the existence of a memory table. Or 
> you can probably suggest an even more efficient solution.
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.  That's the biggest reason I think this is 
better as an add-on module - if a game needs the extra information, then the 
author just pops in the module, and all of the NPC's get all of the extra 
tables.  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.  
The decision is made at compile-time, so there's no need for run-time tests 
for the existence of the tables: either you can count on them always being 
there, or the code doesn't use them at all.

--Mike

_________________________________________________________________
Use custom emotions -- try MSN Messenger 6.0! 
http://www.msnmessenger-download.com/tracking/reach_emoticon