open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: Fixing Lag: Drakes of Destiny (Part 1)
This thread is older than 90 days and has been locked due to inactivity.

Pages: 1 2 3 [4]

Author Topic

Huang Yinglong
Posted - 2010.12.12 21:46:00 - [91]

Edited by: MotherMoon on 12/12/2010 21:46:29
Originally by: CCP Explorer
Incarna will tick at a higher frequency. We are refactoring the network code these days for that purpose.

awesome. In that case consider making an arcade game (in Incarna) where you get to fight people with joystick comabt :P

if incarna become a way for whitewolf to release boardgames.. omg... that's brilliant.

I know this isn't the place but...

With incarna maybe mirco transactions could be profitable? Not for you guys, I mean for the players. Think about it, if whitewolf designs a new board game, you could sell it to bar owners for cash, like 5$ a pop. I'll pay 60$ for a real life board game.

You wouldn't have to print the boxes, or take any risk on materials. And people that play eve could visit said bar, and never have to pay a real life cent to access any content in eve.

and it would give people a reason to visit your bar!

I know if I was working at whitewolf <.< >.> the freedom to design board games so freely would be awesome. :)

Tonto Auri
Vhero' Multipurpose Corp
Posted - 2010.12.13 21:55:00 - [92]

Originally by: Epitrope
Originally by: Tonto Auri
Actually, you're speaking of increasing simulation speed. Not to leap into the future, but to reduce amount of iterations over bigger period.
To clarify, take an example of 10 min battle. Normally, it's 600 ticks of time. If Destiny fails to process all events inside the tick, then switch tick length to 2 seconds AND calculate all events that would happen in these 2 seconds, so do only 300 ticks in the same 10 minutes, but still process all the events that should happen.
As everyone saw in the blog, the time spent on actual calculation is minimal, so increasing tick length AND calculated period shouldn't cause major issues. The only problem, client engine must be ready for this speed stepping.
All this does not exclude the need to reduce unnecessary notifications sent to clients.

I understand what I'm saying, and I believe I understand what you're saying, and they're not the same.

There will always be larger fleet fights than the server can handle. Right now, the pre-tick client updates step(s) are taking up most of the time. You're right that fewer, bigger ticks would allow the server to send out fewer,


updates, which would cause the clients to run at full speed but somewhat jerkier as updates are coming in half as quickly but with twice as much data.

You're making a mistake assuming that data exchanged will be equally bigger - no, that's not the case. The data will be the same "per tick" data, the size will be much lower than your expected double increase, and only come from the unique events that added up - i.e. ship deaths/warps in/out.
With stepped ticks the data exchange will go down considerably.

However, as optimization work continues, perhaps that section won't dominate the tick quite so much and the evolve step will take a larger percentage, in which case fewer bigger ticks won't work as well.

Indeed. There'll be always a bottleneck somewhere. Right now it's pre-tick notification calculations, later it could be the network throughput, requiring specialized proxy servers to relay the events between all the clients on a multicast principle... And the fight goes on.

Your suggestion is, from the information made available to us, a good one. It lessens the lag problem as it exists right now. My suggestion of slowing down the simulation speed is more of a way to keep the game somewhat playable with any lag, current or future, regardless of cause or nature. It's a way to degrade more gracefully than the way high-load nodes degrade do now.

As I see it, 2 mayor problems is the language choice and "solar nodes" architecture.
Python don't scale at all in multiprocessor environment, not to mention the multy-node environment.
Solar nodes limiting amount of people in a system, as well as preventing whole system mobility. Splitting nodes down to single grid would allow mobility (you can serialize almost empty grid into a short sequence of bytes and send it over ntwork to the other node) as well as lowering the load in every separate case.

Tonto Auri
Vhero' Multipurpose Corp
Posted - 2010.12.13 22:04:00 - [93]

Originally by: Dunpeal
If you let the client decide if the update is relative to itself, wouldnt that allow for client hacking and purposefully making a client wich cannot die? I mean

No. And not because, it's just that death is not calculated on client at all.
But broadcasting blindly to everyone on grid would (depends on how it is implemented) allow to create a client that see every ship on grid, including cloaked ones.

Debir Achen
Posted - 2010.12.14 05:47:00 - [94]

Originally by: CCP Masterplan
On slowing down time / increasing the tick period

This is something we've considered, along with a number of other bigger-scale changes that we've discussed. Some we quickly eliminated beacuse they wouldn't actually fix the issue. Some we've got on the board as potentials. Some we've even protoyped.
Looking specifically at the slowing-down-time idea, this has received quite some attention. Some things to think about: What things should be slowed down? (Shield recharge, rate-of-fire, movement, skill-training, market order duration, aggression times, siege cycles...) Suddenly when you have two clocks running at different rates, you have to look at every single mechanic that is in some way related to time. What about other solar systems on the same node - should they slow down too? If we try to let different systems on a node run at different rates, it means we potentially have to keep track of which system a particular function call is dealing with, in case it needs to query a timer.
I'm not saying all of this is impossible, simply that there is a lot more to it than you might initially think. (Take this as a sign that this is indeed an idea that has received attention)
At the highest level, the clock division seems obvious to me: world-sim vs encounter-sim. Anything that is bubble-independent - skill training, market orders, etc - should progress independently of the simulation clock. Otherwise, a laggy node could mess up skill training times, which would be strange.

In contrast, anything "on-grid" (so to speak) is tied to the sim clock. If the node gets overloaded, it strikes me that slowing the simulation to some fraction of real-time - and sending the client a note so that it knows to perform activation timer updates and flight extrapolation at appropriate speed - is a far better solution that dropping events (bad) or increasing the sample granularity (jerky). Slow-mo is way better than unpredictable-mo. :) "Game time" would pass at the same rate, but everything within some domain (bubble, system, node) would move more slowly. It's not a great solution, but at least it's explicable to the end user and everything stays in-sync. And you've just given yourself twice (or 3x or 4x or more) as much time to process everything without risking dropping stuff.

I'm sure the implementation is not that simple, but I think the basic idea is sound. I deal with similar multi-clock issues at my work, and clear splitting of domains helps no end.

BTW - is the 1Hz tick why missiles - especially Defenders - often seem to overshoot their target and then burst back onto it?

Ensei Grad
Posted - 2010.12.14 11:11:00 - [95]

This now scales much better as the number of balls and observers rises - it is more like O(n+m).

So cpu load will still be this small when we got like 300 drakes on each side shooting each other?

Winters Freedom
Posted - 2010.12.15 16:23:00 - [96]

Could you train 'Server Agility' to level 5, 'Server Multiple events' to level 5 and then add 'Server-client Impact' gaining 5% speedup per level?


Daneel Trevize
Posted - 2010.12.17 02:00:00 - [97]

Edited by: Daneel Trevize on 17/12/2010 02:01:19
skill training, market orders, etc - should progress independently of the simulation clock. Otherwise, a laggy node could mess up skill training times, which would be strange.
Evil(?) way to deter blobs - those involved experience time dialysis and so train slower. Therefore poeple have to decide if they want to keep being in massive gangs or if they'd rather find a smaller encounter lifestyle Twisted Evil
Of course, the real fix to blobs is change to gameplay to something that rewards dividing numbers, like having to take synchronised and/or simultaneous actions in each system adjecent to the one you're after, splitting the forces 2-5+ ways.

Jehanne D'ark
Ghost Tribal Credit Union
Posted - 2010.12.18 19:36:00 - [98]

With each advance the game makes, the maximum size of forces will grow as more players come to the game. This we all know. I just can't wait till I'm reading player news segment about the 300,000 man battle for some 0.0 system and how their modules were laggy but they did fine. :3

Jehanne D'ark
Ghost Tribal Credit Union
Posted - 2010.12.18 19:39:00 - [99]

Edited by: Jehanne D''ark on 18/12/2010 19:45:05
"CPUs will not support such size fleets!" I call bs!
Linkage Enter the graphene processor!

More Linkage

immortal son
Posted - 2010.12.18 23:30:00 - [100]

i don't know if this is the right place to say my mac client dn't work. I have downloaded it like twice already. It's getting crazy and annoying

Pages: 1 2 3 [4]

This thread is older than 90 days and has been locked due to inactivity.


The new forums are live

Please adjust your bookmarks to

These forums are archived and read-only