Search Unity

2D NPCs keep overlapping

Discussion in '2D' started by JtheSpaceC, Oct 13, 2014.

  1. JtheSpaceC

    JtheSpaceC

    Joined:
    Oct 5, 2014
    Posts:
    14
    Hi. I had posted the below in Answers but the admin said there were too many questions (can't say he's wrong) and to put it here. It's a problem that I imagine has many simple(ish) solutions and I've made many attempts but can't seem to seal the deal. And advice on best practice here would be appreciated:

    This is two or three problems actually, but I only need one solution. In a top-down space shooter scenario, I have ally and enemy fighters who will attack each other or the player. I have 2D trigger colliders on them and move them using rigidbody (3D, with the rigidbody on a child) AddForce. The reason I created a child was that I couldn't successfully modify the 3D movement script to affect the 2D rigidbodies.

    Anyway, take a scerio where 2 allies are chasing one enemy ship. The allies will move onto the same spot and fairly soon overlap and completely blend together. To prevent this I added a non-trigger circle collider(2D) to an empty child object named "BreathingRoom". For some reason the collisions didn't register, and I've checked the 2D physics settings. The layers should be colliding. Next I tried a SPHERE collider instead and these collisions DID register. The allies and enemies will no longer fly on top of their team-mates, but fly next to each other , at the distance of the sphere collider radius (x2, obviously).

    The problem with the sphere approach is that each collision they make is changing their rotation, so that they no longer point forward, but off to one side more and more as they make more collisions. I tried to lock the rotation by adding a rigidbody(3D) and locking the rotations but then the NPCs were back to flying on top of each other, seeming to ignore the sphere.

    So, I either need to lock the rotations on the collider, or learn some advanced scripting to prevent them moving on top of a team-mate, while still heading to their targets. Which way would be more correct/ efficient/ doable?

    Thanks much
    Kevin
     
  2. Pyrian

    Pyrian

    Joined:
    Mar 27, 2014
    Posts:
    301
    I'm not clear on how you got this working at all. The 2D trigger colliders have no corresponding Rigidbody2D, so they're going to be treated as static colliders. Then, your 3D Rigidbody is a child; that's going to move a sibling object? I didn't think they worked that way, though I admit I've never tried it. Once you've got a 3D Rigidbody and a Rigidbody2D in the same hierarchy, they should move independently based on their respective physics engines, ignoring colliders in the other dimension.

    That being said, it should be fairly simple to lock the rotation of the spheres by setting freezeRotation on the associated 3D Rigidbody - but creating another Rigidbody3D isn't the answer, as then it becomes functionally two objects moving independently.

    The "correct" answer would almost certainly be to stick to 2D or 3D physics and have the Rigidbody on the root GameObject of each ship. Then you can mess with colliders and Layers on child objects to your heart's content.
     
unityunity