NPC motive logic... Transferrable AgendaItems?

I’m working on basic questions of how to cause NPCs to run about and do things. My question here is, can I make an AgendaItem that can be transferred from one NPC to another?

For example, it’s not difficult to put objects into, or take them out of, the pockets of NPCs while the game is in progress. Similarly, I would like to be able to put AgendaItems into, and take them out of, the NPCs’ “minds,” as if the minds were pockets and the AgendaItems were possessable trinkets.

Basically, I’m trying to tie these things together: NPCs playing mini-games with each other (RPS and such); NPCs choosing to play them with each other; external events causing NPCs to play games; NPCs selecting game-strategies according to changes in the external situation.

–I don’t know enough about software engineering to be certain I’m saying this right, but I’m inclined to put it this way–

I’m looking to make an API by which these different parts of the animate TADS world can all talk to each other. I have a basic idea of how the parts might work individually. Now before I put too much work into the parts, I need to figure out the API and get sorted out the language they’ll use to signal and message each other.

How do I do that?

Conrad.

Since nobody else has replied, I’ll give it a shot. It appears (based on my quick perusal of the docs) that an AgendaItem is just an ordinary object. That is, it’s not a PreinitObject or anything like that. So you should be able to move one around using moveInto(), just like any other object.

One factor that might influence the desirability of doing this is that a given actor will perform only one AgendaItem per turn – and I’m pretty sure it will be the first active one in the actor’s containment hierarchy. You would have to investigate where an object ends up when it’s moved into an actor using moveInto() – I’m hazy on that. If the newly moved AgendaItem goes to the bottom of the list, that might not be desirable.

But there’s a better solution, I think: Create a subclass of AgendaItem for each type of behavior you want actors to engage in, and then create an instance of your subclass within each actor that you want to be able to perform that action. Then, instead of using moveInto to move a single object around, you just switch isReady on and off for each instance, as needed.

To do this, they have to be named objects, not anonymous ConradAgendaItem objects, but that’s trivial, because you would have to have named objects to move them too.

Jim,

Thanks for the thoughts. I will experiment.

BTW, AgendaItems are prioritized by a setting called agendaOrder, which is an integer 1-100. AgendaItem priority is not related to the sequence they appear in the code.

Conrad.