WARNING: The forum is now in read-only mode as we will soon be transitioning to different forum software. Feel free to join our Discord server in the meantime.
User avatar
NoFaTe
Blazin' your Brains!
Posts:520
Joined:Sun Dec 16, 2012 7:22 pm
Contact: Website
The Netcode, Spectator, and the Future: Part 1

Tue Apr 28, 2015 8:44 am

The so called Frostbite netcode has been a huge topic of debate over the past couple of years.

Since release, various 'unoptimized' portions of the networking system in Frostbite games have been plaguing the Battlefield community, with high in-game response times from client to client, hit detection issues, slow replication of movement updates, and so on...

Most people first 'discovered' this topic with the release of Battlefield 4, where some of the previously mentioned issues were significant, and directly affected the enjoyment and playability of the game, but the truth is that even earlier games are plagued by these issues, and in our case, Battlefield 3.

After numerous requests from our community, we decided it was finally time to take a closer look at the so called netcode, perform some research on it, and see what we could do about it.

The first thing we did is to gather some statistical data on how the game performed.

For all of our tests, we spawned two VU clients connected to a dedicated server, all running on the same machine, and therefore with virtually no network latency overhead.
Then, we fired 38 shots (from both game instances), and we measured the time it took for every shot to register its damage on either client.

All of our measurements were accurate down to the microsecond, but for the purposes of this presentation, all times were converted to milliseconds.

Image

In the above graph, you can see the time distribution between different shots, along with the low, high, and average latency values in ms.
To our surprise, updates averaged to a staggering 90ms, which means that from the moment someone shot you on his screen, it would take approximately 90ms (+ network latency) for you to see that reflected on your screen.

The other thing that we could deduct from this data is that updates appeared to occur within a 30ms interval from each other.

From that data we came to the conclusion that the incoming frequency for clients was approximately 15Hz, and the outgoing frequency was approximately 30Hz (and vice-versa for the server).

Out of curiosity, we performed another test, but this time, with network smoothing set to 100% (in the first test it was set to 0%).
We think the results speak for themselves...

Image

You might notice that after the 19th shot, updates are shifted upwards by approximately 30ms.
This appears to happen because of the simulation latency difference between the two clients, since the last 19 shots were shot from the second client.

Long story short, unless you're filming a cinematic (or something similar), you should avoid having network smoothing on.

After we were done with our initial tests, it was time for research and experimentation.

Our goal wasn't to optimize the internal workings of the netcode, as doing so would require countless hours of work and dedication, with probably little to no payoff.
What we set out to do was to figure out whether it was possible or not to up the replication frequency whilst maintaining a fully functional game, and if in doing so we could improve the update latency.

After approximately two weeks of constant research, tests, failures, and more tests, we came to the following conclusion:
It was definitely possible!

That's why we're extremely excited to announce the High Frequency update for Venice Unleashed!

Starting with build 8312, the Venice Unleashed client can optionally function in High Frequency mode, allowing you to connect to High Frequency servers and enjoy low latency updates.

We could go on and on babbling about how much more better the game works with our High Frequency code, but instead we'll let our test results speak for themselves:

Image

From what you can see in the above graph, the average latency has been decreased by almost 3 times, to an impressive 35ms, a value which makes our client compete with some of the most optimized competitive games out there.

There is still a slight deviation of ~12ms, but that's to be expected and shouldn't be significant when it comes to gameplay.

For those of you that don't really like graphs, we've also recorded a comparison video, comparing the regular frequency netcode against our high frequency netcode:



The original footage was recorded at 60fps and then slowed down in post.

Now, all these changes might sound good and dreamy, but they do come at a cost.

A server (or client) running in High Frequency mode will consume approximately four times (x4) more bandwidth (both incoming and outgoing), and will see a slight increase in CPU usage.
Additionally, there are a couple of issues that are currently present, the two most significant of them being wobbly first person models, and weird dirt-bike physics.

We are of course currently in the process of fixing the aforementioned issues, and we hope to have a fully functional high frequency client as soon as possible.

Interestingly, another side-effect we observed was that loading times were slightly decreased when running in high frequency mode, but we don't think that's something that requires fixing.

Unfortunately, because some of our code changes are being performed at a very deep level in the engine, switching to (or from) high frequency mode requires a client restart.
When connecting to a high frequency server from a regular frequency client (or vice-versa), the client will automatically prompt you to restart your game.

Alternatively, you can always run your game in high frequency mode by providing the -highfreq parameter when launching vu.exe (also usable for running a server in high frequency mode).

Test Server #001 is already running in High Frequency mode, so you can already jump in and test it for yourself!

This post is the first of a two-part post.
Stay tuned for the next part, in which we will discuss the latest changes in the Spectator mode, and the future of the project.
[03:55:41] <~Bag> Yes, I can put things inside me when I need to

User avatar
Freeshnik
Posts:470
Joined:Tue Feb 19, 2013 3:14 am

Re: The Netcode, Spectator, and the Future: Part 1

Tue Apr 28, 2015 9:02 am

This is Spectacular!
Hope "dying behind cover" will gone.

P.S. For me loading time become ULTRA FAST - 3 sec :shock:
Last edited by Freeshnik on Tue Apr 28, 2015 9:21 am, edited 1 time in total.
Image

User avatar
AvatarNikhil
Posts:29
Joined:Sat Mar 21, 2015 8:42 am
Location:India
Contact: ICQ

Re: The Netcode, Spectator, and the Future: Part 1

Tue Apr 28, 2015 9:08 am

Awesome ! Great to know that ! :D Hope to get keys to try it out ! Hopefully SOOON :D
Image

User avatar
Professor.Oak
Posts:145
Joined:Fri Apr 05, 2013 6:47 am

Re: The Netcode, Spectator, and the Future: Part 1

Tue Apr 28, 2015 9:09 am

Itching to play some BF3 right now. This is great news. Hoping for future optimizations to reduce the latency even more while decreasing Network and CPU usage. I'm sure it will happen at some point given how gifted you guys are. Spreading the news far and wide.

klappflapp
Posts:1
Joined:Sun Apr 28, 2013 5:40 pm

Re: The Netcode, Spectator, and the Future: Part 1

Tue Apr 28, 2015 11:06 am

This sounds awesome, that was one of the main downsides of BF3!
Lookin' forward to get my hands on VU and the dedicated server.

User avatar
BattleNonSense
Posts:10
Joined:Mon Dec 15, 2014 7:17 am
Location:Austria
Contact: Website Facebook Twitter YouTube

Re: The Netcode, Spectator, and the Future: Part 1

Tue Apr 28, 2015 11:12 am

so does this mean that you "simply" force a server->client send rate of 30Hz instead of 10Hz?

also odd that the networksmoothing in BF3 delays damage. In BF4 I does not do that. :-/

User avatar
lycanwrath
Posts:47
Joined:Tue Dec 18, 2012 10:06 am
Location:Mauritius
Contact: Website

Re: The Netcode, Spectator, and the Future: Part 1

Tue Apr 28, 2015 11:50 am

BattleNonSense wrote:so does this mean that you "simply" force a server->client send rate of 30Hz instead of 10Hz?

also odd that the networksmoothing in BF3 delays damage. In BF4 I does not do that. :-/


Would love to see a comparative netcode video of yours once Venice comes out between BF3, Venice, and BF4's post Spring patch.
That would be epic! :)

User avatar
kiwidog
Posts:283
Joined:Tue Dec 25, 2012 8:19 pm
Location:United Kingdom
Contact: Website

Re: The Netcode, Spectator, and the Future: Part 1

Tue Apr 28, 2015 11:50 am

NoFaTe's a bawse.
kiwidog > NoFaTe.

User avatar
3ti65
Posts:15
Joined:Sat Jan 31, 2015 2:13 am

Re: The Netcode, Spectator, and the Future: Part 1

Tue Apr 28, 2015 12:27 pm

Good to see updates. Escpecially when the update has this quality.

Im severely amazed by your work! Keep it up :)

User avatar
Dendari
Posts:28
Joined:Mon Feb 11, 2013 4:22 pm

Re: The Netcode, Spectator, and the Future: Part 1

Tue Apr 28, 2015 12:41 pm

Really awesome job, as always! Too bad you have to restart the game every time you switch from Regular Freq to High Freq (and vice-versa), but it's definitely worth it :D

Anyway I find it very interesting that these changes have such a huge impact on a local server (almost 3x faster response times), considering the delay on online server with ~20ms ping should be 133ms (at least based on this video). May I ask if it's possible to receive more info about these changes?

Return to “Announcements”

Who is online

Users browsing this forum: No registered users and 34 guests