TLDR :
When incoming ships may overload the grid, create multiple clones of the grid; each with a 'beacon' and a weakened objective. Original target dies when a sufficient majority of the objective clone grid targets are destroyed.The scenario
- There is a fight over some object with a re-inforcement timer.
- Very large fleet A arrives on grid early. TIDI happens.
- Very large hostile fleet B arives on grid later. Server starts to whine. TIDI breaks and issues start to happen.
- Reinforcement fleet (from whatever side is losing) arrives and tries to crash the server.
The plan
Each clone of the original grid would have a version of the original structure, with less HP. Each grid is hosted on a dedicated hardware server. Compromises are made such that anything not essential to the current fight is ignored. Local for example could be pilots on grid and disregard pilots elsewhere in the system.
The initial move to the grid will be a 'recall drones/fighters/probes'/emergency warp to the new grid. As part of this warp, ships are moved to the new server. Ships are pointed for an arbitrary time (say 15 seconds). Already on grid ships are moved to grid #1. The new fleet is moved to grid #2. A grid #3 without ships is created.
There are now 3 grids, each with 1/2 the original HP (shield/armor/hull). The attackers must destroy their target object on at least 2 grids. If the attacking force leaves a 'defeated' grid undefended, the defenders can run behind and repair.
A 'beacon' would mean it can be warped to by anyone in 'the system'; assuming there is capacity on the requested grid. Ships/squads/fleets can still request to warp to the beacon for another grid; but will only be accepted if there is room (some TIDI is fine; risk of soul crushing lag is not).
The POS question. Assuming it a POS is being attacked, any array inside the forcefield would be available to all instances of the POS. Any POS battery outside the forcefield (i.e. batteries) would be randomly allocated between grid clones. On/Off lining a module inside the array would affect all instances of the POS. On/Off lining a battery would affect the powergrid/cpu of all of the POS instances.
Reinforcements would be handled in a similar manner, with a new grid created (and further reduced structure HP) as pilots start to overwhelm grids.
In order to concentrate pilots into the same fighting zones, preferred access would be granted to pilots on a grid clone over pilots out in general space.
The goal
Very large fights around a defend-able object that scale regardless of how many pilots are thrown at it. Dynamically increase the number of 'objectives' according to fleet sizes. Each objective is hosted on it's own 'reinforced server'.Other notes
What we know:- Double the number of ships, and you more than double the server workload.
- Even with Moore's law there is a limit to the server increases we can get. Also Moore's law is looking shaky.
- Alliances will add more pilots to big fights until the server dies, for as long as that works.
- The losing side will claim it wasn't fun.
- The winning side will (usually) claim that CCP did the best they could on the day.
It requires Brain in a box as a pre-requisite.
The next battle of Akasi would be it's own problem. But even that would benefit from the ability to dynamically be shifted to a dedicated server solely looking after the fight.
This is a thought exercise. The numbers are unbalanced in some way. Build a bridge (and get over it). Adjust as necessary the number of grids; the % HP for objective structures on each grid; the % of grids required to be captured. The point is to cause the attacking force to have to move, and for a defending force to repair behind them as necessary.
I also like Vonkeigai's solution : "You mongrels, You overloaded the grid, and made some poor CCP schmuck work overtime. Said CCP schmuck is going to randomly break stuff until some of you just go away. More pilots MOAR DAMAGE. Die ungrateful capsuleers, DIE!!".
Put a gas cloud into each grid. The higher the TIDI, the more general damage done. Damage could even be proportional to signature.
Further reading
- http://jestertrek.blogspot.com.au/2014/01/soul-crushing-lag.html
- http://treborofthecsm.blogspot.com.au/2014/01/the-cold-equations-of-soul-crushing-lag.html
- http://vonkeigai.blogspot.com.au/2014/01/fleet-crushing-lag.html
- http://evenews24.com/2014/01/21/ccps-reaction-to-petitioned-ship-losses-in-hed-gp/
- http://greedygoblin.blogspot.com.au/2014/01/eliminating-soul-crushing-lag.html
Disclaimer.
The only structure grinding I have done in game is POCO and the POS bashing (and most of those were online). My assumption is that most big fights are over some form of reinforcement timed structure; with massive HP.I do work as a Business Systems Analyst, and have spent many years as Systems Analyst working with very large datasets and number crunching problems. If its too big to chew through in one sitting; cut it up first works.
Before split
The problem is alpha. If you split a slowcat fleet into half, you get a half-as-strong slowcat fleet. If you split a Maelstrom fleet into half, you get two heaps of useless garbage as they can't alpha down anything.
ReplyDeleteThen the metas changed. Change is good in this case.
DeleteThe choices I still see are : node crashes; split objectives on different servers; or hard limits (and finally - Gevlon's proxy pilots).
ReplyDeleteI asked a null resident in our corp to pull apart my idea; he thinks I am .... better off sticking to wormholes and PI.
His main concerns were about the technical difficulties in ... stuffing around with grid mechanics and off grid boosting. With still being able to lob bombs in from off grid; all things that the above proposal would throw out in order to keep the servers stable.
However, his method of solving this was to "rework sov so that you need to hold multiple system at the same time"
It would still involve splitting fleets, but would require less 'clever' coding. (clever coding tends to bug filled and breaks when looked at too hard).
My concern with the multiple systems approach is that it would potentially stretch the resources of small groups fighting it out, but even that is solvable.
I think having big fights is a good thing even if though I'm more of a spreadsheet based carebear than Foo.
ReplyDeleteUnfortunately, I don't really see most of the proposed solutions actually being worth implementing.
Some points:
Sov mechanics are largely irrelevant here, for the most part they act as catalysts for the big fights rather than as actually being an integral part of the fight. Furthermore, everyone wants those big fights.
In most cases the actual fight is between fleets of ships. Which means that the number of passive entities on the grid is small. Maybe one fleet is trying to destroy your big reinforcible object, but usually rather than trying to repair it the other fleet is trying to destroy the attacking fleet.
For this reason, splitting the active fleets in the manner you suggest would be difficult to do. Furthermore, as Gevlon suggests, when you change the sizes of the fleets then the effectiveness of certain ships can suddenly change.
Removing participants from the fights by ghosting there contribution is not likely to be seen by CCP or the players as a viable solution because it effectively reduces the ghosted players to being a passive entity which no-one really wants.
The biggest complaints about the HED fight was the loss of agency. For whatever reason many of the ships got into the state where they could do nothing, but were considered valid targets for the rest of the game. When that happens in eve, generally CCP will normally fix it, or declare taking advantage of such a mechanic to be an exploit.
This is why TIDI was a good "band-aid" fix to the problem of game lag, with the whole game slowing down everything still worked as expected, it all just ran much slower.
With the recent crashes / lagging the battles have escalated beyond the artificial 10% limit that tidi can handle (arguably changing this limit may be the best thing to do in the short term). Which means that the things no longer happen in the expected way. As Trebor points out, the current drone heavy meta seems to put additional stress on the servers. which means that this point is easier to reach than it was before.
Perhaps in a perfect world the answer would be to multi-thread the grid calculations. Doing so is a non-trivial task. It also may lead to some interesting decisions. How much of your universal processing pool do you dedicate to a single null-sec fight. Is it worth giving everyone else tidi so that the null-sec blocks can add a few more ships to the big fight?
I don't really have a solution. I'd make changes to alter the meta and I'd allow tidi to further slow things down.