Vanguard chatter

[Mrbloodworth]

I like the opiate comments 

[Simond]

Damn, couldn't that have been posted before Geldon got rebanned? 

[Soukyan]

But is it fun?

[Wershlak]

I wonder who will play McQuaid in the movie? 

[shiznitz]

Rush Limbaugh?

[Venkman]

I thought the drug-addiction thing was a pretty strong accusation. Is that common knowledge? Someone can usually recover from a train-wreck launch and it being common knowledge that you have no managerial skills at all. But a drug thing, wouldn't that be a career killer (except for Hollywood)?

[acerogue26]

I thought the drug-addiction thing was a pretty strong accusation. Is that common knowledge? Someone can usually recover from a train-wreck launch and it being common knowledge that you have no managerial skills at all. But a drug thing, wouldn't that be a career killer (except for Hollywood)?

Speaking of...What's ol' Brad doing these days? I wonder about gaming's Britney Spears from time to time.

[Trouble]

A quote from that thread

I guess we now know where Brad McQuaalude got his visions from.

That's good stuff.

[Venkman]

* Nevermind. Found it * 

[CharlieMopps]

That rant seriously deserved its own thread. "Brad's on drugs" is an entirely newsworthy topic.

[d4rkj3di]

Is that common knowledge?

Pretty much. No one talks about it because all it will ever be is an accusation or rumor until there is an admission. Or an autopsy.

[DarkSign]

Can someone explain the Diplomacy system to me? Im curious...just not curious enough to buy.play the game :)

[Draegan]

I played it once.  It was a card game similar to those Magic games.

[shiznitz]

It was only similar in that it uses cards. There are four colors of cards. When you play a card, you get "points" in that color. Each card requires color points to play. Cards can give you points in other colors. When a card is played, it is timed out for an amount of turns based on the card. Your accumulated color points can be changed by your opponent and vice versa. Playing a card moves your opponent's "health" meter by the number on the card. Take your opponent down to zero to win.  You can only bring 5 cards to a challenge. Most of the time, one color is not used and you know which one before the challenge starts.

I don't know if that makes any sense at all to someone who hasn't seen it in action.

[Venkman]

Sounds like playing a lightning-fast round of M:TG using only old Red/Blue decks?

[shiznitz]

The color points aren't like land because they get used up when you play a card and you have to rebuild them again. There are no buffs or instants either. All the cards have names like "Soothing Words" or "Furious Gestures".

[Venkman]

Oh, ok, so a Red/Blue deck versus a White deck then. 

(I kid I kid. I've reached my limit of what I know about M:TG and TCGs in general :) ).

[SnakeCharmer]

Just a random observation from reading that guys little rant...

Everyone is quick to blame the many headed monster of management for everything that went wrong with VSOH (or SWG, or any other game).  Management isn't the one writing the shitty shoddy code that doesn't work.  Are none of these devs, programmers, coders, etc going to step forward and say "Yeah, I worked on VSOH.  And my code completely sucked.  Full of typos, conflicts, all kinds of fun stuff.  It's my fault stuff got stuck in terrain because I was high when I coded it.  It's my fault quest #23 ends in a dead end because I didn't finish it."

Lots of blame to go around from the peons but none of the peons stepping up.  All to easy to blame "The Man" than themselves.

[Morat20]

Just a random observation from reading that guys little rant...

Everyone is quick to blame the many headed monster of management for everything that went wrong with VSOH (or SWG, or any other game).  Management isn't the one writing the shitty shoddy code that doesn't work.  Are none of these devs, programmers, coders, etc going to step forward and say "Yeah, I worked on VSOH.  And my code completely sucked.  Full of typos, conflicts, all kinds of fun stuff.  It's my fault stuff got stuck in terrain because I was high when I coded it.  It's my fault quest #23 ends in a dead end because I didn't finish it."

Lots of blame to go around from the peons but none of the peons stepping up.  All to easy to blame "The Man" than themselves.

I don't even know where to begin addressing that. Suffice it to say that the problems with Vanguard, and SWG, and in fact most MMORPGs are entirely on the design and software management side. Individual coding errors are simply bugs, easily correctable with even the most minimum of development standards.

Those people don't NEED to stand up. They're not the problem. In fact, in any even marginally competent enviroment those people's bugs (and mistakes are inevietable) are caught and corrected early, and people whose work is not up to snuff are either retasked to something they CAN handle or replaced.

The coder's aren't to blame. And if they actually HAPPEN to be to blame, the only reason they got the chance to screw up so severely is because their project was designed and managed by flaming morons.

Oh -- and no one's blaming management, so much as they're blaming design.

[SnakeCharmer]

I can't speak for VSOH, because I lasted all of about 6 hours played.  And it's one of those experiences that I've locked away in the corner of my mind trying to forget.

SWG?  I can speak pretty fluently on.  So, let's take Ranger camo.  Never worked.  That wasn't a question of design (hide the user from getting agro), it's a question of crappy code. 

But all this "WAAAHHGGG it's management's fault!!!" by programmers and coders is doing nothing but playing the blame game in many (but not all) instances.  Do people really need management to tell you to do your job correctly? 

Sure.  Shit not working 'as intended' may partially be blamed on design (WAAAHGG!! It's too hard!), or management (WAAAHGG!!! They didn't tell me what to do!!) but neglecting to mention shoddy coding isn't telling the whole story.

[cmlancas]

In Vanguard's defense, (and it is a very, very small defense), Diplomacy was rather cool. Unfortunately, it was tacked on at the end of the game. I'd say the scaling of equipment and lore related to diplomacy was about 33% done when the game launched.

[Venkman]

It's management's fault. It has to be because they're the ones charting the vision and path to building it. Otherwise, they wouldn't be management.

Individual contributors (artists, coders, QA, etc) can be taught, but you need someone in charge to be willing to do the teaching. That's management.

And it's not like it was up to the coders to announce the launch date, due what marketing would get done, handle distribution to various retail channels, and manage the budgets and projects into the mothership.

Conversely, it's these very contributors that have a much brighter future ahead of them than the management that bears the full brunt of failure.

[Morat20]

SWG?  I can speak pretty fluently on.  So, let's take Ranger camo.  Never worked.  That wasn't a question of design (hide the user from getting agro), it's a question of crappy code. 

But all this "WAAAHHGGG it's management's fault!!!" by programmers and coders is doing nothing but playing the blame game in many (but not all) instances.  Do people really need management to tell you to do your job correctly? 

You don't code for a living, do you? Or if you do, it's obviously small jobs where one or two people do the entire damn thing -- from design to testing.

But to answer your question: YES. WE FUCKING NEED MANAGEMENT TO TELL US HOW TO DO OUR FUCKING JOBS CORRECTLY. Why? Because goddamn correct is defined by the overall system design.

Which is defined by management. By the game designers.

Individual coder fuckups are minor, easily caught and corrected. Design fuckups kill your product. Fixing a coder error is easy. Fixing a design error, especially in a live product, is like having your nuts yanked out through your throat.

If you notice the problem for more than a patch cycle, it is almost certainly a design error.

[Archimedian]

Just a random observation from reading that guys little rant...

Everyone is quick to blame the many headed monster of management for everything that went wrong with VSOH (or SWG, or any other game).  Management isn't the one writing the shitty shoddy code that doesn't work.  Are none of these devs, programmers, coders, etc going to step forward and say "Yeah, I worked on VSOH.  And my code completely sucked.  Full of typos, conflicts, all kinds of fun stuff.  It's my fault stuff got stuck in terrain because I was high when I coded it.  It's my fault quest #23 ends in a dead end because I didn't finish it."

Lots of blame to go around from the peons but none of the peons stepping up.  All to easy to blame "The Man" than themselves.

I don't even know where to begin addressing that. Suffice it to say that the problems with Vanguard, and SWG, and in fact most MMORPGs are entirely on the design and software management side. Individual coding errors are simply bugs, easily correctable with even the most minimum of development standards.

Those people don't NEED to stand up. They're not the problem. In fact, in any even marginally competent enviroment those people's bugs (and mistakes are inevietable) are caught and corrected early, and people whose work is not up to snuff are either retasked to something they CAN handle or replaced.

The coder's aren't to blame. And if they actually HAPPEN to be to blame, the only reason they got the chance to screw up so severely is because their project was designed and managed by flaming morons.

Oh -- and no one's blaming management, so much as they're blaming design.

Some what true, I've never worked in an MMO but I cut my teeth designing client server applications (which everything still is but the definitions have changed).

For a standard application of any size (anything above the hacker level type of coding, meaning one guy in his basement just making an appy) most people in this world follow a standard development process.

So I would assume you have a high level business document, basically a 30k mile high over view of what you want your application to do.  No specifics just bold points so that every one knows what is being made and why.  We'll call this the "Vision".

From there you'd have business leads (they can be tech leads but in order not to confuse the world I'll call them business leads).  That have a vested interest in specific sub systems. They create a business document (usually non technical) of what they want out of a specific set of sub systems.  We'll call this designing the "fun" or in business development we'll call it deliverables.

Then you have your technical leads create specific design documents as to how each of the sub systems is going to be develop.  This is where things get technical per say, depending on the scope of the project this might be a high level over view or get into specifics.

Then your design leads actually write their tech documents, with how the minutia of a system will work, with estimated time lines in man hours, budgets (both monitary and technical).  You have database reviews with DBAs on proposed concepts and network budgets on bandwidth, art requirements and so on.

Mind you for a business application this is what usually occurs before a stitch of code is ever put down.  This usually filters back up and redesigns and the like occur at this stage.  If you have people who know what they are doing your estimates should be pretty good.  From the top down, you fight the scope creep fight the entire time.

You know who is off this list?  The code monkeys, the guys who usually get paid minimally are some times outsourced out of a job and their job is to translate a spec document into code.  Some people judge them on error per 1k likes of code.  Most modern tools make it rather difficult to have "typo errors' they wont compile and have a standard "spell check" built in.  The harder part is logical errors, like endless loops and impossible statements "world != flat if the world is flat then run something".  Usually you pair your developers and have code review.  If it's a serious application that is expected to be maintained you have more lines of documentation than code.  It makes it so code monkey that follows your footsteps 3 years down the road trying to figure out why the flat world code doesn't work can spot it easily.

After all this and many iterations you figure out your platforms, in game terms I guess this would mean server tech, client tech, 3d modeling tech, network layer tech, database tech, source control tech, Q/A tools, Bug tracking software and so on.  For business applications this is a bit easier.  You usually have some of these desitions made for you based what's in house or current contracts (ie this is an oracle shop! or we use PVCS!) but in virgin development this is pretty open.  For a start up you then figure out workstations, local servers, backups and all that jazz with out getting into too much detail.  Figure out how much you want your employees to work remotely (i'm a huge fan of remote work, it lets you up your developer productivity by about 30% but it includes the added risk of IP theft).

This is pretty standard and tons of books have been written on the subject of proper project management, how to run a start up, development practices.  Even some one with minimal experience with about a months worth of reading (depends on how fast you read) could learn and apply all these concepts.

My guess is that at sigil they had a high level design doc, skipped the rest of the steps, in order to increase output left out the code documentation (creating what's commonly known as spaghetti code) and did a standard death march project.  Where the ends justified the means.  Who's fault is that?  I would say any one above code monkey would be at fault.  From look at the f13 interview and subsequent posts I don't even think they had structures close to resembling a development house.  That you could even bypass the process to "sneak" code in, shows just a completely mismanaged product from the top down and I guess also includes the code monkeys as well if this is what they were doing.

One thing I've always been curious about MMO projects is what kind of automated  testing tools are used.  For our web apps we commonly use Astra, for load testing, regression testing and at times for functionality testing.  We can reproduce 10k simultaneous connections to any of our applications, which is probably better than any stress test beta I've ever seen an MMO do and it requires 2 Q/A guys to run (one to set up and one to review).  Is there any applications out there being used?

[Morat20]

That you could even bypass the process to "sneak" code in, shows just a completely mismanaged product from the top down and I guess also includes the code monkeys as well if this is what they were doing

Their versioning was that loose? Hell, we use at least basic versioning for even our dinky little web-apps here, even if sole developer -- just for rollbacks, if nothing else.

[Archimedian]

That you could even bypass the process to "sneak" code in, shows just a completely mismanaged product from the top down and I guess also includes the code monkeys as well if this is what they were doing

Their versioning was that loose? Hell, we use at least basic versioning for even our dinky little web-apps here, even if sole developer -- just for rollbacks, if nothing else.

I have no idea, just going off the FoH post, while I find the opiate allegations of the CEO midly amusing, the "sneak" comment caught my eye awhole lot more.  I would probably lay blame if he was an absent keeper in the old addage that a fool and his money are soon parted.  Granted he did get 30 million from microsoft a suplemental from SOE and an eventual "buyout" which I would assume was an asset for stock deal or a debt pardon (probably both to satisfy MS venture capital) so not sure how much money he risked (I would guess he got his prefered stock from original funding and kept that stock multiplier through subsequent funding rounds).

The sigil story is so similar to about 90% of .com stories as to be pretty funny.  Considering it started 4 years after most people became savvy to these type of start ups :)

[SnakeCharmer]

SWG?  I can speak pretty fluently on.  So, let's take Ranger camo.  Never worked.  That wasn't a question of design (hide the user from getting agro), it's a question of crappy code. 

But all this "WAAAHHGGG it's management's fault!!!" by programmers and coders is doing nothing but playing the blame game in many (but not all) instances.  Do people really need management to tell you to do your job correctly? 

You don't code for a living, do you? Or if you do, it's obviously small jobs where one or two people do the entire damn thing -- from design to testing.

But to answer your question: YES. WE FUCKING NEED MANAGEMENT TO TELL US HOW TO DO OUR FUCKING JOBS CORRECTLY. Why? Because goddamn correct is defined by the overall system design.

Which is defined by management. By the game designers.

Individual coder fuckups are minor, easily caught and corrected. Design fuckups kill your product. Fixing a coder error is easy. Fixing a design error, especially in a live product, is like having your nuts yanked out through your throat.

If you notice the problem for more than a patch cycle, it is almost certainly a design error.

So if the design document says "This is the stealth class.  When activating the stealth ability, the character disappears from view and radar".  And then the designer/manager hands this document over to the coder/programmer, how much more handholding does the coder/programmer need? 

You (not you specifically) need to be told to make it work and make it work correctly without typo/error or anything else? 

Really?

If it doesn't work, do you toss your hands up in the air as if to say Not my fault and blame it on the design document that told you what to do?

Maybe we're arguing two different points and neither one of us is realizing it....

[Morat20]

So if the design document says "This is the stealth class.  When activating the stealth ability, the character disappears from view and radar".  And then the designer/manager hands this document over to the coder/programmer, how much more handholding does the coder/programmer need? 

You (not you specifically) need to be told to make it work and make it work correctly without typo/error or anything else? 

Really?

If it doesn't work, do you toss your hands up in the air as if to say Not my fault and blame it on the design document that told you what to do?

Maybe we're arguing two different points and neither one of us is realizing it....

Well, since my FIRST response to this post was "Learn to fucking read, moron" I would say that yes, indeed, we are discussing two different things.

Since you seem locked into the stealth concept, let us use that as an example. This is how it SHOULD work:

0) Vision document. VERY abstract design.
1) Initial design (management level) discuses multiple classes and PC abilities. Combat, in a MMORPG, is discussed in high-level and abstract way. Things like "ranged combat", "melee combat", "heals", "mezzes", "stealth" etc. Maps, radars, user perceptions, etc. The systems are created in an abstract way.
2) Design of systems integration -- how ranged fighting works and melee fighting go together, how/if stealth can be broken by other players or systems, etc. How systems touch and interact.
3) Design of games systems is done -- fleshing out things like "ranged combat" to include things like hits, critical hits, etc.
4) Coding of design. At this point, the coder knows HOW stealth should work. He knows what should break stealth. He might not have specific numbers (20% chance of breaking on X), but he has a detailed understanding of the way stealth is supposed work with the combat system and can code it abstractly -- specific numbers can be loaded in later.
5) Handoff of design to coder. Specifically "Do the stealth thing now.".

Now, how does that BREAK? Most common cause: Stealth wasn't included in initial design (step 1). Which means it was shoehorned in ad hoc, and often by people who don't fully understand the system designs and thus unintentially fuck with other systems. Stealth was poorly thought out (step 2) and never worked usefull in the game. Stealth was poorly integrated in design (step 3), meaning stealth was never properly designed to work with other systems -- doesn't actually WORK because none of the other involved systems (player maps, player UI, etc, are properly handling the stealthed character).

Poorly implemented by coder -- Step 4. This is the easiest to fix as there should be a detailed explanation of how stealth should work and how it should play with ALL affected other subsystems. If the coder fucks up, another coder can easily step in and figure out where it's not working. It is an easy fix, UNLESS it's not working because steps 1 through 3 were not well thought out.

Not given enough time to implement -- (step 5). This is either easy (give coder additional time to complete) or hard (not enough time because Steps 1 through 3 didn't think it through properly and it's having to be redesigned.

Now, most companies use a form of evolutionary development -- they do things in cycles. They do big design down through little design, implement it simply, see how it works, then start over refining their design. But the basic process is the same -- Big picture down to littler picture, until you've given a coder something he can implement and test in a single cycle.

Where did the SWG camo code break? Probably where something like 95% of serious software problems occur -- at the interface between systems. The camo code probably works perfectly. But if the way camo was implemented by the combat engine, the UI, and the NPC coding wasn't designed properly -- it won't work at all.

Look, a coder's job is pretty simple -- he's given a set of requirements (which can range from vague to VERY specific) and he writes code that meets them. Good coders write cleaner, more elegant code and can generate more robust solutions (there are generally a LOT of ways to handle any problem) from vaguer descriptions. Poor coders need more detailed requirements. And testing against those requirements is pretty easy.

Bugs are rarely the problem. Piss-poor design -- which is the initial and ongoing job of management -- is the real culprit. That's the very BASICS of software development. They fucking teach it in classes, every software company on the planet accepts it (even Agile/Xtreme/Whatnot agree with this -- it's just their coders are ALSO responsible for design, making them the equivilant of MMORPG Devs and leads). That's why the Devs, the team leads, and all the management folks responsible for creating a unified product get all the blame.

Because the mistakes that linger, that aren't easily fixed, that plague your fucking product for all of eternity come from their decisions. Coders and programmers mistakes are so compartmentalized by modern processes that fixing it is more a matter of figuring out where the bug is occuring than anything else, and the bulk of mistakes are caught during coding and at intergration-level testing at the latest.

[Archimedian]

Because the mistakes that linger, that aren't easily fixed, that plague your fucking product for all of eternity come from their decisions. Coders and programmers mistakes are so compartmentalized by modern processes that fixing it is more a matter of figuring out where the bug is occuring than anything else, and the bulk of mistakes are caught during coding and at intergration-level testing at the latest.

Just as a side note, not necessarily true.  I remember one of my forays into (game name excluded) into some pre-release focus group content testing involved a bug that took about a year to figure out.  Their login process for some unknown reason instanciated ports 0-255.  Well I'm sure they had a reason.  It did this randomly.  So it would establish a handshake operation by trying one of those ports.  Obviously the design wasn't very scalable, I mean if you had more than 256 trying to concurrently log in some one is going to have to wait.  With that aside at one point they had a network security review and one of the net techs while looking at logs saw lots of random access to this port 0.  Thinking no one in their right mind is trying to access that port they shut it down.

The result was random cannot connect messages for people trying to log in.  Reproduceable?  Well a 1-256 chance.  Which reminds me of another code bug in an MMO.  Semi well documented by the AC1 devs.  I think they called it the Wi bug.  Where a PC would always get initial aggro when starting an encounter breaking their distance / what ever initial aggro code they had.  I think it took them for ever and if I were to guess at the origins of this bug who ever originally coded it probably put a (if userid = 123 then AGGRO!) so they could unit test some piece of code.  Thinking no one would ever be assigned that userid left it there to be forgotten.  Since maybe 1 person per server would ever be affected and they would also have to be playing that character long enough to notice it, it never went found.

Then again these are logical (and actually code review and implementation issues) bugs and not so much "typos".  I don't think any amount of QA would ever have revealed these bugs and they definitely fall on the code monkeys shoulders.  The difference is, if some one is looking these are trivial bugs, fixable in maybe 5 minutes time.  Core design issues are rarely if ever quick fixes.  It is why you do iterative process prior to laying down code (which you already know any way).

[Venkman]

Congrats on 4000 posts Morat

[Morat20]

Just as a side note, not necessarily true.  I remember one of my forays into (game name excluded) into some pre-release focus group content testing involved a bug that took about a year to figure out.  Their login process for some unknown reason instanciated ports 0-255.  Well I'm sure they had a reason.  It did this randomly.  So it would establish a handshake operation by trying one of those ports.  Obviously the design wasn't very scalable, I mean if you had more than 256 trying to concurrently log in some one is going to have to wait.  With that aside at one point they had a network security review and one of the net techs while looking at logs saw lots of random access to this port 0.  Thinking no one in their right mind is trying to access that port they shut it down.

The result was random cannot connect messages for people trying to log in.  Reproduceable?  Well a 1-256 chance.  Which reminds me of another code bug in an MMO.  Semi well documented by the AC1 devs.  I think they called it the Wi bug.  Where a PC would always get initial aggro when starting an encounter breaking their distance / what ever initial aggro code they had.  I think it took them for ever and if I were to guess at the origins of this bug who ever originally coded it probably put a (if userid = 123 then AGGRO!) so they could unit test some piece of code.  Thinking no one would ever be assigned that userid left it there to be forgotten.  Since maybe 1 person per server would ever be affected and they would also have to be playing that character long enough to notice it, it never went found.

Then again these are logical (and actually code review and implementation issues) bugs and not so much "typos".  I don't think any amount of QA would ever have revealed these bugs and they definitely fall on the code monkeys shoulders.  The difference is, if some one is looking these are trivial bugs, fixable in maybe 5 minutes time.  Core design issues are rarely if ever quick fixes.  It is why you do iterative process prior to laying down code (which you already know any way).

Well, yeah -- I'm not saying that these bugs don't happen. Lord knows coders make mistakes (even awesome and kick-ass ones such as myself.). Fixing them is generally trivial -- finding them is a fucking pain in the ass. (Oh god -- I was away from OOP for awhile, and stupidly was copying nested objects shallowly. Took me two days to work out why a simple copy wasn't working right. I felt like a moron when I figured it out. Net time to fix? An hour).

Design bugs are nightmares to fix. Especially post launch, because your ability to force design changes on other interacting systems drops. Which leads to hacks designed to fake it working rather than force all affected modules to update and "do it right". Which, of course, leads to spaghetti code nightmares. I've got some hacked security solutions sitting around that I'm dying to fix, but don't have the time for -- and I'm not jonesin' to fix them enough to do it unpaid. :)

I should say that coding bugs are often hard to locate, but easy to fix. Design bugs are slightly easier to find, but are a nightmare to fix.

Darniaq: 4000 posts? Jesus, I need a hobby.

[Abelian75]

The result was random cannot connect messages for people trying to log in.  Reproduceable?  Well a 1-256 chance.  Which reminds me of another code bug in an MMO.  Semi well documented by the AC1 devs.  I think they called it the Wi bug.  Where a PC would always get initial aggro when starting an encounter breaking their distance / what ever initial aggro code they had.  I think it took them for ever and if I were to guess at the origins of this bug who ever originally coded it probably put a (if userid = 123 then AGGRO!) so they could unit test some piece of code. 

I had a whole big explanation written of the actual bug, if you're interested, but here's a better, ore correct one:

http://guildwars.incgamers.com/forums/showpost.php?p=5167415&postcount=2698

It wasn't a 100% this person gets aggro every time type of thing, which is what made it particularly devious.  Indeed, the complaint is pretty much what you hear all the time from players complaining about random things not being in their favor, which one can typically write off to the frailty of human perception.  Just in this case they ended up being right.

[Morat20]

I had a whole big explanation written of the actual bug, if you're interested, but here's a better, ore correct one:

http://guildwars.incgamers.com/forums/showpost.php?p=5167415&postcount=2698

It wasn't a 100% this person gets aggro every time type of thing, which is what made it particularly devious.  Indeed, the complaint is pretty much what you hear all the time from players complaining about random things not being in their favor, which one can typically write off to the frailty of human perception.  Just in this case they ended up being right.

Fun bug. I've done something similiar when normalizing values in prep for a random roll (basically wanted a proportionally chance of being selected). I had to use two-part normalization, and screwed up one part. End result looked right, but results were heavily weighted the wrong way. I learned to test that sort of thing more thoroughly -- made me learn to love test tools. :)

[Archimedian]

The result was random cannot connect messages for people trying to log in.  Reproduceable?  Well a 1-256 chance.  Which reminds me of another code bug in an MMO.  Semi well documented by the AC1 devs.  I think they called it the Wi bug.  Where a PC would always get initial aggro when starting an encounter breaking their distance / what ever initial aggro code they had.  I think it took them for ever and if I were to guess at the origins of this bug who ever originally coded it probably put a (if userid = 123 then AGGRO!) so they could unit test some piece of code. 

I had a whole big explanation written of the actual bug, if you're interested, but here's a better, ore correct one:

http://guildwars.incgamers.com/forums/showpost.php?p=5167415&postcount=2698

It wasn't a 100% this person gets aggro every time type of thing, which is what made it particularly devious.  Indeed, the complaint is pretty much what you hear all the time from players complaining about random things not being in their favor, which one can typically write off to the frailty of human perception.  Just in this case they ended up being right.

Thanks, I knew (and this is from vague rememberence) what the bug actually entailed not what the bug actually was.

As to human perception with RNGs, I think the devil is in details on that one.  People want to perceive randomness and when they hit a streak their perception of randomness is broken due to small sample size.  The only RNG work I've ever really done is for producing session state variable assignment.  Meaning when creating a passable key the generation of that key was "mostly" random with a few cheats in there to help associate who that user actually was without making some database calls to find all the session user information.  I'll just call that pre-processing information (nothing to see here please move along) that ensured no dupes could ever exist at the same time.

But here is an MMO slant, if your RNG is truely random but when you look at a specific sample size you see streaks, is that process really random?  Meaning per user their streak chance is high but for your user base it just normalizes.  That's been my experience with most MMOs.  You can sense that some one took a shortcut and is using a predictable seed that while the entire solution is random the specific result is streaks of a non random nature.

[UnSub]

To throw 2c in here: it was found recently in CoH/V that the taunt code worked entirely differently than how it had been documented. It worked, so no-one had questioned it, but certain things were wonky (exceptions to the rule) and not working as expected. One of NC^2's programmers (Ghost Widow) did a line-by-line scan of the code only to find out everything they thought they knew about the system was wrong. So yes, sometimes programmers don't do what they are told and QA would never catch it.

However, to SnakeCharmer: if Vangard had been a world-smashing success, management would have been their to roll around in their money and do the victory speeches. Conversely, when it bombs the failure is on their head. Especially because it failed due to preventable design issues, not uncontrollable factors (e.g. major and sudden shift in market demand, an external patch from MS breaking everything, the collapse of the US sub-prime market, etc).