by the way why is the seax being held with the blunt side or is that how ancient horde of mongols used to hold their specific types of weapons?
That’s the sharp side. Saxons, not mongols.
Tibberius commented on this not too long ago.
For what it’s worth: the analysis makes overly general assumptions on how players enter the pool, because it treats players as i.i.d. variables, when in reality they are highly correlated since the matchmaking algorithm is in control. Simple counterexample: matchmake once, repeat match over and over again. Clearly unacceptable in practice, but it shows the loophole.
To get practical low-population matchmaking out of that loophole requires more work though. But this is a textbook algorithm design & analysis example of a tradeoff between efficiency and generality, i.e. the more general the solution is, the less efficient it is.
A battlefield-type conquest mode with a large open map full of siege machines, where holding multiple capture points decreases the enemy team’s tickets faster. Then the only thing keeping it from being perfect is mounted combat.
Would this even work, though? In battlefield you run around capturing flags, which is made bearable by there being LOTS of vehicles and everyone uses a ranged weapon, so the distance isn’t that bad. But I can’t imagine that being fun endlessly running from one point to another on foot using a melee weapon. Someone sneaks behind lines and caps a far away point, now someone has to spawn there to stop him, and even if he does stop him, he now has to either suicide and respawn at the front, or have a long ass trek back to the frontline. Sure horses could help, but people on horseback are almost as annoying as archers. And then there’s archers on horseback.
As long as the torso movements get more natural I think the animations will be fine, You and wubb are doing a great job, keep it up!
Thanks! Do let me know what you mean by torso movements specifically, it’s hard to know what exactly people are referring to sometimes :)
Also mind that server CPU use increases geometrically as you add more players; 64 is much more than twice as expensive as 32 players is.
Could you give any hint as to why this is? Hit detection is done client-side, so that only leaves server-side movement, which can be quite expensive I suppose. But geometric? That’s an exponential asymptotic bound. Surely you mean quadratic?
Well have you seen people with like 150 ping run, if you dont see em teleport to much then its good.
This has nothing to do with it. The teleports happen when the snapshots miss the interpolation window. The actual position of the player is not where you see him teleport to, but typically one or two snapshots ahead (which your client already received, but won’t display for a while in order to make them smooth), plus network delay.
Server mostly does a good job at guessing someones position. Sure theres many laggers that have teleportd a meter here and there
The server cannot guess anyone’s position. At best, you could be using past snapshots (lag compensation) to decide hit detection, like Counter-strike etc. I don’t know if this is currently supported by UDK.
Yeah, in the case of feeling a little laggier for last millisecond parries i exchange for less laggy late parries of which I think would happen more. I’d certainly like to give such changes a bash and see how it pans out.
These things are largely non-issues in the sense that they can be faked/overcome with some trickery. My main worry with serverside hit detection is attacking accuracy – the attacker’s screen looks different to what is actually on the server. This might seem like a small difference, but it isn’t because it includes interpolation delay (for position anyway), and typical interpolation delays are 2*sendrate, which is on top of ping and everything else. So try chasing down someone with a weapon, chances are you’ll miss. We already know how easy it is sometimes to force misses in Chivalry, and that’s with perfect accuracy on the attacker’s side.
This same warping/accelerating technique could also be done to the animations to sync them all to the correct position, time permitting. It could work out quite well, or it could be really jarring. In the case of animations you would have to accelerate/decelerate them for defender/attacker, warping wouldn’t work.
You shouldn’t accelerate/decelerate animations, instead you should indeed warp them to the expected point. To smooth the transition simply use animation blending from the state you’re in, and it’ll look smooth (or in other words, interpolate in 4 dimensional space using quaternion algebra, same underlying basic principle as the arrow solution). Accelerating or decelerating would produce desynced animations over the entire duration, whereas jumping to a time and blending produces a different animation only for a fixed amount of time after which it is synced. To be fair, for windups, which is what you will be trying to “fix” most of the time, this is not really relevant, unless the windup animations have tracers going on them or somewhy need to be synced (like releases).
As for projectiles, I think it would be fine to do that server side, right now it seems that a projectile is spawned on clients computers that is an approximation of the server. As I’m sure we have all seen the the projectiles that whizz well and truly past our heads, only to hit a moment later.
So the projectile on the defenders client computer is an approximation, the attackers computer may be correct and may even be the real projectile, server not giving a damn?
I guess the projectile code is poorly written. There is no reason why a projectile should desync like that. Once a projectile is fired by defining its origin and direction, that is all that’s necessary to produce a perfectly synced trajectory (assuming speeds and such are known by each client). I guess it is something to do with how the trajectory is calculated, or how the initial parameters are transferred over the net. It would not surprise me, given that some time ago projectiles flew further at lower frame rates, which indicates a very inexperienced programmer wrote that part of the code.
Note: By desync I mean flying miles above your head, that is absurd. I do not mean hitting you after you’ve moved already, that will happen in any case, whether serverside or clientside detection is used (unless clientside on the person getting hit).