NPC management

mstultz
edited September 2010 in Photon Server
Hello, I am currently adding AI to the example NPC classes provided. NpcItem pumps their AI via ScheduleOnInterval. This works fine.

I was adding a behavior to check an Npc's surrounding area to see if another Npc or Player (MmoItem, basically) was nearby. My plan was to keep track of items that entered/exited the Npc's NpcInterestArea, with the following data:
struct InterestAreaData
{
   string itemId;
   byte itemType;
   Vector3 position;
}

List<InterestAreaData> interestAreaData;

Items have a "local" channel that receives events for other items in their interest area. For instance, when a player attacks, it sends an attack event to this local channel, and the other items determine if they've been hit. Move events are sent through this channel.

Items receive these move events, and basically track the items around it. The AI would then query this data, and it should be thread safe since the Item owns this data.

However, I a few questions have sprung from this excercise:

1. Inside Npc/MmoClientInterestArea's OnItemSubscribed, I have an Item parameter and an AttachedItem member. Is it thread safe to access either or both of these items?
2. Why did the example code opt to not supply an Actor for NpcItem? Is it true that this means I cannot use operations with the NpcItem, as it does not have a Peer to supply EnqueueOperation()?
3. What is the best way to populate my List<InterestAreaData>? Without thread safety in mind, I would just add the following call within OnItemSubscribed: AttachedItem.AddInterestAreaData( item ); However, I do not know if this is safe. My next idea was to submit an operation to AttachedItem's operation queue, but I cannot do this for Npcs. Can you offer more insight on this?

Mainly, I am confused as to when I can access data to maintain thread safety. Is there an easy high level rule to this?

Comments

  • mstultz wrote:
    1. Inside Npc/MmoClientInterestArea's OnItemSubscribed, I have an Item parameter and an AttachedItem member. Is it thread safe to access either or both of these items?
    In general access to interest areas are is only thread safe within a lock.
    As for OnItemSubscribed: access to the interest area is thread safe (it's called within a lock).
    Secondly, access to items is only thread safe if the method has been enqueud on the item fiber.
    OnItemSubscribed is not executed on the item fiber, therefore accessing the item in this method is not thread safe.
    mstultz wrote:
    2. Why did the example code opt to not supply an Actor for NpcItem? Is it true that this means I cannot use operations with the NpcItem, as it does not have a Peer to supply EnqueueOperation()?
    An Actor is an operation handler for clients and the glue between Peer and Items and InterestAreas. NpcItems do not have a client/peer, and thus no Actor.
    mstultz wrote:
    3. What is the best way to populate my List<InterestAreaData>? Without thread safety in mind, I would just add the following call within OnItemSubscribed: AttachedItem.AddInterestAreaData( item ); However, I do not know if this is safe. My next idea was to submit an operation to AttachedItem's operation queue, but I cannot do this for Npcs. Can you offer more insight on this?
    Even though npc items do not have a peer, they DO have an OperationQueue and the OperationQueue has a Fiber property. Enqueue your npc items actions to this fiber.
    mstultz wrote:
    Mainly, I am confused as to when I can access data to maintain thread safety. Is there an easy high level rule to this?
    Items: Thread safe only when you use the OperationQueue or the OperationQueue's fiber. Items that belong to clients use the peer's request fiber as operationQueue fiber, so it's thread safe to access the own items directly when handling an operation.
    Interest Areas: require locking