Andrew Finch
Nik Davidson
Summary
Seemed very strange that it got killed as a project. It sounded as though WotC had “learnt from the experience” but it also sounded very foolish to have haemmhoraged the newly-trained/experienced personnel. That smells like some kind of political battle that got lost rather than a normal operating decision.
NB: The slot for this talk was half the normal length for GDC talks (speakers choose their alotted time period, usually), hence the short writeup – the speakers tried to cram a fair amount in the time they had.
All errors and mistakes my fault, [my comments in square brackets]
Wizards of the Coast
[Wizards of the Coast (WotC) brief background]
2004-2005 – really wanted to be part of the digital age currently in process. Lots and lots of different small internal digital products. Rather than creating separate components and programmes, senior management decided to bring it all together.
Decided to create a framework to allow making new web-based games cheaply and easily.
Have a way for players to experiment with new games without having to leave behind their social networks of friends in order to do so.
Aimed to publish 2-3 games with a shared social networking side.
Aimed to do lots of prototyping/incubation, and then 3rd party developers would write games that plugged in to the backend architecture that our IT group was building. But didn’t want to be forced to accept whatever game was ready next, but instead always have a choice of 2-3 games at any one time that could be published next.
[ADAM: classic description of the way that games companies would like to do incubation, but not many are willing to spend enough cash to do – sounds like WotC were bullish on the funding, which must have been great]
Problems
In reality …
- our tech wasn’t good enough
- 2008: we were way behind schedule
- M:tG online was siphoning off lots of resource
- D&D 4th Ed was also siphoning off lots of resource
[ADAM: M:tG and D&D of course being the massive money maker and the massive RPG brand; no surprise that they get whatever resource they need]
But … in 2008, a new incoming CEO retracted the rule of “don’t mess with the traditional brands, they can only be developed/deployed in their traditional media”. This suddenly gave us loads of design opportunities.
Also, noticed that games that did NOT use the framework/technology/etc that we’d been trying to use … were the games that were successfully sticking to schedule and being delivered as intended.
Changes
Decided to re-think the game-design process. Some people internally wanted to become more like Blizzard, a giant of computer game design, to do vast amounts of polish. We felt that we had to get more experience of actually delivering stuff, stuff live in the market, to earn the experience we needed to become that dream.
Challenge
I challenged internal staff to design, develop, and publish a new game … in 4 weeks flat. Focus on quick delivery rather than awesome design.
Our first game – Art Fight – went up on Facebook.
[Nik Davidson took over here]
Did we – with 8 people – in 8 weeks … build a new virtual world?
Well, yes, but…We didn’t aim to … it just kind of happened.
Usually, you look at the things you couldn’t do, and then asked how can we squeeze more stuff in?
New approach
Let’s give ourselves the smallest amount of time we can use to create shippable stuff.
We moved to doing a game-a-month.
[ADAM: he spoke too quickly (was running out of time) for me to write down the list of roles / skills on the team, and how many of each]
- one week for conecpeting/paper prototypes
- finish point of week1: make sure we’ve made good prototypes of the top two
- pick one of those two
- three weeks for development
- one week to wrap up, bugfix, and deploy
[ADAM: that’s five weeks?]
Tiny Post-mortem
- Sporadic gameplay was a big success
- Fit very nicely with how people use the platform
Co-operatively gameplay was a bit lacking, very little friend stuff.
Server power was very poor early on – no budget.
Replay incentives were lacking – but we fixed this when we noticed it.
We proposed to WotC that we could do this as a marketing thing for WotC. In the end, it wasn’t enough, and the team dissolved.
Conclusions
- Aim small. No. Smaller even than that
- Keep the team small AND autonomous
- Let the platfrom drive the design
[ADAM: very scrum-like in philosophy: he explictly described the autonomy being advantageous because they never had to stop to get signoff for anything]
Questions
What happened to the team inside WotC after it failed?
Some of them are here looking for jobs, some got re-absorbed into M:tG etc.
One reply on “GDC09: Dragonslaying: Facebook lessons learned from Dungeons and Dragons Tiny Adventures”
[…] T=Machine coverage […]