Game development without design document?

News & General Discussion
1

Hello everyone. I’m new here, so pleasure to meet you (and don’t kick me too hard if my topic is old or dumb pls :))

For me personally, writing design documents is a torture. Not because I cannot express my thoughts or because I hate to write, but… Well I don’t really know why. It feels like I should be making games, not pages filled with letters.

One other thing is that long thinking over the paper kills enthusiasm. You cannot see the result for your work. You cannot test it or check if your ideas work. So after a while team just fall apart and you just silently put your project aside.

My point is
When you are making other art like drawing or writing or coding, you don’t sit and write down all the little detail of your picture or program. You know your theme, story or feature set that you want to achieve in the end and just start working with that.

Some preparations are made, of course, like characters, plot point, guidelines, class hierarchy and basic workflow. But you don’t describe every action of every scene, every line of dialog, every muscle and piece of close, every variable and line of code beforehand. Then why it is so different with game design?

Problems
First, games are complex and there is a lot of people working together to make them.
Second, games are complex and made out of different kinds of art, that should work together to create an experience.
Third, time is a big issue, no one wants to spend hours on work that is going to be redesigned later.
Fourth, time again, you need to meet your release dates and can’t just say “when it’s done” (unless you are Blizzard).

And the last problem in my opinion is that design document does not solve any of those issues in a long term.

Methods?
Let’s imagine the a game development workflow without design document.

There should be some starting guild lines, so every one knows, what game they are dealing with. What those guidelines should be?
One method that I know of is Design Canvas (google if interested, or ask in comments, i’ll provide some info)

Design Canvas (my understanding of it)
A helpful link (original site is down, so gamasutra)

The Design Canvas is a small (2 to 10 pages) document, that describes the game, but provides only the most basic info. Think about it as My Game Idea document.
It helps you write down stuff that pops in your head as ideas and fill in some blanks, to make it a full, but basic game description.
The document is divided into five main parts.

Core experience - is a very short (1-4 phrases) description of the focus and overall feeling of your game. Like Soldier on the modern battlefield (Battlefield 3). Or a Hero saving the galaxy (Mass effect). It helps feel your game and set focus to what is important.

Basic mechanics - what buttons player presses, while playing the game? There goes your controls and play style. Like first person shooter with WASD controls, or touch enemy to shoot it. You can go deep and describe all of your controls, or just mention the most important or original ones. It helps to imagine the gameplay.

Reward and Punishment - what is the rules of your game? What would you like your player to do and how are you going to guide him? What is important to the players gameplaywise? Like you don’t want the player to take hits from the monsters, so you give him a health bar and when he runs out of health, level resets. Or may be you want player to collect stuff, so you show a cutscene, every time player finds something and so on. Again you can go deep and describe all the rules, bar, stats and values in your game, or just fill in the most important or unique. It helps understand the player behavior in your game.

Aesthetic Layout - how does your game look and sound? What is the art style? What kind of music is going to play in the background? Everything that related to visuals and sound goes here.
As a subpart here goes the story and the way you integrate your story into the gameplay. Is it linear or player have some choices to make? Is there cutscenes (mass effect) or everything is gameplay (portal, half life)?
This section helps to images the game world and story.

Long term incentive - what is going to keep players in the game? Is it replayable? Is there going to be new content or unlocks or more difficulty levels? It helps define the future of the game and understand is it fun enough to keep players playing.

Check out google or link above for more info.

How can you keep people updated with latest changes and decisions?
One of the methods that i know of is Design Logs (pretty self explanatory)

Design logs (the way i understand it)
A helpful link

The Design Logs is a document that holds updates of the game design in process. It is basically a log of decisions, issues, updates and goals, that describe the current state of the game and the current goals and issues, that should be addressed.

Updates - the log is made of updates. Each update have a date as the title and a short description of the design process. The description includes:
Ideas that worked - if you think that something works and should be left alone, at lean for now, like: new grenades work just fine
Issues+Solution - if you find something in new build, that is buggy or you don’t like, example: the damage of the new sword is way too high, nerf it down to 100 from 140; or: new Sleep skill for the mage does not give this class the playstyle that we wanted to, consider changing it to Blind skill
Prioritized next step - what to do next and in what order, like: implementing new abilities of the mage class
Tasks accomplished - if some major piece of work is finished, that state it, like: parkour is fully implemented and working just fine
Experiments - stuff that you are not sure about, but want to try, like: let’s add some flying spiders to the Forest of Doom level :smile:

Tips:
Keep it short. If you don’t have to, don’t write it. Keep the length of an update so it can be read it 5 minutes.
Prioritize. Write stuff that matters now. Specify the order of next steps, if there is a lot of them.
Make sure others can comment. It should not be a monologue from the High Commander. Discussions help the project grow.

This approach helps to resolve multiple issues:
You are not limited by the design document, so you can grow your game the way you think it should, and take turns if needed.
Allows to jump to the development and actual prototype as soon as possible.
Keep everyone updated.
Focuses your team on most important tasks.
Can quickly provide all the needed info to the new member of the team (especially with Design Canvas)

Google and see link above for more info.

How can you prevent people from wasting hours on things that are going to be changed later? (It’s safe to say that 90% of art in alpha going to be replaced)
One of the methods i know of is Thin Slices (google or ask for more info)

Thin Slices (the way i understand it)
A helpful link

A Thin Slices is a development method, that allows to develop and change content without artists going crazy. Or in other word a process of game development with quick iterations as the centerpiece.
And by saying quick, i mean very quick, faster then you are comfortable with.

The few basic ideas is:
Prototype. Prototype fast. Prototype a lot. Prototype everything. Treat it as a prototype.
Don’t overpolish. Things will change. Keep it in mind all the time. Better make next step in iterating, then the polished version. It will save a lot of time and nerves.
Reuse assets. Prototype with what you have, then change it to prototype of what you really need there.
Switch back and forth between assets. Jump from one asset to another few times a day.
Polish when your asset meet all the requirements (like artsyle, render time and so on).
Iterate and gather feedback fast and a lot. Every day or twice a day.

This simple rules will help you resolve issues with:
Wasting time on polishing.
Keeping the enthusiasm up.
Save nerves of artists, because when you know that you are prototyping and you jump back and forth between assets, you don’t get too attached to assets and can change them.

Google and check link above for more info.

How can you estimate dates in such a workflow? (I have nothing here)

Or may be all this is just a nonsense and Design Document are mandatory?

Please leave your comments. Share some methods and techniques, if you did use something like that, or your thoughts on the subject.

2

yeh its a difficult one, our current game we started without a GDD, I found it hard explaning to new members about the game as i didnt know enough about the game.

Instead I (secretly :p) wrote a small GDD with just the essentials on it, then i mostly use it as a reference and also send to new members so i dont have to repeat myself too many times. It definately is a very useful document, maybe you should write a brief one and make changes as you go along?

3

I agree with adam, I’d definitely get one done, it’s so much easier just to send one to someone rather than explaining the game.

4

At simian squared we thrash out ideas vocally and pick whatever sounds fun, cool and meets the current business goal, then we make a prototype, no GDD.

Then once the proto has been played and we agree we want to go further, we make a full GDD. There is no escaping the fact that a GDD is essential in a team environment.

If you’re just one man messing about, a GDD often isn’t required at all. It is mandatory in a team environment otherwise your programmer will get incredibly pissed off at random changes, and your art team will just be saying WTF every 5 minutes and throwing their wacom pens.

Put simply, a professional team will make a GDD, and allow some wiggle room at milestones to fix what isn’t working out perfectly in practise. It’s important most of all for teams, not individuals.

For teams, yes, mandatory.

5

Thanks for your replays.
On the subject of small GDD and updating it, there is a methods called Design Canvas on Design Logs. Those help solve this issue and provide some guideline of how to use them.

About the artist throwing their wacoms to the window after “one last change”, there is a method called Thin Slices.

But i think i’d rather write them down in the 1st post, so anyone can see it. So going to update 1st post with some info. (it can turn into a big pile of text, sorry :()

6

Of course you don’t! That’s not what a GDD is about at all. A GDD may actually include almost all lines of dialog since there may be a story script tied up to it, but everything else is overkill. A GDD describes features, highlights, goals (this level should inflict fear, this one is a relaxing breath catcher, this one pumped up action, this one a lot of pitfalls and a nazi plane, etc etc.)

The GDD is there to make sure you know what to do next. Sometimes they can be very extensive, sometimes they can be very lightweight.

You CAN make (solo) a game without a GDD, but it will likely take much longer because you are running about without goals and therefore have no clue when enough is enough to make things complete. With a GDD at hand, not only can you say “ok this level is done, next!” but you can also tell “11 levels out of 15 complete… 73% done! Almost there!”

A game design document, for instance, is the reason why a game like the original Super Mario Bros had 8 wolds each split in 4 levels, with the 4th always being a castle that holds a fire breathing dragon.

7

Starsman Games
So you are saying that you don’t have to describe every type of trap and enemy and background and graphics and all the other stuff in each level before you even start the first one?

And i do believe that there are other ways to set goals and know what to do next, even without GDD, like having plot planned out a bit and a note that says “think about the next chapter of the game and how far we are from ending”.

My point is GDD is overthinking ahead, but things are going to change (changing GDD, that you spend so much time writing, ough) and you can get bored with it before being even close to the development itself.

8

That’s why you, especially as a solo developer, would want to leave some wiggle room. You want a filled-in outline, not an in-depth technical guide that goes down to the minutiae of every last little thing. Things need to change at times during development, and it is of little benefit to write it exactly. However, providing a good milestone guide, a components and modules guide, planning out what you’ll need to make and test, etc. is absolutely worthwhile. It will help keep you or your team on track, give everyone solid and clear/concise goals, and provide a design guide for the overall game.

Make sections and subsections for everything, and fill in what makes sense to. Just like if you were writing a research paper, you’re not going to want to effectively write the entire thing, before writing the “real” thing. Make it useful to yourself and your team, and be willing to change/revise it as development is ongoing.

For example, a section might look like this for an enemy, that is good:

A bad one might look like this…

Basically, you want enough detail to make things clear, but not so much you leave no tweak room/room to implement the actual behavior. The important thing is that a GDD should be a “living document” open to modification as needed. Notice how the top quote’s text is broken down into clear sections with milestones that can be reached and noted, with possible changes broken off from a main behavior. The bottom quote for example says much of the same, but is too short to provide a clear guide. Plan ahead, but don’t overplan. Only plan when and where it makes sense to… test prototypes of things so you know what you need to, before making a design.

9

This is how I normally design my games: Think about your idea, tell it to the team and get their opinions, have a mental plan for a prototype, if it succeeds then make a simple GDD so everybody knows what to do, work hard until it is finished.

As it has been stated many times in this thread before, a game made by one person doesn’t need one, but it should so you can keep yourself on track. Studies also show that if you plan your days out a day before then start working on it as soon as you wake up then you will get the tasks done faster. So a GDD is always good, even a very basic one.

10

I have added some info to the 1st post. I’m not saying that it is the best way to develop the game, but those three together is better, then GDD in my opinion. Please comment, what you think about it.

11

I am definitely working without a GDD… I usually have a strong vision of what i want… i work alone on my games so it is not a necessity to bog myself down in details of a document… I’m also a visionary so the thing I see can be easily seen in the final result… (I have Asperger Syndrome)

12

It’s a ‘it depends’ case. I’m working on 4 things at the moment. I’m just finishing off the second GDD for a trilogy of 3 HOGs. These require a detailed GDD because these games rely on picking up objects etc, sometimes in a particular order and can be surprisingly intricate and quite large games from a finicky POV. So a GDD is needed . My last 2 have had a GDD of 150 and 64 pages respectively. So quite large.

I’ve had a template made for Time Management games for a different game engine, largely to create a random level generator that creates gameplay so the GDD for this was 10 pages laying out characters, NPCs pickups, general game stuff but no great detail because these games need a lot of QA and testing and need tweaking to the nth degree and nothing can be laid down in stone except for the art.

A programming partner is working on a demo for a wii U game and the ubiquitous kickstarter campaign (there’s a game which will never see the light of day) and the GDD for this consisted of a paragraph in an email because it is a FPS and these are the sort of games given to the Core Design idea you mention. Because of the way unity is organised by objects it is also very easy to go in a tweak the level design without causing too many problems for the programmer so it can be a case of suck it and see, and one needs a certain flexibility to develop a good design whilst trying to limit feature creep.

I’ve also got a project on the go which is learning software with a game component but as the learning aspects take precedence it is hard to create a GDD and it is a case of seeing where it goes.

The main thing about detailed GDDs though is that they are meant for other people. Any game I design and progam myself I usually do it with rough notes because I know what is required. Sometimes with a team a game bible is of more use than a GDD. To be honest, in a company these things are used more to assess possible blockades in the game building process and to identify software requirements and game control specs and not for detailed gameplay, they are largely there to ensure that all aspects of the development process are considered because without one it often happens that several months into the process it occurs to someone that they really should have considered buying a piece of software for managing the sound sytem and a nice bit of Fmod wouldn’t go astray - and suddenly there is a crisis because it’s not in the budget.

13

My current project requires a GDD due to a few complex systems that I need to work out before I jump head in. It also gives substance to my idea. If I forget something or start with an idea that I should consider another game mechanic when implementing, the GDD becomes useful. I think it depends on your game. I always make GDDs and I frequently reference them when working on my projects.

14

Hahahaha! That’s made my day. Throwing their Wacom pens, like it!

15

You just made my day :smile:

but seriously those things are weak!

16

You don’t need architectural plans if you are just one guy building a dog house in his garage.

But you’d be considered insane if you proposed building skyscrapers without them.

Same difference with a singular piece of artwork for a concept sketch compared to an entire animated movie.

What works for a small project involving one or two people does not work for a team of 10, 20, 100 or 200. And vice versa. There are big tools out there that can do more harm than good to a project if you deploy them.

The ability for a process, a technique, or a tool to scale from one size requirement to another is important, but it is also not a one way scale. Some are too small, some are too big. The craft of software development, game development, project management, is knowing when to deploy each tool, technique or process and under what circumstances – that comes through experience and hard won battles.

These disparate pieces have elasticity, how much can you stretch them from one size to another size. They don’t all stretch equally. There is also brittleness: some fail gracefully, others shatter.

17

Thank you, every one, for useful info.

The sad part is, from what I see here, when you encounter game development problems, like sharing the vision or current state of the game, estimating the resources or planing the game, you All just go for a GDD and explain only why you might need small or a detailed one. It’s like you don’t give even a little thought to other methods and techniques or they just don’t exist at all.

Why is that? Is there really Nothing useful outside of GDD or you just don’t know/use/like other techniques?

What i mean is, there is problems in game development, all the problems you mentioned are valid, but why GDD to solves them? Is there Anything else? Or why GDD is so much better in your opinion?

18

This says it all really.

One thing you don’t want to do is get bogged down with documentation, keep it very clear and make it easy to find important things. For every complicated description, have a summary as well, it can serve as a good sanity check and increase the chances of people understanding what they’ve read so far.

GDDs are considered “living” documents, in that they’re subject to change during development, so keep a history of changes too so others can see what’s changed, and the reasons.

Ultimately all documentation is only as useful as peoples’ willingness to read it though, so your mileage will always vary.

19

Well, A GDD mostly serves to keep people on the same page regarding the game’s goals, content and mechanics. One of the reasons a GDD is changable is the fact that goals are often changed due to circumstances - they may be technical issues, resource issues, new requirements or ideas, or simply mechanics that seemed a good idea originally but aren’t so hot in practice.

In a studio setting, technical problems are usually identified in a Technical Design Document, which normally won’t be updated as often as a GDD (best case, it never gets updated because you’ve covered all your bases at the start). Some things you can’t account for early on because they’re out of your control - this applies especially to middleware, where updates or undiscovered bugs can change the status quo.

Generally, the best you can do is estimate what you need and, if possible, when (because you’ll very rarely need everything up front). Development models/approaches (this applies to Agile too) are all about being organised, or more’s the point putting a lot of random stuff together so it doesn’t fall apart when someone asks “why are we doing it like this again?” six months into development. :slight_smile:

20

As other things, like Design Canvas and Design Log that provide info about the original idea, how it evolved and where it is right now.
Why you choose GDD? Do you even consider other stuff?