WotC WotC blacklist. Discussion

[Deset Gled]

I was under the impression that Wizards of the Coast has been quite profitable since the 90s with M:tG. Can you point me towards some information they were having those problems?

Dungeons and Dragons wasn't having problems in 2006, it simply wasn't a big enough market to justify and large expenditures at the corporate level. It was profitable because Hasbro controlled how much money they spent on it.

Here's Hasbro's financial report from 2006: https://www.annualreports.com/HostedData/AnnualReportArchive/h/NYSE_HAS_2006.pdf

Note that D&D is mentioned a total of 3 times, and the only time it's more than an also-ran with Magic The Gathering is in reference to selling it's computer game rights. Brands that get more attention in the annual report include the Game of Life, Furreal Friends, and the Tooth Tunes line of musical toothbrushes. D&D may be getting bigger now, but it was a niche hobby for years.

 

[billd91]

I was under the impression that Wizards of the Coast has been quite profitable since the 90s with M:tG. Can you point me towards some information they were having those problems?

Yeah, I’m not aware of any problems either. But this was under the Hasbro regime with their brand divisions. If they had gone with WotC as the core brand, the profits of Magic could have subsidized D&D - which is probably what Peter Adkison had in mind when independent WotC bought TSR. It was a prestige/vanity purchase specifically to keep D&D alive by bringing it into a bigger company with its financials in order.

With Hasbro’s core branding separating D&D from Magic, that may not have been allowed. And that meant D&D’s ability to be buffered or subsidized was hampered as a core brand.

 

[Hussar]

I was under the impression that Wizards of the Coast has been quite profitable since the 90s with M:tG. Can you point me towards some information they were having those problems?

Oh Magic has always been profitable. But DnD in the Oughts was a rounding error. Just a very small drop in the bucket.

 

[Hussar]

Think about it this way. The entire rpg market other than maybe in the fad years and certainly never since the beginning of the 90’s never broke 30 million dollars. Total.

Has to wanted DnD to grow that by almost double- 50 million dollars as a core brand - with 4e.

The goals were nowhere near realistic.

 

[Mannahnin]

Well, to be fair, it pretty much was. If you’re a large company like hasbro/WotC and you outsource a major promised component of a major product line to a software hour so small and badly organised that it can be completely and irretrievably derailed by the loss of one person, then it’s a disastrously bad management decision. People change jobs, people get sick, people have personal crises and tragedies. Single points of failure are anathema in software dev, and this sad history clearly demonstrates why.

Exactly this. WotC was relatively small, at least the D&D part, but the VTT was central to the concept of 4th edition. The rules re-write was specifically designed to facilitate and work well with the VTT.

This was a visionary idea, and well ahead of its time, but fell prey to WotC's usual inadequate investment in and poor choice of vendors for digital offerings/support.

Dude, come on. The lead developer and his wife, who also was part of the project die in the middle of project development, and you're expecting this to have no effect on the project?

Of course it would be expected to have an effect. But to completely prevent this core element of the edition from launching means not enough resources/people were ever on it in the first place.

Is important to remember that at the time D&D was not a major product line of Hasbro, and the idea of a VTT was an experiment, not a major component of TTRPGs.

It may have been an experiment, but it was a major component of 4th edition as conceived and pitched. It was definitely ahead of its time, but WotC decided to try to solve an issue that's been known for decades- groups dissolving and spreading out around the country, people wanting to play with their old friends. It was a great idea; they unfortunately muffed it.

 

[UngainlyTitan]

Exactly this. WotC was relatively small, at least the D&D part, but the VTT was central to the concept of 4th edition. The rules re-write was specifically designed to facilitate and work well with the VTT.

This I totally agree with.

This was a visionary idea, and well ahead of its time, but fell prey to WotC's usual inadequate investment in and poor choice of vendors for digital offerings/support.

This is a vey common error in management that have no experience in managing big software projects. So much so, that i have never come across a big software software project in those circumstances that delivered.

Of course it would be expected to have an effect. But to completely prevent this core element of the edition from launching means not enough resources/people were ever on it in the first place.

Well at that point they were on the back foot. They had made promises and were now on the back foot, trying to play catchup. I also wonder if they were hoping for subscription income and if the VTT and associated software was delivered as planned would we have had a slower release schedule from WoTC?

It may have been an experiment, but it was a major component of 4th edition as conceived and pitched. It was definitely ahead of its time, but WotC decided to try to solve an issue that's been known for decades- groups dissolving and spreading out around the country, people wanting to play with their old friends. It was a great idea; they unfortunately muffed it.

I think that, that was just part of it, they were also planning to facilitate DM and player connection and the kind of service they are now delivering via DMsGuild.

 

[Oofta]

Most people that don't develop software don't really have a clue how complex development, particularly of back end and networking can be. If someone shows a flashy demo, it looks to management like the product is almost ready to ship.

Add in that most developers also underestimate and it's understandable why most software fails to achieve their initial goals.

 

[UngainlyTitan]

Most people that don't develop software don't really have a clue how complex development, particularly of back end and networking can be. If someone shows a flashy demo, it looks to management like the product is almost ready to ship.

Sadly true

Add in that most developers also underestimate and it's understandable why most software fails to achieve their initial goals.

My favourite method of estimating development time I have ever come across:
For each feature; Take a wild ass guess as to the time,
double it and add 20% contingency.
Then increase the time units to the next one up (minutes to hours, hours to days, etc) then add another 50% contingency and you will still overrun but not by as much.



Edit: On a more serious note; there are way of getting closer to the true time to develop a project but this often comes in at cost that inexperienced management simply cannot believe. Attempts to do it cheaper are often then tried before going back to the guys that know what they are doing and a lot more money and time is spent.
The other element that management often underestimates is the need to bring the workers onboard and the training costs involved.

 

[Oofta]

Sadly true

My favourite method of estimating development time I have ever come across:
For each feature; Take a wild ass guess as to the time,
double it and add 20% contingency.
Then increase the time units to the next one up (minutes to hours, hours to days, etc) then add another 50% contingency and you will still overrun but not by as much.



Edit: On a more serious note; there are way of getting closer to the true time to develop a project but this often comes in at cost that inexperienced management simply cannot believe. Attempts to do it cheaper are often then tried before going back to the guys that know what they are doing and a lot more money and time is spent.
The other element that management often underestimates is the need to bring the workers onboard and the training costs involved.

Yeah, I used to make the mistake of calling out the "unknown issue" padding that I added. Because you never know exactly what's going to come up, but something always does.

Eventually I just learned to build it into my other estimates. That and never give a realistic range because management will just ignore the range and only sum up the low end.

 

[billd91]

My favourite method of estimating development time I have ever come across:
For each feature; Take a wild ass guess as to the time,
double it and add 20% contingency.
Then increase the time units to the next one up (minutes to hours, hours to days, etc) then add another 50% contingency and you will still overrun but not by as much.

Having worked QA for many years, we would take the dev managers' estimates and multiply by 4. Worked disturbingly well.