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 Information Portal

 
  • Topic is locked indefinitely.
 

Dev Blog: Building a Balanced Universe

First post First post
Author
Previous Topic Next Topic
Serith Ellecon
Federal Navy Academy
Gallente Federation
#81 - 2013-12-03 18:24:49 UTC
I do agree with some of the comments above (not gonna quote).
Systems should get additional weighting based on:
1: Number of pilots who logged out in that system (and are thus shown as there during downtime),
2: Whether the system contains any Reinforced sovereignty structures (either for FW or nullsec)
3: Presence in system of a titan on an active account.
4: Proximity to systems with either of the 3 previous points.


1, is indicative of a staging system, trade hub, or other popular system, but 2 is important as it's a big clue that a fight is going to happen, and 3/4 are likely to be a transit systems (where ambushes happen too).
I'm not sure if the current stats include such a weighting methodology, or simply base it on the last 24 hours stats.

Inappropriate signature added.  CCP Notarealdev.
Bienator II
madmen of the skies
#82 - 2013-12-03 18:27:23 UTC  |  Edited by: Bienator II
Abdiel Kavash wrote:
I am slightly confused. You started the devblog by asserting that the old system was bad, because it put clusters of connected systems on one node (and intra-node jumps are more expensive than inter-node jumps). Yet you end up with a system that puts even bigger clusters of connected systems on the same node? From the pictures it looks like instead of constellations, now huge chunks of regions share the same node. Wouldn't that lead to even more intra-node jumps?

inter node jumps appear cheaper since the load is split between two hardware components. The problem is that if they create a static load balancing like that, a fight in null might affect a entirely unrelated system, eg. in highsec.

the load balancing is better but the player perceived performance is worse. Thats why they used their old strategy again, putting neighboring systems on the same node, even though it does not parallelize jumps.

how to fix eve: 1) remove ECM 2) rename dampeners to ECM 3) add new anti-drone ewar for caldari 4) give offgrid boosters ongrid combat value
GeeShizzle MacCloud
#83 - 2013-12-03 18:30:42 UTC
Abdiel Kavash wrote:
Katrina Bekers wrote:
Abdiel Kavash wrote:
Katrina Bekers wrote:
Well, for one, Dogma doesn't need to calculate anything about the movement of sentries, and notifications about their movements to any of the clients.

I am not exactly sure why would you say that. Perhaps you think that sentries don't move? They do.


Ok, write me the equation of linear, uniform movement. And tell me about predictability of such movement over time, which is a key part of client-server protocol as of right now.

Then the equation of uniformly accelerated motion (aka orbit) -- which can change at owner's whim, anytime.

Sure they move.

Sure the workload is totally different.

QED.

You seem to know quite a lot about the EVE server/client internals. Are you sure you didn't want to post this on your CCP character?


its not something u need insider knowledge on... when u get disconnects and severe lag on a server you're more likely to end up flying off in a linear motion, as well as see people who should be orbiting flying off in a linear motion. when calls from the server come back then their position is updated. but until then it eludes to the fact server side all positional data that are vector based motions are predicted by your client linearly and then confirmed server side.
Solstice Project's Alt
Doomheim
#84 - 2013-12-03 18:43:31 UTC  |  Edited by: Solstice Project's Alt
Great blog !
Very interesting read !

And now to something completely different ! ^_^

I'm sorry i have to ask this here,
but it is extremely unlikely that i will ever get another chance on asking this,
even more so that i will be able to actually catch any of you coders for a response about it !

My question is:

How the hell do you handle drones ?

Do you handle each drone as separate entity with it's own set of vectors ?

The reason why i'm asking is that this doesn't make any sense to me.

Gameplay-wise, it seems that the vast majority of people use their groups of drones as a single unit,
which means that all groups of drones could behave as a single unit,
which also means that the server would only need to do calculations for a single unit.

All drones could be "virtually present" on the client only,
with the server not having a need to deal with positions or velocities for drones,
as these do not have to be consistent between the clients !

The case that two players sit next to each other and will realise
and complain about the fact that orbitting drones aren't exactly at the
same spots on two seperate clients is completely dismissable !

Of course, there are edge cases ... like when an entity interacts with a single drone,
basically seperating it from the unit, but - and i am usually not a fan of edge cases myself -
it seems to make sense to simply handle these edge cases seperately !

Example. With 3000 sentry drones on grid, or 3000 hobgoblins,
i don't see how it makes sense to have each
drone as a seperate entity,
when absolutely most drones will behave as a single unit anyway.


Can you enlighten me on this ? I'm highly interested ! :D

Also, sorry if i don't actually make sense and i know i'm offtopic,
but this is pretty much my only chance to ever ask !

Buy Solstice Project for PLEX4GOOD ! https://forums.eveonline.com/default.aspx?g=posts&find=unread&t=301266 (this alt-character will get deleted once the sale is done, on 6th of december)
Bienator II
madmen of the skies
#85 - 2013-12-03 18:45:53 UTC  |  Edited by: Bienator II
Abdiel Kavash wrote:

As others have already said, the new allocation could lead to even higher load being put on the nodes in battles, as it seems now that any sort of reinforcements or auxiliary fights will directly contribute to the load of the fleet fight node itself. And this will also happen with a pre-reinforced node - even if you take the contested system out of the picture, all the surrounding area still shares the same node. Whereas in the old distribution, it is rare to even find a system whose direct neighbors are all on the same node.

i don't know how they reinforce nodes, but they could just take a single system out of the node and put it on a stronger node. They don't have to replace the whole node with all its systems, only pick a single one.

how to fix eve: 1) remove ECM 2) rename dampeners to ECM 3) add new anti-drone ewar for caldari 4) give offgrid boosters ongrid combat value
Abdiel Kavash
Deep Core Mining Inc.
Caldari State
#86 - 2013-12-03 18:46:42 UTC  |  Edited by: Abdiel Kavash
Solstice Project's Alt wrote:
Gameplay-wise, it seems that the vast majority of people use their groups of drones as a single unit,
which means that all groups of drones could behave as a single unit,
which also means that the server would only need to do calculations for a single unit.

So, uh, how do you propose shooting and killing drones should work?


Bienator II wrote:
i don't know how they reinforce nodes, but they could just take a single system out of the node and put it on a stronger node. They don't have to replace the whole node with all its systems, only pick a single one.

That is exactly what reinforcing a system means.
Bienator II
madmen of the skies
#87 - 2013-12-03 19:06:40 UTC  |  Edited by: Bienator II
Abdiel Kavash wrote:

Bienator II wrote:
i don't know how they reinforce nodes, but they could just take a single system out of the node and put it on a stronger node. They don't have to replace the whole node with all its systems, only pick a single one.

That is exactly what reinforcing a system means.

it doesn't has to mean this. They could just use the loaded system and all its neighbors based on the node balancer output. It doesn't make sense for jita but it might work for some nullsec fights, or live events where thousands of people have to move 10j to be in the event system.

how to fix eve: 1) remove ECM 2) rename dampeners to ECM 3) add new anti-drone ewar for caldari 4) give offgrid boosters ongrid combat value
Djana Libra
Deep Core Mining Inc.
Caldari State
#88 - 2013-12-03 20:11:54 UTC
CCP Prism X wrote:
Hello everybody, my name is CCP Prism X and I am a Libra!


So you are related to me, time to do me some favors then Twisted
Bandit 42
Halcyon Dayz
#89 - 2013-12-03 20:15:24 UTC
Good luck, hope this works :)
Zero Zeven
Element Underground
#90 - 2013-12-03 20:42:57 UTC
by god. its beautiful :')
dat code. them graphs.
all its missing are pictures of adorable hamster comparisons...
M1k3y Koontz
House of Musashi
Stay Feral
#91 - 2013-12-03 20:53:35 UTC  |  Edited by: M1k3y Koontz
Weaselior wrote:
CCP Prism X wrote:

If your fighting system is reinforced that shouldn't be an issue. This is also no more of an issue than it used to be, and now the TiDi you create in your staging systems will at least not be affecting players on the other side of the universe who have nothing to do with your pew pew. Blink

And of course more nullsec nodes mean smaller pockets grouped together.

The bolded part concerns me. It makes a certain amount of sense to avoid inconveniencing the three people in some system in Solidude for reasons they don't understand, sure. However it also makes a great deal of sense when you have a cluster of systems expected to be used heavily to offload the issues caused in those systems to unused systems in buttfuck nowhere as a sort of heat sink - it seems to me that it is better to be inconveniencing three ratters in Solitude because of 1000 people in nullsec than doubly inconveniencing those 1000 people in nullsec.

I don't mean to criticize the work you've done here - this all looks extremely impressive. I'm just concerned that it's assumptions on nullsec battles are not correct and may wind up creating more inconvenience overall in certain situations.


Really it makes more sense to inconvenience the empty nullsec systems surrounding the fight that make up at least half of all nullsec than to inconvenience the highsec systems where there's 20 newbies running missions.

Remember, get the newbies addicted to EVE, THEN we can scare the crap out of them Blink

How much herp could a herp derp derp if a herp derp could herp derp.
Solstice Project's Alt
Doomheim
#92 - 2013-12-03 20:57:49 UTC
Abdiel Kavash wrote:
Solstice Project's Alt wrote:
Gameplay-wise, it seems that the vast majority of people use their groups of drones as a single unit,
which means that all groups of drones could behave as a single unit,
which also means that the server would only need to do calculations for a single unit.

So, uh, how do you propose shooting and killing drones should work?
That's ...

... hey, you're right.

cheers ! ^_^

Buy Solstice Project for PLEX4GOOD ! https://forums.eveonline.com/default.aspx?g=posts&find=unread&t=301266 (this alt-character will get deleted once the sale is done, on 6th of december)
tiberiusric
Comply Or Die
Pandemic Horde
#93 - 2013-12-03 21:02:54 UTC
Lets not get too excited, its not been deployed yet, proof is in the pudding so they say..

Anyway why couldnt you just have a node(s) per region?

All my views are my own - never be afraid to post with your main, unless you're going to post some dumb shit
Gerboah Cobon-Han
Garoun Investment Bank
Gallente Federation
#94 - 2013-12-03 21:16:26 UTC
Very interesting. Post more of these - a great insight into the innards

Fly Safe. 
Billy Hix
Dreddit
Test Alliance Please Ignore
#95 - 2013-12-03 21:20:13 UTC
I can solve this problem without all this math.

1 - Sell all Hilmars pairs of $1000 Japanese pants
2 - Buy every system its own server
3 - Take the rest of the day off, you have done enough
4 - Profit.
Abdiel Kavash
Deep Core Mining Inc.
Caldari State
#96 - 2013-12-03 21:30:50 UTC  |  Edited by: Abdiel Kavash
tiberiusric wrote:
Anyway why couldnt you just have a node(s) per region?


1) There are more nodes than regions.
2) Having adjacent systems on the same node is counter-productive (inter-node vs intra-node jumps)
3) Not every region is equally active.

The whole reason behind load balancing is to group systems based on activity: ideally you want to put equal load on every node. What you don't want to happen is one node handling two big fights at once, while another node is "managing" an empty region. It's much better to split the load so that each fight is happening on a separate node. Unfortunately it is currently impossible to move a system from one node to another when a big fight erupts. CCP is trying to map systems to nodes using statistical data so that, on average, the load caused by battles is equally distributed.

What's worse, you can't just do the mapping once and leave it be. With the political and wartime changes, which systems and regions cause more fights and therefore require more computing power changes constantly. So CCP is trying to predict which systems are going to be active during every downtime, and optimize the node distribution. For specifics read the blog itself.
CCP Explorer
C C P
C C P Alliance
#97 - 2013-12-03 21:32:30 UTC
Abdiel Kavash wrote:
I am slightly confused. You started the devblog by asserting that the old system was bad, because it put clusters of connected systems on one node (and intra-node jumps are more expensive than inter-node jumps). Yet you end up with a system that puts even bigger clusters of connected systems on the same node? From the pictures it looks like instead of constellations, now huge chunks of regions share the same node. Wouldn't that lead to even more intra-node jumps?
Before solarsystems were grouped into constellations for loadbalancing purposes and then constellations from very different parts of space were grouped together on nodes. But that provided a very strange TiDi experience and also the constellation-locality didn't match the load. Now we ignore the constellations and simply group the solarsystems together based on their load and actual-locality. That last part was needed to provide a sensible TiDi experience but since we ignore the constellation then the groups become much more sensible with even load. The final piece of this puzzle, the intra-node jumps vs. inter-node jumps we ultimately want to solve with Brain in a Box.

Erlendur S. Thorsteinsson | Senior Development Director | EVE Online // CCP Games | @CCP_Explorer
CCP Explorer
C C P
C C P Alliance
#98 - 2013-12-03 21:34:49 UTC
Setsune Rin wrote:
when was this fixed deployed or is it still in the pipeline to release?
We deployed the initial version a few weeks before Rubicon per https://twitter.com/erlendur/status/398211109922279425 and then an improved version will be deployed tomorrow.

Erlendur S. Thorsteinsson | Senior Development Director | EVE Online // CCP Games | @CCP_Explorer
CCP Explorer
C C P
C C P Alliance
#99 - 2013-12-03 21:38:44 UTC
One more thing to mention, as a part of this change then the cluster is starting up 2 minutes faster. See here https://forums.eveonline.com/default.aspx?g=posts&m=3897467#post3897467 and here https://forums.eveonline.com/default.aspx?g=posts&m=3899297#post3899297 for details.

Erlendur S. Thorsteinsson | Senior Development Director | EVE Online // CCP Games | @CCP_Explorer
GeeShizzle MacCloud
#100 - 2013-12-03 21:53:18 UTC
would love to see a heatmap of system load through a big fights escalation based on systems in the vicinity of the highest load over time... thatd be truely awesome to see.

and thanks explorer for the clarification! cant wait for Team Gridlock to crack brain-in-a-box!