The Battlefield 4 Thread ~ Server details in opening post ~

Status
Not open for further replies.
15bea6db9dadc606842140f5b8089a60.png

*only just turned ping on

I'm hope that activity is downloading?
 
I see the comment: "Increase the tick rate..." is second on the 'address rubber banding issues'.

Does anyone know what this will do to server performance at a technical level? More bandwidth? More CPU?
 
I see the comment: "Increase the tick rate..." is second on the 'address rubber banding issues'.

Does anyone know what this will do to server performance at a technical level? More bandwidth? More CPU?

Yes to both. Nofate the guy working on BF3 Venice Unleashed posted this about the tickrate and why it's not possible to increase it above 10Hz

Currently, for both BF3 and BF4, the simulation tick rate value is locked to 30 ticks per second.

Changing it will however result to some unpleasant effects (even if it's also changed on the client-side).
For instance, player input will start becoming unresponsive, vehicles will start rubberbanding, several area triggers (eg. Capture Points) will not be able to properly detect the capturing players, fire-rates will become unstable, time of certain timers (eg. out-of-bounds) will be scaled down based on the new sim rate, etc.

I was looking into a way to hotfix some of these issues, however the game timing system appears to be span out across the entire engine, with dependencies upon dependencies, making it rather hard to achieve.

I should also note that the data tick rate fluctuates from 10 - 20 ticks per second, however movement updates seem to be locked at 10/s.

Battlenonsense posted a video on it too and responded on symthic forums when they started ****ging him of.


Additionally, I think I read a tweet ages ago from Sliced_Lime that increasing the tick rate was not possible. It may be covered in the video.
 
Yes to both. Nofate the guy working on BF3 Venice Unleashed posted this about the tickrate and why it's not possible to increase it above 10Hz



Battlenonsense posted a video on it too and responded on symthic forums when they started ****ging him of.


Additionally, I think I read a tweet ages ago from Sliced_Lime that increasing the tick rate was not possible. It may be covered in the video.

That is horrific - no game since late 90s has any excuse for tying any kind of timer to the framerate likewise collision detection, etc.

AFAIK the game works by sending client input updates at 30Hz and sends out 3x game world updates from the server to clients every 10Hz. (EDIT: Ah that video updates the older one to get it the right way around).

In response to the other question - as per my previous post increasing the "tickrate" will increase the CPU use a fair bit especially on the server where the CPU useage will be almost purely gameworld simulation. However bandwidth should not increase massively unless its as badly coded as the game logic seems to be - if done properly you have a base level required to update a client as to the game state which will be fairly constant at any tickrate and then beyond that information on changes that happen between updates - the higher the tickrate the less that changes between updates so if done right the bandwidth increase will not be as bad as it sounds at facevalue.

30Hz client update rate is IMO fine for all but the most extreme top level players using some kind of "promode" style of play/mod but the server update is another matter - even upping it to 20Hz would knock 50ms straight off the built in delay which in a game like BF4 is huge and would immensely increase the quality of the experience for everyone. (EDIT: Well if they can also fix some of the other issues that result in massive delays/desyncs as well as those issues would detract from the impact of the increased update rate).

Personally I don't feel like the game is actually doing input as precise as 30Hz would suggest - trying to do fast multi input actions very quickly produces much worse results than even games that have 20Hz client update frequencies.
 
Last edited:
Yes to both. Nofate the guy working on BF3 Venice Unleashed posted this about the tickrate and why it's not possible to increase it above 10Hz



Battlenonsense posted a video on it too and responded on symthic forums when they started ****ging him of.


Additionally, I think I read a tweet ages ago from Sliced_Lime that increasing the tick rate was not possible. It may be covered in the video.

Fantastic video. This is the first video I have watched where the editor has put some effort into his conclusions.

Thankyou very much for forwarding this on.
 
30Hz client update rate is IMO fine for all but the most extreme top level players using some kind of "promode" style of play/mod but the server update is another matter - even upping it to 20Hz would knock 50ms straight off the built in delay which in a game like BF4 is huge and would immensely increase the quality of the experience for everyone. (EDIT: Well if they can also fix some of the other issues that result in massive delays/desyncs as well as those issues would detract from the impact of the increased update rate).

Indeed, but what I think Chris is saying is that they would almost have to start again to provide a dynamic tick rate which is the ideal solution (given the above assumptions regarding CPU use).

Would you agree that consoles are largely to blame for this issue regarding the engine? I'm not sure I made the link between the higher update rate and lower bandwidth. They seem contradictory to me.

I think what was missing in that video was a better analysis of the variability between different server sizes. If the tick rate stays constant then why does battlefield feel snappier with less people playing? Surely this has to be down to how efficient the gaming engine is and how the server is speced. I would imagine that it is the former that is the root cause of this issue.
 
Last edited:
Indeed, but what I think Chris is saying is that they would almost have to start again to provide a dynamic tick rate which is the ideal solution (given the above assumptions regarding CPU use).

Would you agree that consoles are largely to blame for this issue regarding the engine? I'm not sure I made the link between the higher update rate and lower bandwidth. They seem contradictory to me.

I think what was missing in that video was a better analysis of the variability between different server sizes. If the tick rate stays constant then why does battlefield feel snappier with less people playing? Surely this has to be down to how efficient the gaming engine is and how the server is speced. I would imagine that it is the former that is the root cause of this issue.

Dynamic tickrate is a waste of time IMO though the ability to put idle servers into a hibernated state when empty is handy.

I suspect consoles are largely responsible for the kind of settings they've used the current state of it (bugs and glitches aside) is fine for that kind of gameplay (aim assist, etc. would work with the limitations naturally) but far short of fast paced PC action.

As to bandwidth use (massively over simplified) objects in a gameworld will change state at different rates, some objects like an explosion might just need to be sent once other things like a player driven vehicle will be moving and turning at a high rate of change and can saturate almost any amount of update frequency (which is why typically you will see prediction issues and rubber banding with vehicles especially in early builds of a game where its not a priority to get it completely right). Something like a bullet being fired can often be handled using carnal knowledge of the bullet mechanics on the client and you just need to send the origin and angles, weapon type, etc. once and the client can extrapolate that data over serveral frames until something happens like the bullet hitting an object without extra bandwidth use if the game is coded properly. (This is applicable to BF where bullets are projectiles existing over several frames unlike many other games where they only exist in one frame as a single hitscan).

Within reason as you increase the update rate the less objects within an update actually need a state change broadcast.

Then you have other techniques like area of relevance where you can determine what objects are relevant to a player and which ones you can resend information about at a slower rate as the lower accuracy of their simulation won't have an impact on the player.

I think the problem with fuller servers comes down to 2 factors - one being that they seem to have tried to clamp data rates to within certain limits and sometimes sacrificing accuracy to keep within those limits and also that the way the game has been coded seems to put far more reliance than any other similiar game I've played on updates from every connected player at any one time so someone who is lagging out badly has a much bigger impact than normal and with larger player loads the chance of someone having issues like that increases.
 
Last edited:
I think the problem with fuller servers comes down to 2 factors - one being that they seem to have tried to clamp data rates to within certain limits and sometimes sacrificing accuracy to keep within those limits

Are you saying that the download rate for a client decreases as the server fulls up or do you think the lag is due to the increased chance of a high ping player?
 
For anyone that was wondering. This is the current state of conquest large on Xbox One / PS4


In that same game I ran the system performance test :


Game experience should have been perfect !
 
Status
Not open for further replies.
Back
Top Bottom