Test Server Feedback

Perfect.

Could you amplify on that a bit? I assume that by performance you mean data rate from server to client -- And that real difficulty is staying within the download capabilities of 56K telephone modems. It seems to me that improved overviews are easily possible if coded smartly .

Update only those health percentages that change and maybe limit the maximum rate of updates.

Server CPU load impact should be null given that the server processing fleet battles MUST already handle all health of ship on grid for fleet combat reasons. Plus the trivial CPU load for data transmission to clients task seems ideal for offload to separate process (and associated hardware) that simply pulls "public" grid data from the semiconductor data base grid objects and sends it to clients that are members of that grid. Cannot be client performance either given that overview processing is nonexistent compared to graphical and other UI computational tasks.

So it seems to me that in crudest terms you are talking about the impact of adding 6 health data fields for each ship to the client update stream (current and maximum health) As things stand now a brute force coding solution would require 2 bytes of data per field for ships with less than 64K real hits in shields, armor, and structure and 3 bytes to handle capitals etc with up to 16M real hits. (if you have absolute hits, clients could handle computing display in ehp terms relative to their current ammo loads if desired assuming you also transmitted resists). Updated continuously at maximum overview refresh rate this could be an enormous increase in data rates outbound from EVE servers to clients.

However brute force is very pessimistic. While the 56K data rate would be crossed it need not be enormously so. So Health in the overview might simply be a feature that is not available to people with older type internet connections (mainly remote-rural environment people or those on budget). Allowing a functional but downgraded experience for those with lesser equipment is a long established EVE tradition that allows the mainstream EVE group to move forward. I do understand that such increased data rates does affect the CCP expense (data transmission costs) vs profit model. So marketing effects vs existing and potential customers is the key consideration.


The brute force rate can be cut in half by caching maximum health stats for each ship on grid - only requiring updates only if modules change offline/online status or somehow are destroyed prior to ship destruction. Current health can also be cached until it changes ...a relatively small percentage of ship are under fire at any given moment when there is good fleet control with FC primaries. Additionally the rate of health status updates should probably be limited - probably to once per 0.5 second at CCP maximum or whatever the normal overview rate is (actually that should be user controlled within a 0.5-3 second range so that its readable and not a blur). Clients could specify even lower rates of update based upon their connection speeds and user preferences. The length of current health fields can be shortened to the number of bits needed based on maximum health or compressed. Absolute hits for maximum health can be standardized to ship type is extenders and plates effects are handled like resistance modules and bulkheads (structure improvement modules) ...percentage effect on base hull points. Thus hull type already transmitted to overview would cover maximum health points and server would compute current health from damages after all percentage adjustments.

Finally there is a big question as to whether percentages or absolute hits for other ships should be available. I think percentages of health (three 7 bit fields) should be the standard available for ships that cannot be in your watchlist -- unless you have a ship scanner locked on that specific ship.

As a player I can see that providing absolute hits without a ship scanner would be a tremendous GIFT to pirates and killmail whores. Just sort by total hits remaining and start shooting. The only thing better would be to be able to select auto-targeting behavior to shoot ships based on hits remaining in ascending order.

It'd remain a greater than linear impact anywhere it'd have to pass-thru.

@Amarisen Gream: Take this illustration:
You have a room. And every person in this room shakes hands with everybody else. For starters, there are only 2 people. Then 10. Then maybe 100. -- Now compare the amount of extra work imposed by sending in 1 additional person at a) 2 people inside, and at b) 100 people inside.

It's in the nature of the problem itself that for every new person the amount of total work goes up ever so much faster. You can, and people do, categorize problems by how they behave in this manner (for increasing numbers e.g.). In this case, it behaves badly.

If everyone had only to shake hands with bride and groom at the doorway, it were quite different. Can you see it? A different category of problem, so to speak.

Naturally, there are many other considerations on top of this. What if your room only holds so many people? If you can then do the maximum number of handshakes in an acceptable time, that could be fine. For now. Next year, you are going to invite more people though (allow larger fleets or any other kind of extension), and this concession will come back with a vengeance!

The above is one of a number of things that could make this change expensive. Something that scales up badly is something to be very wary about. You cannot get passed the fundamental problem that every new piece of information here needs to be relayed to everybody else that came before. Add to that all the aggravating implementation specific caveats that are going to punch you in the face if you try regardless.

---
Because they are nice people; and you haven't yet had a chance to realize the other devs are too.

@Amarisen Gream:
It's not only more shaking, it's the difference between the blue plot and the other for increasing player numbers. Proposed change being the blue: It just explodes the higher you go, doesn't grow controllably.

If you look at this from a cost benefit perspective (and I don't even mean money here, just costs the game vs benefits the game), there are changes that demand a lot of concessions from other parts of the game, e.g. network and cpu resources, to make them happen, and other changes that just don't. I'm certain you can agree that the first would've to be a very helpful change to justify itself, while the latter, because it doesn't cost a lot, maybe just needs to be ok.

The fundamental properties of the 'send everyone's health to everyone else' make it an expensive change. That is all what was stated in this thread by a dev.

If this one was to make or break a game, it would happen, even though expensive! But if this one is a convenience change, with the potential to break the game for very many people because of lag, network failures, and node crashes, it probably shouldn't, no?

At its heart doing this type of thing is costly because of the way it behaves when scaling up, no matter which game, no matter which application, no matter the current codebase. As such I don't think you can suggest anyone is 'not looking beyond the current state of code, just because we are stuck in this way of thinking'. That would be a little unfair.

Maybe there is something similar that could be done instead without being quite as resource hungry?