A way to assist TiDi (for citadel battles at least)

structures
game-mechanics
redesign

(Old Pervert) #1

(edit: removed some superfluous text that was not important to read)

Obviously, the problem with things like the recent 9-4 battle is the number of people. There’s no amount of server horsepower in the world that can keep up on a single node when you’ve got >5000 people in a system.

In all cases, the issue here is not scale-up but scale-out. They’ve scaled up as much as they can with some truly boner-inspiring servers… now we need to scale out.

In a nutshell, this means distributing the battle. Multiple grids. Distributed concurrent objectives. Each objective by itself not enough to ensure the battle is a foregone conclusion (save for the citadel fight itself), but together becoming important cogs of the fight.

Consider the following game mechanic for a citadel. All control points are off-grid and in different quadrants of the system (which could be run on separate nodes - this is where the coding comes in).

The Repair timer would work exactly like it does now, the DPS cap would work the same as it does now.

Except:

  • A “Repair control point” in system capable of dramatically slowing the repair timer. A significant amount… 3-4x the duration if the attackers control it. No effect for defenders controlling it, save for having a “normal” repair time. This is because I think that shorter than current would be detrimental to game play. If the default duration were made longer this would allow for defenders to shorten the timer.
  • A “DPS control point” in system . EDIT: The defenders controlling would reduce the max cap and increase the minimum cap (required to pause the timer). The attackers controlling would reduce the min cap and increase the max cap. Net result, attackers controlling can keep it paused easier and kill it easier, defenders controlling makes it harder to keep it paused and kill
  • A “CIC control point” (command information center) providing the controllers of the node with a system-wide beneficial phenomena. Say for example a 10% increase to shield, armor, and hull HP.

The net result of this is that all of the “control points” become optional. You can ignore them. But you won’t want to. Small fights are unaffected because all of the objectives are optional. The larger the forces are, the more they’ll be able to spread out to take control of the objectives and influence the battle in a meaningful way.

You’ll obviously have attackers and defenders hitting the structure itself. This ultimately means that in the case of a 9-4 situation, you’ll have 4 major battles happening instead of 1. That “5000 person problem” just got reduced to a “1250 person problem”. Given that computational problems are compounding, this could be a HUGE boon for the fight… you might still have TiDi but you can reduce the harmful effects dramatically (like people who couldn’t reload their guns for 20 minutes, or people who spent 30 minutes trying to log back in after they got DC’d).

The design intent is to have each of the 3 control points provide an extremely useful but not essential bonus, with each bonus being desirable but not essential. None should be inherently more desirable than any other, and each should be balanced according to their impact to the fight. The exact numbers I used were an example.

Thoughts?

EDIT #3: The phenomina effect would be based on tether rights. If you can tether, you are a “defender”. If you cannot tether, you are an “attacker”. Even if a third party is in just shooting anything, they’d be considered attackers as they’d be liable to also shoot the structure.


The 9-4RP2 Collusions
Practical options for EVE performance issues
(Este DeStirr) #2

When you say “control points” are you thinking FW-style circle-the-beacon-for-long-enough, or something different? I’m trying to imagine what would require 1250 players to break off and attack/defend?

I’m wondering if a large/XL structure’s repair timer be linked to an in-system Engineering structure, for example? As long as there is a “linked” repair structure, the main structure’s rep timer is intact? Perhaps the linked structure has to fit a Standup Remote Repair Module which maintains the main structure’s repair ability, and can have its affect system-wide? Then in order to finally kill the main structure, the repair structure must be killed (and obv the timers etc for repair structures would have to be different somehow)

Just some off-the-cuff thoughts.


(Old Pervert) #3

My first thought was something with a UI that you access like an ESS. You have to fly into a bubble to interact with it, it takes a time to interact with it, and then you can flip the toggle any which way you wish. Allows for third party shenanigans to take place.

Regarding the 1250 players, I anticipate it would be much more fluid. You’d probably see it more as “we’re breaking and we need reinforcements from one of the other control points”. Either way, the goal would be to cause 4 different fights to happen. I anticipate it would look a lot like the “resource wars” you see in other MMO PVP battlegrounds, where you control nodes to score points with the winner scoring x points first.

Where it gets interesting is that capitals aren’t very mobile. You can deploy and move them, but that’s a major issue, because they just aren’t very fast. Subcaps aren’t very useful against keepstars, for example, but these control points they’re going to be essential for rapid response.

I thought about something like that, but I wanted it to be the same mechanic for all structures… avoid confusing the playerbase as much as possible with differing mechanics for differing structures.

I also wanted to avoid any “hard-counter objectives”… the goal with each of the control points for example was to have each provide a bonus that wouldn’t matter if nobody went for it. With the timer being linked as such, you’d HAVE to go for it. Which is fine in a big fight (and you did say L/XL structures) but for small fights it’s definitely going to draw complaints.


(Lady Ayeipsia) #4

Problem is… I don’t think a system can be spread across multiple nodes. In other words, having 2 2000 man fleets battle at the sun is no different than having 20 200 man fleets, one at each planet in a 10 planet system.

I believe this is why we have jump gates and the related delays when jumping. That is time for the server to move you from one node to the next.


(Gadget Helmsdottir) #5

Coming from a non-IT here person here, but I do study systems in general, so I’m gonna ask anyway.

Why grids?
Isn’t the whole (solar) system affected, and isn’t the system reinforced if CCP is given a heads up?
I read server, but what does the special server… serve, a grid or the whole system?

That’s the main crux of my confusion. If it’s just the grid being bolstered, then this idea might work.
However, if the whole system is in question, then spreading around objectives within the same system wouldn’t alleviate any pressure.

Also, another concern. If there are multiple structures belonging to multiple corps, do you have one set of secondary objectives, or does each structure also have it’s own set?

–Curious Gadget


(Old Pervert) #6

I agree. It would require a re-code, potentially allowing multiple nodes to control different quadrants of the system. Regarding session changes, I think the impact would be quite a bit less if the load were spread out… it’s not like how it was a long time ago.

Consider for example, the difference in session changes when undocking from a citadel. If you’re on inside view, undocking takes quite a bit longer. When you’re on outside view, undocking is actually quite quick because the client already has resources loaded. The hand-off to the node is minimal.

Yes you’re liable to overload it and cause things like rubberbanding and traffic control, but those were already problems. Plus, players who are in warp to reinforce other players at different points are not actively contributing to the server load, which further reduces the stress on the server.

This has not to due with IT at all, it’s an in-game concept.
https://wiki.eveuniversity.org/Grid

The overall concept is that you can force the players into areas where they cannot affect each other. Once they cannot affect each other, you make it possible (with coding to make it possible from CCP’s side) to put different groups of players in the same system on different nodes.

Edit: I got click-happy and posted before I answered your second question.

I’d see these spawn for each structure, only while the structure is vulnerable. They’d spawn the same as toaster nodes do now, in separate corners of the solar system (deadspace, semi-random) so that you could not pre-stage at one.


(Gadget Helmsdottir) #7

Thanks.

I’m aware of grids in game from just playing, but I’ve always been a bit fuzzy on the relationship to the servers.
Nodes.

I’ll give this a deep dive when later.
Thanks, again.

–Appreciative Gadget


(Old Pervert) #8

I figured… you’ve always had informed opinions in the past. Mostly posted the link to ensure anyone else with the same question could read up on it.

A “node” can be thought of as an arbitrary “chunk of space”.

When they reinforce a node for a big battle (like 9-4) they are in effect taking just the system of 9-4 and putting it on a single server by itself, where normally 9-4 and an arbitrary amount of systems (for example that entire constellation) reside on a server together.

Under normal load, they consolidate the workload onto servers because the servers are easily able to keep up. When a huge battle happens, they need to devote as much horsepower as possible to the smallest amount of size possible number of players possible (edited).

At least, that is my understanding.

In essence, this solution is two-fold. First, CCP must re-code to allow for smaller chunks of space (quadrants of a system) and then find a reason to spread players out into said smaller chunks, where the scale-out will be effective.


(Lady Ayeipsia) #9

The new nodes would also have to be able to communicate effectively when dealing with objects that impact travel between nodes. If I launch a disrupt probe at node A, node B and C must recognize this act and adjust accordingly. You would also have to plan very well for boundary interaction.

Back when grids were small, Rooks and Kings did a nice video explaining some of the edge grid fu tricks people could do. One was dropping a bubble so it overlapped the grid edge. Those landing in the bubble who were on the wrong edge would not be able to warp (being trapped in a bubble) but could not see the bubble. Then the bombs would come… Scary!

So this would all need to be factored in.


(Este DeStirr) #10

Could be along the lines of “support nodes decloak during vulnerability”


(Old Pervert) #11

Absolutely… but I think that would be easy enough to handle. It would already require a re-code as the hand-off is no longer gate travel. But if a node hand-off could communicate a warp vector, it would definitely be feasible.

100% agree. There’d be some technical details to hammer out, but I believe that they really would not be too bad (certainly less workload than just having 5000 people in the same grid fighting over a keepstar lol). I am not CCP so I don’t know just what their code looks like, but it really doesn’t feel like such a hand-off would be hard to provide the needed information to.

Absolutely.


(Mothre) #12

I really like this idea, the first thing is that it shifts the combat style from a seige a fortress style to Nepolianic - WWI style of “hold the line”. You can do a lot of damage by breaking the other guy’s lines, and so it would require larger fights to hold solid.

The renforcing rtructure doesn’t really do this, in many case it would just make more of a two-stage fight instead of a spread out fight, especially for smaller battles.

On the technical side of things:

A node will, whould, and should have limited interaction with any other node. That isn’t a problem, but there would be some trade offs. But since CCP normally has a warning before big battles like this, and the system will be in it’s own enviornment, it can have some special rules. Only for battle systems, not normally, each grid could become its own node, with some sort of system-wide “observer” node (let’s call it the main node).

The main node should know the location and status of all the sturctures, bubbles, and each of the grids. It would handle things system-wide and between grids. Warp between grid nodes would become the session change. This woud lose some things like d-scaning of anything not on your grid or warpping. But when there are 5000 objects in the system maybe this is an ok tradeoff.

Each grid being it’s own node would allow them to move to different servers based on load, and let each battle stay more reasonable.

This would need new coding of a dynamc multi-node system, but would have little impact on anything else in the game. One problem would be when does CCP switch a system to a multi-node system as it would affect intel gathering.


(Old Pervert) #13

I’ll leave it to better programmers than me to say whether or not it’s actually possible, but my belief would be that nodes must be pre-instantiated at downtime. A “dynamic node per grid” approach would certainly help, if such a thing were possible, but… I don’t think it’s possible myself. I suppose some kind of forking process might work, shoving the workload off to someone else. Hmm.

Regardless, as a concept this is exactly what I’m talking about (just muuuuch more scaled-out than my OP lol).

The hard part is breaking the Eve doggypile mentality. I’m not sure you’d end up with more than 4 grids (you’d probably have fighting on gates too I guess, but those can be on-grid with the citadel)… the control points would specifically spawn far away from each other to help encourage players onto different grids. Plenty of action all-around.


(Mothre) #14

I don’t know that I’d count as a better programmer, I hate writing code, but I was a systems/process/db designer/architect, so I could be wrong, but I have some good guesses how things are working behind the scenes.

I don’t think grids are an in game only thing, they are on the same server node, but they are already doing a lot of load ballancing work. I imagine that your client is unaware of ship movements in your system butoff your grid. It doesn’t make any sense for that data to be moving around to each players client. You are however receiving all the data about the movements of each ship on your grid. D-scan works by polling the node for the location of everything in the system, thus breaking the limiting broudries of the grid. I am almost certain there is some level of grid isolation, so this idea woud just be isolating it more, in special large battle situations, to allow it to run on different physical hardware. Each node wouldn’t have to be on its own server, servers could still host multiple nodes, but they could easily be moved as needed.

Devs vs users doing stupid things? It’s this the life long battle of all devs: making things foolproof vs the universe making better fools.

I do think downtime is the right time to transfer the system to a multi-node system, but if this effects intel then it would make a big diffeence if the fight starts at 10:00 or 12:00.


(Old Pervert) #15

I agree, they’re probably limits imposed in order to reduce load. And I’m pretty sure nodes are all hosted on VMware servers until they need to get pushed onto one of The Big Ones lol. So I agree, in concept, the scale-out is always possible.

The only hard part is the dynamic part. I’d imagine that “grids” are waaaaay higher up on the stack than nodes, and it’d be a whole different ball of wax to spin up a new node on-the-fly every time someone lands “somewhere”.

I’m a network admin… the number of times my users have made me contemplate murder, alcoholism, and self-harm is alarming. In the war between devs and the universe… bet on the universe. Stupid wins every time because it is often beyond any reproach.


(Mothre) #16

I image CCP is playing with nicer toys than VMware, something more like compute nodes, but your point still stands.

Yes, nodes would be much more to spin up, but that doesn’t mean you have to spin them up when someone lands. Empty or even unasigned grid-nodes could exist just waiting to be used, something like grid-nodes = active grid-nodes + 3. Then a node gets assigned and used when someone lands on it, and a new one is spun up in the background.

My concerns would be things like which node are you on mid-warp? The main node? How is the node transition handled when you enter and exit warp? What things would need to be system level instead of grid level? Although if grids are working like I think they are, CCP already has this answer.


(Old Pervert) #17

Hey now… ESXi Enterprise Plus is pretty fantastic stuff. And I’m pretty sure I read that their nodes all run on esxi servers, so that when they need to do maintenance they can just vMotion off to different hardware.

That’s the thing though… space and pilots have to be associated with a node. When you land, you’re on a node. As soon as you amp up the load on that node (cyno in 100 caps at a safe), splitting a chunk of load off to a new node (hostiles are on a different safe, same node) would be very expensive from a resource standpoint. That extra workload generated would definitely be detrimental to the user experience.


(Mothre) #18

Yes, cynoing 100 ships is going to have a hit on the grid, but this already happens when you jump systems. I don’t know if EvE keeps all the systems “up” all the time, I would imaging not. I would think the system gets created from the database only when someone jumps into it. This creation of the system is a preformance hit, but not normally noticed for the one person jumping in. But, if the system were already up and running but empty this would be a smaller hit.

So, CCP could spin up empty unassiagned grid-nodes. They are already running process, so they don’t have the server load of being created. But, they haven’t been assigned a place in the system and known to the main-node. Then when a jump is landing on a grid not in use, one of thee grid-nodes gets centered on the landing spot, tells the main-node where it is, and recieves the jumping ship(s).

Jumping a lot of ships will always have a load cost, but creating the grid doesn’t have to be part of that cost.

Edit: in this post “system” is solar system, not server.


(Tiddle Jr) #19

I’m worried how the system gonna split 5000 pilots in different ships. How the system dermine ‘friend’ or ‘enemy’ what if my 250 man hand would face with 1000 hostile armada and vice versa. How they gonna manage launched small objects.


(Krysenth) #20

In what way is this suggestion remotely better than the thought of CCP choosing to invest in resources to allow them to reinforce nodes far more strongly than they can now? (something eons easier to do that this coding ****fest you’re talking about)