D&D 4E WotC, DDI, 4E, and Hasbro: Some History

After Vince Calouri was pushed out of Wizards of the Coast he was replaced by Chuck Heubner. Chuck basically had to manage Wizards on the downslope from the Pokemon salad days. Hasbro has been through many boom & bust cycles in the toy business and they have a standard response when it happens: cut headcount and reduce overhead. Since Wizards was de facto the only part of the business that had...

After Vince Calouri was pushed out of Wizards of the Coast he was replaced by Chuck Heubner. Chuck basically had to manage Wizards on the downslope from the Pokemon salad days. Hasbro has been through many boom & bust cycles in the toy business and they have a standard response when it happens: cut headcount and reduce overhead. Since Wizards was de facto the only part of the business that had not been rolled up into Hasbro proper it was not insulated by the successes of other things at Hasbro like GI Joe or Transformers.

While this was happening there was a big internal fight for control over the CCG business within Hasbro. Brian Goldner who was at the time the head of the Boys Toys (i.e. half the company) division of Hasbro thought that the company was missing a huge window of opportunity to follow up Pokemon with a series of mass-market CCGs linked to Hasbro's core brands GI Joe and Transformers. These battles resulted in things being escalated all the way to the C-Suite and the Hasbro Board, where Brian lost the fight and Wizards retained the exclusive ability within Hasbro to make CCGs. The downside for Wizards is that they were forced to do things with the Duelmaster brand that they did not want to do, and it never got the traction in the US that Wizards thought it could achieve. (In Japan, by contrast, it became a huge best-seller).

Chuck left after two years and Loren Greenwood, who had been the long time VP of Sales, replaced him in 2004. He was also a visible proponent of the idea that Wizards, and not Boys Toys, should set Hasbro's CCG strategy. Thus when Brian was named COO of the whole company in 2006 and CEO in 2008, Loren had a big problem on his hands. Loren guided the company through the post 3.5e crash of the TRPG market, the loss of the Pokemon franchise, and the unwinding of the Wizards retail strategy. All of this was pretty bitter fruit for hm since he'd been instrumental in building up much of what had to then be torn down. The combination of all these things led to Loren's exit and his replacement by Greg Leeds, who is the current CEO of Wizards.

Sometime around 2005ish, Hasbro made an internal decision to divide its businesses into two categories. Core brands, which had more than $50 million in annual sales, and had a growth path towards $100 million annual sales, and Non-Core brands, which didn't.

Under Goldner, the Core Brands would be the tentpoles of the company. They would be exploited across a range of media with an eye towards major motion pictures, following the path Transformers had blazed. Goldner saw what happened to Marvel when they re-oriented their company from a publisher of comic books to a brand building factory (their market capitalization increased by something like 2 billion dollars). He wanted to replicate that at Hasbro.

Core Brands would get the financing they requested for development of their businesses (within reason). Non-Core brands would not. They would be allowed to rise & fall with the overall toy market on their own merits without a lot of marketing or development support. In fact, many Non-Core brands would simply be mothballed - allowed to go dormant for some number of years until the company was ready to take them down off the shelf and try to revive them for a new generation of kids.

At the point of the original Hasbro/Wizards merger a fateful decision was made that laid the groundwork for what happened once Greg took over. Instead of focusing Hasbro on the idea that Wizards of the Coast was a single brand, each of the lines of business in Wizards got broken out and reported to Hasbro as a separate entity. This was driven in large part by the fact that the acquisition agreement specified a substantial post-acquisition purchase price adjustment for Wizards' shareholders on the basis of the sales of non-Magic CCGs (i.e. Pokemon).

This came back to haunt Wizards when Hasbro's new Core/Non-Core strategy came into focus. Instead of being able to say "We're a $100+ million brand, keep funding us as we desire", each of the business units inside Wizards had to make that case separately. So the first thing that happened was the contraction you saw when Wizards dropped new game development and became the "D&D and Magic" company. Magic has no problem hitting the "Core" brand bar, but D&D does. It's really a $25-30 million business, especially since Wizards isn't given credit for the licensing revenue of the D&D computer games.

It would have been very easy for Goldner et al to tell Wizards "you're done with D&D, put it on a shelf and we'll bring it back 10 years from now as a multi-media property managed from Rhode Island". There's no way that the D&D business circa 2006 could have supported the kind of staff and overhead that it was used to. Best case would have been a very small staff dedicated to just managing the brand and maybe handling some freelance pool doing minimal adventure content. So this was an existential issue (like "do we exist or not") for the part of Wizards that was connected to D&D. That's something between 50 and 75 people.

Sometime around 2006, the D&D team made a big presentation to the Hasbro senior management on how they could take D&D up to the $50 million level and potentially keep growing it. The core of that plan was a synergistic relationship between the tabletop game and what came to be known as DDI. At the time Hasbro didn't have the rights to do an MMO for D&D, so DDI was the next best thing. The Wizards team produced figures showing that there were millions of people playing D&D and that if they could move a moderate fraction of those people to DDI, they would achieve their revenue goals. Then DDI could be expanded over time and if/when Hasbro recovered the video gaming rights, it could be used as a platform to launch a true D&D MMO, which could take them over $100 million/year.

The DDI pitch was that the 4th Edition would be designed so that it would work best when played with DDI. DDI had a big VTT component of its design that would be the driver of this move to get folks to hybridize their tabletop game with digital tools. Unfortunately, a tragedy struck the DDI team and it never really recovered. The VTT wasn't ready when 4e launched, and the explicit link between 4e and DDI that had been proposed to Hasbro's execs never materialized. The team did a yoeman's effort to make 4e work anyway while the VTT evolved, but they simply couldn't hit the numbers they'd promised selling books alone. The marketplace backlash to 4e didn't help either.

Greg wasn't in the hot seat long enough to really take the blame for the 4e/DDI plan, and Wizards just hired a new exec to be in charge of Sales & Marketing, and Bill Slavicsek who headed RPG R&D left last summer, so the team that committed those numbers to Hasbro are gone. The team that's there now probably doesn't have a blank sheet of paper and an open checkbook, but they also don't have to answer to Hasbro for the promises of the prior regime.

As to their next move? Only time will tell.
 

log in or register to remove this ad

Ryan S. Dancey

Ryan S. Dancey

OGL Architect

xechnao

First Post
Christ. That's a lot of money...
I wonder if they would or could ever recover these with their current revenue of DDI subscriptions (of course DDI would have its operational and developmental costs still for what we know it is still in beta and aspires to grow in functionality).
 

log in or register to remove this ad


Mad Hamish

First Post
Depends entiurely on the size of team and delivery contract. The two main methods of payment are time and materials basis (pay each month for the salaries and expenses -- customer eats cost overruns) and fixed price (developer eats costs overruns) with milestone payments (payments made upon reaching specific project delivery points).

Those are the main methods.
In this situation you might get different terms (which could well be part of the problem)
I don't know the details of the company spinoffs and what was going on but I wonder if it was launched because somebody important was a D&D fan and was eager to get in at any cost even though they hadn't got the experience in the area to get results.

For new development with limited requirements and no code basis is almost certainly going to be T&M. No development shop will commit to a confirmed price and milestone payments model because of uncertainties outside their control.

How much will T&M cost? This gets back to the size of the team. Typically, I see 20-30K per month on oversight (program/project management, architectural oversight, customer managment), plus development, documentation, and analysis salaries plus any internal salaries assigned to the project.

It varies a huge amount depending on project size and how the team works as to how much oversight etc is needed (traditional approaches have a much longer design phase than the current agile approaches for instance)

I don't know what SolutionsIQ had done before (they're still around but seem to be more focused on consulting and training than development -> guess based on the website) but if they thought it was worth spinning off a new company for Gleemax and DDI then I suspect that the new development was in significantly different areas from where they'd worked before

Typical bill-out rates are 2x-4x employee salary so a documentation specialist may be billed at $80/hr and receive $30/hr. Senior people especially in solution architecture and development get charged out at in the low thousands per day.

Rates vary a lot by market area, historically game development wages are typically a lot less than business application development

Depending on the engagement, spending over a million a month is notable, but not unheard of. Especially if the client wants it done fast; typically more bodies are thrown at the problem and paradoxically end up slowing the project down (everyone spends more communication and coordination).

"The Mythical Man Month" - released in 1975. Sad that people are still making the same mistake over 30 years later -> as well as a whole heap of new ones being added to the pot.

If Gleemax and DDI were paying enough to justify the cost of spinning off a new company I doubt it would be at the cheap end of the cost scale (It might also be a sign that there was a non-standard funding scheme where Radiant Machine was going to be getting some of the subscription money rather than being paid in a standard manner so that they were sharing the risk)
 

Scott_Rouse

Explorer
I know someone had some base number of subscribers for DDI, how close are they? I imagin board games and the Scyfy movie will help... but I wonder if ANY RPG company makes more then 30 mill...

$30 mil just on TRPGs? no, not is in this day and age.

But if you factor in miniatures, board games, novels, epub, distribution/ecom (like what Paizo does), video games, and other licensed products based on your TRPG property then you might have a chance at $30mm. Video games could push you into the $50-100MM level if you had a really big hit like a Skyrim, Dragon Age, KoTR, Infinity Blade etc.
 
Last edited by a moderator:

Nagol

Unimportant
<snip>

Rates vary a lot by market area, historically game development wages are typically a lot less than business application development

I am much more familiar with business application development costs, it is true. Though they'd probably be getting a bit of "it's geeky fun!" discount, probably not as much as seen on game development. I was trying to give xechnao a feel for the costs. The actual burn rate probably isn't known outside the financial group at WotC and how much internal cost got capitalised as well is also unknowable.

WotC did and does have another networking/game arm in Magic so it would be my hope they could have tagged onto that group, but the internal politics are also beyond my ken. My business instincts are suggesting that wouldn't happen too easily since each brand is reporting separately and extra cost incurred on behalf a sister co. buys goodwill with the sister and hurts with the parent.

"The Mythical Man Month" - released in 1975. Sad that people are still making the same mistake over 30 years later -> as well as a whole heap of new ones being added to the pot.

Some fallacies never fall out of style. "Throw more people into the pit!" and "Sunk costs need protection!" are two I fight most frequently, still.

If Gleemax and DDI were paying enough to justify the cost of spinning off a new company I doubt it would be at the cheap end of the cost scale (It might also be a sign that there was a non-standard funding scheme where Radiant Machine was going to be getting some of the subscription money rather than being paid in a standard manner so that they were sharing the risk)

Yeah, there's a whole bunch of possibilities for setting up a separate companty ranging through protecting the parent from failure, alternative remuneration for key personnel, stakeholder differences, etc. that I don't find the secondary company too telling.
 

Mad Hamish

First Post
This is my field. (Companies hire me to teach them how to organize and manage software development teams.)

As a developer I'll add a few thoughts from the trenches (about 12 years in the trenches as a developer & tester).

The biggest issue is that software is intangible. It's like the proverbial iceberg; for the 10% of the software you can see, there's 90% more required to make that work. And software development is a huge amount of work. Polished, complete products typically take 5 or more people working for months (at least) or years. Big products take much more than that.

And a hell of a lot of the work is in areas that you won't predict unless you've worked on similar things before.

Data storage, speed of retrieval, changed requirements causing redesign, discovering that the framework you were told to use doesn't do what you need it to... (convincing management that the framework doesn't do what you need it to)
performance problems as use and data scale up...

But nobody, not even programmers, are good at estimating how much work software development requires.

There are a few different factors there.

Commonly people are being asked to provide estimates on too big a task at a time or without enough detail. estimating (a+b+c+d+e) without a clear idea of what it should be doing. estimating a and estimating b... (although if you go too low a level you end up with estimates blowing out as well)


There is always something that seems like it should be as easy as falling off a log that turns out to be as hard as log rolling through rapids with termites eating through the log and piranhas in the water.

In most projects you're dealing with some new technology and it's extremely hard to judge how long that's going to take.

Then there are just really stupid estimates and really bad approaches that cause terrible estimates. (I worked with somebody who was working on something he'd estimated as a 1/2 day problem for 3 weeks and was convinced all the way through that it was just a couple of hours away)

Then there was another task on the same project that I'd had to take over which turned out to be way more complex than we'd though it would be because the person looking at it had missed some interactions with how the framework did database saving. I got it working but it took me a couple of weeks for a task that had been estimated at 1 day.

A big thing is that if you pay attention to how your estimates actually turn out and learn from them for the next estimate but this doesn't seem to happen as often as it should.

Remember, it's an iceberg. In one study, 90% of projects took longer than the programmers estimated, even though they updated their estimates as work progressed*. Half of them took more than twice as long. These results are typical.

*http://www.toddlittleweb.com/Papers/Little Cone of Uncertainty.pdf

It's extremely rare that a project comes in much under time or much under budget. I've managed it in a few small projects that I've done by myself.

As I think somebody else has mentioned there are various things that you can (theoretically) control about the system
- quality -> how well the system does the job, this could include be how good the interface looks, how fast things work, what's required to set it up ...
- scope -> what the system actually does
- cost -> how much moolah it takes to make
- time -> how long it takes to develop it

you can't control all of them and there are obviously limits (don't matter what you do it can't be done yesterday and it won't be free)

So even the best-meaning software team has a good chance of taking more than twice as long as their good-faith estimate.

Depends a lot what they're doing.
If they're working with technologies they've used before with a reasonably specified system they should get pretty close.
If dealing with new technologies or with a poor specification then you've got no hope. Of course specifications are hard and always change during projects so that commonly causes overruns itself.
Scope creep is a big issue for most projects


Now for the second-biggest issue. The people hiring software teams don't understand how costly and risky software development is. When they get a schedule estimate, they think of the 10% they can see, and respond, "How it could possibly take so long?" (Remember, this is a reaction to an estimate that's almost certainly too optimistic already.) And then they put pressure on the team to go faster.

There's a lot of truth in that.


Programmers respond to the pressure by cutting corners. Here's the thing, though. The way you cut corners in software development is to be sloppy in the way you design and write source code. But sloppiness creates bugs and makes the source code harder to understand. This is called "technical debt." The net result is that if you do this for more than a handful of weeks, you actually end up taking longer than you would have if you had just tried to keep things clean.

I'm currently cleaning up another company's technical debt...

_sometimes_ you can end with the opposite problem. Something might be good enough but people keep trying to improve it or come up with a better solution where it isn't needed.

They also respond to the pressure by focusing on the 10% of the code you can see (such as the 3D VTT demo shown when 4e was released) and not the 90% required to make it work for real. This shows progress to the business folks, but creates unrealistic expectations about how long things will actually take.

Terrible idea but can happen.

So here's how honest, well-meaning people create software debacles. This happens all the frikkin' time.

Yep.

1. Company asks software team for some software, and asks how long it will take, so they can plan their budget, marketing, and so forth.

Made worse when people put things out to tender, always with too little detail and massively unrealistic expectations.

2. Software team creates an estimate that's 2-4x too low. They think they need 9 months and they actually need 2 years.

I'd like to believe it's not that common that it's that far off but it's more likely the bigger the project is.

3. Company flips out and says 9 months is too long and too expensive. "My nephew could do this in two weeks in his spare time." Demands that the software be done cheaper and quicker.

yep

4. Software team caves and says they'll be done sooner. After all, their estimate is just an educated guess; there's no proof, and maybe they actually will be done sooner.

and then you have the pressure when things are sent out to tender as well or you are quoting on a an external project and management says they need the project

5. Team works on the 10% people can see first, to establish good will and show progress. It's also the most fun part to write.

Really bad idea

6. Company is overjoyed at rapid progress and happily signs checks. "I knew they were sandbagging us with that nine-month estimate."

...

7. Team starts working on the remaining 90%. Company starts pressuring for more results. "You've already shown us everything working, what's taking so long?" Checks signed less happily.

yep.

8. Team takes shortcuts, introduces bugs. Work slows down. Strings company along with increasingly desperate promises of progress.

or decide to use this amazing new product/framework etc which will fix the problem.

9. Company gets more and more impatient and eventually demands to see the actual software, not the demo they got over a year ago.

always a good idea to keep them pretty much up to date with where things currently are.

10. Actual software fails in a big, spectacular way. It's riddled with bugs, doesn't work on the public Internet, and completely fails to protect company's IP. Furthermore, the source code is so badly written it's pretty much impossible to recover.

another classic problem is that it works with a low load but fails completely when the load is increased.

11. Product is cancelled, team fired, and work starts over.

And sometimes all the steps happen the same way...

There are ways of preventing this; the set of approaches I use are called "Agile software development," but it's by no means easy and most software teams don't even know they don't know enough.

or management won't accept the idea...
 

Kzach

Banned
Banned
This is my field. (Companies hire me to teach them how to organize and manage software development teams.)

I'm sorry but all I get from this is that it's the developers fault from go to woe.

At the very start if they were more accurate (and honest, come on, 'good faith', yeah I don't buy that, they're underquoting to get the job...) almost all of the follow-on problems wouldn't even exist, let alone cause projects to collapse.

And then they compound their own problems by being sloppy and throwing more people into the mix and being dishonest to their employer by showing them a false result so as to keep them happy and themselves employed.

Honesty, right from the get-go, would solve almost all of the issues you presented.

Some of what you say would put the blame on the companies employing these teams but when you look at it from a business perspective, they're not asking anything unreasonable. It's the responses that the developers make that turn this whole thing into a massive exercise in fail.
 

Truename

First Post
I'm sorry but all I get from this is that it's the developers fault from go to woe.

...

Honesty, right from the get-go, would solve almost all of the issues you presented.

Sorry, that sounds like armchair quarterbacking to me. I've presented a simplified view of the situation, so it's natural you would jump to a simplistic solution. But the reality is more complex and not so easily fixed.

More honesty would help, to be sure. But it isn't sufficient on its own. Many software teams honestly believe in their estimates. Others present a more realistic schedule, only to be ignored or shouted down.
 

Klaus

First Post
Sorry, that sounds like armchair quarterbacking to me. I've presented a simplified view of the situation, so it's natural you would jump to a simplistic solution. But the reality is more complex and not so easily fixed.

More honesty would help, to be sure. But it isn't sufficient on its own. Many software teams honestly believe in their estimates. Others present a more realistic schedule, only to be ignored or shouted down.
These remind me of building contractors. Any estimate a contractor gives you, you double the time and money and then you get nearer to the actual end result.
 

Nagol

Unimportant
Rule of thumb I use for system design is double the number and increase the time increment one step.

If I think it'll take 1 day, it'll probably take 2 weeks. If I think it'll take 2 weeks, it'll probably be 4 months. It tends to break down after the months stage a bit.

This makes me slightly conservative compared to reality and always draws stares od disbelief when I first present the estimate -- no way it could take that long! I take pains to remind everyone of my original estimate once the system does go live close to my original target.

And this isn't because people are trying to underbid to win business. It happens to internal teams at least as much.
 

Remove ads

Remove ads

Top