We Can Fix That with Data

Two weeks ago, one of the top World of Warcraft raiding guilds announced that they were leaving the game because they were unhappy with the current risk and reward ratio. Despite the fact that the next patch is probably next week, they’ve followed up with a tangent on the trouble with handcrafted content: (copy-pasting quite a bit because the link doesn’t look stable)

Do you want the truth? Blizzard is giving nobody that pays for a subscription to WoW what they deserve. With the amount of money they are making, they should be putting out at least 4 5-mans and 1 10-man per month and 1 25-man every-other month. Not to mention they should probably be adding 1 new battleground each month, and 1 special tournament every other month. […] To be honest, I’m more irritated with this badge loot bullshit […] No, I really really don’t want to do more Kara, more of the same heroics, or anything else that gives badges. That is OLD CONTENT, regardless of the rewards.

Do people that enjoy 5-mans and heroics not enjoy seeing different encounters in different instances? […] . As was said earlier, -everyone- should be getting content. […] It is all being put out in this game slower than it is in AC1, and AC1 has been out for what, 9-10 years, and has less than 1% of the player-base of WoW.

Asheron’s Call 1 has nine years of monthly content updates. They had what, a live team of ten? But they had a famously awesome toolset, and people said they had an obscene retention rate.

Following up on Joe and Damion’s posts, Raph says “a designer who only works inside of data-driven systems will not have a career path and training path to learn systems design unless they are given access to system modifications.”

Well, shit. Somebody tell my boss.

I design “infrastructure systems,” like items and abilities, and I do so all the better because I have years of experience in data management. Five years from now, the live team will be three guys in a cardboard box. If I’ve done my job right, they’ll do more than tweak numbers — they have room for creativity because the systems are well-thought-out and allow for combinations to last for the service’s lifetime. And if they need something the system doesn’t support, they can get an hour’s worth of code and be on their way.

If the player ends up feeling like they’re “wandering through a database,” then the systems were poorly designed.

There’s nothing wrong with design within constraints. That design will be easier to polish, balance, and maintain in the long run, because it’s easier to run a query than to comb through scripts. And we’re failing if we’re not in it for the long run.

Buried away in an article on Zul’Aman, an aside to resurrect an old topic:

We were also told about a philosophical change at Blizzard, namely logical loot. Previously, the loot tables were somewhat random. They’re not going back and fixing years of content, but now, players can expect creatures to drop things that one would expect. If that bad guy is holding a big, shiny axe, then odds are his loot is a big shiny axe. This is a general goal and a monumental exercise in inter-departmental organization* (they need to make sure the artists and loot guys play nice with each other), but one they seem rather committed to. It’s a small touch, but it sure beats wolves coughing up fishing poles!

I’m crying on the inside. I bet the content guys are crying on the outside. I would.

* hahahahaha.

Joe Ludwig’s 10 ways to improve developer efficiency are a great read, especially for all of you folks out there trying to build your first MMO. The problems Joe is avoiding are ones I’ve seen before, and I suspect they’re very common on newbie teams. While he’s talking about making your game easy to build, my god, it also goes a very long way towards making your game maintainable during live service. I can’t overstate the importance of it.

On data and text files, points 2 and 4: it’s also worth noting that it’s an even bigger win if your designers are at all technically savvy. When I was a full-time data manager dealing with text files, I got shit done fast because I took the time to learn Perl. I took the time to learn Perl because I was tired of doing repetitive tasks in text files, and Perl did the job for me. If the files weren’t easy to process, fellow data mangers would be stuck doing those repetitive tasks manually until the end of time. (On a technical note: I understand that Perl isn’t cool anymore, but Python’s regular expression support sucks ass. At least, it did the last time I checked. See also this comic.)

On fast reboots, point 9: this is also valuable in live service. Your servers will crash, you may have to do what we delicately call “scheduled maintenance;” the less time the servers are down, the less time people will have to gunk up your message boards and hate you.

Juice Analytics’ Excel training worksheet is available for download. It covers their previously identified core Excel skills.

I thought I was pretty good with Excel, but a lot of this stuff is new to me. I’m a bad Excel guru. (Nobody tell Damion; he still sends me a lot of Excel questions.) Excel skills are very important for design. That, and data entry. (Tip for would-be designers: go work some shitty temp data entry jobs, and I’ll like you better. It not only improves your implementation skills — faster work, fewer errors — but it exposes you to a lot of bad UIs. Temp data entry jobs are a great way to learn usability.)

The Excel books on my shelf that I’ve read and love:

• Statistical Analysis with Excel for Dummies. No, really! This is a great book. You can read statistics books, which are full of hard math and don’t tell you how to actually implement anything, or you can read Excel books, which tell you how to implement everything but not why you’d want to. This book does both, and it skips the hard math parts.

The Excel books on my shelf that I haven’t read, but think I’ll love:

• Excel Best Practices for Business. It’s about building spreadsheets for usability and efficiency.
• Pivot Table Data Crunching. I just started using pivot tables recently. They’re stupidly powerful and stupidly hard to use. I’m hoping this book will tell me how to build pivot tables that the rest of my team can use.

Ryan Shwayder says it’s fun. Brian Green says it’s a waste of time. I say the data management makes it harder than you think.

We’re all talking about whether or not mobs should drop their equipment. I agree that it’s a neat little feature, and I think neat little realism features can add a lot to a game world, even if nobody consciously notices them. (My pet peeve: worlds with no female mobs. Little thing, nobody’s going to really notice, would make the world feel more organic.) This isn’t a game design blog, though. This is a game data blog.

I worked on a game where humanoid mobs dropped their equipment. When the worldbuilder assigned equipment to a mob, he could specify a drop rate (e.g. “Generic Sword, 25%”). There were a couple of problems with this system:

• When combat formula are extremely complex and mob stat values are different than characters’, it’s already hard enough to predict mob performance without adding equipment on top of it. (We eventually redid the way mob stats were calculated, making all mob equipment cosmetic. This is probably the way that most MMOs should handle mob performance.)
• The treasure system wasn’t smart enough to compensate for the humanoid mobs’ extra loot. The treasure system was balanced to drop stuff worth a certain amount, and mobs with equipment would drop that stuff plus their equipment. Score!

Solution A: Extra Tables for Everyone. Most RPGs have dumb treasure systems. The worldbuilder assigns a treasure table to a mob, and every time that mob spawns, it rolls some random numbers and drops the resulting crap.

You could build a second set of treasure tables and assign them to all the humanoid mobs, but that’s a pain in the ass. (Especially when the treasure system is stupid in addition to dumb, and looking at the tables makes your eyes bleed.) This is what we did. It really, really sucked.

Solution B: We Love Overengineering.You could build a smart treasure system, where you just let the mob know the actual value of the crap it’s supposed to drop. It’d have to take into account the equipment they drop, then add enough extra random crap to meet that desired amount. If a mob without equipment died, it’d get extra crap.

Loot would be more predictable — all mobs of the same level would be equally good choices to kill, reducing the explorers’ joy in finding new camps to exploit for cash. You could engineer the system around that — the worldbuilder could say “these guys drop 25% more stuff than other mobs of their level” or whatever — but then the system is even more complicated. (Also, then the worldbuilders would able to fuck up your careful economic balance. Worldbuilders!)

Solution C: Waste Your Time. Ryan says that you can avoid all these problems by making mob equipment worthless. “Waah!” Right, let’s overburden the item database with totally worthless shit that nobody wants. They might as well just drop melons.

I’m considerate. I don’t want to waste your time. I also don’t want to overengineer the hell out of a system unless there’s a damn good reason, and letting you kill a guy to take his stuff isn’t good enough. And finally, I don’t want to duplicate data and make new treasure tables unless there’s an even better reason, because that work just sucks.

Sorry.