Thoughts On FozzieSov

I've had a very, very, VERY insane week so far to think about FozzieSov and what it means to the game if implemented as is right now. And I've had some time to listen to other pontificate / wonder / enthuse / rant about it, so I feel ready to give my impressions and thoughts on the new proposed sovereignty system.

Things I Like

- Separation of Structure Dependencies - I hated how what structures could be attacked and when was all tied together into a flow chart of doom:

It was confusing, frustrating for attackers and defenders, time consuming, and time wasting if the defender had surrendered and moved out. How many null players left the game after grinding through this flowchart in a region the defender abandoned? The new system has three simple flow charts, one for each sov structure:

I think its cool that one alliance can control the Territorial Claim Unit (TCU), one can control the Infrastructure Hub (IHUB), and another can control the Station (if present). It feels more descriptive to me of the actual situation in space than some legal wranglings of a massive flow chart; defenders huddling in a station while the attackers take the TCU and IHUB, for example.

- Freeport! - I love the idea that a fight for a station involves a period of time where the station is a freeport, i.e. both sides can dock. I can see some huge fights and casualties erupting as pilots try to evac assets from a station while the attackers start pouring in.

- No Structure Grinding (Sort Of) -Yay! No more hundreds of thousands or million of structure points to grind through multiple times to take a system! In my time in null I wasn't on a lot of structure grinds but the ones I did go on were tedious and annoying. I couldn't imagine having to do it night after night to take over an entire region.

- Constellation Matters - The idea that once a fight for a structure occurs that the corresponding command nodes that need to be captured spawn across the constellation instead of just in the system is brilliant. Since the shape of constellations varies so much and the position of systems relative to each other determines movement strategies and engagement possibilities, it really makes each battle for a constellation unique.

Things I Don't Like

- Troll-ceptor - If the fitting for the new Entosis modules are too low, its going to enable horrible gameplay where one pilot in a small nearly uncatchable interceptor is going to set off reinforcement timers over a wide area. Such a small investment of effort by one pilot requiring a significant defense response by an entire alliance is unbalanced gameplay. I think the fitting for the module should be able to be used only on a cruiser at the very least, preferably battleship in my books.

- Fast Burn - one of the best things about a battle for a system under the Faction Warfare Distributed Objective system is that a battle for a system can run for days or even weeks as long as the defenders have some ability to defensively plex as well as compete against the offensive plexers. This can lead to massive long running fights over days as both sides tug of war at that control bar. The FozzieSov system seems to resolve a lot quicker meaning prolonged fights for a structure control will be over quickly and not have that epic feel to them unless both sides are evenly matched. To be fair, there are a lot more fights to be had for control of a system (TCU, IHUB, and Station) so this might balance out in the long run.

- Four Hour Vulnerability Window - I've heard people talk about how faction warfare's system is "gamey", but this takes the cake. At least in our system you decide when a system is most vulnerable to attack based on their activity and strength compared to your own side's; the FozzieSov's mechanic of alliances setting a four hour window when they are vulnerable seems like a horrible mechanic. I understand CCP is reluctant to have constant vulnerability of structures to attack so that alliances can build empires and farms and fields and feel like they have a chance to counter, but I think that it would all balance out as pilots learn to defend the structures from attack, especially if there was some sort of de-reinforce mechanic, i.e. Attacking Alliance puts a structure into reinforce any time but they now have to guard it from being un-reinforced by Defending Alliance until the battle starts for control. This would allow us to throw out the silly mechanic for 4-hour vulnerability windows and create running battles like faction war has. Alternatively, I'd like to see the size of the vulnerability window grow or shrink depending on another factor like alliance size (#systems controlled) or something like that.

* * * * *

Overall I like where this system is heading, but I think it needs some tweaks before it hits in June.

Distributed Objective Based Warfare

CCP Fozzie took a hockey stick(1) to a hornet's nest today with the first dev blog on the new sov system coming this summer. I'm not going to comment on all of it as I'm still thinking about it (but so far, overall, I like it) but I do want to address one statement I've seen a few times.

"This is just like Faction Warfare mechanics!" Or "CCP is bringing Faction Warfare to Null Sec!"

No.

I can see the temptation to think that way but let's change the perspective.

CCP wants Distributed Objective Based Warfare for null sec sov mechanics so that fights for control over TCUs, IHubs, and Stations are spread out over multiple systems, thus leveraging constellation geography to make fights unique in different constellations as well as lowering overall load per node by making large fleets on a grid less advantageous.

How do you accomplish those goals without introducing constellation objectives that small groups can take or defend? Thus command nodes.

Since Faction Warfare is also a Distributed Objective Based Warfare system, but with slightly different input requirements and implementation, its no surprise both systems look and feel very similar to a casual inspection. But a careful examination shows significant differences between the two that will lead to very different gameplay.

For example, in FW the only thing you capture is control of a system which locks the hostile militia out of the stations. To tug on the control bar for that system you need to capture complexes IN that system. The complexes have acceleration gates (except for Larges) that restrict certain classes of ships which impacts the fleet doctrines that attackers and defenders utilize (i.e. T1 Frigates have a very specific role). In addition you need many plexes captured to flip a system, over a hundred, and that's if unopposed.

In contrast, in the proposed null system the Command Nodes to capture a structure are spread out over a constellation, far fewer are needed unopposed to succeed so the time to capture is a lot faster, there are various things to fight for control of in a system (TCU, IHub, Station), the command nodes are not locked in complexes so there is no need for T1 frigate doctrines, and the area of space brings its own wrinkles such as bombs and warp bubbles.

In other words, the differences far outweigh the similarities.


1 - Hockey stick because he's Canadian like Yours Truly

Its a Start EDIT Not So Much

Loving this post from CCP Fozzie:

Hello everyone!
In the upcoming Summer release we are making a lot of changes that we expect will impact player behavior surrounding manufacturing, mining and starbase use. We see an opportunity here to make some adjustments to the way that Jump Drives consume their isotope fuel that will hit a few birds with one stone.
The goals of this change are:
Stimulate the isotope (and therefore ice) market to help cushion any drop in demand from players using smaller starbases after the science and industry slot changes.
Help encourage cost competitiveness for local resource gathering in nullsec.
Although we don't expect this change to significantly impact behavior around jump drive power projection, it should at least provide a small incentive change through higher costs for moving huge capital fleets often.

The plan for this release is to start with a 50% increase in the fuel cost of all jump drives and jump portals, and adjust further if necessary once we see the results. This change applies both the the base consumption of ship based jump drives, as well as the isotope consumption per kg of mass on all jump bridges and portals.
We will also be increasing the fuel bays on all jump capable ships (and the fuel storage on starbase jump bridge arrays) by 50% (60% for Black Ops Battleships) so that they do not need to refuel more often.
For reference, this will increase the cost of running a max skilled Rhea from Jita to RIT-A7 (jump drive transit the whole way) from ~50m isk to ~75m isk.

The tears from capital and supercapital pilots have already started and the reasons are not hard to see why: Carriers and Supercaps carry large reserves of fuel in fleet hangers which are not getting a size boost. Therefore this is a huge nerf to their independent range. In order to have the same power projection they enjoyed so easily before, they will have to coordinate refueling more often. Not to mention the cost of running these ships is a lot more expensive (but still trivial to these vastly wealthy players TBH).

Its not much of a huge change overall but its a start to nerfing capital power projection.

EDIT: After I posted this, CCP Fozzie responded to feedback and changed the post from upping the fuel bays on ships to reducing the isotope size:

Hello everyone!
In the upcoming Summer release we are making a lot of changes that we expect will impact player behavior surrounding manufacturing, mining and starbase use. We see an opportunity here to make some adjustments to the way that Jump Drives consume their isotope fuel that will hit a few birds with one stone.
The goals of this change are:
Stimulate the isotope (and therefore ice) market to help cushion any drop in demand from players using smaller starbases after the science and industry slot changes.
Help encourage cost competitiveness for local resource gathering in nullsec.
Although we don't expect this change to significantly impact behavior around jump drive power projection, it should at least provide a small incentive change through higher costs for moving huge capital fleets often.

The plan for this release is to start with a 50% increase in the fuel cost of all jump drives and jump portals, and adjust further if necessary once we see the results. This change applies both the the base consumption of ship based jump drives, as well as the isotope consumption per kg of mass on all jump bridges and portals.
To compensate for the extra isotopes that ships will need to carry, the volume of all four isotopes will be reduced by 1/3, to 0.1m3. Thanks to Resgo for some excellent feedback.
The storage volume of jump bridge starbase structures will be increased by 50% since Ozone volume won't be changing.
For reference, this will increase the cost of running a max skilled Rhea from Jita to RIT-A7 (jump drive transit the whole way) from ~50m isk to ~75m isk.

So the price of jumping will still be higher, but not limited by space in the ships. :(