Search Unity

Design Question: Managing multiple NPCs

Discussion in 'Game Design' started by Volcanicus, Aug 7, 2019.

  1. Volcanicus

    Volcanicus

    Joined:
    Jan 6, 2018
    Posts:
    109
    I am calling on your experience with Unity to tackle this problem.
    I have ~20 scenes in which NPCs exists. Sometimes, the same NPC will exist in 2 scenes.
    Each have their dialog, quests and schedules. Some roam, some sit, some stand. Each's schedules is recorded on a .csv file and read.

    What would be the best way to manage the NPCs on a schedule and why:
    1) Each scene contains each NPCs that are required (read: already placed, no spawning event). If the player is in the scene between certain in-game hours or is doing a quest, the NPC will have its navmesh and other scripts activated and will be rendered and scaled from 0 to 1. Otherwise, NPCs are disabled, scaled to 0 and parked elsewhere in the scene until needed. This may be the least efficient method but the most easily manageable with the least amount of debugging.

    2) Each scene contains spawn points that will spawn or de-spawn NPCs based around their schedules. This will require creating and managing NPC prefabs based around their schedules. Each time, an NPC will be created and later destroyed. This seems most efficient in terms of resources however, how efficient is it? In terms of debugging, many tests will have to be done to make sure the NPCs do not interfere with each other.

    I cannot think of any other design to manage these NPCs.

    Any suggestions?
     
  2. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    9,518
    Another approach is to provide areas that NPCs can do things in. These are sometimes called anchors or affordance objects. They can run on a schedule. For example, a cow could have a high priority anchor that turns on at dawn and is available to the NPCs on the farm. When an NPC goes to that anchor, it would make the NPC play a milking animation for 60 seconds, after which the anchor would turn off. One of the NPCs will choose to go to the anchor because it's a high priority. At night, a bed anchor could turn on, causing an NPC to go to the bed and play a sleep animation. This gives a little more flexibility than hard-coded schedules, and it may be easier to coordinate multiple NPCs.

    Whatever design you choose, you'll need to prioritize actions. If an NPC is walking to the cow to milk it, and trolls enter the farm and stand in the NPC's way, the NPC should prioritize fighting (or fleeing) instead of blindly continuing to walk to the cow. Hierarchical FSMs are a common way to implement this.
     
  3. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    4,546
    What is the problem? It seems the only comparison so far has been the amount of debugging, which I don't quite understand how you arrived at.

    I tend to think that using prefabs is pretty much always better, especially in terms of making sure that scenes are synced to changes you've made in your game. That would seem to reduce debugging.

    Personally, I think the best approach for AI design is to create time-based model of the AI behaviour cycle, and instantiate prefabs according to the current status of the model when the player is in the vicinity. I also prefer to keep everything in one scene, since that reduces workload duplication even more.

    I did some AI for ship trading a while back. If I remember correctly, the AI script simply iterated a Vector3 position within a solar system according to ship velocity, warp acceleration and deceleration, etc. When the player was near it, this model would stop iterating, spawn an AI and hand over control to the AI, which could then engage the player and do whatever. When the player was far enough away, the AI fed its current status back to the model, which continued iterating according to its parameters.

    That way, the player could find an AI that it had lost contact with as long as they had some idea of where the AI had gone.