Rebas Kradd, on 06 October 2014 - 12:30 PM, said:
Are we STILL suggesting that we should remove this dynamic?
Players don't want their fire to go anywhere but where they're pointing. This is a problem unique to MechWarrior, because very few other games have multiple weapons being fired from different places on their avatar.
The moment you remove pinpoint convergence from the game, you remove the ability to target specific components of an enemy mech. Players will NEVER be able to target components if that's removed, at least not efficiently. The result is that "shoot the CT" becomes the metagame even more than it already is, and a lot of MW nuance is involved.
I get that convergence makes no sense, I get that it tends toward a meta, but the alternatives are even less optimal.
I just wanted to point out that "Shoot the CT" or 'aim for a body shot' is pretty common in most FPS games. They still have head hit boxes and they're still hittable even with the spread that every FPS has. Most FPS use a CoF for all weapons. CoD sniping notwithstanding but BF3/4 Sniping even had things factored in like Gravity, Friction from air, Weight of the round, velocity of round. I can't remember if they also took in to account Wind, Ambient Temperature and Humidity. Either way, these factors modify where the round actually goes. This mimics reality. This is one of the reasons why we're suggesting CoF or something similar to it.
I actually had an idea that blended roadbeer's, Koniving's, and a few others ideas. Those of my Organization have had lengthy (and somewhat heated) discussions on this and have come up with some interesting ideas. I'd post them once I've had more time to put the ideas to paper. I can say that, the idea we had involved Roadbeer's convergence system but having it deteriorate given certain conditions. Full speed run adds a longer time to it (as per Roadbeer's) but Jump Jetting literally reduces the convergence over time to none. The numbers would need work but the intention is so that a HGN/CTF/VTR using Jump Jets to 'Poptart' would be so that at the point in there jump where they clear their 'Mechs height they have no convergence at all (parallel weapons). Think of the computer struggling to maintain accuracy as the uneven thrust from the Jump Jets propels the walking death machine into the air.
Don't get me wrong here, the weapons would still fire where they're pointing (not your crosshair) but you'd now have to use
more skill to aim and fire those weapons. In the end, you'd get the 'poptarts' only able to fire one, maybe two weapon system locations at a time before falling too far. Even then, these shots would not be in the same place (but they would be where you were aiming). This would not only spread the damage but also require considerable skill to even pull off. Granted, the player would need a graphic to give them an idea of where the shots are aiming. Think the distance markers on sniper scopes, but in a line from weapon mount locations in relation to when they're parallel. This can also have the benefit of allowing Jump Jets to return to normal.
Now here's where this convergence method gets interesting though. Notice that I said it needs to be so that convergence goes away once you're nearing a certain height? Imagine a light/medium using jump jets. Usually they're burning the jets briefly to gain mobility or hop over shorter obstacles. They're also usually medium to short range skirmishers. The convergence for lights would be much less a problem for them. They could also balance it by giving lights/mediums a quirk of some sort that allows them to jump 1.5x or 2x their height before convergence becomes parallel.
Keep in mind here that this only a small piece of the grand idea I had. I'm sure there's something that I missed or didn't think of.
I'm also aware that the logistics of this idea are probably impossible due to HSR. Most of the things to make this work the servers already get. It's basically only changing the aiming point for the player. It already takes in to account positional data, trajectory, point of impact, and rewinding the server for determining where the shots are hitting. Basically all the convergence change does is change the server authorizing the change in convergence. It then pushes the 'current convergence state' to the client. That would be another 8 bytes of data to transfer the values 00 to FF (-127 to 127 or int8_t for those uninitiated). This gives 256 values to represent 0 to 100% giving you an accuracy down to 0.4%. That is nothing. You could bump it up to 16 bytes of data to transfer the values of 0000 to FFFF (-32,768 to 32,767 or int16_t) giving you an accuracy down to ~15 ten-thousandths of a percent or ~0.0015%.