Hello once again fellow brothers and sisters of New Eden! It feels like our last chat was only yesterday. How time flies.
My name is CCP Fozzie and I’m here to bring you another dev blog covering our fast approaching EVE Online: Rubicon expansion, landing in just a few days on November 19th! Today I’ll be discussing two of the numerous medium sized changes that will be gracing our patch notes for Rubicon. These two changes are near and dear to my heart, as well as the hearts of many of you, our most passionate players. Both these changes are linked through a connection to Starbases, as well as by the role that our player-elected Council of Stellar Management played in helping us prepare them for you all.
Our most dedicated forum-watchers will probably already have guessed the two changes I am talking about:
New Ship Maintenance Array wreck and loot mechanics
and
Strategic Cruiser subsystem refitting in space.
I will be discussing the details of both of these changes, as well as providing some insight into the processes and journeys that led to where we are today. Firstly however I want to quickly discuss the Council of Stellar Management and their crowdsourcing efforts in particular.
The Council of Stellar Management (CSM) is our player-elected council that represents the needs and desires of our player community to CCP and advises us with the shared goal of making the best possible decisions for the quality of EVE Online. They are elected every year and we fly them out to our Reykjavik headquarters twice a year as well as constantly discussing the future of the game with them over forums and online chat.
The CSM undertakes a number of initiatives to help collect your feedback and convey it to us here at CCP. These range from actively reading the forums and passing us notable threads, to running live town halls like the one being hosted this upcoming Saturday, and organized crowdsourcing efforts like their “Reasonable Things” initiative.
The “Reasonable Things” initiative this last summer was intended to source a prioritized list of changes that are desired by the EVE community. CCP could then do an internal pass to determine how feasible the items were and incorporate the list into our expansion plans. The crowdsourcing used the same Wright-STV voting system that is used for the CSM elections to allow players to vote for more than one item and list their preferences in order. A total of 4090 votes were cast and the results were published this last August.
CCP has been looking for opportunities to incorporate this feedback into our expansion plans, and although some of the suggestions have proven infeasible, several will be reaching the EVE client in Rubicon and beyond.
Several of the items on the “Reasonable Things” list were already strongly on the radar of our gameplay teams, including the two changes this blog is covering.
Ship Maintenance Array Looting
(Click To Enlarge)
Ship Maintenance Arrays (SMA) are Starbase structures that allow players to store and refit their ships. They are common sights in many starbases, especially in uncharted wormhole space where stations are not available as a ship storage alternative.
The saga of the SMA loot drop starts a little over a year ago, in late 2012. At that time a destroyed SMA would eject all the ships it contained into space where they could be easily boarded or picked up by an Orca or Carrier. This provided a valuable conflict driver as players could expect the possibility of obtaining valuable ships as a reward for the effort expended attacking their neighbors.
This system however had one fatal flaw, in that ejecting the contents of a SMA into space separately could potentially mean hundreds or even thousands of ships entering space at one moment. Evidence from related situations had demonstrated that this kind of rapid ship ejection could cause extreme server load and even threaten crashes, which was completely unacceptable. A programmer was tasked with quickly correcting this defect to ensure that it did not cause any harm. The solution reached at the time was to simply delete all ships contained in a SMA when the structure is destroyed, therefore preventing them from ejecting and causing instability. It was acknowledged as an extremely suboptimal solution but it was deemed far better than the potential alternative.
When players (especially those living in wormhole space) noticed the change there was a fair bit of consternation displayed on the forums. We knew internally that we wanted to develop a more complete solution but fitting in the design and implementation of that solution into our busy release schedule was easier said than done.
The CSM was a key ally in this regard. Several CSM members (including but not limited to the wormhole dwelling delegates) were proactive in filtering and communicating the player feedback on this issue. They helped lobby to ensure that a good chunk of development time was dedicated to implementing a complete solution to the issue, in the earliest possible time slot. They also helped us validate our designs as they progressed, giving us valuable player feedback during stages of the process when we were not ready to announce the project in public.
In the end, the solution that has been implemented and will be releasing next week in Rubicon is as follows:
When a SMA is destroyed after Rubicon, it will drop a wreck. The wreck will contain ships dropped from the destroyed SMA, with each ship having the same 50% chance to drop that governs normal loot drop mechanics. That wreck will have special functionality that allows players to eject the intact ships out into space, where anyone can board them. You will also be able to fly up with a carrier or orca and drag ships directly into your ship hangar.
The act of destroying a SMA will now also provide a full killmail listing what ships and modules dropped and were destroyed.
It will not be possible to add ships to the wreck, and you can't board ships directly from the wreck since that would mean placing your current ship into it. We have also removed the multi-eject options from all SMAs and SMA wrecks to avoid node crushing volumes of ships entering space. You must eject ships one at a time.
The SMA and X-L SMA wrecks will have much higher hitpoints than normal wrecks, but can be destroyed, in which case their content disappears just like a normal wreck. They can only be salvaged if there are no ships left inside them.
This solution provides a far better user experience than the original behavior while also preventing any adverse effects from large numbers if ejected ships entering space at once.
We had been working on the design since earlier this year and it was an official part of the Rubicon release plan since August. This may cause some of you to ask the following question: why did we choose to keep the project a secret for so long? I want to address this question and hopefully provide some insight into our ongoing communications in the process.
The most important step in keeping your promises is to be careful what you promise.
It may seem like a truism, but this simple fact is very easy to forget and ignore. When most people break their word it’s not caused by a desire to maliciously deceive, but by recklessly overcommitting.
In game design this challenge is especially difficult, as player are just as passionate about the game as we are, and therefore can easily misinterpret a discussion of future ideas and options as commitments. As Devs we see the benefit of bouncing ideas off our community and sharing exciting (and often unproven) ideas for the future, but the nature of the game development means that priorities must be able to rapidly adjust to new realities and to bypass unforeseen roadblocks. This means that we must be careful not only what we promise, but also how early we share our plans with the community. If we had run into an unforeseen problem that blocked the implementation of this SMA change after announcing our designs it would have caused unnecessary anger and distress among segments of the community. This is why we elected to keep the plans away from the public eye until they were completed and to rely on the CSM with their non-disclosure agreements to provide player feedback.
Many of you will have already noticed that CCP developers tend to be very tight lipped about our plans for specific features and issues. This does not mean we are not working on those areas or that we don’t have an internal plan. It simply means that we are endeavoring to be responsible with how we set expectations. For issues that have especially strong emotional connections to segments of the community we will tend to wait until very late in the process before making announcements.
Strategic Cruiser Subsystem Refitting in Space
(Click To Enlarge)
Strategic Cruisers (Tech 3 Cruisers) are a special class of ships that can be customized by switching any of their five types of subsystems for alternatives with different bonuses. Introduced in the Apocrypha expansion, these ships have proven extremely popular. One of the most common player requests we have received over the years has been for T3 Cruisers to gain the ability to switch their subsystems while outside of a station hangar.
This has been a change we have desired to implement for a long time, but it faced a number of challenges along the way. Originally the idea of allowing subsystems to be switched directly on a piloted ship in space (when within range of a fitting service) was investigated and eventually discarded as infeasible due to issues updating the ship model dynamically.
During the development of the summer expansion, EVE Online: Odyssey, we once again attacked the problem, this time as part of a package of Starbase usability improvements. The design that was attempted for Odyssey was intended to bypass the original problem by allowing pilots to store their T3 Cruiser inside a ship maintenance bay and switch subsystems through a right click menu in that location while the ship was unpiloted and out of open space. This implementation was not only suboptimal from a user experience perspective, but also ran into its own hurdles and was eventually bumped from the Odyssey release.
During the development period of Rubicon, we took another crack at the problem, this time attempting to solve the original challenge of letting T3s refit while piloted and all the associated side effects. I’m happy to say they were successful and this functionality will be releasing on November 19th with the rest of the Rubicon expansion.
Below I will include CCP Paradox’s explanation the details from the feedback thread:
I'm happy to announce that with Rubicon, you will be able to refit your subsystems on your Tech 3 cruiser in space.
This change will apply to any fitting service in space, supplied by SMA, a capital ship with a fitting service (like the Orca) or even the new deployable the Mobile Depot.
Fitting the subsystems works just like in station, you can drag and drop to the fitting window to refit. Any modules that need to be unfitted will be returned to your cargo hangar. The replaced subsystem will return to the destination that the new subsystem was taken from. For example if you decide to use a new engineering subsystem from an Orca fleet hangar, the subsystem you currently have fitted will be placed inside the Orca fleet hangar.
While we are placing modules from your ship into your cargo hold, you can overload your cargo this way. It is important to remember this, and make sure you can safely store away the modules which were removed.
These changes should be especially advantageous to wormhole dwellers who had previously needed to travel to known space just to swap their subsystems. It is also an excellent change to release alongside Rubicon’s new Mobile Depots that will make refitting in space much more accessible to the masses. There are still more changes to Strategic Cruisers that will make their customizability really shine (dealing with the interaction between subsystem refitting and static rigs for example), but those will need to wait for our more comprehensive Strategic Cruiser rebalance at a later point.
Action Points
We want to give a very special thanks to all the players who discussed these issues with us, and to the CSM for their continued work to help make EVE Online the best possible version of itself.
If you want to help make your voice heard through the CSM process, there are a number of ways to do so. The first and most important is to vote in the CSM elections. We run CSM elections once per year and they are open to all subscribing accounts. When it comes to having your say on how CCP gets advised nothing is more important than casting your vote. Never trust anyone who tells you your vote won’t matter, as they’re usually just trying to prevent you from voting to increase their own power (this kind of deception is both clever and within the spirit and rules of EVE, but that doesn’t mean you need to fall for it).
You can also communicate with the CSM directly through events such as this weekend’s CSM town hall that will be hosted on EVE University’s public mumble server and broadcast live over EVE Radio.
We here at CCP are very happy to be releasing EVE Online: Rubicon to all of you in just a few days on November 19th. We hope you enjoy these two changes as well as all the other hundreds of changes and features that combine to make an EVE expansion.
If you want to find out more about what’s coming your way in Rubicon, make sure to tune into the CCP live stream at 19:00 UTC tonight broadcast on our twitch.tv page. We’ll be discussing and demoing new features as well as hosting the world premiere of our new Rubicon trailer. I can’t wait to see you all in stream chat!
Thanks as always for everything you all do to make working on this game universe such a rewarding job.
-CCP Fozzie
New to EVE? Start your 14-day free trial today.
Returning pilot? Visit Account Management for the latest offers and promotions.