How about because their servers are from 10 years ago? All you have to do is look at bdo ff15 and wonder.

RinaldoGandolphi wrote: »

Using TCP for this game was a huge design blunder on their part, and I don't think they will re-write it and move away from TCP to UDP although doing so would probably solve most of their lag issues.

While I agree that UDP might've been a better choice, it's not a magic silver bullet. Point one: there is still the possibility that ZOS' implementation would be so poor that we'd end up with just a tad less laggy mess.

Point two: the issue is not as simple as "any packet older than 5s is worthless, just roll with what arrives in time". Imagine you hit weapon swap button. When does the client UI show the back bar? When client sends the packet, or when it receives confirmation from server that you're allowed to weapon swap? If client shows back bar when sending packet, and that packet never arrives at server, the client thinks you're on back bar, while server thinks you're on front bar. On the other hand, if client waits for confirmation from server before swapping, what if that confirmation never arrives, even though the server received the request and sent confirmation? They would have to implement a consistency layer on top of UDP, and that'd be a lot of room for "killing it".

Point three: you mentioned early 2000's... some games from that era serve as proof that large-scale real-time combat over TCP is definitely possible. I might be repeating myself as I'm pretty sure I've talked about Lineage 2 on these forums in the past. Perhaps it doesn't fit the "triple A" category (which in my opinion says nothing about quality, only budget), but that's irrelevant.

tl;dr: you can choose TCP, if you know the implications, and if your combat design doesn't contradict those.

Lineage 2 released in 2003/2004, and until around 2007 didn't have any instanced content. The whole game world was one persistent huge map with no loading screens; there were some dungeon-like areas, but these were actually just confined underground or underwater rooms still on that map, where you teleported instantly. Obviously they wouldn't be able to support unlimited number of players on one map, so they had many independent "shards". The shard server software consisted of several services running on dedicated machines (database, logging, etc); login server pointed the client to your selected shard's game server, that was your connection to the game world. This game server -- and I mean one dedicated machine -- routinely handled 3k concurrent players and tens of thousands of NPCs. Most of the time these were running around in small groups, killing mobs or other players, but there were a few towns and events where many players gathered. The events that attracted hundreds of players to duke it out in a small area were world bosses whose respawn timers counted in days, and castle sieges that occurred every other weekend (i.e. like Cyrodiil, but only 4 hours every 2 weeks).

Granted, that game had a much simpler combat system than ESO has, but it also had ten times the population on a single server, which had no trouble running AI scripts for antelopes (cf. deer) and other creatures being slaughtered by players in various areas all over the map, while hundreds of players were spamming buffs, nukes and heals around castles. And it ran smooth over TCP in an era of much lower bandwidths. When some crafty Russians got hold of the server software, they figured out how to let 15k people in, and it didn't crumble. ESO under such stress would float out of Craglorn...

The reason server performance is so terrible is because they have utterly failed to keep up with the growth of the game's population. They are either unwilling or unable to spend the money necessary to upgrade the servers to what they actually need to be to accommodate the current player base and rate of growth. Any other reason given is just an excuse.

Delparis wrote: »

imo the server got this bad performance because all the calculation responsable for the lag and frame rate drop are made server side. Those calculations are liked to:
- many skills have multiple effects (dmg, buffs, debuffs) which make the calculation more complicated and time consuming

These are not an issue when we are talking about Big O notation. The additional + or - in a damage calculation do not affect the run time in a meaningful fashion. F(x) = x and F(x) = 3*x+5 are both classified as O(n).

Delparis wrote: »

- skills don't have a long enough global cooldown to prevent too much ping a request to the server
- animation cancelling with LA weaving is increasing the stress on servers

Well, stripping these away would make the combat more clunky. Performing actions on your character should feel fluid and entertaining. What difference would it make if you had a huge lag where you can perform actions every 2 seconds versus a scenario where you had a minimal lag and you could perform actions every 2 seconds?

Delparis wrote: »

- there is too many buffs and debuffs available and they are splitted into major and minor buffs

Yet again, these do not affect the big O notation.

Delparis wrote: »

- objects, containers and npc are dynamic so the server has to tell the client were they are (npc) and what they are and what they content (objects and container)

to name a few..

Yes, dynamic environment means the collision detection algorithm has a bigger Big O notation. With static environment you could use sweep and prune with a O(n), but with dynamic environment, the notation changes on the worst case scenario to a O(n^2). But! A static environment would be quite boring and would feel like it is not 'alive'.

Delparis wrote: »

i really think Zenimax devs should have a look on those points and improve them instead of putting more ressources in hardware.
a way to adress those issues is as follow:

1. Make skills have only 1 dmg, heal or buff effect
2. Increase the global cooldown to skills to 1 sec and make LA share the same global cooldown (clunky combat maybe but at least you don't play on a slideshow)
3. remove the animation cancelling on LA as they share the same gcd with skills
4. standerdize buffs and debuffs, no more minor and major one (less factors for the calculation), and make some of those buffs and debuffs available through foods, drinks and potions
5. npc position should be known from the client rather than the server so less useless informations transiting, the same thing for objects
6. container should have an RNG tool when interacting with it, so the server won't have to comunicate to the client what they contain. also since rng players will be able to interact with the same container and get different loot depending on their rng. each container have 1 loot.

hope this can help you Zenimax devs

As said, making the skills have only 1 effect would not affect the calculation's big o notation in a meaningful way, rendering the 'fix' useless to combat lag and ping. The same thing with buff/debuff proposition. Switching the location data from server to client would still keep the collision detection algorithm's Big O notation as O(n^2). And worst of all, every action performed on client side is vulnerable to hacking and cheating - and cheat detection is usually quite demanding process when it comes to run times!

I think the real reason why we have bad performance is because of the amount of players. It is a good thing for the game to have a growing playerbase, but it also means the servers need to be kept up to date and upgraded.

We do not know if the programming is done in an optimized way or not, because we cannot access the source code to analyse it.