43 replies to this topic

[Kaldor]

You want convergence? Get slower internets. As your ping gets worse, it will get harder for you to hit your target.

[DaZur]

Dimento Graven, on 15 August 2013 - 06:53 AM, said:

First off, I am going to do something that you should NEVER do on a forum and that's admit ignorance:

I am completely ignorant as to the full convergence mechanism in the CryEngine.

You sir just took a giant step toward being part of the solution and not part of the problem... The internet is the only place where everyone can pretend to be an expert on everything and admitting naivete on a particular subject is a welcome moment of clarity! Kudos...

I think (and I'll be correct if I'm wrong I hope) a hurdle in many game engines, not necessarily just Cryengine, is that most games are not concerned with the accuracy of multiple asynchronous weapon fire, their convergence and location specific pont-damage.

MW:O is unique in that the game is required to track multiple hit boxes on multiple mechs all at one time... It's paramount to translating damage output / receiving accuracy. In most other games we typically are looking at maybe a couple weapon convergence at most with a singular hit box...

In essence a little bit of information overload...

HSR seems to address this globally but I believe inequity in broadband quality, ping and TTL have a large impact on how much HSR can compensate right now.

[Dimento Graven]

DaZur, on 15 August 2013 - 07:14 AM, said:

[/size]
You sir just took a giant step toward being part of the solution and not part of the problem... The internet is the only place where everyone can pretend to be an expert on everything and admitting naivete on a particular subject is a welcome moment of clarity! Kudos...

I think (and I'll be correct if I'm wrong I hope) a hurdle in many game engines, not necessarily just Cryengine, is that most games are not concerned with the accuracy of multiple asynchronous weapon fire, their convergence and location specific pont-damage.

MW:O is unique in that the game is required to track multiple hit boxes on multiple mechs all at one time... It's paramount to translating damage output / receiving accuracy. In most other games we typically are looking at maybe a couple weapon convergence at most with a singular hit box...

In essence a little bit of information overload...

HSR seems to address this globally but I believe inequity in broadband quality, ping and TTL have a large impact on how much HSR can compensate right now.

LOL! Ok well let me go back to being a partial 'internet problem child' here and say, I had "thought" the reason that the CryEngine was selected is it supported the multi-hit box tracking.

The only piece in question is the multi-asynchronous weapon fire. I would get where most engines would probably be written around the "one weapon" (at maximum TWO, how many hands have YOU got to hold a gun?) perspective, and as you mentioned and hopefully everyone realizes, that ain't what we got with MWO (unless you design your 'mech that way). Heck with MWO we could easily be firing upwards of 5 different weapons, and I've seen 'mechs with upwards of 10.

Each would require it's own 'pin point' for aiming.

I still like the mechanism I described in other posts (maybe this one too, not sure, not going to go back and look) to nullify the 100% weapon convergence we have now, yet providing reasonable accuracy at range, and as little possible affect on the "close in" fighting we have now.

The only issue, would the CryEngine currently used for MWO be able to support that kind of 'cone of fire' approach? I'd research it but, I get paid to research, I ain't gonna do it for 'free' without significant motivation.

I guess I'll remain ignorant, but I'll try and not be 'arrogantly ignorant' as so many of our forum compatriots seem to be in a permanent state of...

[Kitane]

I thought the convergence as previously implemented was PGI's creation, not something directly supported by CryEngine. I haven't seen anything like that in Cryengine SDK, but I didn't spend much time looking for it.

I can imagine the convergence calculations being pretty hard on the server. The client is running a 3D map, tracks your position and calculates the convergence based on the point in space where a ray projected from your aim point collides with a terrain or an object.

PGI claims that server has the authority and does all important calculations to prevent cheating. That means the server has to be capable to calculate the point you are looking at in 3d space and calculate correct convergence based on your current position.

Now the current instant convergence implementation is probably easy on the server - it would need to cast the ray and calculate the distance only when a player fires a weapon and for lasers for the duration of the laser beam.

The previous convergence implementation with a weapon convergence that was being continuously adjusted and lagged behind the cursor, the server would have to calculate this constantly over and over for every mech in the game on every world simulation tick (or every second). Or the alternative solution, perhaps the server was keeping a last second or two of mech's movement in a buffer and used it to recalculate the correct state of convergence when needed. That might get better performance and it could possibly even share data with HSR mechanic, both features have to deal with last few moments of each mech.

Taking lasers for example:
1) User starts to fire his lazors at T=0
2) The server receives the info at T+1
3) It then looks at user's position at T=0 and calculates the user's weapon convergence for T=0. Here would be the first point of integration for the old style convergence. This would be a lot easier to implement if the server just calculated the convergence for all mechs all the time, but the easy solution often comes with a bigger performance impact.
4) Server starts casting a ray in the calculated direction to search for collisions against fixed objects and other player positions at T=0
5) The ray position is constantly updated during the duration of the beam with new rewounded data from the client. The convergence has to be recalculated on every simulation tick. And this would be the second point of the integration, replacing the instant calculation with the one determining the degree of change of convergence since the last tick.

Doing this right while keeping the additional server load to minimum is going to be a quite an effort.

edit:

The cone of fire is a big problem for this system. A client needs to display the shot immediately without any lag, so it has to pick the deviation on its own. However the server can't let the client pick the final flight path that easily, because it would become vulnerable to hacks reducing cone of fire to nothing.

They could find a way around, for example using a synced random generation routine where the random deviation generated by the client would be also "randomly" selected by the server. But in either case it would result in adding cone of fire calculations right into the above listed HSR+Convergence process.

Edited by Kitane, 15 August 2013 - 09:03 AM.