So what do you guys think? Which is more efficient/accurate?
It depends entirely on what you want to do with your game. Physics-based combat may require more skill on the part of the player, and might be more difficult to implement. As far as efficiency is concerned, it depends once again on what you want for your specific game. Different styles of games use different combat systems. Either method could potentially be more/less efficient and accurate than the other, it just depends on how far you take it. Your question is very vague.
In the end it just depends on what you want for your game.
1 Like
Depends on the weapon. If itâs a sniper rifle with instant hit, a ray cast might be best. If its a grenade launcher or shotgun, colliders will be better.
Yeah but in the title he says âfor melee weapons.â
1 Like
Go with colliders and triggers for melee combat. Chances are that the motion is slow enough that colliders will register all hits, unlike with bullets and the like that may travel right through and past a gameObject during the course of a frame.
Oops, missed that one.
For melee a ray cast doesnât make any sense. Definately a set of colliders on the weapon, (to determine which part of the weapon hit the opponent), and a few colliders on the various body parts.
Telescoping can be remedied by using rays drawn between the two points from of a moving object in between frames.
I believe the physics engine does this by default, and itâs what stops objects from falling through terrain constantly.
The trouble is that a lot of âbulletsâ are teleported in each frame rather than moving.
Hereâs a great article about it:
http://www.militantgame.com/web/classic-8-bit-bullets-for-a-modern-day-3d-game-how-projectiles-work-in-militant/
That said, back to the OP, I too would like to know what works best for different kinds of melee.
Unless this was updated in a recent version of Unity, no this is not handled automatically.
There is a script on the wiki that replicates similar behaviour to what you mentioned above.
Huh, youâre right. I just checked it and sure enough with enough speed objects do fall right through the terrain. Thatâs odd, I figured that would be like physics engine 101.
Thanks for the link, btw.
Yeah thatâs one way to do it. But a lot of RPG games and such have targetting systems and automatic combat which is not physics based. If youâre going for that kind of game, raycasting is better. I kind of agree though, physics based combat is more fun. 
Melee motion might be slow enough, but not necessarily. Often the swing of a sword will be too fast as well. However, there is something you can do about this in Unity if you use rigidbodies. In the rigidbody component you can change the collision detection mode. This will tell Unity to detect collisions for fast moving objects. Very useful, especially for projectiles.
http://docs.unity3d.com/Manual/class-Rigidbody.html
Well, solving it can be pretty â101â, but itâs a compromise you might intentionally make for performance. 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).
As 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. 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. 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 also wouldnât assume that you necessarily even want to apply hits based on contacts alone. 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.
Last time I implemented melee attacks I did a âhit frameâ accompanied by a trigger. Anything in the trigger during the hit frame had damage applied. 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.
Another 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. 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⌠unless you want to repeat it, which you might. (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.
Plenty of ways to skin this cat. Knowing which one to use really depends on how you want your combat to actually work.
- How fast will it be?
- How do you want to apply damage?
- What approach will you take to balancing your game?
- What kinds of weapons will you have?
- What type of animation do you want to have?
- How do you want the player to control it?
- Do you want it to be deterministic?
- So on and so forthâŚ
9 Likes
People who make games with auto-targeting/button mashing weapon systems should be dragged out into the street and shot! Hence I would never advocate such a system for melee. Agreed, physics based targeting and âreal combatâ are much more satisfying and interesting.
Depends on the game and the accuracy requirements.
I would think a distance check would be the best option generally⌠think wowâŚ
but if you want the melee to make physical contact, then colliders⌠they work better with animated weapons.
You could use sphere cast, cast it only during the animation momentum and in the direction the weapon move
That makes a lot of sense.
Thank you!
Back to the OP:
So to clarify, a game like Diablo 3 when you attack one target you would most likely use a ray and distance followed with an animation. Then when you do a sweeping move you would use âsplinesâ to cast a ray through the objects being hit.
Then a game like Elder Scrolls would use a collider on the weapon and a collider on the target, then have a frame count as the âhitâ frame and either have the target do an animation or have their collider move with physics from the point of collision.
And of course, colliders for things like spells and area effects.
Is that about right?
1 Like
It depends on the game. If you are talking about FPS knife swipe like it CoD, Iâd use a cone or sphere trigger, so that the knife doesnât have to be accurate, but itâll still hit the enemy.
If itâs a third person game like Devil May Cry, then Iâd use a triggers. The tricky part is getting the trigger to activate(take health) ONLY on swings, and not when player is just walking around with it. For that, you will have to know the animation system!
It will all be dependent. If itâs weighted and not ludicrously fast, then basic colliders should be fine, otherwise you may need to play around with hitboxes to give physics more slack. If you make the colliders while taking into account that physics wonât catch everything, then it shouldnât be a problem.
So long as you are aware of what can be used and in what situations they should be used, then more power to you.
Wooah! This is interesting read.
So, in a game such as the Soul Calibur on the Dreamcast.
The Dreamcast version, not the sequels.
How do you guyâs, think the Soul Calibur dev. team back in 1998 would have approached this weapons melee combat thing?
For games like diablo/wow I expect they only use distance, and a ray if it involves a line of sight element.
Thereâs nothing gained by using a ray except for players missing the target (and getting frustrated)
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.
But in general, yes, this kind of simple approach (check distance â angle â occlusion) can work wonders.
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. Spaceship? Sphere. Zombie? Sphere. UFO? Sphere. Sometimes Iâd text that sphere against a box, if I was getting advanced. 
Iâd roll my own collision detection systems inn an hour or less, and use that for the entire length of a game project.
Why? Because Iâd decide early on to fix it when players told me it was a problem⌠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. Draw a big trail on your sword swipes or whatever youâve got, and make sure that enemies look like theyâre responding appropriately. 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.
2 Likes