Damion Schubert’s reply to Anthony Burch’s “Fun isn’t enough“.

Gamasutra has posted this story about Damion Shubert’s talk from the AGDC, covering why endgame content is so important in MMO titles.

“The most important thing about your endgame, about elder gameplay, is that it’s one of the few things in your games that’s actually massive. And at the end of the day, that’s what we’re talking about here.”

It’s easy for me to relate to his points about PvP endgame content, with the experience I gained working on Fury. I feel that any MMO that goes the purely PvP endgame route is automatically restricting itself to a smaller player base. There is quite a large percentage of players out there that simply do not enjoy PvP, and would much rather ‘pop bubble wrap’ and socialize while they progress through the game. Often enough this could be due to poorly designed integration of PvE and PvP modes.

There are a number of things to think about when designing PvP endgame content for a typical MMORPG: (Some were mentioned briefly in Damion’s talk, but I would like to expand on that)

• Introduce people to PvP without forcing it down their throats and putting them off. It is often best that you leave it purely as an optional part of the gameplay, and let players gravitate towards it as they tire of grinding monsters.

• Offer PvE players incentives that they can relate to, where ladder standings and PvP accolades may not have any meaning to them. Sets of armor or weapons awarded for PvP achievements, or purely aesthetic benefits such as auras, colored names, titles or other extra details added to your character.

• Keep a wary eye on game balance. If a certain imbalanced type of character is rampaging through your casual PvP areas destroying less experienced players you can guarantee that will be the last time they attempt to get anywhere in PvP.

• Educate people through the game about what makes an effective character set up; A player can be quite happy in PvE with their possibly terrible combination of abilities, but they may well find themselves neutered, ineffective and very frustrated when it comes to PvP. The same goes for introducing basic PvP tactics and strategies through PvE play.

• Don’t set the entrance bar for PvP too high. You need to let people compete on an even field as much as possible. Having high end items in the game that give players a huge edge on the competition is going to make it more enjoyable for the minority that manages to obtain them, but for less enjoyable for the majority getting their asses whooped. Favored solutions include offering basic sets of PvP gear with comparable (if not completely equal) stats to the high end PvE gear, or having all gear conform to uniform statistics when entering a PvP zone.

• Don’t fall into the trap of thinking PvP gameplay is purely arena/RvR/siege style direct conflict. Some of the greatest MMO PvP gameplay in history has been set in PvE zones, attempting to achieve PvE goals faster than another guild or group whilst sabotaging their efforts where possible. Introducing this kind of indirect competition in the advanced stages of the game can make people more open to trying direct competitive PvP later.

• Most importantly, a topic I regularly harp on about (and have already partly covered), visual recognition. Being skilled in a game can make it more enjoyable, but being recognized as skilled is pure ecstasy to a lot of gamers. A good example of this is the Hall of Heroes mechanic in Guild Wars: The Hall of Heroes is the final stage of a multi-map knockout tournament arena, with a king of the hill style mechanic. Every time a new guild or group wins the match and takes control of the Hall of Heroes their names are announced across the global chat channel. Growing your reputation, your brand as a gamer or guild, is what drives most hardcore gamers to play the way they do.

Manage to get all of that right and you are half-way to developing your healthy PvP endgame community. Now you just have to worry about the finer points of exactly how all of this is going to work… But never fear, Lum covers most of that in this blog post on how to make a game with ‘PvP done right’!

Perhaps a bit overdue, but nonetheless, here we are discussing the upcoming Austin GDC! Not sure what others are hoping for, but as this will be my first official conference to attend, I am…giddy, for lack of a better word. The Writers’ Track alone looks amazing, not to mention audio portion and other key guest speakers.  Personally, I am looking forward to the speech: Endgame: How to Build High-End Gameplay for Your Most Devoted Players by Damion Schubert, Bioware, Austin. So, maybe I’m a little biased about this one because I absolutely love Bioware’s products, but it’s nice to know that the company does think about its most hardcore fan base (“They love me. They really love me!”).

And on to some (not all) of the individuals that I am eager to meet.

First up: Rhianna Pratchett. Not only is she the narrative designer for the upcoming Mirror’s Edge by EA Digital Illusions, she put the “bad ass” in Nariko from Heavenly Sword. Plus, she has all but promised me a quick Q&A session – more than likely nothing you haven’t read elsewhere, but I’ll be the one asking the questions. (Insert evil, maniacal laugh here…unless you are Rhianna Pratchett, in which case, you should have only read the first two sentences of this paragraph)

When I think about you, I touch myself...Get it? Get it?!

Another presence that I’m looking forward to is Austin’s own Susan O’Connor. Okay, I’ve devoted two different blog entries to Bioshock’s amazing story so, all of that applies here. Now. To this woman. ‘Nuff said.

Richard Dansky’s workshop is another one pulling me. I’ve actually spoken with him briefly on the phone once, so…I don’t really know what that equates to, but it’s out there now for the record. Can’t I just be excited to meet people in the industry without having to qualify it all? Who are you to judge me? (grin)

That is all I have for now. If you’re going to be there, be sure to stop by the Writers’ SIG Booth as I will more than likely be there most of the time. And say hi to me. I would like to meet my two or three readers!

Repetition ingrains the idea

Design documents are a tricky thing, and can vary in purpose and form depending on the developer.  For some (Naughty Dog comes to mind) the design document is short and to the point — the rest is left up to team cooperation throughout development.  For others still the design document is a modular ‘wiki’; appointed wiki masters manage submissions and revisions by team members, and the document is constantly kept up to date.  And for some, sadly, the design document is just literal documentation; a detailed description of ‘the plan’ that nobody reads and is there to comfort executives.

All of the following best practices are more or less extracted from Damion Schubert’s latest presentation on writing design documents, and from my own experience and schooling.  You can find the presentation here.

Hit the jump for a delicious wall of text.

——————————–Overview ——————————–

What will be covered:

Getting Started

Functionality

Form

The Process

Scrum and Design Documents

——————————–Preface——————————–

The most important point to make is that as a designer, you will always be learning how to write a good design document.  Different studios and different games call for different requirements, and so standardization is difficult, and can even be damaging (ie. formulaic games would be produced).

Another excellent point Schubert establishes early on is that common complaints about design documentation are more or less tied to how you, or the designers that team has worked with in the past, have constructed their documents.  If someone is telling you that design documents are a waste of time, it’s because they’ve been exposed to poorly constructed documents.  Hopefully they weren’t yours.

Important to note is the distinction between a Systems Design Document and other overview-type documents.  That alone should be something you actively think about while formatting your document: you are detailing how a system functions, and in doing so how it will be built.  A system is a number of things coming together to form something complex; make sure the document supports that cohesion.  Documents I have written personally tend to have story sections to keep team members on the same page thematically, but I admit it would be better to contain that in its own document and reserve the actual design document for detailing the game system.

——————————–Getting Started——————————–

Don’t start creating the document in isolation.  Even if you are ‘the doc guy’ your skills are being exemplified by how usable, concise, and detailed the documentation is — it does not mean you alone are designing the game.  This is a more applicable warning to students than professionals, as it can be easy to start thinking you are the one responsible for writing the document in isolation.

Decide on the goals of the game systems so the document has a clear beginning and ending in terms of what it details.  Schubert notes that a design document could probably go on forever, since different systems will inevitably touch and influence each other.  That much detail should be avoided, as it’s not particularly useful but can clutter the document and confuse everyone.

And of course, look at games that are similar to yours and see what you can borrow or use as a guideline.  If your game is a shooter, you’re hurting yourself by not looking at what the best shooters are doing; see how they did something and then determine how you are going to do it or what you will be changing.

Brainstorm, etc.

Now, this is especially vital if your intention is to create a true ‘living document’ that is going to play nice with an iterative design process: the design document should start out simple, outlining what is essentially a prototype of the intended final product.  Test that build, get feedback, then iterate and expand the complexity of the document.  This is the major failing of any sort of document writing class — you can teach anyone to construct a document that can be used as a blueprint to construct their dream game, but you can’t teach iterative development and the documentation that entails outside of making a game.  So in practice, build the complexity of the system as the actual game build grows.

Think of cellular automata; complex things are defined by simple instructions that multiply to create complexity.  Creating complexity from the outset — creating a blueprint — is going to hurt this process, doesn’t make sense for iterative development, and is sadly what I was taught at first.

And remember, the programmers are the ones building the game system you’re writing.  Make friends with them.  Ask them what they want and need from the document.

And lastly, ‘kill your babies’.  It’s rare for a design to maintain itself in its entirety through an iterative development cycle, so be prepared to see your favourite little features mutate or dissapear.  And, just like any sort of writing, if you aren’t prepared to let someone read your document, then you know there is something wrong with it and “it is probably either too complex or too weird”.

——————————–Functionality——————————–

Fewer pages are better than more pages.  A big document is not the goal here.  The longer the document is, the more ends of different systems meet, and the more contradictory your document will become.  Or, it just means you’re not being concise enough.  Be concise.

Schubert has some great examples of the following starting on slide 26 of his presentation:

Create modular sections in your document.  If you have a section that contains all of the enemies in your game and another section that contains all of the weapons, keep them separate.  When describing an enemy and the weapon he uses, do not copy and paste from the weapon section, reference back to it with a hyperlink.  Basically, try not to copy and paste information, be referential.

Break things up into phases and prioritize.  What does this mean?  Firstly, it does not mean ‘describe what you can do conservatively, then describe what you could do with more time’.  Outline what functionality a feature needs to have for the prototype build; what functionality it needs to work correctly; what functionality it needs to have when the game ships; what could be done post-launch (patch, DLC, etc); and what could be done if you had tonnes of money or extra time.  The important thing to take away here is that something might get cut due to costs/development time, and you need to be able to point and say ‘this won’t work if it’s not at this level’.

Illustration.  This doesn’t mean you have to include pictures everywhere, but pictures help.  For example, screenshots of similar games so that people can get a feel for what you’re shooting for.  Diagrams and flowcharts can accomplish this as well, in different situations.  But most importantly, remember that you can illustrate something with text, Schubert calls it ‘example text’.  If you feel that a piece of technical writing requires a summation of some kind you can write a short blurb from the user’s perspective: walk the reader through what someone would do if they spent a minute with your inventory system, etc.

Don’t tell others how to do their jobs.  This comes into effect with user interfaces that are going to be displaying some of the functionality or user feedback of the game system.  Schubert’s point here is likened to how humans perceive abstract representations as compared to a realistically rendered representation.  If someone sees a rudimentary smiley face they’re going to project their own viewpoint onto it: basically, if you tell someone how to do something then you’ve stunted their creative process.  This is a bit tricky since everyone works differently.  For instance, when I design a user interface I’ll often tie the art style to the functionality: if the interface is supposed to be a dirty martian control panel, then I’m going to go into Photoshop and create a control panel.  I don’t see anything wrong with this as long as you make sure you’re not stepping on anyone’s toes.  In such an instance, talk to the artist who will be working on the UI before you go ahead with it.  Make sure he understands why your dirty designer art exists on the wireframe mockup, and that he is to use it only as a springboard for his own artwork to complement the functionality.

So, if you can, describe the functionality and let the artist interpet the aesthetic qualities that should work with it.

Capture your reasoning.  Again, build your document to be modular and compartmentalize things.  State things rather than explain things.  If anyone needs an explanation, direct them to a Frequently Asked Questions section.

——————————–Form——————————–

Form, as in external appearance.  Humans are visual creatures, and generalities that you might not consider will have an effect on them.

For instance, you’ll find on slides 46 and 47 of Schubert’s presentation that he speaks about separating code from content.  When he says code he is talking about functionality: what do the programmers need to do, what are the code requirements to make that feature work.  He takes a large bullet point list and distills it into two levels of functionality — basic and advanced — written in text, with the corresponding content that that functionality requires boxed up in a neat little chart underneath.  Programmers are going to be able to dechiper what work they need to do out of that much better than they would with a bullet point list.

Make sure navigation is easy. If your document has been designed modularly this is no problem.  Include a table of contents.

Find a format and be persistent, but don’t be afraid to break it.  People like things that look ‘professional’, and trust it more.

Be clear.  If you’re going to be using jargon, don’t even assume that everyone reading your document will know what it means. Establish its meaning clearly if you must use it, but try to simplify terms.  Schubert even suggests including a glossary.

Back to being referential.  Don’t let your document be redundant, as it can cause problems when updating.  For instance, don’t copy and paste information from another document as you then have to update two instances later (and may make a mistake or miss updating something), but rather reference the other document with a link.

No weak language. The use of phases and prioritizing should eliminate the use of words like “if, when, maybe, perhaps” etc.  Speak in absolutes.  A system is designed, and a design is concrete.  It may change later, but at the moment of writing that does not matter.

——————————–The Process——————————–

Writing a game design document is not something to be practiced in isolation, so make sure you establish what you need in that first meeting.  What are the team goals for the project, what are the boundaries the team will be working within — how expansive and involved is this game system.

Using phases, concentrate on the phase at hand.  Don’t concern yourself too much with the next phase of functionality.  The requirements for the next phase could change when you’re done designing and locking down the current phase.

Consult slide 61 of Schubert’s presentation for how a design document can “survive contact with the enemy”.

Have an approval process for the design document.  Lead Designer –> Design Team –> Senior Leads/Cross-Team.

Establish a way to visually track the approval process.  Schubert reccommends, on slide 63, using post-it notes on a whiteboard or something similar.

Have a change process.  Things will change, so plan how you will handle those changes.  Have someone act as an arbiter, such as a lead designer, or leave it up to some sort of team approval — this really depends on the studio.  Valve’s change process is no doubt quite different from id’s change process.

Make it searchable — this ties back to choosing a wiki format.

Remember that this is a business and be ready for your producers to tell you what you can never show.

‘Audit’ the process.  Make sure the team is comfortable operating within the bounds you have established.

————————Scrum and Design Documents————————

Read slide 71 and on for Schubert’s more in-depth comparison.

He suggests concentrating your documentation on user stories.  These are short function requirements written in plain english.  This use of user stories is still more involved than how they generally function in other areas of software development, as Schubert creates a user story with one requirement, and several sub-requirements housed within it.

Keep in mind that when you are constructing a user story you are creating tangible work for coders.  You need to be able to estimate how much coding time your requirements are going to take — for one user story operating with Scrum, it needs to be under one week.  Schubert gives some guidelines on slide 74.