Ideas on the fly: What I would do to fix Nullsec
Of course when I say “fix” I might mean “spay” or “neuter”.Ideas on the Fly
This is an idea on the fly. Please feel free to leave comments here, through EVE mail or Twitter.Background
Nullsec is, in my mind, the place for awesome large-fleet PvP with consequences. It is supposed to be about world-shaping at the players' hands. It is supposed to be about building empires and tearing them down. There should be drivers in place to encourage neighbours to fight each other. Where do you find the most natural PvP in EVE? PvP free of the fear of the blob? The place you can go to pick fights with some certainty that the people you pick a fight with are going to be committed to the fight, and you won't be surprised with massive supercapital fleets dropping on top of your battleship fleet? That place is Unknown space or w-space. What makes w-space different to nullsec? In short it is the difficulty of access and the inability to move large fleets through cynosural travel.From my perspective nullsec should be like w-space in some degree, but with the added risk of large fleets being moved into running fights with no limits, and the freedom of movement offered by star gates (stable wormholes which have been harnessed for the purpose of on-demand interstellar travel). The idea of massive fleet moving around via cynosural travel faster than sub-capital fleets can move using star gates just rubs the wrong way: it doesn't gel. Nullsec should also be the ultimate in player-driven content, to the point of world shaping. How much world-shaping is possible if players can't build and destroy the stuff that makes the world what it is?
So what is wrong with nullsec at the moment, and why does it need to be fixed?
First: reinforcement of a fight in progress through the use of cynosural fields is far too easy. A fight will escalate to capital ship fleets faster than it can be reinforced using sub-cap ships travelling through star gates. In short, the fight can be won simply by having more pilots online able to dog-pile a fight through a cyno bridge.
Second: far too much of the business of nullsec sovereignty involves static fights at very predictable times.
Third: for a game that purports to be a sandbox, nullsec has far too many rollercoaster rails in the form of fixed-in-stone stargates, inflexibility in player industry, and the inability to shape the world to suit player desires.
Rebalancing Cynosural Travel
Tweaking cynosural travel is necessary for two reasons: First, cyno travel is practically instantaneous; Second, cyno travel has far too great a range. These two factors combine to allow unreasonable "force projection" (at least it is unreasonable according to the forum trolls). Even without jump clones, it is possible to get ships from one side of New Eden to the other in tens of minutes (as opposed to requiring a day or two to redeploy). Thus any reinforcement timer, anywhere in nullsec, can potentially be greeted by the full force of all of nullsec's capital and supercapital fleets, regardless of where those fleets were stationed.More about balancing cynosural travel in my article "Fixing Cynosural Travel".
Removing Sovereignty Structure Bashing
CCP has already started the process of building mechanics for claiming and challenging sovereignty that don't involve structure bashing and reinforcement timers. The occupation mechanics used for Faction Warfare have been developed with a mind to expanding the mechanics to nullsec player sovereignty.So for the moment, I'm happy to leave it to CCP to know what they're up to here: implementing FW style offensive and defensive plexing, combined with “victory points” of some kind for blowing up other people in your space. Imagine if "treaties" of some kind could be implemented through alliance-issued charters for POSes: a renter will have to buy the treaties that the alliance members are selling.
I would like to see a removal of reinforcement timers as the underlying mechanic of sovereignty warfare. I recognise that reinforcement timers are a necessary mechanic for allowing pilots to defend critical infrastructure in this always-on game which we only participate in during our own play times. Sovereignty could be moved to an activity-dependent system rather than a structure-dependent system. But as I said, I'll wait to see what CCP is up to with Faction Warfare & "Sov Lite".
World Shaping (and Destruction)
How do we put the power of world shaping into the hands of players? Here's the core of my strategy: allow players to build and destroy stargates. On the way to that goal first, there are a few things that need to be sorted out.First, the range of all cyno travel should be reduced. Black Ops ships are at the appropriate level: people constantly complain that their range is not enough, but black ops are still actively used. This indicates that Black Ops are balanced. After Black Ops, the next furthest range should be given to carriers and dreadnoughts. Finally, Titans (and their associated bridges) and Supercarriers should have the shortest range. See my article about cyno travel rebalancing for more thoughts about the mechanics of cyno travel.
Second, the process of building, upgrading and destroying (or subverting) star gates must be designed from the outset to allow the installation of star gates in systems where no star gates are available: the mechanism must not depend on getting ships into a star system which will not fit through any available wormholes or jump bridges.
Third, the local channel should be put under player control.
Finally, nullsec industry needs some serious love.
Remove Local
Local chat is provided to most systems through the fluidic router relay system. In nullsec, it is the sovereign of a system who installs the fluidic router relay and controls access to local chat. Note that ships jumping into system through a star gate will be registered (but not necessarily connected) to the fluidic router relay by the stargate itself (but a successful hack might prevent the stargate registering the new ship for a minute or two).A fluidic router relay is of course hackable, so intruders can open it up to everyone or switch it off to everyone, delay the fluidic router registration process, or fake the deregistration of the hacking ship, up until the routine self audit system detects that something is wrong, alerts home base and resets the fluidic router to “last known good” configuration. Security conscious sovereigns might opt to install backups to certain features, such as a backup registration system which will be a structure (or structures) which ensure that all ships visible on grid are registered with the local fluidic router relay. Ships entering space through a wormhole may be able to delay registration with the local fluidic router relay, but only at the expense of losing all comms channels (which are accessed through the fluidic router relay).
Thus local as an intel tool is available to those who want it, but the fluidic router relay has to be installed and operational in order for Local to be available. Should this mechanism be extended to w-space too? Perhaps not: w-space is not just space-shifted but time-shifted too: how do you get a fluidic router connection to a place and time that you don't know? For the moment we have "magic" chat channels allowing pilots to communicate with each other in the absence of any communications infrastructure.
Now for Stargates
Stargates should be anchorable at certain points in a system which are determined by the intended target system. These points might require extensive surveys to be undertaken to determine gravitic contours. Subsequent to these gravitic contour surveys, the prospective stargate builders will need to identify locations of natural stable wormholes that can be utilised by the stargate infrastructure. Thus there are two distinct processes involved: a system survey which should take a coordinated group of players a week or so to perform, then the wormhole hunt which will essentially be a probe scan of the targeted area, similar to hunting down unstable wormholes.The survey and wormhole identification needs to be performed in both systems simultaneously. The process of identifying the suitable wormhole will require teams in both systems to “knock and listen” at all the wormholes they find: there might be a dozen candidates, only one of which is connected to the target system. This “knock and listen” process will require structures to be deployed around candidate wormholes, activated, and maintained while the “knock and listen” survey is completed. When a suitable wormhole is found, a gantry can be erected over that hole. When both gantries are anchored and onlined, communication between the two gantries will be established.
Once a stargate gantry is in place in both systems, the star gates can be built. In the initial stages of modifying space, all stargates will have infinite capacity for transit, so choice of stargate will be aesthetic rather than strategic. Star gates will be upgradable, with upgrades (and downgrades) taking an appropriate amount of time during which the star gate is still usable. Later in the development of this process, different star gates will provide:
- Transit capacity
- Fuel consumption
- Hit points
- Hacking difficulty
Some game design issues here will be the length of time that should be set aside for creating new star gates: for a rapid turn-over, perhaps the "knock and listen" survey could be done using modules fitted to ships, with the process of identifying linked wormholes intended to take in the order of an hour. For a longer turnover, perhaps a gantry would need to be erected, with certain fuel requirements to maintain the survey equipment for a week. What duration is appropriate?
Tollways and Access Rights
Star gates will also be configurable by the sovereign owner such that ships passing through the gate have to pay a toll, or may even have access restricted depending on standings. Gates will also be hackable, so that people of malicious intent might hack a gate to avoid paying tolls, or allow unauthorised ships through that gate, or even lock that stargate altogether so noone can use it.Hacking a star gate will provide some change to that gates behaviour for a period of time (say, half an hour). At the end of that period of time the star gate's self auditing mechanism will come into play, at which point the hacking attempt will be reported.
Removal of Static Resources
Remove static moon goo. Moon goo should deplete, with that resource eventually repawning somewhere else. T2 moon harvesters should extract resources faster, and multiple harvesters should extract resources faster. There should be sufficient resources on a moon that reports a resource available to allow a T1 moon harvester to extract that resource for about 2 months. Harvesters should not openly report what they are harvesting, but it should be possible to hack into any item of a POS infrastructure to see what that structure is configured for, what it contains, or any other details that might be of interest.Thus it should be possible to hide a highly valuable moon “in plain sight” as a CSAA POS, or perhaps even a jump staging POS. Spies will be even more valuable than before, as will black ops fleets sent out specifically to scout out enemy resources (or potentially valuable moons).
No longer will one be able to refer to a five year old moon survey and have confidence that certain POSes are harvesting particular resources.
Which brings us to nullsec industry.
