Player Features and Ideas Discussion

Basic idea is to have the server spawn instances to handle sov battles, using a new sov mechanic.

To challenge sov, you drop a new deploy-able in system, or retask SBUs for it. Only need one of them dropped and onlined by your alliance to challenge sov, its a single use object, and takes some time to online during which a defender could show up to destroy them. They show up on the overview and trigger alerts to the current sov holder.

If successful, someone with the correct roles in the attacking alliance must fly upto it and enter the attack parameters for the assault. This includes the time of day you'd like it to take place in, the system you'd like to base in and the number of instances you'd like to have spawned, between X and Z. X and Z are odd numbers, to be balanced by CCP to limit fight size, but lets say for this example between 5 and 21). You would have upto 24 hours to do so. The numbers/times you pick are upto you to reveal to anyone else. If you forget to do this, then, whelp.

The defending alliance upon being alerted can also have someone with the correct role to take the challenge, having 24 hours to do so upon the time of the SBU going online. They also pick a time they'd like to fight, the system they'd like to base in and how many instances they'd prefer, which is not revealed to anyone either. If they pick nothing, don't notice the challenge, or choose not to contest it, then that is their choice.

At that point, either 0, 1 or 3 fights are arranged.

If the attacker forgot to enter any times/instances, then nothing happens, the SBU disappears after the 24h time limit.

If the attacker enters something, but the defender doesn't, then 1 fight is spawned at a time the attacker chose, +/- a few hours 2 days later..

If BOTH sides entered times and numbers, then 3 fights are spawned, separated by some number of days. The time for these fights will be EVE mailed to the folks with the appropriate roles in both the attacking and defending alliances, and show up on the SBU like reinforcement timers do.

The first will take place two days later at the time the defender chose (+/- a few hours, wont repeat this again). A few days later the second fight will take place at a time of the attackers choosing. The final fight (if needed) will take place a few days later at a time of the defender's choosing. The number of instances the server will spawn for each fight equals the average of the numbers each side picked in secret, rounded to the next odd number.

The bases chosen could possibly be restricted to be within some proximity to the SBU'd system to prevent fast travel exploits (will make sense further down lol). They'd also be limited to null and lowsec systems.

That's the basics. Whoever wins the majority of instances on each day, wins that day for their side. Winning the majority of fighting days, flips the TCU to your control.


For the actual instance mechanics, that's where the bases come in. Each side picked a base, or if the defender didn't contest it, then the defender's base defaults to the system that was SBU'd.

Each instance will be a randomly loaded WH system, or arenas, or whatever CCP decides to make them, with 2 entrance wormholes connecting to K-space, I'll call them arenas here. Any size ship can enter these wormholes, there are no mass limits or other restrictions... they're basically gates that allow even caps/supers to move through.

Inside the Arena, the two wormhole entrances are in deep safes far apart, to give each side a chance to get setup if they move quickly. Somewhere in the system is the objective that must be captured. It will show up on the scanner overlay and can be warped to.

Dunno what the exact objective(s) should be, CCP can figure that out, or they can invent lots of different kind of arenas and you'll find out what you jumped into when you arrive inside the system (or send in a scout to each first, whatever). Orbit the beacon, hack the can, mine the roid, whatever. Doesn't matter as long as it has a win condition for each side. Different objectives could favour different ships/tactics, ideally.

Once the entrance holes seal up on the K-space side, you'll only have what resources you brought with you to the fight. That could include backup ships inside of carriers and the like. If you get podded, you're out, obviously. Any ship can leave at any time by exiting EITHER of the wormholes to K-space. Any capital ship can jump out to any cyno lit in either of the basing systems. Likewise, bridging could work to either basing system.

So that's about it. Your teams fight in each instance, and whoever wins the most instances that day, takes the overall win. If the defender contested, then its the best 2 out of 3, with the defender having the extra day of TZ advantage, although the first day of their advantage will be a bit more chaotic, as the exact number of instances won't be known until the first fight occurs (or spying reveals it to you).

If the objective for an instance is not completed within a certain amount of time, or a certain amount of time being uncontested, then the defender will win that instance by default.

So while you could try to dogpile and zerg through each instance with your entire fleet, you'd probably lose a majority of the instances if your opponent chose to spread out instead. Assuming CCP designs the objectives for the arenas that way, it should work out. If you're worried about lore reasons and such, these don't actually have to be other entire star systems, they could just represent control points surrounding a solar system.. its defenses or what have you. At its simplest example, each arena could represent a battle station you have to capture, like in FW. There would just be more of them, and could be spread to different nodes, limiting TiDi and encouraging smaller fights without hard coding it.

The game is already instanced.. they're called systems. You can't fly from one system to another, you have to be magically teleported there by a gate, WH or by jumping to a cyno.

CCP will never implement instancing. If you ask a marketing guy what eve is the first sentence you get will be "eve is a single sharded sandbox..."

Its a major bullet point what defines eve. But don't worry, there are several options how to fix the problem differently. Key is to parallelize the whole show.

Instances won't happen, whats left? Multithreaded servers or proper distributed systems (multiple servers handling one system) probably won't happen too since CCP is stuck with stackles python and a lot of legacy code. Other options? Sure, game mechanics to distribute peak server loads. For example require multiple fleets in multiple systems (in parrallel) to flip a system. And you even could sell it as null-sov rebalancing expansion.

This idea basically is, instanced grids with individual objectives to all combine together to determine victory. It just gets around the problem (as I understand it), that instanced grids aren't possible.

The idea is to make multiple simultaneous objectives when attacking sov, taking place on separate server nodes in order to limit TiDi and hopefully, eliminate node crashing in large sov clashes. Almost like spawning 20 FW type plexes in the system at once, and the side that wins 50%+1 takes sov.. except to save the node, the plexes are simply hosted on different nodes.

As for 3rd partying, this idea handles that fine. The only thing the actual attacking and defending alliance HAVE to do is pick a preferred timer and number of arenas. As long as CCP designs the arena objectives correctly, there will be a defender and attacker win condition, but won't matter WHO actually does the attacking or defending.

A simple, if unimaginative, example would be a structure that starts at half HP. If it gets repped to 100% it turns invulnerable and the defender wins that instance, if it gets destroyed, the attacker wins. Doesn't matter what alliance is repping or shooting it, the only thing that matters is the final result.

Another might be hacking a structure for some amount of time (any damage would disrupt it). Upon success, a popup appears to the hacker to choose who to claim the structure for.

There are no tech solutions to the actual problem, they are only band aids like TiDi was. As long as the game is designed in a way that encourages large blobs on a single node, the blobs will only get bigger to fill any lag available.

Yes, you could use objectives in multiple systems instead of this, but it doesnt scale well, or make much sense unless you remove the idea of single system sovereignty entirely.

You could have constellation or regional sovereignty instead, and have objectives spawn in each system involved. That could work, but it would chop up the map into even fewer conquerable blocks. However, you're still left with the problem of a fixed number of targets, but at least it would be more than one. A much more robust design is better though, since who knows what the future holds. If EVE's population (or nullsec pop) doubles in a year or two, you'd start running into TiDi fights on a constellation level (if not already, with 4000+ clashes spread over 8 or so systems. Its unlikely that CCP will have a couple dozen server nodes just set aside so that each system in the constellation will have its own node. After all, there could very possibly be multiple constellations under attack across different areas of nullsec at the same time.

i am convinced that there are technical solutions to mitigate the problem. The anatomy of a fleet fights is that you always try to focus fire on very few targets. Thats a fairly easy parallelizable tree structure. But it would require a rewrite of most of the core server logic, using concurrency frameworks. Eve is not Star Wars where every little fighter is fighting a random other fighter - which would indeed scale very badly and would be very difficult to distribute (-> star citizen is instanced out of the box).

Its just a matter of how much resources CCP wants to spend on the problem. Having legacy code in single threaded stackles python is not a unsolvable situation. Big systems are rewritten everywhere in industry.



concurrent users online is fairly stable if you look at the graph. The problems start if 10% of all users try to meet on one system, which means one server and also one core. Its the worst case scenario for the current architecture. Now imagine you could reduce this 10% to 5% or even 2.5% by splitting those huge battles in two or four battles. You suddenly are using the eve architecture as it was intended to (scalability by adding more servers to the cluster) - and all you did was to change game mechanics.

There would be nothing stopping you from bringing any amount of ships to the fight. The fight would simply be split up into different "wormhole arenas" simultaneously... These would not be locked or closed either, so if your particular gang went into one, were having problems, you could always ask for help from someone in another arena. They could leave theirs to join yours, and vice versa. I'm sure that'd be some of the tactics.. try to win as many instances as fast as possible, then pile them into the remaining ones. In the end, you need to win in 50% + 1 of the arena fights. You could even re-ship if you die, and go back into the fight.