Matthew
   |
Posted - 2005.07.27 12:41:00 -
[1]
 Originally by: Mark A
IMHO it's time that CCP throttled back on some of the new features and instead concentrated on getting what's already there to actually work. New (and not so new) features are still very buggy (POSs and sovereignty spring to mind) and the basic ability of the game to handle a couple of hundred objects simultaneously still just isn't there. CCP has stated before that server load generally isn't that high, so personally I suspect it's the client that needs the most attention.
Erm, they have pretty much eliminated adding any new content that required significant programmer input ever since Exodus release, to do exactly as you suggest.
While server load can be generally "not that high", in a clustered server like Eve, that can be true while at the same time having one load hotspot in real difficulties.
Originally by: Mark A
I'm a games programmer by day, so I know what I'm talking about. Most games can run a few thousand objects, AI, physics, FX, etc. and still maintain 30 fps, ie everything gets processed in <33ms.
Of course, most games have it much easier because everything is happening internally within the single PC. The eve client is completely dependant on the server for all game state computations. Which is why most of the lag I see these days is entirely server-side lag.
Originally by: Mark A
Take for example the turret FX, which you can (thankfully) now disable. In some cases like when a bunch of people are shooting a station this takes my frame rate from 5fps (ie 200ms/frame) to ~25fps (ie 40ms/fr). So the question is what on earth is the turret FX code doing that takes 160ms/fr?
The issue with turrets and stations is a known one, and is in the line to be fixed. From what I gather, models in eve have a set of "impact points" defined on them, which help define the vector of the turret fire. The stations do not have those impact points defined, which causes the turret FX code to lag as it goes to an error-catching backup state to try and cope with it.
Originally by: Mark A
I know most of CCP aren't games programmers, and in a way that's been a good thing, but client performance is where that lack of experience in code optimisation is really hurting you. Yes, the base frame rate has improved provided nothing's going on, but the scalability is still terrible, which points to both inefficient code and poor algoritmic time-complexity in some cases.
Apart from fixing a few noticable, specific error cases (turret FX vs stations being one), further optimisation of the client at this point isn't really worth it, from what I can see. At the point the client fps begins to die off, the server has already hit it's limit and started to lag you out anyway. There's no point having a client going 100fps if the server is taking 2 seconds to respond to a command.
The specific case you complain of, with 100's of people in one place, is not something that can just be put down to sloppy code or poor optimisation. It's not the code that scales poorly, it's the fundamental task itself. With 100 players in one grid, that's 100 clients that all need to know everything that's going on. So each player needs to be notified of the actions of 100 players (they need to know about themselves too). This scales as n^2 and no amount of optimization is going to change that. The best you'll do is shave a bit off the base time, and support a couple more players, not a huge number more.
The only dramatic fix to this would be to allow the distribution of one system over multiple nodes. But this would need a fundamental rewrite of the entire server software, and a restructure of the server hardware as well. Which is why it hasn't been done already.
Originally by: Mark A
I think most people would put up with a feature freeze (or at least slowdown) if it meant the basics of the game, and the lag in particular, saw significant improvement.
Previous evidence argues against you on that one I'm afraid.
Beware those beyond here, for they cannot see evil. |