Most of the data comes out of a database and also has to go back into it. From what I remember are the mechanic calculations not a big issue, but it’s the format of the data and the data tables, which need to be shaped in such a way that one can process as much as possible in parallel and that the database itself can update the data quickly and without causing a lock on other data tables.
One could see this in the old database dumps, but also with the current API, where some of the data just seems upside down or unhandy at first, but it’s likely connected to how the server processes it. A simple example here are the resistance values of ships. So is a 35% resistance on a ship’s armor stored as 0.65 in the database and not as 35 or a 0.35 as one perhaps might expect.
If I had to guess, I’d say it’s a bit of both and you could take the Upwell structures as an example of CCP not only making improvements to the game, I know not all may see them that way, but also removing obsolete code (POS, which could not be improved upon) from the game. well it hasn’t quite been removed just yet but well on it’s way
Yeah, I love how quick one can dock and undock at the new structures. It’s always a magical moment. It’s so quick now that one can no longer abort the undock. One click and it’s happening.
What you expect from todays CCP is not achievable. Even simple thing like chat in game is broken (sporadically) after “improvements” and cant be fixed for few months.
Or that moving white circle scanner around my ship hp bubble. It doesnt fade away and stays visible, where before they broke it it faded away.
Some of the things you mentioned actually depend on each other.
As for being an example. Yes, most of the things you’ve mentioned are tiny parts of what’s happening and probably wouldn’t even need to be parallized. These things are calculated faster than they could be delegated.
That’s putting a lot of butter on the bread, considering that many other MMOs limit the number of players per server, because they can’t get it done in any other way. You didn’t say what kind of concurrent systems you’re creating. Are they any similar to the challenges of EVE? If yes, maybe you should work for CCP.
I’d be happy to come on board and lend my expertise.
I have no idea to your question - whether this EvE MMO video game presents some uniquely hard challenges to concurrency. But my intuition tells me no. I’ve seen highly parallel and computation-extensive graphical simulations run before (fluid dynamics, millions of particles colliding in particle physics simulations, etc). I don’t know what EvE might be doing computationally that is some unique computation bottleneck. It’s why I created this thread - to try and find out.
Since you mention graphical computation I think one of the things in large fleet battles that is very different from video encoding and the likes, is that you have an extremely high amount of different little calculations to manage whereas in graphical simulations you can use parallization (same instruction, large set) for great advantage.
I have a similar question going on in the forum also. What would help is if a real CCP employee could answer the question rather than all the hypothesising.
It’s not my problem if you can’t understand a thing that people discuss here. I’m still curious about the gank that got you so salty that you’ve spent the past couple of weeks persistently trolling the forums.
So, back to topic. My understanding is that the we need to look at both the client and the server.
Client-side there can be lag due to the sheer amount of moving objects in space. There are a number of settings in the menu that can help ease this lag.
I’m not sure wether or not the server still sends unneccessary data to the client, after the graphic settings have been lowered. For instance positioning information about missiles and other objects that you’d probably disable to counter client-side lag. If it does, this might be a way to reduce client lag further.
Server-side, TiDi is the attempt to avoid crashes or unintended behaviour (dropping of requests for instance). When you mentioned graphical simulations I assumed you were talking about calculations that can be parallized and would be so much more effective when employing GPUs. My understanding is that there are too many little and different calculations for this, so that in the end a CPU is the most effective approach. As already discussed, there are limits to the computing power of CPUs, so TiDi is currently unavoidable.
However, what I don’t understand is why we still see node crashes or people losing their connection to the server. These things should be exactly what can be avoided with TiDi.
Use or non-use of GPUs is a different topic. I was merely using graphical simulations as an example of computationally-expensive work which, in the end, is parallelizable (both with the use of GPUs and non-use of GPUs) and can be sped-up tremendously with the use of said parallelization.
I want to know what is so special or different or unique about EvE and it’s calculations which is not parallelizeable and which must forever be subject to non-playability once X numbers of people are all fighting in a system. My intuition and experience tells me ‘nothing,’ and my experience working in this field is that you have to 1) know what you are doing, 2) design for parallelism from the outset, and 3) I rarely see examples of either in my work.
There are not limits to computing power of CPUs, if the problem is parallelizable, and if you use enough CPUs. Thus the question and the topic at hand.
The space-simulation (dogma) was designed back in the day when everyone thought that clock-speeds would keep getting higher. Back then, nobody was running more than one core.
CCP has been moving as much away from the main space-simulation as they can, to increase the amount of players that they can handle in one system. Unfortunately, we players keep pushing against that line and breaking it every time.
Let me say it clearly : they are not
They MUST be computed in the sequence of their happening, and the effect of the each impacts the results of the next.
eg. during a tick , at time 0.2 I activate my turret to finish a titan. Then at 0.3 that titan pilot uses his DD. Which kills a dread if the titan is alive. You understand that the death of the dread depends on how the events are handled. That means you can’t parrallel the titan, the dread, or me’s ticks.
You think “maybe we can make the graph of interactions and split it in connected subgraphs, to handle them each in a parrallel thread”. Well to do that you need to resolve a good part of the events.
This is exactly what i’m confused about. CCP improved their hardware, they work on optimizing software and added TiDi. But in the end node still crashed and clients lose connection.
I suppose that current implementation of TiDi has some hard limits and these limits prevent it from using full potential. For example it might be unable to make time slower below some value. And this still allows for server resources to be not enough.
Why client can lose its connection to server even before TiDi is an another question.
I can’t just take it as a bare assertion. I’d have to see and hear more, as to why this is the case.
Anyway, if the current design is unparallelizeable, there was probably some other design that was parallelizable. Bottom line, you shouldn’t design an MMO game in ways that are not parallelizable. Which is why we are where we are now.
Naturally, you wouldn’t parallelize across ticks, so you are stating the obvious. You would parallelize each tick. And you would parallelize whatever else you could parallelize.
This is already done. For instance, physics simulations, whether simple or complex, have already been shown to be parallelizable, and have already been parallelized. Think a bunch of balls bouncing around hitting each other, whether they are molecules, billiard balls on a pool table, or whatever else. You don’t know what the outcome of striking the cue ball with the pool stick is going to be until the simulation is run, because it first has to hit the racked-up balls, those balls have to bounce around and knock into each other, etc. So it’s the same situation as you just described - the outcome of what happens to this ball depends on the outcome of what happens to that ball which depends on what happens to that ball, etc. But again, this kind of thing has already been parallelized, and you parallelize the ticks, not across ticks.
As a separate matter not necessarily related to parallelization, in my day-to-day work I also see lots and lots of slowdowns related to either database architecture and design, and/or how programs are designed to hit the database. Queries which could have been done in one database hit instead do it in three hits, four hits, five hits. Often, I’ve had attempts to fix this kind of thing frustrated by fools who sit on high, e.g. marketing departments who insist on a stupid requirement when the dropping or modification of that requirement would allow for fixing of the problem.
Again, I simply refuse to believe that this situation cannot be rectified with proper design, unless and until someone proves it. That should be our default stance for anything: things are solvable, unless they are proven not to be. If you take the opposite approach (things are unsolvable, unless they are proven to be), we’ll never make progress anywhere as a society.
The problem is heavy load which the node and system at large are simply not designed to deal with. At enough load, without proper design the thing is gonna crash no matter the TiDi or whatever else.
