[NPC] Architecture

Drewen
edited February 2011 in Photon Server
Hi all!

Two months ago, I wrote a topic about the NPC's movement (here). Well, after all this time, my NPCs are working well but I have a doubt about the architecture of the NPC system.

Actually, my architecture is:

- I mapped the path of the NPC to a NpcSequence (a sequence is a List of NpcMovement).
- With a frequency of X (50 ms for example) I update position and rotation in the current NpcMovement (to give a sensation of fluid movement).
- When the Npc finishes the current NpcMovement, the Sequence goes to the next movement and so on.

But I am not comfortable with this structure, because if I have 100 Npcs updating its position and rotation every 50 ms, the server could be overloaded and this is not good.

Do you know a different Npc Architecture? I am thinking in another method, this is the basic idea:

- Setup a time to do all the sequence.
- Sending only the "next" way point (not all the movement).
- The client will get the NPC "next" way point and will interpolate from the current position.
- So, I am sending only the way points instead of each movement position every 50 ms. The interpolation job will be in the client side.

Any idea?

Thank you so much!

Comments

  • To save threading overhead you could use the same fiber for all items and schedule one callback that updates all 100 NPCs instead of scheduling 100 callbacks as you probably do it right now.
    Just sending the way points and have the client calculate the current position seems risky - I doubt that the NPC positions will be in sync on the different clients.
  • So, your purpose is to create a fiber to update all npcs at the same time (putting it in the game world I supose).

    Well, actually I have several instances of a game world so the idea would be updating all existing npcs at the same time... it is ok, but it should have another option!

    What about the idea of "PlaneShift" (take a look here)? All their npcs are in separated processes (or computers) and they connect npcs like users but with another type of client (npc client). Maybe this model is more scalable but I am not sure of the efficiency...

    Does anybody have an idea?


    Thank you!
  • Sure, some people already rely on that architecture to run their business logic with unity headless.
    And there is a "special client" in the photon.socketserver.dll - namespace ServerToServer.
    I am looking at PlaneShift now, haven't seen this before.
  • The concept, when taken to such a granularity, sounds fine, but you need other node types to make up for it that handle path finding for example, so you don't have 100 npc all loading geometry etc.
    And its naturally extremely complex to pull it off, independent of how you turn it, due to the consequences and the required optimization as you can't afford multi 10gbit fibers within the cloud (and real cloud network technically is in a whole different price class) to stil get reasonable pushthrough and latency ...

    would go more with an approach like HeroEngine does it with area nodes that handle it all and where the nodes can take control or more or less large areas depending on their load
  • Thank you so much for your responses.

    Yes dreamora, this is the question... right now I have two options:

    - Putting all NPCs in the server side (overloading the server).
    - Putting all NPCs as NPCClient (overloading the network).

    But I am sure that exist another architecture for that...I am sure!

    Does anybody else have another idea?

    Thank you all!
  • there are others but those split the server more by task and responsibility. But in such a case Photon or any "centralized" server solution will no longer fit the picture very well.

    And the server becomes significantly more complex to develop and maintain, especially in respect to target availability
  • Well,

    I am designing a new model... probably, I will try to write a paper about this, because there is no enough information about this kind of architecture.

    I will let you know something in the future, thank you so much for your help!
  • Looking forward to it :)

    Also in case you didn't buy the only 2 books on mmo game development, I would recommend to give them at least a read to see if they can help you avoiding pitfalls :)
  • Haha I got them! (they arrived yesterday through amazon!)

    Thank you Dreamora!
  • dreamora wrote:
    Looking forward to it :)

    Also in case you didn't buy the only 2 books on mmo game development, I would recommend to give them at least a read to see if they can help you avoiding pitfalls :)

    What books exactly are you talking about? :)

    thanks,
    Slav
  • What I would recommend, is not to worry about performance at the start, and simply make architecture flexible enough for modifications if you run into performance troubles later. One of the approaches is to split your whole program into "services" and communicate between them using only messages - no direct calls! Also, each service should be owning it's data, and nobody should have direct access to it. If done right, it makes your program very modular with very independent parts. So in mmo example you could go with several services:

    * NpcService - service that manages npc list, their creation, destruction, updates, queries for properties, etc.
    * AiService - runs AI for npc's.
    * PathFinding - handles path finding queries.
    * Combat - handles all combat in game.

    You could send a message to NpcService, like: create entity here, with these parameters. NpcService sends a message to AiService that npc wants some brains. When npc AI wants to run somewhere it sends a message to PathFinding service to find him a path. When AI knows where he wants to run, it sends a message to NpcService to move here, or follow this path. And so on.

    Most awesome thing is that you can run these services on a single thread, or split into multiple threads, or even move the whole service to another server! Another thing, is that data is owned by only one service, and if you see that PathFinding could benefit from multithreading, you can modify code inside the service without impacting other code.

    By the way, don't update all npc's at once. Do only what you need to do. Have a list of moving npcs, that needs update say every 0.3 second, have a list of entities in combat, that need their attacks made each 0.2 second, etc.
  • Drewen wrote:
    Haha I got them! (they arrived yesterday through amazon!)
    Would be nice to have some literature, have you dug into them yet? They seem a bit outdated (2003,2005) which bothers me in correlation with book description:
    As the MMP game market continues to grow, new challenges and technology hurdles constantly emerge. Massively Multiplayer Game Development 2 is an all new volume in this successful series written to address the challenges faced by the entire MMP development team, not just the programmers.
    Do you think content of those books is still somewhat valid? Also I can't seem to find e-books nor kindle editions so I guess i'll have to pass on them anyway.
  • @Smilediver:

    Thank you dude, I will take your post as reference!


    @Xeevis:

    Yes, it is plenty of useful tricks and recommendations in different sections. I am reading now the game design articles and they are awesome. It is a must.