redistressed

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.

> 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.

I’ve had this thought. You know what I worry, though— even if I did have a vividly realized simulation of a human body accurate enough to engage in realistic medieval melee combat, wouldn’t I just have her sit at home and write esoteric computer programs? That’s what I do with this one.

Appreciate the comment, but I want stress that the problem really is the computational complexity. (Or at least, computational complexity really is a serious problem.)

If everything in your world behaves like a bullet, physics is simple. If everything in your world behaves like a sword, physics is a nightmare. A lot of games with swords literally pretend that swords are made of bullets to get around this. No kidding.

To spoil my deep explanation: in the sense games are concerned with, a bullet is a non-rotating length-0 inertially-controlled sword. That doesn’t generalize cheaply.

I don’t know specifically, but the general trick is to get your approximate solve to have the impact happen at a consistent time, since that’s what players have fine-grained control over. Other stuff involved in restitution, like angle of deflection and force at the point of impact, you can basically fudge to be close enough for gameplay purposes. If a game feels really satisfying, it generally means that stuff has been tuned really carefully. (So it is with games.)

You work that stuff out with numerical accuracy if you can be careful about when you need to, but since the animations and audio cues need to be carefully tuned anyway, it tends to add unnecessary complexity.

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.

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.

I don’t see people talking about it, but this has to be a huge part of why sword combat in video games is so much less explored and well-realized than gunfighting. Figuring out why it’s such a hard problem, and exploring the various workarounds and their limitations, is a fun weekend project if you know a little computational geometry. (And it’s probably the work of a few minutes if you know enough formal geometry, I guess.)