I am still in the “sandboxing”-phase when it comes to unity…still got a lot to learn.
I decided I might try a “simple” 2D top-down fighting engine next…kinda like in zelda (Gameboy, NES, SNES).
I read that you should use tile-based / grid-based collision detection for performance reasons…
so, as I understood I basicly have a 2d array kinda like gameworld[xtile,ytile] where I then set info such as “is acccessible”, “is blocked” etc.
I get that…its easy to understand. However, I may not use collision with rigidbody for those blocks then… but, can I even use physics then to do collision checking etc?
I really like using physics as its really smooth and accurate. Removing physics for movement means I’ll have to develop pixel-perfect movement myself. I did that a long time in Game Maker (been usin it for 12 years or so) and I really hated it cause it would always lead to some situations where it becomes glitchy.
So, yeah, maybe anybody can help me out on this topic.
Maybe there even is a magical limit on how many tiles I could use while still using single collisionboxes and physics before it even makes sense to move to a tile-/grid based system!?
I experimented with this a while ago while trying o make a Ultima style of movements in a grid (the first Ultimas). I managed to have a totally free from physics system, by simply having as you did a 2d array of strings. Each string would be an index of the kind of terrain the player is walking taken from a List of premade terrain types. So every time the player move a direction a comparison with the next tile id with the terrain will be made to see if you can move or not.
Now the problem in this is that the movement is tile based, meaning there isn’t smooth movement, is unit by unit. For what I understand you still want to keep the smooth movement so this method may not suit you. Also not having rigidbodies you are out of luck for trigger events.
So you got few alternatives I guess, one is not to use a collider for each tile, but instead just use edge colliders around solid objects. To save some performance on physics you can have your characters have circle collider which are the fastest to calculate. Mind that the performance gain from a box collider is minimal but is still something.
The problem can come when you have a lot of physics elements moving, you have to find a way to make them inactive if they are not needed in the immediate time. For example there is an enemy patrolling an rea that you can’t reach for now, is pointless to even move it for tthe time beign.
The other method is raycast collision, using raycasts to test a collision against other colliders without having physics in place. To do that you just turn everything into triggers, and calculate your delta force by code. Check this for an in depth explanation in this last method: Overdeveloped: 2D Platformer Collision Detection in Unity
Thanks for the replay. I’ll take a look at the link.
So, the real problems are non-static colliders? So I could still “make it” when most colliders would be static box colliders?
I’d really like some kind of benchmarking on performance loss with colliders in a 2D project.
Well the problm is that collisions are not culled, so if there is something offscreen colliding, it will be calculated. You still can have a lot of static colliders, but is always advised to have the less of gameobjects possible thats why I suggested edge colliders, is just lines.
One thing you need to be aware of, moving colliders that doesn’t have a rigidbody will be a bottleneck. Think of a door for example that you want to move with a transform position, if you move it and doesn’t have a rigidbody the engine have some hard time, so at least you need to put a kinematic rigidbody on it, however this will be addressed in unity5 where moving colliders without rigidbody are dealt with properly without you needing to do anything. There was an old blog post about this issue I can’t find now.
Also consider that when you collide with something, the collision test will be done on the whole collider and not oly the face you touch. So for example you have a complex collider of many faces or polys when you touch it, the collision test will be done on the whole thing. So you are close in between using not many objects but not having too many colliders, you have to pla ahead I guess depending on how big your scene is.
In the end I always find troubles to balance all those things and maintain a retro look of a game, as those old games moved by pixels and not vectors, so on one side you want to use physics, but on the other you want to maintain the retro behaviour so can’t use physics.
As a last thing midn that I’m obsessed with performance on everything, I just can’t help it, so maybe the loss of performance in some areas isn’t that significative as it is, I just like to have everything the best as possible.
Thanks for your reply.
I think I will try with using bigger box or line colliders regarding the situation…objects placed within the game field would get box colliders if possible. The outline of the map will get line colliders… think thats a good approach.
I will just have to try n get it to work. And I should also try to only activate GameObjects that are near the camera…but once activated they should stay active… Well, I think it would be best for me to see how much of an impact it will have on performance…