1
\$\begingroup\$

I want to design a Metroidvania style game that uses different primary weapons, having very different hitboxes. I understand that many devs simply hardcode a collider in front of the character, but what would the most efficient way to organize multiple colliders (so that you would activate one whenever its corresponding weapon is swung)?

Also, is it possible that ray casting may be a better option for this function?

\$\endgroup\$
7
  • \$\begingroup\$ Have you experienced any problems just setting up one GameObject for each different weapon collision, and parenting these collision objects for your active weapons to the player character? \$\endgroup\$
    – DMGregory
    Commented Jun 21, 2017 at 12:08
  • \$\begingroup\$ @DMGregory I had considered that, but I was afraid it would be a dirty method of going about it. Is that your personal recommendation? \$\endgroup\$
    – Richard
    Commented Jun 21, 2017 at 12:12
  • \$\begingroup\$ As a general rule, I recommend doing things in a way that's simple, intuitive, and flexible first. That direct method seems to check all of those boxes — if you ever need a new collision shape, add another collision object. You can see & modify them in the scene view which helps with debugging too, compared to code-based checks. So even if it seems blunt, I wouldn't consider that a disqualification unless we discover some problem with it in practice. That's why I asked to see if there'd been any issue with approaching it this way. \$\endgroup\$
    – DMGregory
    Commented Jun 21, 2017 at 12:17
  • \$\begingroup\$ @DMGregory seems simple enough. I'll do that and get back to you if I run into a snag. \$\endgroup\$
    – Richard
    Commented Jun 21, 2017 at 12:18
  • \$\begingroup\$ How many weapons are you talking about? Scalability could be an issue with multiple colliders, but if you're only talking about 3 weapons then who cares. \$\endgroup\$
    – jhocking
    Commented Jun 21, 2017 at 16:21

1 Answer 1

1
\$\begingroup\$

You might consider using OverlapArea instead of a collider for the hitbox. Then the hit area is programmatically defined, instead of a box manually placed in the scene.

Of course you may find that editing it is a little trickier now that it's not a box in the scene; that's pretty easy to handle by drawing a custom Gizmo in the Scene view.

\$\endgroup\$
1
  • \$\begingroup\$ I originally tried something similar with boxCasting, but I had difficulty just as you mentioned. Your proposed method might be a bit more sensible though. \$\endgroup\$
    – Richard
    Commented Jun 21, 2017 at 19:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .