5
\$\begingroup\$

I have a walking NPC that will "see" the wall in front or behind him (2d gameplay) and that will react accordingly.

I was thinking to attach him to an invisible collider that would react to objects at collision, but I did not manage to do so, a collider seems to always go with a visible mesh.

How should I implement it, and how can I do it in Unity?

\$\endgroup\$
5
  • \$\begingroup\$ 2D top-down, or side view? \$\endgroup\$
    – ChrisE
    Commented May 5, 2011 at 16:07
  • \$\begingroup\$ Side-view with a twist, the camera and the gravity rotate. \$\endgroup\$
    – Sylario
    Commented May 5, 2011 at 16:50
  • \$\begingroup\$ Colliders in Unity do not require a mesh (except for MeshCollider, but you shouldn't use it anyway) \$\endgroup\$
    – Nevermind
    Commented May 5, 2011 at 18:45
  • \$\begingroup\$ Is it possible to use something that isn't a full collision check? If you are just checking for (static) walls, for an NPC, couldn't you just specify a line segment or path to traverse back and forth and so completely avoid npc-level collision (think a navmesh, sorta)? \$\endgroup\$
    – ChrisE
    Commented May 5, 2011 at 21:25
  • \$\begingroup\$ Doesn't Unity give you the coords of objects? \$\endgroup\$
    – jcora
    Commented Sep 21, 2011 at 14:42

3 Answers 3

5
\$\begingroup\$

A common way of solving the "seeing" problem is to use raycasts.

http://unity3d.com/support/documentation/ScriptReference/Physics.Raycast.html

Basically the gist of it is that you define a line starting at your NPC and going in the direction they are looking and do a trace for a certain distance with the world. You can do things like set up the world such that you're only doing traces with colliders that are marked with a certain tag (like "world").

When you get the trace information back, you know 1) if the trace hit anything 2) the object the trace hit and 3) the point at which the trace hit occurred. From there you should be able to figure out what you need to do.

\$\endgroup\$
2
\$\begingroup\$

I recommend using a trigger instead of a collider. Using triggers has almost no performance impact, as raycasts are very performance hungry (you should never use raycasts in the update loop). Triggers do not block movement on collision but trigger the OnTriggerEnter event.

If possible use different layers for your collides and triggers, and use the collision matrix to improve the performance and reduce unneeded collision actions.

Be aware of the collision action matrix http://unity3d.com/support/documentation/Components/class-MeshCollider.html (bottom of the page)

\$\endgroup\$
1
\$\begingroup\$

Colliders need not have a rendered (visible) mesh. I solved a somewhat similar problem by creating invisible targets (no rendering) with large colliders, giving the NPC (in my case, a radio tower, but this could be used to simulate something like motion detectors for a stealth game) a particle emitter, and using OnParticleCollision to script the results. Particle effects have very little overhead. When the Targets were hit by the particles (i.e. OnParticleCollision(whatHit : GameObject) ), they updated an array (each target being named as an int which was also its array index) so I could tell if all targets had or had not been hit.

\$\endgroup\$

You must log in to answer this question.

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