Change MMOItem Owner when a client disconnects

edited October 2011 in Photon Server

We are currently working on a sort of Hack'n slash game. In the cooperative mode, we want that each player machine manage a fraction of the AI that the player discover.
Let me explain our goal :
1- A party is created (1 to 8 players)
2- The players sends a request to the server to create a MMoWorld for their game. The server dispatch some random values in the map that describes the AI(positions and characteristics), then sends this as a dictionnary to all the players of the game.
3- When a player "discover" a AI on the map, the client instanciate the AI object and create the MMOItem corresponding to the AI. This way, each client is responsible for a AI, and AI are synchronised with each player of the game.

The problem we enconter there is if a player disconnects, we loose the AI its machine is responsible for.
So here is my question ; as we use MMOItems to manage AI, is there a secure way to change server side the owner of the MMOItem when the server detects that a player have been disconnected ?
I saw that the Owner of the MMOItem server side is read only, Is it safe to just add a setter to the accessor and remove the readonly attribute ? Or is it a little bit more complicated (like using fiber) ?


  • BorisBoris ✭✭
    Normal mmo items use the owner's request fiber so that the mmo actor can directly access his items at OnOperationRequest.
    Example OperationRaiseGenericEvent:
    if (actorItem)
       // we are already in the item thread, invoke directly
       return ItemOperationRaiseGenericEvent(item, operation);
    // second parameter (peer) allows us to send an error event to the client (in case of an error)
    item.OperationQueue.EnqueueOperation(() => ItemOperationRaiseGenericEvent(item, operation), this.Peer, request);

    I you want to be able to transfer ownership the items have to use their own fibers and you will always have to use item.OperationQueue.EnqueueOperation.
    Now I see two solutions:
    1) You depend on the client to actually see the AI item. Then call something like "I want to be owner" and enqueue it on the item fiber. Let the item decide whether it works or not.
    2) You give AI items their own interest areas (not ClientInterestAreas): At OnItemSubscribed the AI decides whether to assign ownership to the player. The AI item could also have a the ability to detect whether the client stops doing anything (lags, disconnects that are not detected fast enough) and then hand-over ownership to the next player. Also, in times of having no owner you could make it do something regardless.
    In both of these cases you could instantiate and add all AI items as soon as you create the world.
    Your clients would then discover them with their interest areas.

    You should not store AI item as actor items (Actor.AddItem) because all these items get destroyed when the actor gets disposed. All other methods do not use the EnqueueOperation method on these items so it actually saves you a lot of rewriting. Instead store AI items in a separate dictionary. At dispose inform these items that the current actor is not the owner anymore.

    Oh, and owner does not have to be read-only if you do it this way.
  • Thanks a lot for the quick reply !

    Actually, we want to manage the less possible things server side (our goal in terms of charge is to maximise the number of games one server can handle).
    If i understant well (noob as i am), using the second solution can multiply very fast Interest areas if we want to have massive number of ia per game (so very very massive number of ia per server !)...
    I don't really know what that fact involves in term of charge server side, but i think (correct me if i'm wrong) that for the first solution the server charge can be minimised (When the client see an AI, he looks if the AI have a owner, if not he claims to be its owner).
    That said, if i choose this solution, i think that i will have to lock the AI access server side when a client claims to be its owner... isn't it ? Will this be annoying for perfomances ?
  • BorisBoris ✭✭
    True, more AI logic on the server = more load means = less CCU.

    The fibers are used instead of locking. Just enqueue everything you get/set/execute on the AI item to the AI item fiber.
  • Also keep in mind that anything done client-side is easily hackable regardless of what you do to protect it, so make sure it's nothing that would "compromise" the game per say.
  • Kalagaraz wrote:
    Also keep in mind that anything done client-side is easily hackable regardless of what you do to protect it, so make sure it's nothing that would "compromise" the game per say.

    Yup. Right.
    That's why we are NOT trying to protect our client code, but instead we save all the game data server side and control if there have been hacks afterwards.
    This way we think that we will be able to save server load.

    Edit : spelling
Sign In or Register to comment.