1
\$\begingroup\$

I am curious as to what algorithm/logic game AI/NPCs would use when discovering information about their environment.

There are two scenarios that I could envision.

  1. The NPCs are all knowing in regards to elements in the environment, but choose to ignore them unless certain conditions are met (e.g. the guard will not "find" his fallen comrade's body unless he is x feet from the body)

  2. The NPCs really do discover the environment by scanning it or something... (maybe similar to path finding?)

Maybe these are both used in conjunction...

Could anyone point me in the right direction towards any preferred methods?

I tried googling for this information, but could not find anything that seemed relevant.

\$\endgroup\$
1
  • \$\begingroup\$ Usually I just do stuff like this with collision detection. In the guard example I would simply have him patrol an area by default and should something enter his perception sphere (some fairly large collider around him) he would check the state of the object. If it is another guard or object of interest he could then perform an action according to its state. If dead run to the object and trigger an alarm if alive just wave at a distance or exchange some dialog. I try not to make them all knowing because it adds a lot more work on the programmers end of the pipeline. \$\endgroup\$
    – Benjamin Danger Johnson
    Commented Jul 31, 2013 at 16:38

1 Answer 1

Reset to default
0
\$\begingroup\$

You have two main ways to go here:

1) Most simpler games simply have the game engine apply rules, then dispatch alerts when certain conditions are met. So on a game tick they check to see (using your example) if a dead body is within x feet of a living guard and/or his field of vision, and if so they throw a livingGuard.hostileAlert() call and let the guard's logic take over from there.

Here the rules are with the game engine, and not with the NPC object itself, with something like collision detection. The advantage of this system is all the perception logic is on one place in the engine, and so if there is a bug in 'seeing' something it would be universal to all enemies, not just one guard that seems unable to ever see anything.

2) More fully modular/object-oriented games would feature the guard having its own set of perception rolls (like in DnD systems), where at certain ticks they ask the game engine if they can see something interesting. The "Game Master" (the game engine) compares the NPCs abilities/limitations (field of vision, line of sight, visible range, etc) to the environment, and responds to the guard accordingly.

The game engine would take the guards request to Perceive, look up/request its abilities, make the calculation, and respond with "all clear" or "hostile visible", etc. It would then be up to the guard object to decide how to respond with it's own internal logic.

The advantage of this system is that every NPC can easily be customized to have it's own perceptive abilities, and the engine can also be customized to deal with things like low-light or fog conditions, illusion/invisibility effects, etc. So you could create a camera that only "takes a picture" every 10 seconds by only having it request a Perceive function every 10 seconds.

Using the same system you can also force "obvious" effects, like if a person pulls out a weapon the game engine immediately triggers a hostileAlert() of all nearby NPCs, etc.

On the downside, every 'feature' is a potential 'bug', like a dragon with a sight range of 1 inside his own cave, or see-in-the-dark bats that can't see anything because its dark, or 1 guard you typo'd and can see people coming a mile away for no reason.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .