Monday, April 13, 2009

Technical Writers

Picture from www.freefoto.com

The writing field of video games almost seems top secret when all attention is drawn towards gameplay, level design, and whether or not stuff explodes. Few and far between know about all the work that goes into sending out memos to all departments, throwing together an instruction manual, or the 500 page game design document that is poured over before a game's production.

Thanks to www.igda.org, I was able to talk to Megan Wiseman, the technical writer for Red Storm Entertainment. Although Red Storm may not be as large as its parent company, Ubisoft, there is still a ton of work involved for a technical writer. See for yourself!



1) How did you get on board as a technical writer of Red Storm Entertainment?

Well, this job kind of fell into my lap. I had a friend who worked at Red Storm, and I originally had been thinking I would try to get on in the Design department--I do creative writing as well, but I don't have anything published yet. So I really didn't have the actual stuff on my resume to break in that way. But last summer, my friend contacted me and said "We desperately need a technical writer, and no one we've interviewed has a clue, or is even someone we like. I like you and I know you know your stuff, PLEASE apply." So I did. And I got hired.

2) What is your typical day at work?

Well, my day is about the same as anyone else's. Or about the same as any other technical writer's. I come in to work, I look at my task list, I pick a task and start working. If you are looking for the types of tasks that I do...that is highly variable, but that is addressed in the next question. If you want a walkthrough of my day...I get coffee; I banter with my co-workers; as I said I pick tasks to work on; I do some work; I banter some more; I might go talk to someone else in the company if I need additional input or have questions about something; I might set up a more formal sit-down meeting if I have several things to ask or several people to address at once. I usually have a brief check-in meeting with my supervisor once a week to let him know what I'm working on, what I am having trouble with, what questions I have, etc. We have a company meeting once a week where all departments give updates. Generally my day is pretty fun, though--I get to hear people talking about the different parts of the projects they are working on, brainstorming ideas for new projects, working through storyboards or blocking out scenes, etc. It's all very exciting.

3) What tasks are you in charge of?

I've done a little work on a game manual, but most of my work has to do with the documentation that the engineers produce in the process of creating the game. How to use the game engine, the editor, and the software tools that attach to the engine; tutorials for the art team in how to use the software; tutorials by the art team for other artists on specific techniques to use in creating game objects; information about the networking and multiplayer capabilities of a game. I also work on process and policy documentation--in other words "how do we do things here?" Sometimes these are referred to as "best practices" documents. Eventually I'll also be documenting the documentation processes I create--meta-documents, or "documents about documents". Confused yet? I do a bit of everything. Mostly because I'm the only one. Eventually a lot of this will be delegated. I hope.

4) Which tasks do you find most rewarding?

That's a tough call. I enjoy working on manuals, though it's a small proportion of what I do now. At the moment my boss is asking me to focus more on "big picture" projects, having to do with the overall organization of our documentation, and our infrastructure for creating, storing, and distributing that documentation. What I'm doing now could be seen more as "information management" or even "information architecture". I'm also working on a project to completely re-do our company portal or intranet. So those are the biggest things, and I think once we get them done it will improve overall productivity and efficiency at the company, so I think it will have a big impact. That makes me feel pretty good.

5) Which tasks do you find most challenging?

See above! While it's rewarding to work on something that will impact the entire company and improve things on a big scale, it's also something I've never done before. I've never been in charge of infrastructure, developing standards, creating processes wholecloth, or building a company portal/intranet from the ground up. All of it is new to me. Additionally, I appear to be one of the few (maybe the only) actual "technical writer" who is labeled as such in the video game industry. Thus, it's a very challenging job.

6) Who do you work with for information and tasks?

I work with just about everyone in the company, but that's because my job function is still being worked out to a large degree. Right now, I'm in charge of ALL the documentation, for ALL departments in the company. Even though we're still a fairly small studio we're growing fast, and have more than 100 employees so it's a daunting task. I'm still getting to know what all the parts are, and who everyone is, and I'm still defining what needs to be done. I work with the heads of departments, company management, group leads, and some individuals. It depends on the task I'm working on. If I need a particular piece of information or a question answered, I'll go to an individual I think might have what I need. If I'm trying to get more general information or a bigger vision of what needs to be done on a task, I might choose a group lead, a department head, or even company management as a whole. When I was working on the one manual I have worked on so far, I worked with the testing team a lot, as well as the lead designer and the producer on that project. So it just depends on the task.

7) What skills or education are required to be a technical writer?

In general, technical writers can have a pretty broad skill set and educational background. As for me, I had an English degree and some personal background in various technical areas. I was fascinated by computers so I had a small degree of knowledge about them, and more important I had the curiosity and interest to learn more. I think that is probably the key skill or talent you need--curiosity and a desire to learn more about just about any area of interest. If you can summon up your curiosity about even a topic you never thought to investigate before or didn't think you would be interested in, you can probably do a good job. Because a technical writer usually stands in for a particular audience, you see. The people with the information you need are so close to the subject they know that they have forgotten what it's like for someone who *doesn't* know what they know. So the writer has to represent all those folks who need the information that engineer or programmer or whoever has in their brain.

So the skills you need are:
--> Good writing skills (grammar, spelling, punctuation, ability to communicate clearly and accurately, ability to write for a particular audience);
--> Curiosity;
--> Ability to get along with and talk to many kinds of people;
good interviewing skills (ask open-ended questions, create more questions based on answers you get, etc.);
--> Ability to think logically as well as creatively;
--> Good editing skills (sometimes you'll have an editing department but more often you'll do your own or you'll have peer edits only)


8) Are you a permanent employee or is it a project-by-project type of job?

I'm a permanent employee.

9) How much demand is there for the tech writer field? How much do small companies rely on a tech writer? What about larger companies, such as your parent company, Ubisoft?

You know, I really don't know the answer to this question. On the one hand, I seem to be one of the few (or only, as I said) technical writers who actually hold that title within the industry. I think that's because so many studios are general small, and even larger companies are usually made up of several smaller divisions or studios. So in general I think people in the industry tend to multi-task and have variable skills sets. Given that, I would say a lot of technical writing gets done, but probably by people who aren't labeled as technical writers as such.

I really don't know what the state of the industry in general is or will be for a technical writer. I think there is definitely room for technical writers within the industry if you can find a company who is willing to hire you. The key, as in all areas of the game industry, is to diversify your skill set; make sure you know video games and love them; and network, network, network! If you are capable of doing something besides just technical writing (game design, programming, 3D graphics, game writing, etc.) you'll probably be a better sell just because most studios, even big ones, are looking for the most bang for their buck. A lot of the technical documentation created at most studios is likely created either by the engineers (meaning it's likely not very well organized, or very clearly written, unless that engineer also happens to have training in technical writing) or its done by the design writers (which could mean anything; most of them at least will have fairly strong writing skills but may not have experience or training specifically in technical writing).


10) Is there any extra information or advice you’d like to give people interested in this field?

First and foremost, don't give up. I first met my friend and became interested in working for his company in 2004-2005. It therefore took me four years at least to get this job! Granted, I wasn't working actively to get in that entire time. I imagine I would have gotten in sooner if I had. But my point is, it can take time to gather the skills and experience you need, or to meet people who can help you position yourself correctly to break in. So perseverance is important. KNOW VIDEO GAMES. KNOW YOUR WRITING CHOPS. Those are the two most important things, I think, besides perseverance and patience. It's not vital to know and play all genres of games, but the wider your knowledge base the more likely you are to impress whomever you try to get a job with.



Thanks goes to Megan for her time!




Thursday, April 2, 2009

The Game Design Document


I'll be honest: I've only written about 5 or 6 college GDD's and they were pretty lame by anyone's standards. So me telling you how design a GDD would be hilarious to the professionals, who have websites dedicated to the stuff.

Instead of telling you how to make one, I'm going to go into what a GDD actually is and what it accomplishes. I will also add in some links to websites if you'd like further help in creating the documents themselves.


What is a game design document?

A GDD is a humongous stack of papers that tells everyone on a gaming staff what the game is, how it works, and every single small and large detail incorporated within the game. It's an exhausting document that makes Leo Tolstoy's War and Peace seem like a children's book. Grant you, the less complicated the game, the shorter the GDD. But for large game worlds like Grand Theft Auto or Kingdom Hearts, these documents can be anywhere from 200-1000 pages.


Who is in Charge of Writing it?
This usually depends on the company. The most common way of doing it is to have everyone fill out their own pieces and then the lead designer puts it together and makes it shiny. If there is a technical writer on the staff (which isn't as common as you may think) they usually have a hand in it.



Why do games need such a big friggin document?
If you're a studio of 3 or 4 working in someone's mother's basement making an arcade game, maybe you only need a few pages of memos. But if you are Ubisoft, Square-Enix, or EA Games and employ 100s of people, you're going to need one.

A GDD tells everyone what's going on at any time. If something changes, it's in the GDD. It may not seem like it, but this document saves buttloads of time down the road.

Not only is it important for the developers, but for the publishers as well. They look at the GDD to see if they want to fund the developer or not.

So make sure it doesn't suck.


What does a GDD Cover?
Everything. Seriously. Here's a list of some of the things a GDD covers:

  • Why you should play this game
  • What sets this game apart from others
  • Characters and Controls
  • AI and Enemies
  • How the World is Set Up
  • Storyline
  • Graphics and Engines
  • Scales and Objects
  • Camera and Lighting
  • Interface and Sounds
  • Weapons, Health, and Special Abilities
  • Single Player vs Multiplayer
  • Etc

How does the template work?
Depends on the company. There really is no set way of making a GDD except for a few things: First, the beginning pages are the ones that make the readers (AKA publishers) excited about making the game. Second, there is always a well written table of contents. And third, everything about your game is easy to find and well written.

Other Notes
GDDs aren't really meant to be particularly exciting nor creative. They're just a reference for publishers and developers. So if you're a college student and you find writings up GDDs boring, just be grateful yours will only be 5-20 pages instead of 500.

Conclusion
All game companies have GDDs. If you want to be a game designer, you're going to have to learn how to write them well. If you want to become a game writer, it wouldn't hurt to know the strings.

Great Links
http://www.gamasutra.com/features/19970912/design_doc.htm

http://www.sloperama.com/advice/specs.htm

http://www.thecorpament.com/the_importance_of_design_docs_in_game_development.html

Templates
www.runawaystudios.com/articles/ctaylordesigntemplate.doc

http://www.cowgodgames.com/articles/designdoctemplate.htm

Examples
https://www.digipen.edu/fileadmin/website_data/gallery/game_websites/Claustrosphere/GDD.pdf

http://gamasutra.com/features/20070220/bateman_01.shtml