Has anyone implemented melee?
by Richard Preziosi · in Torque 3D Public · 11/18/2009 (2:27 pm) · 11 replies
Saw a few posts in a quick search of T3D private forums, but can't see em. Was just curious if anyone has gotten some kind of melee into T3D yet or if it's still a work in progress.
#2
What is melee? More importantly: what is melee in your game?
Let us think, for a moment, about swinging a sword. Swinging a sword is an action in which a sword is moved from position A, to position B along some path. In other words, you are taking a volume, and sweeping it through space. Something is hit by the "sword" if it intersects that volume at the appropriate time.
For ease of calculation, let's assume a sword is a sphere (or several spheres). By sweeping the sphere(s) through space, we now have an approximation of a sword swing. You could use a more complicated volume if you wanted, but I don't think it would net much better results.
It is very important to game development that you not think of features in an entirely concrete way. This feature you desire is not really "melee", it's a swept volume collision with a specific response, and animation, associated with the action. The accuracy of that collision is something which is game specific. Maybe you are making a Die by the Sword re-make and you need super-accurate collision so you do a full, swept-cylinder implementation, or maybe it's more of a brawler game, and a simple hemisphere check centered on the player is good enough.
11/18/2009 (3:26 pm)
I am always slightly confused when people mention melee not being supported. It makes me slightly frustrated, not because it is an unreasonable request, but because it is important to not just say, "I need melee, Torque doesn't have it. Brickwall." What is melee? More importantly: what is melee in your game?
Let us think, for a moment, about swinging a sword. Swinging a sword is an action in which a sword is moved from position A, to position B along some path. In other words, you are taking a volume, and sweeping it through space. Something is hit by the "sword" if it intersects that volume at the appropriate time.
For ease of calculation, let's assume a sword is a sphere (or several spheres). By sweeping the sphere(s) through space, we now have an approximation of a sword swing. You could use a more complicated volume if you wanted, but I don't think it would net much better results.
It is very important to game development that you not think of features in an entirely concrete way. This feature you desire is not really "melee", it's a swept volume collision with a specific response, and animation, associated with the action. The accuracy of that collision is something which is game specific. Maybe you are making a Die by the Sword re-make and you need super-accurate collision so you do a full, swept-cylinder implementation, or maybe it's more of a brawler game, and a simple hemisphere check centered on the player is good enough.
#3
However I agree with your rant in some respects,because you are right the question has melee been put into the engine is silly, as it implies the engine cant do that, but i do not think that was the intent of the question, real question i think being asked is has anyone integrated a coded solution to a swept volume collision with a specific response and animation, associated with the action (melee), and the answer i gave Rick was yes one particular solution which has been used in each major build of torque has been ported successfully,
and there are other multiple solutions posted as resources out there that just need a little love to become integrated with the latest and greatest code base. I believe in fact in the original thread i posted in the private forums when i was struggling with the port, someone asked if one of those other solutions has been ported over.
However it would be nice if such a swept volume collision with a specific response and animation associated with the action were an out of the box feature, but unfortunately it is not, because if it were it would require less time as you would not need to implement someone else's solution and then adapt it to individual needs. and could go right on with adapting
I don't think Ive run into any particular thread though who has yet implicitly said it is impossible for torque to do this, though those of us with child like skills with the C syntax often struggle with such an implementation and rely on the good will of others to tie our proverbial shoes :)
11/18/2009 (11:27 pm)
I am a little puzzled by your response Pat? mainly because i do not think anyone here (in this specific thread) has indicated that it was not supported? but more of has anyone implemented a swept volume collision solution with a specific response and animation associated with the action (i.e melee for short) :) However I agree with your rant in some respects,because you are right the question has melee been put into the engine is silly, as it implies the engine cant do that, but i do not think that was the intent of the question, real question i think being asked is has anyone integrated a coded solution to a swept volume collision with a specific response and animation, associated with the action (melee), and the answer i gave Rick was yes one particular solution which has been used in each major build of torque has been ported successfully,
and there are other multiple solutions posted as resources out there that just need a little love to become integrated with the latest and greatest code base. I believe in fact in the original thread i posted in the private forums when i was struggling with the port, someone asked if one of those other solutions has been ported over.
However it would be nice if such a swept volume collision with a specific response and animation associated with the action were an out of the box feature, but unfortunately it is not, because if it were it would require less time as you would not need to implement someone else's solution and then adapt it to individual needs. and could go right on with adapting
I don't think Ive run into any particular thread though who has yet implicitly said it is impossible for torque to do this, though those of us with child like skills with the C syntax often struggle with such an implementation and rely on the good will of others to tie our proverbial shoes :)
#4
11/18/2009 (11:58 pm)
Haha, well atleast you guys knew what I meant. Thanks for the responses. And yea I simply said melee cause it was shorter, and the main source of damage in Torque in the past was projectile based, so I figured melee was just understood.
#5
In World of Warcraft, a melee attack is a spell. It is a radius check, an animation, and some random numbers.
In a fighting game, a melee attack needs to be precisely timed and tested against fully animated meshes (not static shapes or simple volumes).
In the typical FPS, a melee attack is usually hitting with the butt of the rifle, and so that may as well just be an "instant explosion" so basically just instantiate an explosion object, and let it apply the damage. I should probably test that solution, but it should work out of the box.
Something that is like Dynasty Warriors you really want some kind of swept volume like I described if you want it networked. That would be a good chunk of code to get generalized in Torque if it is fast enough.
It does keep getting a lot of requests so maybe it is something we can ask more questions about, and figure out some kind of compromise. It is just that the needs of one game, for melee, can be totally different from the needs of another game, and all but the simplest implementations are unnecessary overhead for some uses and needs. One method may work fine for a single-player (short-circuit connection) game, but not for an actual networked multi-player game. What works for a hand-full of targets may fail badly when you are fighting hordes of enemies. It's always kind of a moving target, and game-specific.
11/19/2009 (3:16 am)
Well part of the frustration is also that "melee" is many things to many people, and it's not always clear what is what. In World of Warcraft, a melee attack is a spell. It is a radius check, an animation, and some random numbers.
In a fighting game, a melee attack needs to be precisely timed and tested against fully animated meshes (not static shapes or simple volumes).
In the typical FPS, a melee attack is usually hitting with the butt of the rifle, and so that may as well just be an "instant explosion" so basically just instantiate an explosion object, and let it apply the damage. I should probably test that solution, but it should work out of the box.
Something that is like Dynasty Warriors you really want some kind of swept volume like I described if you want it networked. That would be a good chunk of code to get generalized in Torque if it is fast enough.
It does keep getting a lot of requests so maybe it is something we can ask more questions about, and figure out some kind of compromise. It is just that the needs of one game, for melee, can be totally different from the needs of another game, and all but the simplest implementations are unnecessary overhead for some uses and needs. One method may work fine for a single-player (short-circuit connection) game, but not for an actual networked multi-player game. What works for a hand-full of targets may fail badly when you are fighting hordes of enemies. It's always kind of a moving target, and game-specific.
#6
I think the implementation of some melee out of the box would benefit T3D greatly. I don't think you could go wrong with implementing a "What you swing at is what you hit" type of melee. As that is basic enough to start anyone off that is not using a direct damage approach.
Direct damage can already be done quite easily, but I think a good tutorial for it would be a good thing. Maybe I'll cook something up if I dont' see something surface in a month or so.
11/19/2009 (7:35 am)
Great post Pat thanks for the elaboration, and you are correct, melee is different to different people. But I think we could meet somewhere in the middle and satisfy most people.I think the implementation of some melee out of the box would benefit T3D greatly. I don't think you could go wrong with implementing a "What you swing at is what you hit" type of melee. As that is basic enough to start anyone off that is not using a direct damage approach.
Direct damage can already be done quite easily, but I think a good tutorial for it would be a good thing. Maybe I'll cook something up if I dont' see something surface in a month or so.
#7
I was thinking of ways to do FPS melee and figured that a raycast forwards 2 metres/units (probably from eyenode), play attack animation and then apply damage and impulse would be best, rather than spawning a projectile, and keep things simple.
11/19/2009 (11:14 am)
@PatI was thinking of ways to do FPS melee and figured that a raycast forwards 2 metres/units (probably from eyenode), play attack animation and then apply damage and impulse would be best, rather than spawning a projectile, and keep things simple.
#8
That is exactly the way that one of UDK's melee methods works, and I think it would be a good method, basically it how most engines handle this is:
The TraceShot function lets us trace along a line in 3D space to see whether it intersects an object.
This approach is used by many games/engines for "instant hit" weapons.
You simply allow a script to determine the length of that line and to toggle if it is applicable at that point in time, ie. when state is onFire you allow it to do damage. This would also let you have ways to do damage just by running into something with the weapon if you wanted.
11/19/2009 (12:26 pm)
@SteveThat is exactly the way that one of UDK's melee methods works, and I think it would be a good method, basically it how most engines handle this is:
The TraceShot function lets us trace along a line in 3D space to see whether it intersects an object.
This approach is used by many games/engines for "instant hit" weapons.
You simply allow a script to determine the length of that line and to toggle if it is applicable at that point in time, ie. when state is onFire you allow it to do damage. This would also let you have ways to do damage just by running into something with the weapon if you wanted.
#9
My naive first approach would be to mount the weapon as an object with collision instead of an image. Naively, I would presume that collision would still be functional, even if the reason for the object moving through space is an animation.
I have an article more or less layoung out my approach:
http://dancingelephants.wordpress.com/tag/physics/
11/19/2009 (2:21 pm)
Well my design requires swept volume collision; though I have not got to the torque part yet as I'm still working on the Python back end (yes, PW). My naive first approach would be to mount the weapon as an object with collision instead of an image. Naively, I would presume that collision would still be functional, even if the reason for the object moving through space is an animation.
I have an article more or less layoung out my approach:
http://dancingelephants.wordpress.com/tag/physics/
#10
11/19/2009 (2:53 pm)
Interesting read David, keep us posted on your progress.
#11
11/19/2009 (5:07 pm)
A very basic implementation in my opinion would be best for out of the box implementation in my opinion, because you are absolutely right everyone has different needs, and many dont even need it, for my personal needs non of the melee systems currently resourced meet my needs, however i can use the server side resource as a starting point. if a very basic system were in place out of the box then that would become the starting point i would use.
Torque Owner Ken Johnston
Indiestructable Systems