These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE General Discussion

 
  • Topic is locked indefinitely.
12Next page
 

Technical question: EVE Smallest Timestep/"quantum" of time
Author
Previous Topic Next Topic
IceGuerilla
Viziam
Amarr Empire
#1 - 2013-08-20 04:17:16 UTC
After 8 years of playing this game, I can't believe I've never asked this before:
A) What is the smallest unit of time simulated by the game servers?
on a related note:
B) Does the server use some sort of clever algorithm (e.g. RK-4) to solve differental equations?
Tippia
Sunshine and Lollipops
#2 - 2013-08-20 04:21:50 UTC
Depends on what kind of time step you mean.

The world simulation run at 1-second ticks (longer under TiDi), but in terms of precision for things like cycle times and delays, everything seems to be counted in milliseconds.

I'm not sure it uses differential equations at all (at least not for the purpose of predicting and interpolating between frames), but it sure uses clever algorithms. P
IceGuerilla
Viziam
Amarr Empire
#3 - 2013-08-20 04:28:08 UTC
Accelerating from 0 to 100m/s, charging cap from 20% to 30% etc are all differential equations.
Is a millisecond the most basic unit of simulation time? Seems a bit long.
Tippia
Sunshine and Lollipops
#4 - 2013-08-20 05:04:15 UTC  |  Edited by: Tippia
Cap (and shield) recharging, maybe, but that's mainly because I've never seen anyone come up with a proper function for it.

Acceleration, if I've done my math right (which admittedly is doubtful) is just 10⁶/(I×M) × 1-v/vmax, and speed changes can be determined through v(t) = vm × (1-e^(-t×10⁶/IM)), so no particular trickery is needed to solve any of it. I wouldn't be surprised if the cap and shield ones are similarly simple once you drill down a bit precisely so you don't have to delve into differentiation.

And again, the frames are one second long, not a millisecond, which is why I suspect they've done away with any such need as far as possible. But sure, that's just speculation based on what the (know) formulas involved look like.
Donbe Scurred
University of Caille
Gallente Federation
#5 - 2013-08-20 05:28:47 UTC  |  Edited by: Donbe Scurred
What is this? Intelligent and informative conversation on eve forums and to boot in GD!?! THIS MUST BE STOPPED!!!!Lol

Seriously though, good stuff, my neurons are tingling.

Tippia, can you break those acceleration formulas down a little more for those that are not as informed as yourself? Such as myself. I realize there may not be an idiot's version, if so I understand you not taking the time.
Tippia
Sunshine and Lollipops
#6 - 2013-08-20 06:00:46 UTC
Donbe Scurred wrote:
Tippia, can you break those acceleration formulas down a little more for those that are not as informed as yourself? Such as myself. I realize there may not be an idiot's version, if so I understand you not taking the time.

I can write them out a bit more thoroughly, if that helps.

Acceleration as a function of current speed is: (1,000,000 / (inertia modifier × mass)) × (1 - current speed/max speed)… but I've probably hideously messed that one up because it's a bit small once you start plugging in actual values — I've probably missed a max speed multiplier somewhere. Anyway, the first part simply denotes the maximum acceleration of the ship, and the second part is the bit that makes it all non-linear: the closer the current speed/max speed ratio is to 1 (i.e. the closer you are to flying at max speed), the lower the second term becomes and the lower your current acceleration is.

Speed as a function of time (where you're standing still at t = 0) is max speed × (1 - e^( -t × 1,000,000 / (inertia modifier × mass) )). Not much to say there. Your speed increases inversely exponentially as you get closer to its maximum, and again, exactly how quickly it does this depends on your inertia modifier and mass.
IceGuerilla
Viziam
Amarr Empire
#7 - 2013-08-20 07:06:52 UTC
In a perfect world - yes - but if you're turning, being bumped etc, then you can't pre-emptively solve for x(t). Anyway - as with cap, there are differential equations with non-analytic solutions which the server must solve; a high order routine would be smart.
Also, there must, as I've asked, some finite timestep the server takes; TiDi notwithstanding. Someone out there must know what it is!
Tippia
Sunshine and Lollipops
#8 - 2013-08-20 07:21:02 UTC
That's what the causality bubbles are for… Blink
Anyway, turning and bumping is just acceleration along a different vector and are both just as predictable as any other movement.

And again, the world simulation operates at 1Hz; the time step is 1 second.
Arduemont
Rotten Legion
#9 - 2013-08-20 07:27:09 UTC
From what I understand everything runs on 1 second ticks server side, but the client runs much closer to real time (ie, the information is fed back to the server every 1 second). So for all intensive purposes, 1 second is the smallest unit of time in Eve.

Sorry if this has already been said. Couldn't be bothered to read the rest of the replies.

"In the age of information, ignorance is a choice." www.stateofwar.co.nf
Mara Rinn
Cosmic Goo Convertor
#10 - 2013-08-20 07:29:06 UTC
Intents and purposes.

Sorry. I am easily baited, I know. The folks from Rifterlings are rolling their eyes at me right about now.

Day 0 Advice for New Players
Mara Rinn
Cosmic Goo Convertor
#11 - 2013-08-20 07:32:37 UTC
IceGuerilla wrote:
In a perfect world - yes - but if you're turning, being bumped etc, then you can't pre-emptively solve for x(t). Anyway - as with cap, there are differential equations with non-analytic solutions which the server must solve; a high order routine would be smart.


Why would the simulation need to preemptively solve the outcome of a collision?

Day 0 Advice for New Players
Trevor Dalech
Nobody in Local
Of Sound Mind
#12 - 2013-08-20 07:40:10 UTC  |  Edited by: Trevor Dalech
Tippia wrote:
Cap (and shield) recharging, maybe, but that's mainly because I've never seen anyone come up with a proper function for it.

Acceleration, if I've done my math right (which admittedly is doubtful) is just 10⁶/(I×M) × 1-v/vmax, and speed changes can be determined through v(t) = vm × (1-e^(-t×10⁶/IM)), so no particular trickery is needed to solve any of it. I wouldn't be surprised if the cap and shield ones are similarly simple once you drill down a bit precisely so you don't have to delve into differentiation.

And again, the frames are one second long, not a millisecond, which is why I suspect they've done away with any such need as far as possible. But sure, that's just speculation based on what the (know) formulas involved look like.


The words acceleration and velocity by themself already imply differential equations.

The formula you give is the solution to the differential equation describing an object moving at constant thrust and experiencing a resistive force proportional to its velocity. Given an initial condition of zero velocity, this object will accelerate until it reaches a terminal velocity where the drag force is equal to the thrust. It approaches this terminal velocity exponentially.

If you are not starting from a standstill, are changing direction, orbiting, or changing your acceleration in any way, your formula will not work.

However, the EVE servers operate at one second ticks. This means that inbetween ticks, acceleration is essentially constant. You do not need Runge Kutta algorithms to solve that, you can simply integrate with a one second time interval.

The only tricky bit would be collision detection. However, my many experience of ending up inside an asteroid or other structure and then being slowed to a crawl tell me that this is simply done at the end of the tick.
Tippia
Sunshine and Lollipops
#13 - 2013-08-20 08:43:52 UTC  |  Edited by: Tippia
Trevor Dalech wrote:
If you are not starting from a standstill, are changing direction, orbiting, or changing your acceleration in any way, your formula will not work.
Not as simple slot-ins, no, but like I said “determined through”. Juggling the parameters around gives us such fun mappings as v(t), t(v), and a(v), at which point we can just remove both a and t from the equation.

Quote:
However, the EVE servers operate at one second ticks. This means that inbetween ticks, acceleration is essentially constant. You do not need Runge Kutta algorithms to solve that, you can simply integrate with a one second time interval.
You don't even particularly need integration. Since t just becomes a dummy variable — the game doesn't care how long it takes to accelerate to a given speed, just what the current state is, and the aforementioned formula is just to give us players something to calculate — you can fairly trivially express next frame's speed in terms of current frame's speed, and the acceleration (or whether it's constant or not) doesn't even matter. As far as I can tell, vnext = vmax × (1-(1-v/vmax)×e^(-10⁶/IM))

Yes, technically, we have a differential equation right there, but it's so ridiculously simple and comes pre-solved due to how the whole system is set up, so all you have to do is slot in the current v. Afaik, changing direction is simply a matter of accelerating along a new vector, and the turning speed depends on how quickly you're already moving along that vector. Orbiting means a different “new vector” is calculated every frame. The only mystery is how quickly you decelerate along the normal (I'm guessing it just sets the vmax to 0 along that vector and goes to town).

Quote:
The only tricky bit would be collision detection. However, my many experience of ending up inside an asteroid or other structure and then being slowed to a crawl tell me that this is simply done at the end of the tick.
The linked thread describes how collisions are handled, iirc.
Zakarumit CZ
Zakarum Industries
Forgers United
#14 - 2013-08-20 08:58:53 UTC
I dont think EVE solves differential equations at all. Even RK-4 algorhithm would take too much CPU when every online player would need differential equations solved on regular basis.
Also I dont think there is any need, shield and cap formulas can be approximated well enough. You dont need to differentiate, just use "increments small enough" and you are very close, or close enough considering server clock is not very small I bet.
mechtech
Ice Liberation Army
#15 - 2013-08-20 09:04:18 UTC
(CCP input here would be interesting)
Lee Saisima
Doomheim
#16 - 2013-08-20 09:07:46 UTC
The client running natively on your OS handles all the graphical, calculative, and I/O (peripherals, server communication, monitor refresh etc.) intervals in milliseconds (thousandth of a second). At a very low level it all depends on the capabilities of your CPU (and GPU). But packet information is shared with the EVE servers at 1Hz (once every second), so that is the smallest interval, or "tick", that the game will make. But not sure of the original question proposed by the OP; the servers do not undertake any such equations, packet information is shared so that positions, velocities, and other such numbers are simply shared in a uniform way between clients. Your CPU (or even GPU, depending on the technology) handles all of the calculative aspects of object collision etc. As to what equation is used for all of this, it is impossible to tell unless you have been working directly with the code. The solution is rarely as complex as those found in standard mathematics, due to the computational costs. Differential equations are a very expensive way of calculating velocity / object collision directly, so yes maybe a clever method is used. But it is never really as complicated as you would imagine, because of the time constraints of pushing out code for such a huge project.
Jake Warbird
Republic Military School
Minmatar Republic
#17 - 2013-08-20 09:22:38 UTC
I read this thread and gained a few IQ points. +1

Sugar Von MurdererTits : Jake Warbird gets my vote for most intriguing and attractive male character in Eve.
Trevor Dalech
Nobody in Local
Of Sound Mind
#18 - 2013-08-20 10:01:01 UTC
Zakarumit CZ wrote:
I dont think EVE solves differential equations at all. Even RK-4 algorhithm would take too much CPU when every online player would need differential equations solved on regular basis.
Also I dont think there is any need, shield and cap formulas can be approximated well enough. You dont need to differentiate, just use "increments small enough" and you are very close, or close enough considering server clock is not very small I bet.


You just described the simplest method of numerically solving a differential equation. RK-4 does the same thing, just in a slightly more complicated fashion.

RK-4 would be overkill. This is a space game not an astrophysics simulation. There is no need for numerical accuracy, as there is no reality to compare to anyways.
Kehro Urgus
Dark Nebula Academy
O X I D E
#19 - 2013-08-20 10:12:57 UTC
The server should calculate Planck Time for each player compensated for relativity. That should make some nice lag. Twisted

Yeeee! 
Trevor Dalech
Nobody in Local
Of Sound Mind
#20 - 2013-08-20 10:53:21 UTC
Kehro Urgus wrote:
The server should calculate Planck Time for each player compensated for relativity. That should make some nice lag. Twisted


General relativity has already been implemented, get a large enough mass of players in a small enough area and we get time dilation.
12Next page