Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
2D top-down, or side view? – ChrisE May 5 '11 at 16:07
Side-view with a twist, the camera and the gravity rotate. – Sylario May 5 '11 at 16:50
Colliders in Unity do not require a mesh (except for MeshCollider, but you shouldn't use it anyway) – Nevermind May 5 '11 at 18:45
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)? – ChrisE May 5 '11 at 21:25
Doesn't Unity give you the coords of objects? – jcora Sep 21 '11 at 14:42

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

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.

share|improve this answer

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 (bottom of the page)

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.