Reverse Engineering (185)

April 4, 2009 in Uncategorized

How World of Warcraft has endeared me to the ‘addons’ community, and encouraged me to reverse engineer its design document.

After a year in which I didn’t play many games at all, World of Warcraft has done a lot to revive my gaming hobby. I have taken the odd break to ask myself why I enjoy it so, when I’d not shown any particular enthusiasm towards RPGs or online gaming before. It’s only after I spent some time as lead designer on a team project that I begin to see one answer. The work I did encouraged me to write more documentation, which in turn has let me look at other disciplines to see how design documentation can really be put to use. When my engineering profession inside World of Warcraft grew so complex as to demand real planning of its various ingredients, an idea struck to try and illustrate this process in some form, reverse-engineering what Blizzard’s developers may have used.

World of Warcraft has kept my designers’ brain ticking. In an artistic and cartographical sense, I’m aroused by Azeroth’s kingdoms and the sense of journey within them. In its logic and detail sense, its professions astound me in their complexity. I’m also intrigued by the balance of spells and character attributes, even if understanding it is as blinding as looking at the Sun. I’ve never understood this side to RPG design, though.

Engineering, a profession available since the original release of World of Warcraft, is perhaps the most complicated and resource-rich of those available. For those uninitiated in the game, allow me to explain that engineers are capable of producing gadgets both useful and frivolous, and often comical, from many of the game’s base resources. Combining metals, herbs and fabrics to craft anything from guns to parachutes and motorbikes, theirs is a costly hobby and one which will often demand all the available storage space in a player’s individual bank.

Creating ever more advanced gadgetry as you gain more skill points is no small task. Many professions will require a character to combine parts from earlier sessions, such as by treating leather scraps to make leather, and using the leather to craft an armoured vest. Engineering takes this to new heights, with some mid-level creations requiring five steps or more, and not all of those steps can be accomplished by engineers. Take, for example, a pair of Goblin Rocket Boots. Available from around skill level 150, these boots grant the wearer the ability to sprint for 20 seconds. It’s an ability which rogue-class characters can learn too, and is useful for escaping an attacking foe. For engineers to make it, they require the following:

  • 1x Black Mageweave Boots (a tailoring item, requiring the following:)
    • 3x Bolt of Mageweave (another tailoring item, requiring 5x Mageweave Cloth to make one bolt)
    • 2x Heavy Silken Thread
    • 2x Thick Leather (a skinning item)
  • 2x Mithril Tube (an engineering item, requiring 3x Mithril Bar for each tube, which in turn is a mining item)
  • 4x Heavy Leather (a skinning item)
  • 2x Goblin Rocket Fuel (an alchemy item, requiring the following:)
    • 1x Firebloom (a herbalism item)
    • 1x Volatile Rum
    • 1x Leaded Vial
  • 1x Unstable Trigger (an engineering item, requiring the following:)
    • 8x Mithril Bar (a mining item)
    • 1x Citrine (a jewel found through mining or jewelcrafting)
    • 4x Elemental Fire

Confused? You’re right to be. This one item requires input from five professions other than engineering, and no less than 55 base items in order to make the 10 top-level components. This is just one example of an engineering item, and not a very high-level item at that. Of course, what really confuses the matter is that each character may only learn two professions, meaning that if an engineer already has mining too, they will need to import the ingredients or hook up with other characters.

So, engineers must engage in two responses to the game. On the one hand, it is almost essential that they socialise and develop a trusting partnership with one or a handful of other characters. Engineers will not only require their produce but can also create gadgets in return, such as a salt shaker for leatherworkers to make new treatments for their fabric, or recipes for alchemists to use. On the other hand, this more than most professions seems to cry out for strategy guides, and it’s here that my designers’ brain is aroused. World of Warcraft‘s professions are designed so that each schematic will detail which items are needed, and how many you currently own in order to make it. his does mean that, in theory, you could just bash away at ingredients and consume all your resources until you make the gadget you want, but most of the time you’ll have to rely on a shopping list. I think it is for this reason that so few addons have been made for the engineering profession. Unlike a gathering skill, which needs only a point on the map for guidance, engineering is so complex as to require a sprawling script of its own. For a designer like myself, to contemplate such ideas is inspiring.

Perhaps I may never live up to my fantasy goal of writing all of the necessary steps down, creating an app. or a guide which lays out each progressive step in any engineering object’s creation. he fact I’d like to try, however, suggests to me that World of Warcraft has done for me what dungeon mappers once had with MUDs and old-school role-play software – the urge to document.

Design Document Structure

March 25, 2009 in Uncategorized

Part one of a retrospective on my temporary role as a design lead, writing design documentation for reference and presentation.

Apologies for two weeks of fairly free-form, perhaps nonsensical writing. I’m still very new to this ‘Friday 500′ style of scheme that John McKnight got me onto, but I haven’t been paying its dues recently thanks to ‘crunch time’ at university. Today though, as one half of a module has been sent to the printers and cast from conscious concern, I have time to reflect on the new role I took on as a lead designer.

Before I plunge into the meat of this article, in which I claim some semblance of amateurish insight, some context: for the past six months I have been working first as a level designer, then lead designer for Awesome Cheese’s Floaters – an exclusively two-player co-operative action and puzzle title for Xbox Live and Windows PCs. Inside of a thoroughly entertaining module for my games design degree’s final year, I have been working with four other designers and four programmers to create a demo piece based on this game. While making it, I discovered an utter fascination and passion for writing games design documentation, and so I took the mantle of lead designer.

I feel proud of the work I’ve done, not because I’m confident in the product or my skills, but simply because writing the document has taught me so much. I owe a serious tipping of the hat to Brenda Brathwaite (fast becoming my unwitting guru), and to Mark Baldwin [.DOC], for being amongst a rare number of people actually telling we students what makes a good design document. Even putting the work into practice feels like only a small step in the right direction, but then every little bit of practice helps.

Where we started was probably the same place everyone else starts – lobbing ideas about the meeting room until a few of them go well together, and somebody volunteers to write the useful information down. At the start this was our minutes man, and without a formal document in place the team were able to discuss any new ideas or changes they may have thought up outside the meeting room, via an online forum. Work did start to have to be committed though, so I arranged a wiki installation. It’s from here that I realised how quickly the whole structure of a document can and must change. The first hurdle, as in any large document or general wiki, is working out the structure. How should the pages on this wiki be categorised? Where shall the multimedia go? How should I allow users to navigate the document? As a perpetual fan of the alphabetised bookshelf, online library and neatly-structured Picasa gallery, the hardest thing for me to do here was find a good solution fast – I had no trouble trying to start! So, as in any other coursework or essay, we look to precedents.

As much as it is irritating never to be allowed to see a working design document (at least, from outside of the industry), it is of course understandable why studios would never wish them read by the general public. This then, is the one good thing to come from the canning of a game project. My sole design doc. reference was that written by SEGA Technical Institute for Sonic Mars. Its worth lies in its structure, and particularly in its attention to detail, if not the actual game design itself. Little details like being shown animations for each of the main characters may not occur to a student working without such guidance. As Brathwaite (2008) says, “design docs [..] tell a programmer or an artist everything they need to know to create your game.”

The contents table was revised two or three times before the final structure stuck, and although the details would bore you I noticed a particular change in writing style, as a result of structuring. The best example of this is in a level design pitch, which in my original draft occupied only a few paragraphs. Restructuring that to include greater depth of detail led to vaste swathes of the document being.. fairly unreadable. Brathwaite suggests that designers should “write in an average, everyday voice” – tricky to do when you’ve had to rethink your style thanks to a lack of information. She makes a good point of reminding us that these are colleagues we’re writing for though, and that they may be seeing the document at 3am hoping to find precisely what they need. How does one balance an easy writing style which runs the risk of cluttering, with delivery of cold, hard facts that can turn a disheartened programmer off reading?

Perhaps I’ll never find an answer for that. I certainly can’t think of one now.