135 replies to this topic

[Ranzear]

Yeah, was gonna link the same thing as the last post of the first page. Lag compensation has only been in games for ... you know ... a decade?

Seems downright absurd that it'd take this long to implement, but Crytek is getting notorious for 'pretty first, mechanics later'.

Edited by Ranzear, 15 January 2013 - 10:23 AM.

[Jasen]

/me thinks source engine would have been a breeze to work with... or what about id's Tech5... specializing in big sprawling worlds....

cryengine3 was chosen to wow the cod crowd I'm guessing. in truth, there were probably better choices.

[Matthew Craig]

Ranzear, on 15 January 2013 - 10:22 AM, said:

Yeah, was gonna link the same thing as the last post of the first page. Lag compensation has only been in games for ... you know ... a decade? Seems downright absurd that it'd take this long to implement, but Crytek is getting notorious for 'pretty first, mechanics later'.

Best we can tell Crysis went with a client authoritative approach (very prone to hacking) therefore they didn't require any form of lag compensation (hence why it's not implemented), we went server authoritative for reasons that have been well outlined, so we get to add this to the engine (as would any other game that uses CryEngine that goes server authoritative). Once it's added the net-code will be comparable to other games like CS, TF2 etc. that use this approach.

[Ranzear]

Actually I'd pick Cryengine just so mechs could stomp trees flat, but seeing as that hasn't been implemented, your guess is as good as mine.

Yeah, I've been doing some studying of client-server authority models. Actually working on a 'distributed' authority system myself that timestamps packets between clients and each 'rewinds', to use the term of present, and tries to find a consensus on who hit who. It's only for a silly HTML5 game anyway, but I plan on having a 'violation' system that will inform the server when someone is causing too much desync and should be dropped from the game.

Edited by Ranzear, 15 January 2013 - 10:32 AM.

[Matthew Craig]

Jasen, on 15 January 2013 - 10:28 AM, said:

/me thinks source engine would have been a breeze to work with... or what about id's Tech5... specializing in big sprawling worlds.... cryengine3 was chosen to wow the cod crowd I'm guessing. in truth, there were probably better choices.

No engine is perfect, I have yet to work with the mystical perfect engine and I've worked with a wide variety of engines.

[Jasen]

Oh awesome. For the record I'm not dissing... I'm a programmer so I understand the complexities of the topic.


Ever considered going client authorative and investing that time into anti-cheat technology? Nothing is ever perfect but even ability to submit demos and actually have a small department reviewing and banning... could go a long way, clear some technical hurdles, and possibly work.

That said... sounds like you guys have already sorted the netcode so this is probably old news to you.

[Ranzear]

Client authority is a slippery slope. Hit detection is one thing, but even just bending limits of turn speed and whatnot can garner an unfair advantage. To say: You have to have the rules a little 'loose' to account for latency and whatnot, someone can abuse that wiggle room to get whatever buffer as extra turning or movement speed. It's not just about hit detection, but consistency throughout.

[Matthew Craig]

Jasen, on 15 January 2013 - 10:32 AM, said:

Ever considered going client authorative and investing that time into anti-cheat technology? Nothing is ever perfect but even ability to submit demos and actually have a small department reviewing and banning... could go a long way, clear some technical hurdles, and possibly work.

Anti-cheat technology is a constant cat and mouse game, the tools to ensure the client is not cheating are very time consuming to make and eat a lot of development effort (one of the reasons we didn't want to go this way). I believe WoW does take this approach where they have a sentinel program that constantly has to evolve to ensure your local machine isn't hacked. I'm sure they have their reasons for whatever approach they've taken just not the route we wanted to go.

We also knew that going client authoritative would have had a seemingly smooth running game much sooner; however, long term we'd likely have major issues with hacking (beyond what we have to suffer now). We chose the slower, harder path for exactly these reasons. Once we're out of open beta the lag shield issues will be a fading memory, but in reverse the nightmare of client authoritative hacking would only just be starting.

[Jasen]

some good, even over-reaching, anti-cheat could detect a lot of that...

a department constantly releasing anti-cheat updates also makes it hard for the cheaters to keep up.

(this response was not to above dev post)

EDIT:

Matthew Craig, on 15 January 2013 - 10:40 AM, said:

Anti-cheat technology is a constant cat and mouse game, the tools to ensure the client is not cheating are very time consuming to make and eat a lot of development effort (one of the reasons we didn't want to go this way). I believe WoW does take this approach where they have a sentinel program that constantly has to evolve to ensure your local machine isn't hacked. I'm sure they have their reasons for whatever approach they've taken just not the route we wanted to go.

Thanks for taking the time to respond. No doubt you have/had your reasons. Just sucks having to write all that engine code. Don't pity you guys at all...

good work so far, keep on moving.

Edited by Jasen, 15 January 2013 - 10:44 AM.

[FrDrake]

Matthew Craig, on 15 January 2013 - 10:40 AM, said:

Anti-cheat technology is a constant cat and mouse game, the tools to ensure the client is not cheating are very time consuming to make and eat a lot of development effort (one of the reasons we didn't want to go this way). I believe WoW does take this approach where they have a sentinel program that constantly has to evolve to ensure your local machine isn't hacked. I'm sure they have their reasons for whatever approach they've taken just not the route we wanted to go.

Thanks Matthew for responding about this and to the OP for bringing this topic up, I'm a programmer as well (healthcare though not video games) but this information makes a whole lot of sense to me as to what the "root" issues are when before I really had no idea.

*Edit* yea from an engineering perspective I'd advocate in my group for the same path they've chosen, get the work done once and put a bow on it, instead of constantly having to go back and update for the newest client side hacks or worse leaving yourself open to a hack that may take a while to fix in the future. If you ever want to go competitive you simply cannot leave open the chance for a gamebreaking hack in the future.

This also makes sense to me as to why the netcode has taken so long to resolve, that's a serious overhaul. I'm not sure if this has been posted before to the general public but just telling this reason a while ago I think would have helped. It's always been so vague when discussed before.

Edited by FrDrake, 15 January 2013 - 10:48 AM.

[Chavette]

From what I gather, to the end user joe this means, before the fix you have to shoot infront of the guy if he was lagging, after it you'll have to shoot infront of the enemy if you are lagging.

Edited by Chavette, 15 January 2013 - 10:48 AM.

[FrDrake]

Chavette, on 15 January 2013 - 10:46 AM, said:

From what I gather, to the end user joe this means, before the fix you have to shoot infront of the guy if he was lagging, after it you'll have to shoot infront of the enemy if you are lagging.

When it all shakes out you shoot the guy on your screen, he just may die behind a rock on his.

*Edit* Though the speed the mechs move will make cases like that pretty rare for anything except lights.

Edited by FrDrake, 15 January 2013 - 10:50 AM.

[Jasen]

Chavette, on 15 January 2013 - 10:46 AM, said:

From what I gather, to the end user joe this means, before the fix you have to shoot infront of the guy if he was lagging, after it you'll have to shoot infront of the enemy if you are lagging.

Don't try to over-simplify extremely complex issues... it means nothing like that. In truth, if there is actual lag involved, not much you can do period. If we are dealing with somewhat constant, known latencies, with minimal to no packet loss, there are things you can do.

FrDrake, on 15 January 2013 - 10:49 AM, said:

When it all shakes out you shoot the guy on your screen, he just may die behind a rock on his.

Excellent way to put it.

Edited by Jasen, 15 January 2013 - 10:50 AM.

[Johnny Morgan]

Matthew Craig, on 15 January 2013 - 10:30 AM, said:

No engine is perfect, I have yet to work with the mystical perfect engine and I've worked with a wide variety of engines.

Have you completed the Quest for the Jade Monkey....because if you haven't that would explain that

[Philldoe]

How does the Unreal Engine handle these things? For quite some time I've tried to wrap my head around Why PGI chose Cryengine over UE. I would really love a good long winded statement as to why. I'm sure you have legit reasons I just want to be aware of them.

[Jasen]

Philldoe, on 15 January 2013 - 10:56 AM, said:

How does the Unreal Engine handle these things? For quite some time I've tried to wrap my head around Why PGI chose Cryengine over UE. I would really love a good long winded statement as to why. I'm sure you have legit reasons I just want to be aware of them.

If we're actually getting this reply - a short part on the same for Tech5 would be interesting... hell, even source.

Edited by Jasen, 15 January 2013 - 11:00 AM.

[The Amazing Atomic Spaniel]

Matthew Craig, on 15 January 2013 - 10:40 AM, said:

Once we're out of open beta the lag shield issues will be a fading memory

Please, please let this be so!

[DarkOmen42]

Back in the day we were hitting players at 100 M, flying through the air with explosive frisbees. We used to be our own lag compensators. Now the game tries to do it for us. We expect games to do it. We've been conditioned to accept the lag compensation. I don't know that I would prefer one to the other, when we were doing it all the time we were all pretty good at anticipating lag and leading targets.

[Red squirrel]

Many thanks to you Matthew.
It's great to get some input on the netcode issue


Now that I know you have to implement server side auth. into the cryengine I finally understand why it takes so much time.
Maybe you could answer me another question:
With server side auth. players might create lag on purpose to get an advantage?
If so what can you do about it?

Philldoe, on 15 January 2013 - 10:56 AM, said:

How does the Unreal Engine handle these things? For quite some time I've tried to wrap my head around Why PGI chose Cryengine over UE. I would really love a good long winded statement as to why. I'm sure you have legit reasons I just want to be aware of them.

[Tice Daurus]

Red squirrel, on 15 January 2013 - 11:09 AM, said:

Many thanks to you Matthew.
It's great to get some input on the netcode issue


Now that I know you have to implement server side auth. into the cryengine I finally understand why it takes so much time.
Maybe you could answer me another question:
With server side auth. players might create lag on purpose to get an advantage?
If so what can you do about it?

Oh Red Squirrel, awesome question on this, and I also for one would like to hear the answer for this. Matthew if you are reading this, and it looks like you are, this is an important question. Recently, I've been playing Planetside 2 off on the side for giggles, and I've noticed an incredible amount of people lag hacking in order to gain an advantage in shooting in that game. What is being put in place to deal with this problem so we don't have the same problems here that they do in there?

Edited by Tice Daurus, 15 January 2013 - 11:14 AM.