halfflat

Fair enough. Do you know when they went down?

Hmm, is this then going to be in addition to the regular Thursday downtime?
What are the usual market downtime hours, and are they actually written down somewhere?

I strongly disagree. I'm glad JB has taken the role of the Tankers' defender. Brutes really do do what Tankers do nearly as well, while actually being capable of defeating foes in a timely manner. The core group role of a Tanker, which is aggro management, doesn't even make sense if the Tanker isn't actually much of a threat. Tankers as implemented are some sort of thematic compromise which makes them into a kind of durable one-trick controller.

I'm sure there are many options for giving the Tanker archetype some legs again. Personally, I favour the distinction between a slow/durable/hits-hard versus fast/agile/hits-precisely triad. If Brute-comparable raw damage is not an option for balance reasons, let them show their strength in other ways: let their attacks bypass a proportion of damage resistance, for example, making them more effective on the toughest foes (bruising seems a poor implementation of the general idea); give them lots of knock-downs and knock-ups which get the mooks out of the way, so they can concentrate on the big guy. I'm sure JB has his own suggestions.

Currently Tankers are in a weird no-man's land. We shouldn't have to abandon the archetype and all switch to Brutes — let's fix Tankers instead!

Slightly faster is barley worth the effort. It is a whole order of magnitude slower, and slight changes are going to be lost in the noise.

Even in an ideal land, where the iTrials were super-fun for everybody and did not pall after repeated playings, it's simply not going to be a viable game path for people who have the misfortune to be in a low-population timezone or server. Making the activity over 20 times more rewarding will not magick iTrialing players out of thin air. There needs to be an alternative, and it's clear that DA is not a serious one.

I honestly like the story arc, and will happily run it a few times across different characters. Given the time it takes, it should offer rewards vaguely comparable with running a similar number of trials. Taking 30 days to match 6 hours of trialing is simply ridiculous.

I agree with these things entirely.

I didn't see the quoted post in the thread, but nonetheless, I will argue against this interpretation. To say that it falls within two sigma is to beg the question: it already assumes that the drops are all coming from the same distribution. (As an aside, if they indeed were all from the same Bernoulli distribution, the best parameter estimate would be p=53/297; the s.d. of the Binomial distribution with N=119 (the 20110628 sample) is 4.18, the mean is 21.2, and the observed value of 16 rare drops is certainly within two s.d. of the mean.)

Before applying the s.d. heuristic, we have to confirm that the hypothesis that all the rare drop rates are the same is a reasonable one. Suppose the rare drop rate for 20110628 is u, and that the rare drop rates for 20110913 and 20110426 are the same at v. Let hypothesis I be: u and v are equal(the drop rate did not actually dip). Let hypothesis II be: u is v-0.05 (the drop rate for rares was 5% lower in the 20110913 build.) We can apply Bayesian model selection (with u and v otherwise unconstrained) to see which is the better model.

Let n1=119 be the number of drops total in 20110628, r1=16 be the number of rares, and n2=178 the number of drops total in 20110913 and 20110426, and r2=37 the number of rares.
The marginal likelihood of I is:

(n1 choose r1)(n2 choose r2) Integral(u=0 to 1, u^r1.(1-u)^(n1-r1).v^r2.(1-v)^(n2-r2) du) (with v=u)
=0.000107.

The marginal likelihood of II is:

(n1 choose r1)(n2 choose r2) Integral(u=0 to 0.95, u^r1.(1-u)^(n1-r1).v^r2.(1-v)^(n2-r2) du) (with v=u+0.05)
=0.000393

The Bayes factor for II over I is the ratio of likelihoods, = 3.66. A ratio above 3 is 'Substantial' - I'm relying on Wikipedia here - evidence for the second hypothesis. We cannot safely assume that the drop rates are constant across the three releases, and there is substantial evidence that a 5% lower drop rate in the 20110628 release is a better explanation. (Actually any proposed difference between 4% and 10% gives a factor greater than 3.)

However, given the fundamental assumptions behind the analysis have to be re-examined regardless!

No, that's not so.

To use more of the data though, let's consider the hypothesis that the rare drop rate in the 20110628 build was less than the rare drop rate in the builds on either side, which was the same in each (let's ignore build 20110405 on the grounds that we know they changed the drop rates between that and the next build.)

In builds 20110426 and 20110913, in total, there were 37 rare drops and 141 non-rare drops. Comparing with the 16 rare, 103 other drops from 20110628, we get

P(rare drop in 20110913 or 20110426 more likely than rare drop in 20110628) = 95%

If anything, the evidence is stronger.

All of this though is under the assumption that drop rates are constant throughout each build, and constant across trials and archetypes. This might not be so.

It turns out that if you're trying to tell if the underlying probabilities have changed, you don't necessarily need that much data at all - it depends on how different the results are.

Compare the rare drop rate between the June and September builds:

20110628: 16 rare drops, 103 other component drops
20110913: 13 rare drops, 44 other component drops

Just eyeballing the figures, it looks like the chance for a rare drop has increased between the last two builds.

Starting with the assumption that we don't know anything about the relative drop rates, we can model our confidence in the probabilities of a rare drop by a Beta distribution: for the two builds, P(rare drop in 20110628 build) ~ Beta(16,103) and P(rare drop in 20110913 build) ~ Beta(13,44). The most likely drop rate for 20110628 is 16/(103+16) = 13.4%, and for 20110913 is 13/(44+13) = 22.8%, but given the limited data, how likely is it that the rare drop rate actually increased between the two builds?

The confidence that X > Y when X ~ Beta(a,b) and Y ~ Beta(a',b') is given by a fun double integral of f(x+u;a,b)f(x;a',b').dxdu, with x and u ranging from 0 to 1, and where f(x;a,b) is the pdf of Beta(a,b). Plugging the numbers in and computing gives:

P(rare drop in 20110913 more likely than rare drop in 20110628) = 94%.

Based on the data given, there's roughly a 19 in 20 chance that the underlying drop rate for rares has actually changed (increased) between the two builds. Alternately, you could say there's only a 1 in 20 chance that these observed changes are just a result of random chance.

Looking at the very rare data, the raw numbers indicate that very rare drops have decreased between the two builds, but because there are fewer drops to work with, the results have lower confidence. With:

20110628: 11 very rare drops, 108 other drops
20110913: 4 very rare drops, 57 other drops

the calculation gives:

P(very rare drop in 20110913 build less likely than very rare drop in 20110628) = 72%.

So there is some evidence indicating that the very rare drop rate has decreased, but it's very weak: it easily (about 30% chance) could just be a result of random variation. We'd need more data to be sure.

I'm coming from a different angle, obviously, but I disagree for two reasons. Firstly, I have worked in the game industry as a programmer, and seen the stuff that gets shipped even as 'A' titles. It would make your stomach turn. But the chief reason for the poor code is the incentive structure: publishers want to get things out to meet various calendar constraints, and of course want to spend the least amount of money; and further, the rewards to the developers for shipping bug-free or at least well maintainable software are slim at best. Granted, MMOs, with their longer-term focus, will have different development pressures.

The second reason, is that I am and have been working right now on a large, distributed, database-backed project which has very infrequent downtimes (one every few months, typically.) And this even uses MS' SQL server (I'm not the one who has to baby sit it, thankfully.) In earlier work, I've written computationally intensive and data intensive software that would run for weeks on a large cluster, with a custom data store that handled the various contention issues. It too did not need to be periodically restarted. So I do know the technology is feasible, even if it certainly is not trivial.

Consequently, I honestly believe it can be done, and that the reason it is not done is primarily one of developer or publisher priority.

That said, we're not talking about five nines uptime here. Even reducing CoH downtime to an hour a month would be a huge improvement for those affected by the choice of maintenance window over the 2 to 6 hours a week we see now.

Can you prove that you can't do it for a relatively small increase in costs compared with revenue? See, we can play this game all day. It could pass the time while the servers are down.

Perhaps you yourself also have considerable industry experience, in which case I apologize for judging your comments as shallow and mostly baseless. But if so, it would help your case if you argued coherently, as opposed to lurching between rhetorical devices, unsupported by anything approaching facts.

I love it when people deliberately take something out of context in order to make snide remarks. It makes my morning. Mmm, blowhards and coffee — perfect start to the day.

Do you think CoH would be the great game it is, if they cared only about making a profit?

Never even suggested they should. You are arguing with a straw man, so please spare the personal barbs. Just brought up the example to show that it is entirely possible for a live, database-backed application to not need rebooting every few days. And from personal experience, I know you don't have to be a bank to do it.

In many other circumstances, it's called discrimination, and is actually illegal in many countries. (Again, before you go off on a tangent, I'm not claiming NCSoft is acting illegally.) Companies often DO have a legal obligation to act equitably in many important regards, and inasmuch as they are participants in our society, they also have an ethical obligation to act equitably.

I would not want to live in your world, MajorPrankster, where everything appears to be decided by dollars alone.

Well, my post was obviously a sarcastic reply to an unreasonable one liner, so I didn't go in to details. I know my background is not unique, but I do have experience in the games industry (network programming, but not MMOs), distributed scientific computing, and in industrial long-running time-critical (and large!) database-backed applications.

I can't see why you would need to have downtime to do a full backup.

Er, yes. Was this in an earlier post? It's not in your reply to my snarky comment.

Well, not entirely moot. It shows they are happy to compromise the user experience of a particular subset of players, in order to save money. It's not equitable, only economic.

In your haste, I think you missed the bit about network-service software, too.

I'm not talking about bugs that become apparent, and need to be addressed post haste — that's why there is also unscheduled downtime, annoying as it is. The question is: what is going on such that every week, the whole thing needs to be effectively turned off and on again?

Databases can and are backed up live. (I know my bank, for example, doesn't have weekly scheduled downtime. Does yours?)

Well, yes, that's correct. Your post really did not explain much at all that needed explaining, and was patronizing to boot.

It comes down to an economic decision: doing it 'right' obviously requires more manpower and possibly hardware than doing it the way they are now. They believe, and quite possibly correctly, that the lost revenue from those who give up playing from a disadvantaged timezone is more than offset by the savings they gain from just kicking the servers every week instead.

Pray, do explain.

Please use small words, as my years of experience writing long-uptime scientific-computing and network-service software have possibly left me ill-prepared for a sophisticated argument.