19 ms·

> Fun side note to this: although bullet collisions are trivial, sword collisions are genuinely computationally complex, in the sense that I’m not aware of a si

> Fun side note to this: although bullet collisions are trivial, sword collisions are genuinely computationally complex, in the sense that I’m not aware of a single publicly available game engine that ships with a robust real-time solver for sword-sword collisions. That's not a sense in which you can determine the computational complexity of the problem. Perhaps accurate sword combat just isn't very fun. Maybe it makes convincing animation much harder. Maybe it makes controlling the character much harder. Maybe you just don't know that many games. There are plenty reasons that it might be true that no games that you know of shipped with a robust real-time solver for sword-sword collisions other than computational complexity. > I find this really interesting because it’s a complete inversion of reality, where bullet impacts are vastly more energetic and chaotic than sword clashes. It tells you something about the scale we play games at, maybe. Of course the modelling of bullets is also usually extremely simplified in video games. If there is anything we can learn from this I think it's that players prefer games to be predictable and controllable over them being perfectly realistic.

rossnordby 7y ago
I prototyped a physical first person sword fighter doohicky once, so allow me to weigh in: You're both right! I'd point out four big categories of difficulty: 1) Physics. You need a swept collision test capable of handling very high linear and angular velocity of very thin shapes (a sword is not thick, and the tip can move pretty dang fast), and collision response capable of dealing with the results. This is doable- conservative advancement operating on distance functions will work- but working out all the details in a way that makes the final result fast is not easy. A speedy implementation alongside a speculative contact solver can work, though: https://www.youtube.com/watch?v=sfgC_eNx9M8#t=1m20s https://www.youtube.com/watch?v=sfgC_eNx9M8#t=1m20s 2) User interface. A mouse and keyboard struggle to express all the degrees of freedom available to a physical handheld weapon. Swinging using the mouse works okay, but you need to do so in a way that doesn't interfere with camera control, and you need to be able to interrupt and redirect movements at any point, then add jabs, different guards, ... Expressing all of that in a single intuitive interface that doesn't require awkward mode switching is not easy. My prototype had an okay-ish approach, and I think it could still be improved further, but there's no way a mouse-keyboard user would be able to compete with someone of equal skill using VR hand controllers. There's a good reason why melee combat games are so much more common in VR. 3) Graphics. Single planar projections simply aren't enough for first person (especially outside of VR)- it feels like wearing blinders. Even third person doesn't help enough, and seeing your character gets in the way of seeing your weapon and opponent sometimes. Using a nonplanar projection like stereographic fisheye, it starts feeling okay around 160 degrees, though 200+ is nice once you adapt to the mild distortion it introduces. This requires a pretty different approach to rendering (like multiple subviews, direct projection raytracing, vertex warped rasterization, etc.). A couple of examples: https://www.youtube.com/watch?v=jQOJ3yCK8pI https://www.youtube.com/watch?v=jQOJ3yCK8pI https://www.youtube.com/watch?v=mIax_ProQ8c#t=1m4s https://www.youtube.com/watch?v=mIax_ProQ8c#t=1m4s 4) Animation. While achieving a level of animation quality common in early 2000's titles is pretty easy- just have a set of poses for various weapon states to interpolate between, blend in some leg motion, shrug, done- achieving a very high animation quality bar is extremely difficult. Most modern AAA games use massive libraries of mocap data, and in some cases the animations directly drive motion to make everything grounded and solid. For Honor is a good example: https://www.youtube.com/watch?v=4pdcA3mhe0E https://www.youtube.com/watch?v=4pdcA3mhe0E. But in a game allowing total physical control with expectation of proper physical response to every interaction, the mocap coverage requirements explode. You can still do pretty well if you have enough data and put in a huge amount of effort, but at a certain point you start wishing the magical machine learning genie would swoop in and save you. I think all of these things are solvable enough to permit the existence of a game, but they're hard enough that it's not surprising that they are still so rare.
- redistressed 7y ago
  Just to close the circuit. If you do ever make the move to VR, frame times go way down and arc accuracy requirements for the very tip of the blade go way up. You are going to get really frustrated that you can’t just google up a numerically robust solver :) In VR you will run into edge cases where the difference between a miss and a parry at the tip of the blade requires sub-frame rotational resolution at the controller. If it were a gun, you’d never know the difference— with a sword you can feel that it moves wrong during the frame. I don’t think there’s going to be any software solution for that, we just need better tracking hardware before we can properly model a 1-meter object held out at arm’s length. Which makes you think about constraints, is all I’m saying.
  - erikpukinskis 7y ago
    I would expect you'd have to go DEEP into cognitive science to find a good model for this stuff. E.g.: https://www.researchgate.net/publication/12618263_Perceptual_independence_of_whole_length_partial_length_and_hand_position_in_wielding_a_rod https://www.researchgate.net/publication/12618263_Perceptual... http://scholarpedia.org/article/Dynamic_touch http://scholarpedia.org/article/Dynamic_touch
  - rossnordby 7y ago
    On the software side of things, the good news is that the combination of a decent conservative advancement detection scheme and speculative contacts can get you down to microsecond tier fidelity pretty cheaply. (Incidentally, this specific problem is why I built that particular form of continuous collision detection :P) You're definitely right though that it's not going to magically solve away hardware level concerns. On that front, one of the things I had to end up doing to ensure physical consistency was bite the bullet on a level of indirection. This can be flat out necessary on a gameplay level- allowing full 1:1 control often leads to pretty nasty pathologies and difficulty with correct physical responses. A truly physical character's motion can never truly match the input motion, since your controller is dramatically more nimble than even a light 2.5 pound longsword and the physical sword may be interfered with. This introduces some challenges on the side of user responsiveness and intuition, to be sure, but the physical motion also smooths out input and seems to make small scale controller imprecision a distant concern to the player. If the player can adapt to the physical indirection, they tend to allow a lot more leeway. This becomes even more valuable when trying to hide latency. If you have physically reasonable accelerations, networking overhead becomes a whole lot less objectionable. There are definitely tradeoffs- the feeling of being a puppeteer takes some time to get used to.
redistressed 7y ago
> There are plenty reasons that it might be true that no games that you know of shipped with a robust real-time solver for sword-sword collisions other than computational complexity. This is the kind of comment that makes me just want to skip HN altogether. Why on earth are you arguing this at all — the counter to a point I never made — and why are you arguing from a position of ignorance like it makes you smarter than me? You don’t have to pull an opinion out of your ass here. Just try it, the way my sibling poster has. This is a mathematically hard problem, and it will constrain your game design, and I think that’s really interesting. You really don’t have to be a dick about it.
- dang 7y ago
  HN can definitely be annoying when commenters act like they know more than they do. No question about it. But please don't let it trigger you into lashing out, which only makes the thread worse. Instead, remember that the vast majority of readers are here to learn, and if you know more, sharing some of what you know, or some of your experience, is really helpful to them. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html p.s. On another note, can you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines too. HN is a community. Users needn't use their real name, but do need some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix&page=0&query=by:dang%20community%20identity https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
  - vlunkr 7y ago
    Is there a reason hn admins can't send direct messages to users, as opposed to calling them out publicly for things like this? I suppose doing it this way is probably more effective in changing behavior.
    - dang 7y ago
      That's the main reason for doing it publicly, yes. We do try not to seem like we're picking on anybody personally.

rossnordby 7y ago

I prototyped a physical first person sword fighter doohicky once, so allow me to weigh in: You're both right! I'd point out four big categories of difficulty: 1) Physics. You need a swept collision test capable of handling very high linear and angular velocity of very thin shapes (a sword is not thick, and the tip can move pretty dang fast), and collision response capable of dealing with the results. This is doable- conservative advancement operating on distance functions will work- but working out all the details in a way that makes the final result fast is not easy. A speedy implementation alongside a speculative contact solver can work, though: https://www.youtube.com/watch?v=sfgC_eNx9M8#t=1m20s https://www.youtube.com/watch?v=sfgC_eNx9M8#t=1m20s 2) User interface. A mouse and keyboard struggle to express all the degrees of freedom available to a physical handheld weapon. Swinging using the mouse works okay, but you need to do so in a way that doesn't interfere with camera control, and you need to be able to interrupt and redirect movements at any point, then add jabs, different guards, ... Expressing all of that in a single intuitive interface that doesn't require awkward mode switching is not easy. My prototype had an okay-ish approach, and I think it could still be improved further, but there's no way a mouse-keyboard user would be able to compete with someone of equal skill using VR hand controllers. There's a good reason why melee combat games are so much more common in VR. 3) Graphics. Single planar projections simply aren't enough for first person (especially outside of VR)- it feels like wearing blinders. Even third person doesn't help enough, and seeing your character gets in the way of seeing your weapon and opponent sometimes. Using a nonplanar projection like stereographic fisheye, it starts feeling okay around 160 degrees, though 200+ is nice once you adapt to the mild distortion it introduces. This requires a pretty different approach to rendering (like multiple subviews, direct projection raytracing, vertex warped rasterization, etc.). A couple of examples: https://www.youtube.com/watch?v=jQOJ3yCK8pI https://www.youtube.com/watch?v=jQOJ3yCK8pI https://www.youtube.com/watch?v=mIax_ProQ8c#t=1m4s https://www.youtube.com/watch?v=mIax_ProQ8c#t=1m4s 4) Animation. While achieving a level of animation quality common in early 2000's titles is pretty easy- just have a set of poses for various weapon states to interpolate between, blend in some leg motion, shrug, done- achieving a very high animation quality bar is extremely difficult. Most modern AAA games use massive libraries of mocap data, and in some cases the animations directly drive motion to make everything grounded and solid. For Honor is a good example: https://www.youtube.com/watch?v=4pdcA3mhe0E https://www.youtube.com/watch?v=4pdcA3mhe0E. But in a game allowing total physical control with expectation of proper physical response to every interaction, the mocap coverage requirements explode. You can still do pretty well if you have enough data and put in a huge amount of effort, but at a certain point you start wishing the magical machine learning genie would swoop in and save you. I think all of these things are solvable enough to permit the existence of a game, but they're hard enough that it's not surprising that they are still so rare.

redistressed 7y ago
Just to close the circuit. If you do ever make the move to VR, frame times go way down and arc accuracy requirements for the very tip of the blade go way up. You are going to get really frustrated that you can’t just google up a numerically robust solver :) In VR you will run into edge cases where the difference between a miss and a parry at the tip of the blade requires sub-frame rotational resolution at the controller. If it were a gun, you’d never know the difference— with a sword you can feel that it moves wrong during the frame. I don’t think there’s going to be any software solution for that, we just need better tracking hardware before we can properly model a 1-meter object held out at arm’s length. Which makes you think about constraints, is all I’m saying.
- erikpukinskis 7y ago
  I would expect you'd have to go DEEP into cognitive science to find a good model for this stuff. E.g.: https://www.researchgate.net/publication/12618263_Perceptual_independence_of_whole_length_partial_length_and_hand_position_in_wielding_a_rod https://www.researchgate.net/publication/12618263_Perceptual... http://scholarpedia.org/article/Dynamic_touch http://scholarpedia.org/article/Dynamic_touch
- rossnordby 7y ago
  On the software side of things, the good news is that the combination of a decent conservative advancement detection scheme and speculative contacts can get you down to microsecond tier fidelity pretty cheaply. (Incidentally, this specific problem is why I built that particular form of continuous collision detection :P) You're definitely right though that it's not going to magically solve away hardware level concerns. On that front, one of the things I had to end up doing to ensure physical consistency was bite the bullet on a level of indirection. This can be flat out necessary on a gameplay level- allowing full 1:1 control often leads to pretty nasty pathologies and difficulty with correct physical responses. A truly physical character's motion can never truly match the input motion, since your controller is dramatically more nimble than even a light 2.5 pound longsword and the physical sword may be interfered with. This introduces some challenges on the side of user responsiveness and intuition, to be sure, but the physical motion also smooths out input and seems to make small scale controller imprecision a distant concern to the player. If the player can adapt to the physical indirection, they tend to allow a lot more leeway. This becomes even more valuable when trying to hide latency. If you have physically reasonable accelerations, networking overhead becomes a whole lot less objectionable. There are definitely tradeoffs- the feeling of being a puppeteer takes some time to get used to.

redistressed 7y ago

> There are plenty reasons that it might be true that no games that you know of shipped with a robust real-time solver for sword-sword collisions other than computational complexity. This is the kind of comment that makes me just want to skip HN altogether. Why on earth are you arguing this at all — the counter to a point I never made — and why are you arguing from a position of ignorance like it makes you smarter than me? You don’t have to pull an opinion out of your ass here. Just try it, the way my sibling poster has. This is a mathematically hard problem, and it will constrain your game design, and I think that’s really interesting. You really don’t have to be a dick about it.

dang 7y ago
HN can definitely be annoying when commenters act like they know more than they do. No question about it. But please don't let it trigger you into lashing out, which only makes the thread worse. Instead, remember that the vast majority of readers are here to learn, and if you know more, sharing some of what you know, or some of your experience, is really helpful to them. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html p.s. On another note, can you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines too. HN is a community. Users needn't use their real name, but do need some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix&page=0&query=by:dang%20community%20identity https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
- vlunkr 7y ago
  Is there a reason hn admins can't send direct messages to users, as opposed to calling them out publicly for things like this? I suppose doing it this way is probably more effective in changing behavior.
  - dang 7y ago
    That's the main reason for doing it publicly, yes. We do try not to seem like we're picking on anybody personally.