CSM9: Week Three

One minor site related thing before diving into the update – I’ve got a submission page for topic requests. Nothing more to say about that, really.

So what’s new this week? Meetings. More meetings. Oh god, the meetings!

Actually, no, it’s a great thing, the meetings have been productive. As an added bonus we’ve figured out how to overcome one shortcoming of the meeting platform, allowing more of us to attend live on a regular basis. That includes myself – the vagaries of scheduling meetings involving people across five or six timezones and two continents means the “optimal” time falls in my commute hour or in the first hour of work. Fortunately, the efforts of CCP Leeloo (who we’ve decided must be a Genie) mean that recordings of the meetings are posted for any of us who missed them within a couple hours.

In the “newly posted features” department, Sugar Kyle and Xander Phoena have both done a good job covering that. I hate feeling like I’m just rehashing what they write, so I’m not going to belabor the point too much. Instead, I’ve got a few bits of my own to add to a couple things,

MMJD are removed from ABCs… for now. They are not ruled out for the future. Personally, I hope they come back for that application, although the slow fall from favor of the class in many of its old applications has its roots in things that go well beyond what just MMJDs would solve.

The Mordus NPCs currently on the Test Server are actually found in anomalies, not belts as was originally stated. That it explains why I had no success finding them the other day. Edit: No it doesn’t, the sites are the source of BPCs for the new modules and the like, belt rats remain source for the ships themselves. I just misattributed my bad luck.

And then Freighters. Last week it was rig slots, and after public feedback and plenty of internal debate, they now have low slots instead. Overall I’m a fan of the outcome here. The upsides are a little larger, though the downsides are as well, a fact that there’s no getting around; “freighters as they are with modules on top” was something that was never on the table to begin with. The ability to refit on the fly to suit the next hauling job does a lot to offset that, though, while the permanence of rigs only exacerbated the downsides.

The question I’m sure some people are asking, then, is why didn’t the CSM fight this before it was posted? The answer there, simply, is good ideas don’t always happen all at once. Just like anyone else, we see something, we look it over, we think about it. Reservations may manifest themselves immediately, as they did in this case. I was concerned about rig permanence eroding the supposed new flexibility, and the steep downsides to go one way or another was something everyone was concerned about.

Most of the time, though, “we’re concerned about this” isn’t enough. When I was growing up, one piece of advice I heard from my dad over and over was “When you have a boss, don’t just bring him a problem. That just makes you a problem. Instead, bring a problem and a solution, or better yet two or three.” In this case, we had the problem (our concerns), and even had a solution (“why not slots instead”) but part of a solution is being able to defend the solution. The solution had problems of its own as well – low slot modules are far more powerful than rigs, and so difficult to balance, as Sugar Kyle noted last week. And thus, Fozzie marched onward and took the changes public… as he well should have! More on that a bit later.

Internally, discussion continued. Low slots for freighters looked like a fun little design exercise, so I generated some numbers. Scroll down through that post and look at the base EHP numbers and EHP numbers for various fits, and you can see why Damage Controls were left out of the final design – while they’re arguably balanced, the swinginess and tradeoffs involved are ultimately far too large. Nevertheless, it demonstrated it was possible, and so we submitted the design, our strengthened verbal arguments, and (quite possibly most importantly) the support low slots had received in the feedback thread both before and after my post.

And so here we are.

I mentioned a bit earlier that Fozzie was absolutely right to press on and take the changes public. Why? If the CSM has reservations, no doubt the players will as well, and so why not wait and address them? A large part of that I already explained, the lack of a good argument defending concerns. Another major factor, though, is that the very reason things are released far in advance of a patch (sidenote: balancing existing ships is generally not very demanding on developer resources, so two and a half weeks before patch is pretty far in advance) is to give time for feedback from everyone. That does include us – we’re not banned from giving feedback once a feature is posted in F&ID, after all. And besides, often as not in such situations, our continued feedback will draw inspiration from yours.

Just to close this post off, what exactly qualifies as a strong argument, and why isn’t we’re concerned enough? CCP Greyscale had an unbelievably good post on the topic of giving feedback a couple weeks ago that delves into that. I’ll quote the bullet points and briefly explain them each in (mostly) my own words here, but go read the whole post too.
Be calm and reasonable. Rageposting (which needs no explanation), outlandish and/or hyperbolic claims (“this will absolutely kill X and everyone will quit”) and childish labels (“coward module” comes to mind, courtesy of the MMJD thread) are not convincing and generally will not get you anywhere but ignored.
Show your work. This is the why; your opinion is not enough, as a thread will often have multiple conflicting opinions. A side that can support its opinion is far more likely to be successful.
Be Specific. Numbers are fantastic. Demonstrating why something is too big or too small is much better than just stating that it is. To grab the easiest kind of example, you might feel a post-balance ship doesn’t have the CPU to fit a reasonable fit for a certain task. Your argument will be strengthened by saying “This is the fit I want to use, these are the compromises I have to make (meta modules, different tank choices, etc) to make it work, and these are fits similar ships in similar roles can use that don’t have to do that, for that reason this ship should have at least 30 more CPU.” Actual example, not saying who, what or when.
Consider the whole picture. Much as you might like to think so, you are not the only player in this game. The developers are going to consider all angles on feedback as it is. Demonstrate you’ve done so as well and you raise the odds of your suggestion being taken into consideration.
Start your post well. A clear, concise summary – an abstract, if you prefer – will grab attention. This is especially true when your feedback is, by virtue of topic, a wall of text.
Speaking of a wall of text (to take the bullet points out of order) make sure it’s readable. Break up your paragraphs, punctuate correctly, and perhaps include some wit.
Finally, be novel. This isn’t to say that the tenth or twentieth or hundredth “I agree with this idea” post isn’t useful, as it indicates that one idea or another is something players can get behind. But there’s nothing to +1 without succinct yet comprehensive posts laying out why something is a good or bad idea and how to fix it.

While he was speaking for himself, I virtually guarantee you that this goes for literally any developer in the company… and speaking for myself, a lot of it goes for me as well. I’m here, among other things, as a conduit for feedback from players back to the developers. Coming to me and saying “this is bad, fix it” isn’t very useful on its own; even if I already think its bad myself, your reasoning and explanation could well be the new insight needed to convince CCP.

Just a little bit of food for thought next time you’re writing a feedback post.