CZuschlag said:
The claim that throwing out the top and bottom 10% is a standard process is ridiculous!
I know this is a game, and not a industrial product. But, given the above, consistency within 1 Sigma shouldn't be too much to ask for!
This is totally OT, so sorry

.
That is incorrect. Standard research methodology when establishing the control group is to discard the top and bottom X percentages (usually ~10%) as generally being out of bounds when it can be determined that there is no method of reliably reproducing those results. Sometimes this is done as a shortcut to eliminating variances in the research when time, funding, etc. are limited. Usually it represents when the values produced at those extremes are not useful in finding the information the researchers are looking for. This doesn't mean those results aren't documented, but that for the purposes desired they aren't useful.
In QM (or QA) these *usually* (but not always) represent external factors to the process which are likewise left off the control chart because the process owner cannot control them. Since the only data that is of value within the control group (i.e. that which is used in forming the control chart) is that which can be reproduced and thus "controlled," anything that cannot be controlled is excluded from evaluation. After all, if your supplier delivers whenever his orders reach a certain number, then its impossible to determine which day of the week your stocks will arrive. JIT delivery fixes that, but not all suppliers are large enough to do that (realistically with UPS nowadays that is becoming less of an issue for small businesses who can't negotiate better contracts with the supplier).
Six Sigma, TQM, etc. rely on eliminating things that are out of control in order to reduce variances in the process and thus improve the result and/or product. While applicable when you know the results you want to achieve, ACtA doesn't specify results it wants to achieve and thus the TQM process management methodology isn't necessarily useful here.
Besides, I would be surprised if any games design out there followed a structured methodology very well, if at all. More likely it's just whatever a designer feels works well in a given situation. This isn't a slam against CZ, but regardless what the TQM folks out there would like to believe, their process improvements aren't necessarily useful in such situations. Sorry

.
@hiffano: my original comment about being a systems design engineer wasn't to "compare penises/jobs." I was using it to illustrate why I don't care to document my games all the time like (I think) Skavendan does. I just have to write a lot already as part of my work and I don't find documenting things that are of no use to anyone all that fun and I'd prefer to spend my time just enjoying the game if I can. It doesn't mean I can't document the games I play if people are interested in the results. It just means I don't like to do so and won't unless someone needs/wants the information. Sorry if that came across as trying to make myself seem more authoritative than I am. That's also why I deleted my response to Ripple since I figured here is not the place to explain why his ideas on games (complex systems) design are flawed. I come here to talk about gaming, not try and show everyone how knowledgeable I am (or am not, depending, though the latter is often more true than the former ;-)). I happened to let his jibes get under my skin and I shouldn't have. Thus I dropped the issue and am letting it stay dropped.
@CZ: that's also why this will be my only post on the TQM/QA topic. If you wish to discuss it further, feel free to PM me

.
Cheers, Gary
PS. I have no guns, a cat and a girlfriend. Does that count?
