5 Replies Latest reply: Feb 20, 2013 4:28 PM by LordPookums RSS

Mechanics Vision


(I noticed how large this is, so I have color Coded sections to hopefully make it easier to seperate ideas. Also if you want to see my biggest complaint, but don't want to read the whole thing...jump down to the FLINCH section of the discussion.)


Before I get to the point of discussion in this thread...I would like to provide a basic synopsis of my experience last night as a lead in. Here it is:




I had a longer synopsis...but to hell with it...trying to get the point across:


In summary, I played last night and the longer I played the worse lag became, but it was incremental. First game was no lag(even played a person with an SPM of 30. WOW) than games slowly got worse, and the final game was horrendous...players were teleporting about 15 player models away per step. Point here isn't the lag...rather the lag let me see how the systems in the game worked, and how they were affected by changes in client-server side data.




There are a few systems that it showed me are just down right problematic. Here are a few systems that need some fixing:


- Global character positioning (its not even correct. Something in the host to local experience changes the true positioning of the host, to the position you actually see the players. I'm not just talking about a delay. It is literally getting certain character/camera positions wrong.)

- Character smoothing (meant to make characters look like they are moving when its lagging to create a more engaging experience).

- Flinch(It would work great for a game of pure LAN but creates problems in online games where latency can get huge. In fact this system is probably the most broken of the bunch).

- Aim Assist (people know its broken...but Im going to propose a solution).


So lets begin:





Global character positioning:


Something is wrong with the relationship between host information - local information - and camera positioning data. No I'm not talking about the camera delay issue (though that is a known issue). I'm also not talking about the bullet detection model vs the character model. No I'm talking plain...the players are not correctly orienting themselves to their true position in the game.


When lag is low, players tend to aim and stand relatively normal to what they are truely doing. Except, even without lag its not perfect. In one of my non-laggy games and in several of my laggy games, there were positions that I simply could not be shot from. Yet the bullets of my enemy...and sometimes even the killcam, liked to disagree.


In these several occasions...I literally stopped behind impenetrable cover...close enough to be near the edge of the walls where I could turn corners, but far enough not to be showing my body/head. I then waited for around a full second in each case(in one case it was close to 2 seconds). Yet, miraculously I would drop dead.


...WHAT!?? Was it a grenade...or did I get killed by an invisible man in these cases?


Nope. Normally I would not rely on killcam...however, in these games most of my deaths in the killcam seemed relatively accurate...so lag or not...my experience to the host seemed consistent. What I saw on the killcam...was both shocking...and unacceptable. Also, the enemies in the killcam did these things:


1. didnt move

2. were far enough away that even if they had, they could not have reached an angle to have seen me around the corner

3. killed me with bullets...not grenades


What the killcams showed...was that I didnt stop before the walls Like I know I had. NOPE. It said I ran right out into the middle of the open territory each time... STOPPED...Crouched...and just looked to the side.


WHAT?!!?!? I wasn't even showing my large toe in front of the walls let alone my WHOLE BODY 1 foot away from from it.


I state this as well...because I have known on many occasions where I will run around a bend...be perfect safe...and yet still get shot from an angle that would be impossible. I thought it was just lag...I think however, that it is in fact a faulty positioning system.




Character Smoothing:


This has to do with lag more than the rest. It's not so much causing lag...as the problem is it hides lag, and is the reason I believe some players believe that some of the lag issues don't exist. It has one issue however...where it does cause a problem, which is why its addressed.


I'm just going to say it. Good in theory...bad in practice. The smoothing in this game is insane. It literally tries to predict your movements up to a possible 500ms....500ms. Let that sink in for a second. Half a second. If you have lag, up to that much...THE GAME...NOT YOU...will decide what it thinks you were going to do...and show that, when it's signal is not working optimally.


Now...this is a great idea in theory. It makes for a very consistent experience, and makes the game run smooth. Fine. I have no problem with that. Where it does create an issue...is that this is not a LAN game. It is a multiplayer game. And because it is a multiplayer game...FALSE CUES can REALLY REALLY SCREW YOU UP. This is also why camping players are having a better time than run and gunners in BLOPS 2 imo, when it comes to the whole "lag vs no lag" arguments. I blame this system. Run and Gunners who develop their skills(don't confuse them with headless chickens or players who suicide..Im talking about strategic run and gunners), require a system of QUICK TO PACE cues, in order to get kills and be accurate.


Campers tend to get kills more on player error and unexpected Ambush tactics. Sometimes they will use cover for long distance kills. As a result, smoothing will have less of an effect on their style of combat. Cues don't have to be exact. The only cues they need are the relative player location, and the knowledge they hit you when you didn't realize they were there. Make no mistake...the smoothing is still an issue. However, I am just reiterating this as the reason why run and gunners tend to complain more about the lag...and camper-styles less so.


Run and Gunners however require IMMEDIATE Cue verification. They win through better reflexes/accuracy and NINJA-flank tactics. This is how they play. Having FALSE CUES however, prevent them from taking advantage of their reflex/accuracy superiority to the enemy. Only ninja style tactics work...but the revenge spawns and two sided maps in this game, make those tactics a tad harder to accomplish in this CoD, negating some of those benefits as well.


I bring this back to something I said in another thread on "teleporting enemies". It is better to have choppy teleporting because it does not give FALSE CUES. It certainly is annoying...but players can still take advantage of the enemy if they know what they are doing.


When the Character smoothing code however, decides that information is lacking, and decides its better to run a character 5 paces to the left, because they started to go in that direction...when in reality they turned immediately after...THAT is a problem. In a teleport-choppy game. The character would have frozen and their face would have turned...you might then receive one-two frames of them coming toward you...That is still horrible...but the freeze says to a player "Be careful, he did something" ...and the face turn with possible frame of character modeling warping toward you, states he "saw you and is trying to kill you".


The code prevents you from seeing that...and instead what happens, is you start firing in the wrong direction..or running after them...only to be killed by a 0hk. All because the code ASSUMED WRONG.


Now...I am not saying to remove all the character movement code for consistency...Rather I am saying to change how it "assumes" and to dial in the length of time it assumes, when data is not collecting optimally.






BROKEN. Broken. Broken. Broken....Did I mention it was broken?


The code is working fine...its just...the design sucks. You made changes...and they are absolutely bananas, in terms of how horrible they are. There are two problems which I noticed after last night...and I do believe these changed from past CoDs. It might just be the values...but I looks like the system itself was played around with to alter the experience.


I would say the vast majority of all issues sometimes added to Lag discussions are SOLELY and PURELY a result of this.




Before we get to the values, I would like to make a statement. In old CoDs, I vaguely remember someone stating that Flinch was purely client-based. Basically, when you downloaded information that you were shot...it would affect your recoil and vision/weapon position...but it would not calculate the flinch at the host level. As a result, if you had fired before you got the flinch downloaded...those bullets would be considered a hit on the hitscan. Only the flinch you saw on your screen, would have affected the hitscan. NOW...it might just be the change in values causing a difference...but I have doubts.


This appears to have changed systemically. Its clear to me the flinch is now calculated at the host level...


I cannot COMPENSATE for DATA I CANNOT SEE!!!!! If on my screen I get a point blank hitscan shot...but the host gets the enemy data first...and does a flinch calculation...suddenly my bullet misses?!?!?!?! WHAT!!! NO DAMNIT. THAT BULLET IS A HIT. There are so many reasons why the enemy data could have come in first. I might have better reflexes...but if they have a better ping to host, then they will get to flinch me more often...and since I can't see the flinch until I myself get that information...I am likely already dead before I can compensate.


THIS is quite possibly the worst idea ever. Flinch should be a client-side alteration. Its nice to think that the first person to hit should get a flinch benefit on their opponent...but that is again... ONLY FAIR ON A LAN SYSTEM WHERE lag is virtually unnoticed. This isn't even a bullet velocity game. ITs a HITSCAN GAME. If my Crosshair hits, it should BE A HIT. It should not be calculated in anyway at the host level. (the one exception for hitscan miss being lag from player model...but that is not what I am discussing here).


Basically, everytime you die and see a killcam and you had a perfect shot on the enemy...watch the screen. See if it says they got at least ONE bullet on you first. If they did..and your bullets missed...you just were screwed by this host-calculated flinch system. It changed your bullet hitscan information. Thats why the killcam showed differently to your experience.




Part 2 of this convo. The values of flinch are just simply too high in this game. Without toughness...a single bullet from anything is powerful enough to throw a Bullseye sniper shot completely off the enemy target. That is WAY TOO much. Unless I just got pummeled by bullets in core and am about to die...my crosshair if centered, should remain relatively inside their body. With toughness...whether I get shot or not,should have little to no bearing on the fight.


A single bullet should not throw a non-toughness sniper completely off their target.


Here is what I suggest. Lower flinch so that a centered bullseye of a shot with any weapon...will still remain in damage territory of the target...but where high recoil weapons might occasionally be thrown off if held down. When you consider that players strafe, natural recoil at distance shots, and accuracy usually isn't BULLSEYE centered shots on the enemy, this would make flinch still valuable. However, it would fix the game-breaking issue, where simply because the enemy player isn't right next to you at point blank range...because a stray bullet happened to hit you, you now have to spray like a madman and get lucky, crouch, or run away if you lack toughness.


With Toughness on...flinch should be so absolutely minute...that only the longest shots and highest recoil weapons could be thrown off...and only slightly at that(Im talking bullet whizzing past your ear closeness).


I guarantee you, that if you fix these two issues with Flinch...the complaints about gamebreaking mechanics and lag compensation will drop ten-fold. I consider this the worst system of this iteration of CoD. It is too powerful.




Aim Assist:


...ok we all know it has issues. So I'm not going to go into detail on the Aim assist problems of the game when players already know the problem. Rather I am stating that Aim Assist should be changed to work based on client Player model. It should disregard global position...and assumed bullet detection models.


The collision and position models...just aren't correct once latency is considered. However, if you set it to player model, at least the aim assist wouldn't randomly break, and you wouldn't have players fighting with the Aim Assist all the time.


Yesterday, I was firing up to the window across from the statue in Standoff. The one near the Truck and hay bail. across from a collapsed wall. I aimed at the enemy in the window...and it literally stopped against the wall. I kept pushing...and it literally would not move my aim the extra distance I needed. I spent around 2 seconds pushing it, while the enemy either failed to see me...or was simply missing me and I didn't see their bullets. He than ran downstairs, and when he was out of sight, my aim jerked to the left with grace.


...really? I know the assist is wonky...but come on now. I should not have to fight with it like that. At least if it was based on the client player model, I could have had a chance of killing him. If he had decided to shoot I would have died.




Well that about wraps it up.


Has anyone else discovered some problems with the mechanics...that seemed to be affected by things out of your client-side control. Feel free to post those thoughts. Also, to the points in this thread, please discuss.

  • Re: Mechanics Vision

    Out of curiousity what credentials do you have that allow you to make these claims as far as coding and  client side host side issues?

    • Re: Mechanics Vision

      Only Treyarch and Activision have access to the specific code. We already know that the camera delay for example is an unexpected byproduct of CoD programming. There is no way that was intentional...but players have provided physical proof since BLOPS 1...and the code is still there in Blops 2. That is a global positioning issue of client/local model with camera. It can be seen in both LAN and online. And since only treyarch and activision have access to specific code, we need to rely on physical experience, physical recordings, or physicals tests like with the camera model issue. They are not going to cough up the code.


      I am also starting the thread, to discuss the issues. That way should treyarch decide to peruse the thread...and if they decide to look into specific issues...they might have a few ideas on things to play with and change.


      Also...the first two are always listed under host/client issues. That is what they refer to. Flinch does not...but my guess is they changed it to a host basis, and I explained why. Without the code, we simply won't know, the flinch isn't consistent with the local experience at the least. That much is known simply by getting shot. AIm assist I listed under Player model and hit detection model...so thats not a host/client issue anyway. However lag can affect it and make it worse as a result.

      • Re: Mechanics Vision

        Thanks for the break down of what i already read. My question is still what are your credentials? Just wanting to know if i am talking to a programmer or just some fan throwing all the vocabulary and none of the knowledge.

        • Re: Mechanics Vision

          programmer by trade - no


          Do I use programming in my trade on occasion - yes


          Have I ever built a game - yes for personal use (2d with basic physics engine using C#...not complicated 3d games however.)(also more experience with webcode and creating scripts but thats a different beast)


          Do I have a strong understanding of 3d, animation and physics which may have some bearing on what I see in game - yes, my primary trade is as a 3d generalist. I do rigging, animation, dynamic systems, modeling, compositing and post-processing effects. I know what visual references look correct, and which do not look correct.


          Final comment - The words I used are not programmer specific(though I have given you some basic vocational info now). They required playing a game and doing physical tests. Had I given specific code example and then talked about more complicated code without examples, it might matter. I merely talked about theory and what I saw(see) in game.

  • Re: Mechanics Vision

    Interesting article.  It sums up the problems I have with BO2.


    You seem to actually SEE the problems with the game that so many are willing to give 3ARC a pass on.  I have not considered the flinch mechanic, but your theory is interesting.


    Good job.