Dear CCP

So taking the common grid into account NPC’s warp in and two war targets start fighting or a gank happens! Chaos theory! there are so many different permutations of what a common grid might be in that given instance!

Theoretically yes, because the grid is defined by the distance of objects to each other. Practically it depends, as most things that happen, happen around clusters of objects you can warp to, like stargates, structures, planets or belts. In theory and sometimes in practise Player A could be on grid with Player B, but not C, while player B is on grid with both Player A and C. (However, I don’t know how the server handles that. I think it actually sends you packages for players who are not but almost on your grid and who just left grid, which could explain that you see players warping off while they are x AU away etc.)

I agree that it is difficult to predict the behaviour of “inherently unpredictable” systems as we see in Eve or any scenario to be honest. As such trying to put a predictable formula on a common grid will always fall short!

Can anyone here tell me how you can parallelize computation for a simulation that happen in real time and must keep synchronization ? I’d be very interested.

Your talks about parallelization are nice, but when things must be computed in order it’s not gonna help much, and when it must be done in real time, I can’t see a graphic card helping.

The only thing I see that can help and might not be implemented yet is a distributed predictive algorithm to run the computations in advance on other nodes. But as you need to consider players input most of your computations will be useless anyway. And you still need the verification to take less time than the original computation. And this is far from a comon technology.

1 Like

This might interest you https://dl.acm.org/citation.cfm?id=831186

1 Like

Ladies and Gentlemen… and Combat Attack Cruisers… The Solution™:

:stuck_out_tongue:

1 Like

Necessarily, it won’t be a perfect expression, but that isn’t needed. For the sake of understanding the reasons behind TiDi, it is enough to show the expontentional progression in terms of packages sent by the server. Same for computations necessary.

The nodes have to compute/communicate within the server tick of 1 second. If they fail to do that, TiDi will set in so that each package is still being sent and each computation can still be done.

It is enough to understand that you need expontentially more ressources for linear progression of players on grid to understand that if x amount of players need y amount of ressources, x * 2 amount of players (double), need roughly y ^ y amounts of ressources, for instance if you’d need 16GB of server RAM (ignoring bandwith to keep it simple) for 500 players, you’d need 256GB for 1000 players.

From there you can look at each aspect and find the bottlenecks. As far as I know the Database server can’t be the reason for TiDi, as those would anyway be far to slow to keep up with all the data streams. The things to look at will be CPU, RAM and Network Interface.

The paper is not available, yet an interesting find. But it still only adress half the problem : this shows real time parallelized computation. Now EVE is also a simulation, which means events must be processed in order and you can’t discard them as you see fit.

That’s the real problem : you can’t use the usual tricks of real time because it’s a simulation, which means you can’t drop anything (players usualy hate when their actions are not processed, and they would hate if their ship’s volley was processed two or three ticks later), and all actions must be processed in order (the difference between a dead ship and a living ship is whether the reps land before or after the damage). So CCP took the only reasonable solution, Tidi, which is what you do in a simulation : you reduce the pace of time to process everything.

This is not quite how grids work. They’re a hard boundary not a soft ‘distance cap’ on object visibility. thus it is possible to be literally 1km from someone and be unable to see them whiclst you cann see the guy 14000 km away on the other side of the grid you’re on. This has lead to some ‘interesting’ gameplay options both in the past (Rooks and king’s grid wall bubble traps with pipebombs of old) and recently (you may have noticed that ccp changed where faction police spawn recently, twice)

1 Like

What if game would be programmed in scalable method to get 10000 threads in a single server unit and assign them to the players in battle, each thread for each player, and then the processing units would make those calculations in one second or less and send back to everyone? What kind of processing unit could have such a number of threads and would it be possible to just exchange data between those processing units? :thinking:

The only answer is turn based combat. Synchronization is what kills the servers: did the shot happen before the ship was destroyed?

In a turn ruleset, the rules determine how the server processes the player inputs. Doesn’t matters who shot first or who turned on or off a module: everyhting is condensed in a turn and the rules determine how inputs and outputs are generated. Plus the server can take as long as needed to calculate the turn.

With 10 second “action” turns plus 10 seconds of “calculation”, players would be able to perform 3 complete turns per minute -which is faster than turning on (or don’t) a weapon rack under heavy TiDi.

How to turn on and off the turn based ruleset, how to get players in and out of the battleground and very specially how to determine the battleground relaitve tot e rest fot he server would be necessary complexities, but the end result would be better than just N+1 until the server buckles.

It already kinda works this way. The simulation in EVE usually runs at 1s per tick which is nothing other than a “turn” that automatically ends after the given time.

TIDI only kicks in if the calculations for the simulation would take longer than 1s. To make sure all the movement, actions, damage etc can be calculated it makes the ticks/turns dynamically longer so the calculation can finish before the next tick/turn.

What you suggest is nothing other than a non-dynamic version of TIDI that is fixed at 10s. If the simulation takes longer than that it would simply crash or desync like it did before TIDI.

I am talking about literal turn based battles. All events happen at the same time, processed by turn rules, not by the sequence of inputs. Like Mechwarrior, but with shorter turns authomatically ended by the server. Since they are not kept in sequence, inputs can be spread over many server blades, and then the calculation blade takes all the time it needs to calculate the turn result and push it to the clients.

It doens’t needs to keep synchrony of whether a ship died before hitting another: all ships that should be dead die at the “death” phase of the rules, and all ships that have a chance to hit are rolled their chance during the “hit” phase of the rules.

Yeah never going to happen. Eve is not a turn based game. Also consider what frigate fights or ganks look like in 10 second bites. And how terrible travel would be in 10 second bites when you have to enter your move each phase.
At least try and use sensible ideas.

This is only half the truth though.

While TiDi is necessary and neither GPUs nor parallelization offer a “zero TiDi” solution, it would make a lot of sense to parallelize during TiDi.

Thanks for the explanation :+1:

Actually in a turn based combat its very important who shoot first, lets see, in every turn based combat there is mechanic about it, with implementing something like that in EVE you would take away a lot of initiative from player and made it essentially a “bring a ship to the battle simulation” kind of stuff. :thinking:

IMHO it already works that way. The “sequence” of inputs only appears as a sequence because normally the simulation is in 1s steps. If you activate two modules within a tick they activate in the same tick/turn. The same thing is true for movement, damage etc.

The only difference to your idea is that it is actually dynamic

We’re talking big battles here, not a replacement to all combat mechanics. Turn based is more scalable and better performing than “real time” simulation will ever be.

Even a “real time” simulation works in steps and the simulation would look exactly the same.

A frame is not the same as a turn. FAI, a frame is open 24/7, a turn has scheduled opening hours. In EVE you can do anything anytime, if it doesn’t fits into the current tick, it will be queued for the next tick. In a turn based system, your actions only matter during the input phase.

1 Like