Optimisations ideas
Ironsoul
Join Date: 2011-03-12 Member: 86048Members
Join Date: 2011-03-12 Member: 86048Members
<div class="IPBDescription">Unnofficial, uninformed, under the sea</div>alright, I should first start off that I am a beginner programmer, I don't really know much at all. But hear me out.
What I present is a bunch of possible optimisations that might improve client side performance and/or server performance.
First up, is the fact that when a server tickrate goes down, so does my fps... why is that? Is it because rendering each frame is linked
to the rate the game world updates? I can only assume it is. It's especially obvious when i have high ping, because I'm receiving data at a delayed rate, and my fps gets worse.
How to fix, well, first up, I would think that separating rendering from updating the game world would be a nice start.
My main idea, is a system which puts more strain onto the server(possibly), and hopefully less strain onto the clients.
How this is done:
The server can tell where the players are, but a player on one side of the map, doesn't really need to know exactly what another player on the other side of the map is doing.
In the same way you get hydras to "sleep", you can get a server to detect when people are too far away from other players to matter, then cause the updates of that player to reduce to x,y coordinates only(no health, gunfire, look direction etc), and then slow those upates to once a second. You could probably use the same occlusion culling mechanism to make it work.
Problems with that: audio, you would still want to hear enemies on the other side of a wall, so perhaps you could send audio only as well as x,y coordinates. But even then, keep the updates to once or 5 times a second). That way, you will still get the sense you can tell where the enemies are, at a reasonably smooth rate, but save on not needing to update everything else. This would save hugely on bandwidth.
Another optimisation: reduce updates of a heap of things to 5 times a second. Such as: building's taking damage/being repaird. Power in rooms going down.
Another network optimisation:
if there is no change in resource generation, don't bother updating player's clients if the client already knows how much res is being generated every 8 seconds:
just update the res increment rate every time a resource tower is activated/deactivated, and also when structures are built. Ignore updating whenever resources goes up because of the usual expected increment.
I think one of the major bottlenecks to performance happens during combat. During this time, a lot of lua calls happen forhandling attacks and damage etc. If you reduced the base principals of this down to C code, and only called the actual attack/take damage configuration(for the sound effect settings, models, how to handle death, and also pushback), that might boost overall performance while retaining modability.
That's all of my horrible ideas for now, I put it in general discussion because i heard uwe doesnt bother to check ideas and suggestions.
What I present is a bunch of possible optimisations that might improve client side performance and/or server performance.
First up, is the fact that when a server tickrate goes down, so does my fps... why is that? Is it because rendering each frame is linked
to the rate the game world updates? I can only assume it is. It's especially obvious when i have high ping, because I'm receiving data at a delayed rate, and my fps gets worse.
How to fix, well, first up, I would think that separating rendering from updating the game world would be a nice start.
My main idea, is a system which puts more strain onto the server(possibly), and hopefully less strain onto the clients.
How this is done:
The server can tell where the players are, but a player on one side of the map, doesn't really need to know exactly what another player on the other side of the map is doing.
In the same way you get hydras to "sleep", you can get a server to detect when people are too far away from other players to matter, then cause the updates of that player to reduce to x,y coordinates only(no health, gunfire, look direction etc), and then slow those upates to once a second. You could probably use the same occlusion culling mechanism to make it work.
Problems with that: audio, you would still want to hear enemies on the other side of a wall, so perhaps you could send audio only as well as x,y coordinates. But even then, keep the updates to once or 5 times a second). That way, you will still get the sense you can tell where the enemies are, at a reasonably smooth rate, but save on not needing to update everything else. This would save hugely on bandwidth.
Another optimisation: reduce updates of a heap of things to 5 times a second. Such as: building's taking damage/being repaird. Power in rooms going down.
Another network optimisation:
if there is no change in resource generation, don't bother updating player's clients if the client already knows how much res is being generated every 8 seconds:
just update the res increment rate every time a resource tower is activated/deactivated, and also when structures are built. Ignore updating whenever resources goes up because of the usual expected increment.
I think one of the major bottlenecks to performance happens during combat. During this time, a lot of lua calls happen forhandling attacks and damage etc. If you reduced the base principals of this down to C code, and only called the actual attack/take damage configuration(for the sound effect settings, models, how to handle death, and also pushback), that might boost overall performance while retaining modability.
That's all of my horrible ideas for now, I put it in general discussion because i heard uwe doesnt bother to check ideas and suggestions.
Comments
Before, there were severe rubber banding issues whenever player's collided, due to missing information that the server was incapable of sending to the client in a timely manner. Thus client-prediction for every frame that the server does not provide would fill in the gaps. This had a negative impact on client performance and everyone noticed it, as i recall it was the build 185 patch. For every frame that the client had that the server did not provide information for, had to be predicted, costing processing power. The implementation of client-prediction was necessary however, as it was an issue that needed to be addressed at some point, which it indeed has been alleviated, and for the most part the performance cost that it had brought has largely been regained.
Frankly, server netcode is something that by all means needs to be addressed specifically so that the <i>server</i> is put under less stress, as the inefficiency of the server is what is causing the drop in client frame rate to begin with, and rather rolling back fixes to collision detection to relieve a little stress on the client, we need to optimize both aspects to give ideal performance. Client performance is, at least from my experience, is less of a glaring issue than server performance is at the moment, as the client can employ various measures through the console to maximize performance. The same cannot be said for the server though, as right now 30 ticks/second is the target performance for servers right now, when in an ideal Counter-Strike server the tickrate can be 100. As of right now even the server seldom performs at maximum capacity, often dipping into the teens, and in the worst case, between 1 and 10, so in reality the server is the last aspect of Ns2 that needs to be put under more stress.
These issues are largely known by UWE, and its safe to assume whatever can be done to improve server as well as client performance is being investigated and integrated into the game.
I don't know more than you but it makes sense to me. You could stop predicting them completely I think, if the server provides 30 ticks it should be enough. I wonder if it's not already in game though, for example the power node state update only when you're close it seems.
But Heroman is right, the server performance is probably the main problem and improving it will probably also improve client performance, because they mostly run the same lua game code (which is the main bottleneck as I understood).
I think it is already on because it is a very crude and basic optimisation and anti cheating mechanism and the fact that other players disappear from your view in when they're far away. This is noticeable in big rooms like crossroads and crevice in Summit. You can try it with your friend by going to the opposite sides of crossroads, moving towards and further away from each other and you will find a distance when you will disappear from each other's view.
Did I mention the part about offloading some of the really performance hungry parts of the game, such as when combat really picks up, to C code? because that would probably at least make the gameplay more consistent.
Did you just moderate yourself, I'm confused :D
I would like to suggest a post-process tool for parsing the dump and building a timeline visualization graph of the event.
This might include some formatting of the dump statements so they can easily be separated into systems, subsystems, and threads.
That is just one idea for a visualization based on my limited understanding of how their engine works.
Other visualizations might be a better investment.
I have found building a visualization can get an entire group throwing ideas on how to prevent, squash, or hide such problems.
it makes it easier to present to the group rather than trying to describe the scenario you have analyzed in a log file.
From what I've gathered so far, the poor performance in general simply comes from all the aggressive technology choices (LUA gamecode, realtime culling, unlimited lightsources, etc..) rather than from simple fixes like proposed here. So fixing performance is a lot more involved than "disconnecting server tick rate from client fps".
Especially obvious example, as this idea in particular doesn't even make any sense at all.
Too many people are being overconfident and think that developing a game like this is as easy as their super mario clone.
<!--quoteo(post=1893340:date=Jan 10 2012, 11:10 AM:name=Zeikko)--><div class='quotetop'>QUOTE (Zeikko @ Jan 10 2012, 11:10 AM) <a href="index.php?act=findpost&pid=1893340"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I think it is already on because it is a very crude and basic optimisation and anti cheating mechanism and the fact that other players disappear from your view in when they're far away. This is noticeable in big rooms like crossroads and crevice in Summit.<!--QuoteEnd--></div><!--QuoteEEnd-->
I never noticed that one... sounds like a quick and dirty hack but will probably get replaced sometime.
<!--quoteo(post=1893563:date=Jan 11 2012, 04:20 PM:name=Kouji_San)--><div class='quotetop'>QUOTE (Kouji_San @ Jan 11 2012, 04:20 PM) <a href="index.php?act=findpost&pid=1893563"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Did you just moderate yourself, I'm confused :D<!--QuoteEnd--></div><!--QuoteEEnd-->
He removed some posts without posting anything himself, it's just the notice that something was deleted in case anyone wonders.
I think it is already on because it is a very crude and basic optimisation and anti cheating mechanism and the fact that other players disappear from your view in when they're far away. This is noticeable in big rooms like crossroads and crevice in Summit.<!--QuoteEnd--></div><!--QuoteEEnd-->
I never noticed that one... sounds like a quick and dirty hack but will probably get replaced sometime.
<!--QuoteEnd--></div><!--QuoteEEnd-->
A temp-fix perhaps in the form of a max-distance for when the occlusion-culler wasn't working at all, which could lead to insane load in some areas\maps (ns2_tram in particular, would almost be completely rendered not that many builds ago).
But hey, keep this thread going, maybe we'll get some ideas yet. Probably the main thing to fix performance is to reduce loops as much as possible. Because as we all know, while a loop is running(excluding the game loop), the rest of the program has to wait for it to finish before it can actually continue.
<a href="http://en.wikipedia.org/wiki/Multithreading" target="_blank">http://en.wikipedia.org/wiki/Multithreading</a>
As for the thread, it's good that you're trying to start thinking about the issues in this game (albeit from a beginner's perspective). Are you pursuing education or a career in computers/software? Watching the NS2HD videos (especially anything involving Max) is a good source of inspiration for me.
Chances are the major performance bottlenecks in the game come from things like the rendering engine and physics (as well as things that have been mentioned more recently like the LUA interpreter). Read up on some numerical math and graphics programming if you want to get an idea how that stuff works.
Either way, they have profiling tools to find sore spots, and they have talented programmers who are devoted to working from a good <i>software architecture </i> - they'll get the game running much smoother given time.