Articles

For sometime now we've been having what the players have referred to as a, "lag issue." This has been the key focus of our game development effort as of the last few weeks as we've tried to nail this down. The good news is we're getting closer and I'll be going into some more detail about what this is, the effort involved and help set your expectations for the intended outcome.

WHAT IS THE "PREDICTOR CODE?"

When we released 1.35 we greatly improved what we had referred to as, "infantry death lag." However the predictor code is all encompassing for infantry players to render (see) other infantry, when they turn a corner, run up a stair case, get shot, or any other instance.

We know how important this issue is for many users because there is a general feeling of, "that guy has hax!" That's something we don't ever want to happen, and particularly when it's code on our end contributing to that, it gets raised up to the top to resolve.

From one of our developers, "VICTARUS."

The problem with the existing predictor code is actually really simple: We don't have any.

The current code just interpolates between two points: The current position we're displaying them at and the last position update we received. The lag players have been experiencing is due to a defect in the code that causes it to delay that interpolation later and later (we have confirmed cases of players' movement starting more than a full second late), but the truth is what you're seeing is *always* delayed because of how the code was written.

To give a severely exagerated example of how this works:

> 0ms : The soldier is just outside the doorway.

> 250ms : The soldier is at the doorway.

> You now set his position to just outside the doorway and, over the next few frames, move him toward the doorway.

> 500ms : The soldier is inside the building and starting to take aim.

> You see the player finish moving to the doorway and just start coming inside.

> 750ms : The soldier is standing still.

> Oh, and he shot you.

> You see the player move to just inside the building where he's been taking aim.

> Oh, and you're dead.

A bit of delay is unfortunately the nature of multiplayer gaming, but in this case there's delay with respect to the information the client actually has available.

So I wrote a simple predictor. Now the interpolation tries to aim for where it looks like the other player will be in X milliseconds based on their movement. So far this code seems to fare better than the previous code when dealing with poor connections, but *really* bad connections can still cause warping and rubber-banding. Again though, that's just kind of the nature of multiplayer gaming.

The difference isn't that obvious when you're just watching people move around — their movements are still roughly the same, after all — but watching people using the old client makes it clear that this will make a pretty significant difference in close-quarters fighting.

THE EFFORT INVOLVED

Has been a collaborative effort between the Quality Assurance and Development team. I've been very proud of their aggressive approach to resolving this and despite the many hurdles they have faced, not giving up on it. Everyone on our team recognizes this issue and has invested a great deal of time to knocking it out.

But don't worry, this isn't the only thing that has been worked on, there's much happening behind the scenes, such as we've officially started our Steam planning phase in preparation for our October developer summit in Texas.

A tip of the hat to the community members who have helped us with this "lag" issue as well. We put our focus onto a couple of guys who had some latency issues so we can get a better understanding of how that adversely affected other player experiences.

THE OUTCOME

While we're still in the testing phase, our intended outcome is to significantly improve character - character rendering. Initially we had tried to do a band-aid type fix to resolve this problem pending a more appropriate surgical clean up, however we quickly realized this was going to take a more aggressive solution to properly fix it.

Infantry game play is the key to our game and really to all battles fought ever, so it should come at no one's surprise how important this is for us to fix.

We'd really like to thank you all for your tremendous support and understanding. I hope this goes to show that the community's feedback is being taken into account and incorporated as part of our development efforts. Everyday we listen to your feedback and discuss it, and although we may not always tell you that, CRS really cares about what our community has to say and think.

Recruiting: Game Developer (C++)

The development team is looking for a couple extra hands with improving WWII Online. We're looking for programmers whom are fluent in C++. This is a volunteer opportunity, working directly with our team to directly improve WWII Online and help us work to get on Steam. E-mail languages you speak / a little about you to, This email address is being protected from spambots. You need JavaScript enabled to view it. - ATTN: Matt Callahan (Executive Producer).

Thanks for your interest, questions are welcome.