- Home /
Can a CharacterController ignore one or more Colliders?
Hi All
I am wanting to add a collider to the scene and move it about with my CharacterController for a tile-based game. There are other possible solutions to this, but ideally, when the player moves to another tile, I would move another collider to that tile, effectively reserving the tile and preventing enemies from trying to enter the tile at the same time. I can't see a way that this would be possible, but I was wondering it it could be done with layers? Can a CharacterController be told to ignore a layer? In which case, I can put all these reservations on this other layer and reference that layer when making decisions about where players and enemies can go and this makes it quite easy and efficient (I hope!).
Thanks in advance Ian H
Actually looks like Physics.IgnoreLayerCollision() may do exactly what I am after here.
Answer by Bovine · Dec 02, 2010 at 04:55 PM
I solved this by creating a prefab consisting of an empty gameobject with a BoxCollider attached. The box collider takes up a tile and the script controlling movement instantiates two of these prefabs. One always occupies the current 'tile' and the other is inactive until the character moves, at which point the 2nd prefab is activated and placed at the designation tile location. When the controller completes the movement from tile to tile, the first prefab is moved to the controller's new location and the 2nd is set inactive. It us necessary to prevent collision between the CharacterController and these two colliders, and because I use raycasting to determine whether a controller can move into the next square, I have to make the first collider inactive while raycasting.
Sorry if this is a bit hard to grasp from my answer - think of the Box
It seems to be fine and I think I will be able to adapt it to creatures of different size eventually.
Answer by Proclyon · Nov 10, 2010 at 03:01 PM
May I suggest you solve this program using a programmatical approach with a Grid that can reserve/flag positions as taken/not taken rather than physically blocking off a location? I believe that could help you get a lot more control over what is going on since every tile can be used as an object that way. It has a specific property or behaviour or anything you want keeping all the knowledge clear and open for yourself and any other programmer that will need to dig through the design.
If you really just want to go about it , I would suggest trying to create a temporary clone of your object and remove it's properties that make it visible or controllable in any other way than collisions. Anything that wishes to move simply has to do a range limited (Already a constructor for that exists) sphere or ray cast.
Yes, as I say, I can do this using a different solution, but being able to use colliders has some advantages: I don't have to create an array potentially as large as the environment which could be expensive; I can have characters take up more or less of a tile depending on their size, so a small character might take up a quarter of a tile, meaning 4 such small creatures could reside on the same tile, or conversely a creature may take up 2x2 tiles. While this is still possible with a grid, it's not so ideal...
Sorry I can't help you much further now I fear, I don't see another way around this problem myself either. Good luck with getting your problem solved :), If you want you can post your own answer or accept another's here so it can aid the rest of the community. That of course is totally up to you
I agree w/ Proclyon. A multi-dim array seems to me to be a better option. If you are only storing ints or Vector3's it wouldn't be all that expensive, or a custom type. I understand where you are co$$anonymous$$g from, and it makes some sense. Have you tested that changing an array is going to be slower that the physics calculations b/c I would be surprised if that is the case?
I'm not saying it can't be done, or that I won't revert to a multi-dim array in the future, but I feel that using colliders provides more flexibility for a lower footprint, but at arguably a greater computational cost.