This is a re-print of the article, “The New Sov: Collected Feedback” by CSM X member and Get Off My Lawn <LAWN> Chairman, Thoric Frosthammer, reproduced here with his permission. It is an opinionated piece, and in no way reflects the opinions of TMC, or any of its Editors.
Maitre D’: Your usual table, Mr. Christopher?
Customer: No, I’d like a good one this time.
Maitre D’: I’m sorry, that is impossible.
Customer: Part of the new cruelty?
Maitre D’: I’m afraid so.
I spent some time last week going through various sources, Reddit, feedback threads on Imperium Coalition comms started by Reagalan and Endie, feedback given to me personally or within my alliance. As I did, definite patterns emerged. This doesn’t purport to be a complete survey of every complaint or comment about ShinyPixieLaserSov, but I think it summons up the most common and pressing issues. I’ll be injecting some of my own opinions into this, but I’ll try to clearly mark them off against the feedback. I’ll also credit Jayne Fillion for helping formulate and focus some of the issues presented here.
I. Specific Issues with Current Gameplay
1. Entosis modules on small, fast ships, and particularly interceptors, allow for a high degree of trolling by aggressors, without any commitment of forces. Nullification is particularly problematic because it allows them to travel to their destination with little chance of being stopped, and renders borders extremely permeable to hostiles. This forces an asymmetrical defensive obligation onto the sov holder, who has to spend hours indexing such systems, and frequently hours on entosis timers.
Commonly Suggested Solutions: Several suggested, including entosis links turning off prop mods or rendering a ship immobile, but remote repairable, thus both forcing fights if the attacker wants to proceed and allowing the ship to be properly defended. Alternatively restriction of links to certain ship types, such as battlecruiser or above. The mechanics of entosis should encourage fights on a grid for superiority, not trolling or kiting mechanics.
My Solution: I believe that entosis links should somehow limit speed via some method, or be limited to slower ships (I am agnostic as to which). I strongly feel that whatever option is chosen should eliminate entosis on nullified ships, and perhaps prohibit fitting a cloak. This puts skin in the game for the attacker and means that entosis becomes a matter of grid control, and not simple trolling.
2. Frequently, aggressors have not made any effort to follow up on their attacks, presumably because they were intended to troll for effect and require a response from the sovholder. This leads to burnout, and frequently, systems will remain uncontested by either side for days or weeks. Sovholders should not have to respond to false threats, or an attacker who is not willing to commit to a fight. Simple griefing of this nature will lead to sovholder burnout and lack of desire for sov.
Commonly Suggested Solution: Decay of nodes to a safe state for defender after the end of the scheduled vulnerability window. Several hours should be sufficient for a serious attacker to press their attack.
My Solution: Yep, i’m in favor of some method of node decay. I’m willing to discuss length, but there are an awful lot of systems where no one is bothering to contest right now. The onus should be on the attacker to press their attack if they really want the system.
3. The nodes are excessive in number and spawn very slowly. In the event where no one contests a timer, resetting or saving the system still takes an unreasonable amount of time. The few contested fights have been lengthy, and have not received positive reviews, as they were limited largely to interceptor solo fights. Most fights, as discussed, were uncontested.
Commonly Suggested Solution: Reduce the number of nodes required for victory, either as an absolute, or linked with index so that heavily used systems require fewer. Spawn all or most of the nodes close to the beginning of the fight so that redeeming a system where the attacker fails to show up is quicker and more painless. If either the defender or the attacker is in position and ready at the beginning of an event, they should be rewarded for their diligence.
My Solution: I’ve actually sort of fallen in love with the “tennis match” solution some folks have been pushing on Reddit, and that was discussed on the Metashow this weekend. Basically first to 5, win by 2. I think it would work really well in this context.
4. Vulnerability windows every day turn sovereignty into an unpleasant job, even for large alliances. The windows diminish or eliminate opportunities for play outside their own sovereign territory because leaving their space leaves them instantly vulnerable to attack. This problem is exacerbated when the entity is smaller. The vulnerability timers are intended — by design — to be during their prime time. Smaller entities will likely have one major time zone. Thus, the members must reside in its space during the entirety of their usual online time. This will be a larger problem in lowsec and wormholes entities for structures particularly due to their generally smaller size.
Commonly Suggested Solution: Reducing the lengths of the vulnerability windows significantly for higher indexes, so that you rapidly gain a greatly reduced window at ADMs higher than approximately 2.0, the basic ADM at strategic index 5 with no other indexes. Additionally the entosis of station services outside of the alliance window has proven to be an annoyance rather than a content enhancement, that leads only to griefing, particularly for smaller entities. It should be removed and folded into the vulnerability window.
My Solution: I strongly believe that the new vulnerability system included in the Structure blogs should be pushed to ALL sov structures ASAP. It allows alliances to create the space they need to take a day or two off and go cause trouble in someone else’s space, thus increasing the potential for conflict. If all of us with similar TZ windows are stuck defending our sovereignty at the same time, the only people left to conflict with are the occasional roams or trolls.
5. Currently, if a structure is partially hacked, but the attacker then leaves or is chased off, it remains vulnerable past the scheduled window, unless someone flies there and manually fixes it. This mechanic, like others in this system, places burdens on defenders without requiring input from attackers.
Commonly Suggested Solution: When the vulnerability window closes, reset the structure to a fully defended state, and make it invulnerable, unless there is an active link on it at the time.
My Solution: That, pretty much.
6. Activities carried out by sovereign entities are not captured by the indexes, and the entities are required to engage in two of what are widely considered the most boring activities in the game, ratting and mining, in order to defend their space, rather than taking into account manufacturing, refining, research, market orders, PI, PVP kills and other activities that legitimately represent activity.
Commonly Suggested Solution: Find ways in the near future to capture these activities significantly within the indexes.
My Solution: Again is perfectly in tune with the most commonly suggested one. I will give credit to CCP here and point out that they have acknowledged this issue, and stated they will iterate on it. It’s not easy, some of these are pretty gameable unless the approach is careful.
7. Under the current mechanics, it is currently impossible to offline or unanchor both the TCU and the IHUB. Additionally, it is currently impossible to remove, destroy, or deactivate upgrades. This prevents the transfer of sovereignty between entities.
Commonly Suggested Solution: Implement these mechanics as soon as possible.
My Solution: This really needs to happen as soon as possible, please.
8. The information given in notifications should include who is attacking the structure and what they are flying. This has been a basic feature of EVE forever, and that information allows defenders to plan, and eventually seek retribution, which is the sort of interaction the game needs. During capture events, it is difficult to tell who is entosing any given node. Finally, an alliance has almost no way to tell that a sovereignty structure has died other than the fact is is missing from the alliance sovereignty window.
Commonly Suggested Solution: Add information to the notices regarding the identity of the entosing ship. Add an ESS like notification to fleets when one of their members is entosing a node, so that FC’s can track the event’s progress more easily. Add clear notifications that a structure has died.
My Solution: Once again, yep, this, please do this.
9. There is little or no role for capital ships under this system.
Solution: Various solutions have discussed but none are widely accepted. This is a difficult issue; for Supers and Titans there is some consensus around making them less powerful, more agile, and less expensive, with some inclusion of a subcap role, but others strongly oppose this. A third line of thought says they should be removed entirely.
My Solution: Hell if I know. I do think that if they don’t come up with something soon that seems credible, they should just work on taking them out of the game entirely. CCP have acknowledged they are actively working on this as a priority, so we’ll wait and see what they come up with.
II. Larger issues regarding desirability of sovereignty
1. The general consensus among players is that the Aegis sov system has tilted the odds too far in favour of the attacker and that the raw number of manhours required for a defender vastly exceeds the number of hours required of attackers.
2. This feeds into a general perception that the risk/effort is greatly in excess of the rewards of sovereignty. There are almost no unique gameplay aspects to sovereignty beyond simply planting a flag. The income that is made available to players who live in sov nullsec is currently subpar compared to other activities such as incursions, faction warfare, L5 missions, or capital escalations in wormhole space – and only after a significant investment in both time and money. The optimal method for making a living in nullsec frequently includes alts in other areas of space.
3. The rewards that are available are not tied into the combat system and do not encourage combat. Income arises from being left alone. The most profitable playstyle is to group up into vast empires so that no one can attack you, and you are well protected enough to make an income uninterrupted. This leads to dissatisfaction with the number and quality of fights. If you want more combat and interaction between players, there should be rewards that directly encourage combat.
4. Due to the density requirements of the current system, it both requires and rewards larger entity formation. In order to have space that is safe enough to support the PvE playstyle required by the index system, a group must expand or make peace with neighbours. Additionally, the PvE players themselves result in further growth. The system’s current obvious end state is the N+1 growth of coalitions. Formed entities should still have a reason to fight amongst themselves even after their empire has been built and established, including scenarios outside of an invasion or scorched earth war.
5. With the introduction of the Phoebe jump mechanics, the game has gotten too large for the current, and decreasing, population. There is little interaction between sovereignty blocs, and each group currently has either enough, or too much sovereignty. There are few reasons for new blood to come into the null system to create additional conflict, and perhaps not enough potential population to create the necessary density and friction with the current space limitations in Aegis Sov.
Solutions: Vulnerability windows and the decay of ADM should be structured so that sovereign entities have the time to accomplish something else besides defending their space all day, allowing them to deploy or take on fights. Rewards should be increased to spur groups to take up Null Sov. This doesn’t necessarily mean increased isk/hr, but it can also come in terms of interesting opportunities for bottom up income for alliances, rewarding gameplay, unique gameplay, and mechanics that spark conflict. Rewards should be tied to seeking interaction instead of avoiding it.
My Solutions: I have spoken on some of these in my other blogs, but conflicts happen as a happy coincidence of several factors. First, co-location. There have to be reasons for the players to arrive at a location where there are hostiles to fight. Second, density, which is closely related to 1. If there is a sufficient density of players available in nearby space, friction occurs on a realtime basis and fights occur. Third, the “winnable bet”. Reward must be in proportion to risk. Both sides need to feel as if they might successfully carry off a valuable objective. If one side has no chance, no fight occurs. Increase the number of fights with a window where both sides feel they can win, either through encounter types that don’t automatically favor N+1 combat, or objectives that don’t necessarily include completely obliterating the other fleet. Fourth, tie at least some of the rewards directly to combat or victory at combat objectives. As the text I bolded above says: Rewards should be tied to seeking interaction instead of avoiding it.
III. Feedback regarding Phoebe Jump Mechanics
1. There are a wide variety of opinions on the specifics of the Phoebe Jump Mechanics. Lowsec entities find them favorable due to the local immunity from the larger supercapital powers, allowing for a greater scope to fights to occur uninterrupted. Not all Lowsec entities are as enthused however, because this means that the local bully-on-the-block can hit smaller or similarly sized entities without the danger of reinforcements from other more distant blocs. Long term, it is not clear if this will lead to the same sort of N+1 stratification of Lowsec that has occurred in Nullsec, although it appears to be trending this way.
2. Nullsec entities have found the jump mechanics, to be a huge hurdle to effective and fun use of capitals due to the large distances that must be covered in Nullsec. Moving capitals, supers, and titans in order to catch up with a group that has moved, or for any other reason outside a large well-defended move operation, is virtually suicide. Fatigue is widely seen as an unpleasant and potentially game killing (for at least a period of days or weeks, on occasion) problem, which can simply result in players logging off entirely instead of playing the game in other ways.
Commonly Suggested Solutions: The goal of restricting capitals from unlimited movement is a worthwhile undertaking, however the current mechanics go too far. The most common suggestions are a reduction of the fatigue cap to no more than five days, so that pilots can recover fully from one weekend’s activities to the next. Trips of up to two jumps could be met with minimal penalties so that players can return to their origin point and still fight later in the same day. A common suggestion is to increase the maximum jump range to 6 or 7 light years, which would allow for significantly more flexibility in the use of capitals without allowing them to cross regional connections unimpeded, but would help players move around within their home region. Other suggestions include mechanics that will give consideration to pilots who are inactive, and return to the game with the need to travel great distances to rejoin their play group. Additionally, it is widely suggested that fatigue be reduced or eliminated for jump bridges, as they are a key element of defense that is currently diminished in value. The current fatigue on jump bridges is also a factor in reducing fights, as alliance members who have moved to their pve locations in your space may be prohibited by fatigue from joining defensive or offensive fleets forming in your staging system. Another recent twist that has caught some favorable press is the idea of having all jump fatigue wiped when you jump into your alliance’s capital system. This would allow much greater local use of capitals while continuing to restrict long haul usage.
My Solutions: I could be happy with some combination of any or all of the above. It’s probably safest to pick one or two and iterate until we are in a more balanced place. I would probably start with the overall fatigue reduction and an increase to 6 LY.
There are a number of dials that can be twirled here to make ShinyPixieLaserSov aka Kafkasov less Kafkaesque. I strongly feel that of all of these, adoption of something similar to the structure vulnerability system for ALL sov structures, and appropriate restrictions on entosis link bearing ships would have the most beneficial effects, if I had to pick two. If you feel I’ve missed something vital, tell me what your major issue and what your solutions might be in the comments. Don’t just whine, be productive.
This article originally appeared on TheMittani.com, posted by Kristoff Merkas.