The game works by selecting a square containing a character (presenting a playing piece on a tabletop miniatures game). If the square contains a character, that playing piece is said to be "in hand". To demonstrate which square the playing piece is in, we place a new game object (a cube for visibility) on the tile that contains the playing piece
A destination square is selected by clicking on another tile. In Unity, I'm working out which tile has been clicked, and placing a cube on it, to ensure that it's not my tile-selection routines that are screwy. From now on, all calculations, rotations, translations and raycasting are done between these two objects (called sourceObject - the one in the starting square, and targetObject - the one in the target/destination square).
The first time a target square is selected, Unity correctly identifies that the ray from the start point to the destination, on the other side of a wall, passes through the box collider on the wall object. The view flips to the "scene" mode, where you can see the two rays being drawn from source to destination.
The second square selected is also on the "wrong" side of at least two walls. Unity again correctly detects that the ray passes through a box collider and will not allow the character to move into the new target square.
The strange stuff happens when we select a point closer to the wall than the character is. When the third target point is selected, you can see that the rays clearly pass through the wall, but the box collider is not detected, and our character happily walks through a solid wall!
Not just a wall with a collider - but the very wall with the very same collider that it detected earlier, when the target square was further away....
Now to make sure it's not a bug introduced when we move our character around, we repeated the test, this time moving the character before attempting any box collider checks:
Here you can see the character is moved to a new square, and target squares are selected behind the walls. The first time we select a target square, the box collider on the wall is detected and our character cannot move to the destination point.
The second destination point is also "behind" two walls, and Unity correctly detects the box colliders on the door and wall, and the character cannot move.
So what gets really frustrating is that the third point - on the "wrong side" of the very wall that it earlier detected the box collider on - does not trigger the box collider, and Unity animates our character walking through a solid wall.
We can't come up with a reasonable explanation as to why this is happening, other than noting that the problem mainly occurs when the box collider hits the "second half" of the ray. In other words, if our character is further away (in terms of straight-line distance) from the wall with the box collider on it, than the target square is, the raycast does not detect the box collider.
If we choose a target square that is sufficiently far away from the wall (box collider) so that the character is closer to the collider than the target point is (on the other side of the collider) then Unity correctly detects the presence of the box collider and reports a break in our line-of-sight.
It's all rather worrying: if we can't rely on the Unity game engine to handle things like line-of-sight and raycasting, we may as well write the entire LOS routines ourselves, from first-principles and GCSE level trigonometry/mathematics - and we've already done that once in Flash. Unity was supposed to free us up from all that, and make things simpler, not more complicated!!
No comments:
Post a Comment