How much detail should a designer be expected to document for their team?

News & General Discussion
1

I’ve got a question for other developers out there because it’s an issue our team struggles with and I was curious how other teams handle it. Typically in a project, there is a designer, or team of designers, who create a blueprint to be passed on to a production team. It can be called any number of things, usually a design document, and it contains assets, features, rules, etc. that describe how the project is intended to function. My question is, how much should a designer be expected to document, or design, for this document to be useful and effective?

There is a certain level of iteration that is expected in a creative project, especially one involving something as complex as software development. It’s unrealistic to expect a completely finished design to be documented because of this. Also, most designers have little or no experience with the tools and processes involved in creating the thing they’re actually designing for, so it’s also unrealistic to expect something on the level of an engineering document. However, when developing it is important to have a clear idea of the expected behavior and subsequent effect on the system. For example, it may be designed that a NPC in a game can be killed. For a developer, this implies other things like death states, quests or missions being active and available, animations and audio needing to be created and then triggered… and also brings up new questions like “Can the character respawn? If so, how long does it take to respawn?”. This area has been kind of a black hole for our team and is typically a source of confusion and frustration when developing. Generally developers are working on such a low level that they don’t have time to think about higher level functionality like this. Conversely, designers have to keep the big picture in mind and can get lost in lower level details.

How do you guys handle this situation? Where is that line drawn and what determines who is responsible for what?

2

What kind of a question is that?
Would you buy a half baked bread?

Everything that is going to be in the game.
Quests, story, items, NPC, world map, main characters. Everything, that’s his job. Is it not?
From an artist or a programmer or a musician you’d expect the work according to their trades.

3

Those aren’t lower level details, those are design questions and should be answered by the design team. The designer should spec out exactly what death means to the npc.

That said, it depends entirely on the development situation. I personally tend to work with other developers who are also strong designers; technically I’m lead programmer at Sortasoft and on our project ‘Meriwether.’ However, I regularly work off of very short specs and fill in the design myself. Generally our process is…

Designer assigns a ticket to programmer/developer. This ticket represents a direct request to implement a feature or fix a bug, and includes as much detail as the designer thinks is necessary (varies wildly based on the assignee’s familiarity with the system being implemented).

Developer reviews the ticket, if sufficient information is given - or the developer feels comfortable and confident filling in the gaps themselves - they start developing. Otherwise, they add a comment to the ticket requesting more information (and explaining what they need to know / aren’t sure about) and, if possible, starts implementing what they can. Otherwise they wait for the ticket to come back to them.

We have weekly meetings to discuss in very little detail the broad strokes of what we worked on last week, what we plan to work on this week, and anything that’s holding us up from being able to continue. Personally, I discuss things daily and in pretty great detail with the lead designer (Joshua DeBonis) - so we tend to be very much in sync with these things.

Our process works quickly and with little complaint on either side because I’m a designer as well as a programmer and my boss (Josh) is a designer with a strong understanding of programming. He may do almost entirely design work and I may do almost entirely programming work, but we both have a firm understanding of what the other person does. That said, the exact same process works fine on teams where both sides know next to nothing about the other side - the tickets just need more detail.

Your designers need to provide however much detail the implementing developer needs to do their job. That said, I giant living design document is a very, very poor way to go about this. I highly suggest using a ticket system where individual features/bugs can be assigned as tasks. It saves the implementing developer from having to dig through giant design files, it saves the designer from having to create giant robust design files, and it allows for the easy passing back and forth of exactly what information is needed (and assigning of priorities). Tickets are king, baby.

tl;dr - Tickets / tasks are insanely efficient compared to giant design bibles. Expect everyone on your team to do exactly their job and nothing more; the designer is not an “idea man” - he is a designer, and a lot of that is filling out specs for implementation.

4

Honestly it’s tough not to feel that way being a developer (and trust me I can relate), but like I described, it is unrealistic. Designers usually don’t understand all of the implications of the things that they design. Also, they can’t be expected to know every detail that will affect the design on a lower level because they operate on such a high level. This issue gets exacerbated the larger a project is. A design document tends to be very fluid for these and other reasons. The reality is that the design document, like much of the rest of the project, is a collaboration. The question is: how far is a designer expected to go?

5

Because they operate on such a high level? Heh, what kind of designers do you work with? Some airy fairy folk in an ivory tower handing out directives and accepting no quibbles?

Whatever that someone actually creating the design has to ask a question about? Should be in design doc - or written down somewhere, with diagrams where needed - and if it isn’t, then it goes in there.

6

Thanks for the breakdown. I like the ticket idea… it breaks down the whole process into manageable bits. Do you update a master document with the changes? How does someone new to the project familiarize them self with it? How do you know what has changed since its inception?

I myself am a programmer/technical artist and so work on the development end. My main reference for design and production organization is The Art of Game Design by Jesse Schell and he breaks the documenting process down into around seven or so documents based generally on different skill sets. As for the design document itself, he says it is typically abandoned around half way through the project, which has more or less been my experience.

7

Lol ehhh… no comment. However, I can relate to losing track of lower level details because I myself can lose track of the larger scope when working on the low end.

8

There is a lot of wisdom in what Kyle wrote. The game doc, the core game doc, can layout the broad strokes, overview, gameplay, narrative flow, milestones… basically the girders of your game’s design. But once the project is underway many of these aspects will change or evolve. Design changes may seem casual, but often represent a nightmare for the devs. The more detail that can be provided as to the scope of such granular events as deaths, spawning respawning requirements, the more information the dev team has in determining how to implement them.

A ‘ticket system’ seems like a great idea to prioritize and implement more concrete and feature locked items and or required fixes. Assuming you’re discussing a Indie project with limited budget and crew, the designer’s role in providing such information is more important than ever. If they feel they can’t handle it, perhaps they shouldn’t be in that role? Or break up the responsibilities (i.e. Environmental models, Gameplay, 2d Artwork…) between several designers so you minimize overlap and clarify who needs to step up.

9

Indeed, it sounds like you have a real issue there.
Looks like your game designer is rebelling.

From what I get you have a small team of developers.
What are we talking about? Are you a legal registered company and all of you bound by a contract? Or just a “when I have free time I make games” collaboration.

In big companies it is actually not welcomed to interfere into game designers work at all.
Imagine one day your game designer pops into programmers department and says: " Me and some guy from an art department were drinking beer yesterday night in a pub and came up with a new damage system and the team manager said go ahead with it". Not that they still have tons of work on new shadders that some other guy suggested to the team lead. But now they’d have to redo that damage system all over again.
The same goes if a programmer suggests to add some new exotic level to the game, hence more work for the artists.
Anyway you get the point here.
What matters here is that it all depends on the role of the Team Manager, he makes his decision if he sees a beneficial value in it

In small companies like KyleStaves everyone works in very close environment, involved in almost every process of game development. Nourishing and taking care of the game as if their own child because they understand their future depends on it. While in a big company if one game fails there are 2 more in development.

And if you in a very small team, a circle of friends or some people you met on the internet, working for free or for some promised fortune. Then do not expect people investing their time while there is no food on the table.

So my advice here, since he is not obliged by a contract, you’d have to go easy on him, sweeten him up, praise his every effort, tell him how great he is, and hope this would motivate him.

10

Responded inline. The biggest thing to remember is that everything you do takes time; if you have no real use for a thorough master design document there’s no value in having one, and the time it takes to maintain is wasted.

I find this pretty true as well; generally a game starts out as a design document and once production really starts that gets converted into tasks. Then the “state of the game” is largely maintained as a series of tasks (which are rejected or modified as the design changes/iterates… new tasks are generated as well of course). It’s far more efficient than maintaining some centralized design bible for smaller teams - the only time I really see a value in a design bible is when you have a large design department that you need to keep synced.

For what it’s worth, in the case of a living design document approach - I find wiki’s to be significantly more efficient than word documents and the like (not just in terms of generating content, but in navigation/iteration). Wiki’s are awesome.

11

You should not be working with a designer that is this clueless. True, your designer will not know how to program. Nor will they be able to create a 3d model, or compose a musical score. They should, however, understand how that all works.

Otherwise, its like someone “designing” a car, and telling the engineers that it should hover 3 feet off the ground, run on coffee and get 800 miles per pot. First… coolest car ever. Second, IMPOSSIBLE to build.

Your designer will not (and should not) know the math that goes on behind the scenes, the poly budget per model, etc. That should be left to the programmers, modelers, etc. But your designer had better know whether or not characters respawn! Basically, the designer should have played the game a hundred times in his head, and be able to describe it to you perfectly.

12

I’ve worked in many game company (well actually 5), and they all have their own practice.

The one I prefer:
A designer has to do a small document ( between 4 and 10 pages ).
He will describe the core gameplay, but also every screen like if there is a progression screen with XP point and where the player access it (player game flow) etc…
But of course not too much details. It’s interesting to know that the player can have a shotgun and that the number of bullet is not infinite, but how many bullets max or how many shots kill a monster is something not relevant on this document.

Honestly I also personally think that it show that the designer know where he go and that he is not a fraud…
The team can then ask questions on it. It helps have a starting point of a discussion. Some modifications can be made.

Then we have a document describing the first version of the game.
This document don’t need to be updated after that !

The designer work don’t end here:
When a programmer start a task (implement the weapon system for example) he should ask the designer every details.
The programmer can also propose better developpement cost solution during this discussion.

After that you really should have a first playable solution very quick.
Until you get it, you shouldn’t change anything or add anything. Well unless you want to triple your developpement time for the same result or if you want your project canceled.

And then there is playtest (by your team, by external people). The designer has to observe player, listen to them, and manage the adjustement with the programmer.You iterate as much as you need

If someone want to know where the developpement is, he can just play the game… The document is outdated but no one cares.
If you don’t have a first playable version, of course it’s harder, that’s why a first playable is very important.

13

Thanks for all the replies and feedback. We’re looking into a ticket system now as we’re almost done with our current project… turns out we actually had the system just no one has been using it.

I think this rings true for us also… and I’ve definitely felt the pain of having to rip out entire systems just to squeeze something into the middle of them that wasn’t considered initially.

14

The following 3 things exist in every single game, and should include detailed information.

Basic Rules
Player Controls
Game Mechanics

If a programmer asks you what would happen when X and Y happens, you probably weren’t detailed enough.

Examples of detailed information (IMO):
Basic Rules
It is a multiplayer 2D game, with up to 12 players
All players start with 125% health
To win: Reduce the health of all other players to 0

Player Controls (You can add the control scheme later in the document)
Movement: Forward, Backward, Left, Right
Shoot
Jump: Upwards

Game Mechanics
Camera
Camera is set to orthographic view
The camera is always positioned above the player looking down

Players
Player character always looks towards the mouse cursor
Same weight as a full grown rabbit

Health
Regenerates 3% health every second
Can not regenerate above 100% health

Bullets
A bullet deals 10% damage to players

15

For a ticket system I can highly recommand PivotalTracker I’ve been using it for some years now. Even when its just me and an artist. Its a great way for assigning and prioritising features and bugs.

16

We are going with wikipedia approach. As lead designer, I’m filling all the little bits of information, well structured, when someones asks/dislikes/needs more info I can update every page, also anyone can alter pages if he to add some changes to art/formulas e.t.c Every day I review them simply using “recent changes” tab. Being coder myself helps a lot, usually I know how to present tasks to every member of the team. I’m more then positive, that it is essential to be multi-purpose person for the game designer, if the team is small. Only for large teams it is possible to have designer with lack of knowledge in some fields, as other person can take a role of formalizing his ideas.