2D Toolkit Forum
2D Toolkit => Support => Topic started by: ozonorojo on June 16, 2012, 11:50:26 am
-
The current handling of collisions in 2D Toolkit seems ok for casual games or those that don't demand much in terms of collision detection, but it isn't yet powerful enough to handle other more complex scenarios. I'm making a game that needs some serious use of collisions involving sprite-based objects. More especifically, it's a beat-em up. Implementing the combat system, I came into these two limitations of 2D Toolkit that blocked my path:
NO MULTIPLE COLLIDERS:
It is only possible to define one collider per sprite. There should be a way to define the number of colliders, from 0 to whatever, then have them show as additional tabs the way the single collider does at the moment. Even if all sprites in a collection needed to have the same number, that would still be good enough.
Why do I need this? The characters in my game need 3 colliders. Collider 1 is for movement (not walking through walls, floors, platforms, other characters, etc.). Collider 2 is a hitbox to receive damage from other characters' attacks. Collider 3 is a hitbox to inflict damage when attacking other characters. If, for example, the character is performing a kick, Collider 1 will cover most of the character's body without the kicking leg, Collider 2 will cover a reduced area that excludes most of the limbs, and Collider 3 will only cover a small area with the kicking foot.
Unity supports multiple colliders by having child objects with a collider component (not to confuse with compound colliders, a similar setup where the parent is the object receiving the collisions from every child collider and they effectively work as a single collider).
ANIMATED COLLISIONS:
As far as I understand, only box colliders animate at the moment. There are many cases when this is not enough. For example, if you have a human character leaning or bent forward and you want accurate collisions (say, to detect incoming attacks), you can't just use a box, since this will either leave out half of the character, or include a lot of empty space.
It has been stated before in these forums that mesh colliders don't animate because their mesh needs to be recreated every frame. I wonder if, given the restriction of all colliders for frames within an animation having the same geometry, it wouldn't be possible to simply update each of the collider's vertex positions when changing frames.
If updating colliders on the fly doesn't definitely work and the mesh had to be recreated on each frame change, that might still be useful. Say you have a big boss that you want to apply a polygon collider to, and it has 12fps animations. I guess recreating the mesh 12 times per second wouldn't be prohibitive if the mesh creation function is optimited enough (but I might be wrong here).
Even without the option of animating polygon colliders, this could be approximated if multiple colliders per sprite were allowed, by using several boxes to cover (approximately) the same area as the polygon collider and then animating each of the boxes.
I need a quick solution for my game because I have some deadlines coming soon, so I'm implementing multiple colliders myself by hacking 2D toolkit in a dirty and ugly way. However, I don't know if I will get it working, since I'm still beginning to understand how 2D Toolkit works internally. I guess official support for the things mentioned above would be a great addition and benefit everyone else.
-
Multiple colliders are planned, but not in the next two releases - you'd probably need it sooner. I'll be happy to go through the steps required to get it working. It'll be much easier to get it working as a specific feature to your codebase, rather than as a feature in generic middleware like 2D Toolkit.
Of the top of my head, here are the prerequisites.
1. The box collider widget needs to support rotation.
2. Add collider structure internally.
3. CopyFrom needs to copy this data correctly and compare it correctly for the editor to save data.
3. In game, you'll need a manager class to pool box colliders, and in UpdateCollider, manage internally the colliders which get created and destroyed - if one frame has 4 colliders and the next has 3. The thing is, this might not be necessary in your case.
Something to note, and it'll be easiest as a content creation constraint - is to make sure that the same boxes are moved around. I.e. you don't want the box used for the feet in one frame to be swapped with a box used on a head, for instance.
Hope that helps.
-
Thanks for replying so quickly.
I can understand why multiple colliders won't be happening soon. Adding them in a clean way needs some redesign. Instead, the way I'm doing it as a quick fix is really, really nasty, changing all collider related variables into arrays. Getting those arrays to work requires A LOT of changes thoughout the code.
Now I need to focus on something else, but I will get back to this next week. I'll update here, whether I get it working or I hit some block.
Oh, I forgot about having sphere colliders for sprites. You commented before that they wouldn't work for non-uniform scaled sprites. I don't know if that's very common, but in my opinion sphere colliders would be useful even if restricted only to uniformly scaled sprites, which I'm guessing are the most common?
I'm not sure why you cited the box collider widget supporting rotation as a prerequisite. On the other hand, having the ability to rotate a sprite's collider was another thing I thought would be useful and forgot to mention before.
As you said, I won't necessarily need to pool colliders. I can always keep the same number of colliders per sprite and enable / disable them when appropriate. I'm not too worried about wasting memory, considering new computers these days come with 16Gb of RAM. I'm more interested in speed.
-
Just found this via Google. you mentioned that multiple box colliders re planned, do we have a date, or rough time scale?
-
I'll hold a poll after 1.80 to decide the next big feature. This could be it, if enough people vote for it. The good news is I know exactly how to go about it, the bad news - just need time to implement it.
-
For the love of god I hope so! I'm making a beat-em up and at the moment I need 2 sets of sprites layed on top of each inside a game Object. The "attack" sprite which holds the attack collider and the "defend" sprite which holds the hit collider. It works, but it's a bit of a faff.
It'll be great to define multiple box colliders inside a frame and for them to animate, and giving the users the ability to read which collider has been hit, etc.
-
NO MULTIPLE COLLIDERS
I agree that better collider support would be nice - I've had my problems with Polygon Colliders falling through each other. But it seems like multiple colliders has a simple work-around inherent to Unity. I'm still new to Unity so I don't know if there are performance ramifications, but I can't imagine that they'd be significant.
1) create sprite object, give it its first collider 2) create an empty game object and nest it inside the sprite object in the hierarchy 3) give the empty game object its own collider, sized and positioned to suit requirements 4) repeat for additional required colliders
The Sprite behaves as though each of those colliders were attached (which they are). For the game I'm starting to build I hope to create each limb of my character as a separate sprite each with its own collider, using Hinge Joints to provide a rag-doll effect when desired. Are there significant concerns that I should know about with this approach?
-
Try to just use box colliders for best performance - compound colliders aren't really that bad, but updating a collider within a compound collider will mean the whole compound collider gets re-evaluated.
Also make sure you have a rigid body on the root object if you need to move any of the sub objects.
-
Any update on the timeline for this feature?
Sorry, I did bump another topic about it as well.
-
No, I will only be able to continue development on this after 2D Toolkit 2.0 is out.
-
Hi there, am new to the forums, and just wanted to first say thanks for such a wonderful tool! I'm currently working on a top-down 2d action rpg, and 2D Toolkit has quickly become an essential part of the project's pipeline/workflow. Related to this post...one of the biggest areas of frustration with the project right now is collision detection. We're trying to figure out a system that can give us very precise collisions in an intuitive manner without the overhead of the Unity physics system (we don't use physics in our game). I stumbled across this forum thread while doing a Google search on 2D collision techniques in Unity. Has any progress had been made towards having multiple colliders on a 2D Toolkit sprite? Something like that would be incredibly beneficial to the type of game we're making. Also, I realize it's been a while since the last post in this thread, so if there are any other resources or posts I could take a look at to help with 2D collision detection, I would love a nudge in the right direction. Any news or help would be greatly appreciated. Thanks!
-
tk2d 2.4 (now in beta) has an editor which will let you define shapes per sprite. It (intentionally) doesn't create colliders for these, but leaves it for you to deal with them.
http://2dtoolkit.com/docs/latest/advanced/advanced_collider_shapes.html
-
Thanks so much! I think that will probably do what I need. This might be a silly question since I haven't actually looked at the new feature yet, but is there a way to reference each individual collider shape specifically, or do I have to iterate through the collider array and guess at what I'm getting? Basically what I want is a collider for dealing damage and a collider for taking damage, and I want to be able to know which is which.
-
No there isn't, but since its in beta feel free to suggest stuff once you've tried it.