![]() Between those two things you won't usually actually need accurate collision detection - players aren't watching your game in slow-motion to see if the damage triggers when and where the sword actually connects to each enemy. Draw a big trail on your sword swipes or whatever you've got, and make sure that enemies look like they're responding appropriately. and they never told me it was a problem! As long as you make it feel good players typically won't get upset about the fine-grained details of things they can't actually see. Why? Because I'd decide early on to fix it when players told me it was a problem. I'd roll my own collision detection systems inn an hour or less, and use that for the entire length of a game project. Sometimes I'd text that sphere against a box, if I was getting advanced. While I use more complicated systems now (as you can probably tell), in my early days of writing games I used to use spheres for collision detection, for everything. How do you want the player to control it?Ĭlick to expand.It could also be useful for occlusion checks - so that if you're attacking a group of enemies only those in the front row get damaged.īut in general, yes, this kind of simple approach (check distance -> angle -> occlusion) can work wonders. ![]() What type of animation do you want to have? What approach will you take to balancing your game? Knowing which one to use really depends on how you want your combat to actually work. (If accuracy was important, I'd probably use splines or something for the sweep test, since point-to-point tests would get less accurate at longer ranges.) Or, you could use continuous collision detection and just use the various collision callbacks. unless you want to repeat it, which you might. Or, you could do sweep tests each frame and keep a list of things you've already applied damage to in the current attack to avoid repeating it. The trigger didn't move because it didn't have to, all it did was keep a list of what's currently touching it for the damage part of the script to use when applying damage in the hit frame.Īnother approach you could use is a hit frame and either a bunch of test points in the weapon or a physics sweep test between the previous and current positions of the weapon, or along a spline which defines the sweep. Anything in the trigger during the hit frame had damage applied. Last time I implemented melee attacks I did a "hit frame" accompanied by a trigger. That makes physical sense, but does it make game design sense? Plenty of games use the concept of a "hit frame", which is some kind of time marker in an attack animation which tells the game at which time of the attack to apply damage. I also wouldn't assume that you necessarily even want to apply hits based on contacts alone. There are plenty of games (e.g.: Ninja Gaiden springs to mind) where animations are so fast that the character is nearly snapping from pose to pose - how fast do you think the tip of those swords are moving? I would not start with the assumption that movement will be slow enough to hit things reliably within frame deltas unless that kind of slow movement is a deliberate part of your design. Unity's physics system does indeed let you pick, thats what the "continuous" collision detection is meant for (though I'm not sure how effective it is).Īs for what to do with melee weapons, triggers and colliders are the typical way to go, but they're not the only way to go. ![]() Click to expand.Well, solving it can be pretty "101", but it's a compromise you might intentionally make for performance.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |