I am not really sure where to post this but this seemed more reasonible area since it is not really a tech question about AGS. Anyway, I was curious about writing a design document for my Game. I have started some of the work on creating the game in AGS, but have seemed to stumble becuase i am creating puzzles and other things on the fly. I guess my question is for those who have maybe completed a game or are currently working on one how have you indivually planned your game before really battling programing?
Well nevermind after some searching i found some interesting ones but hey if yall have any more ideas or anything to add let me know.
I don't think you really have to make a design document, unless it's a really big game in which case I guess it's handy to keep things organized. I have one but I don't really refer to it that often. It's more a sort of repository of bits of info on my game.
Back when I was looking for dd's too, I was linked to the dd's from Leisure Suit Larry and Torins Passage here (http://www.allowe.com/gamedesign/index.htm). It's an inspiration to see these professional ones, how they're structured and what's in them.
Ben and I have long chats on MSN (we are on opposite sides of the world) about the plot, working out the bare bones first and then fleshing it out. Characters and puzzles evolve as we work out the plot. We pay particular attention to making the plot believable and avoiding any inconsistencies. We keep each other updated regularly with progress (in the forms of completed graphics, draft versions of the game, screenshots, etc) and give each other feedback and suggestions for improvements.
I can't speak for Ben regarding the graphics, but for the programming, I tend to have a to-do list that I keep updated with the major things that need to be done (such as importing frames for walkcycles, creating hotspots for a room, writing cutscenes or scripting a puzzle) which are then subdivided into smaller steps. That way, I can see exactly what I need to be doing and how I need to go about it.
One other thing is that nothing is set in stone - plot elements, characters and even whole rooms come and go, depending on what works best for the game.
So there's no formal design document - really it's a question of getting the basics worked out early on and writing everything down so you know what you have done and what you need to do.
Quote from: paolo on Wed 23/01/2008 13:20:19
One other thing is that nothing is set in stone - plot elements, characters and even whole rooms come and go, depending on what works best for the game.
I think that's the important part - flexibility.
I think what you'd need for a common adventure-game is a story-board, not a design-document. I know I'm being anal here, but there's a huge and important difference between the two, at least there is in my books:
Story-boards include the story and actors in a written form or - instead or additionally - sketches of important places in the game. The images can be connected with arrows etc. Also, it includes all puzzles (again, in written description, in a sketch or both).
Design-documents have nothing to do with the story-aspect of a game. They describe in written, drawn or both forms how exactly the game is gonna run. How the player interacts with the application. How the UI looks like, what happens when the user clicks "new game" in the main-menu.
In a common adventure-game, you don't usually need design-documents, because they'd only describe the obvious, like the verbs you can click and what they do and how you can cycle through right-clicking or not.
It is a good idea to know what exactly you want to put into the game.
Make up a few characters, the hero is a good start, the villain helps to (villany is not confined to a person. essentially it is an opposing force, perhaps you want to make a love story, the villain could be another suitor, or it could be the main characters flaw of being an ugly bastard) Give them a life. Backstory, history et al. Once you know who you are dealing with you can put them in a story. It creates more believable stories, because you can work it into the game. Just look at Dave Gilberts and Grundislavs games, they have strong characters. You can't make a good game with a lifeless cast.
Read the GTD thread in the popular threads forum (currently on the second page). You know the one. the one where all the threads that are cool go to die. Print them out and keep handy. They are uber helpful.
Write a paragraph defining the setting, protagonist and the antagonist, and basic plot. If you need help, just take any classic work of fiction as a basis. Most stories are relatively the same. They have a beginning, middle and an end. 3 Acts. Beginning introduces the protagonist and antagonist, and the main characters.
The middles usually is where all the main bits of the story are, where you go hunting for clues or objects, and try to solve the mystery or just develop the story. Kill one of you main characters as well, just to shock. And if you ever get stuck, kill someone else. nothing moves a story forward better than death.
In the end, you must have the protagonist facing the antagonist, with the protagonist winning. Yay, you have written a story!!!
The 20 basic plots http://www.tennscreen.com/plots.htm
If you encounter any difficulties developing dramatic situations, read this! : http://en.wikipedia.org/wiki/The_Thirty-Six_Dramatic_Situations (http://en.wikipedia.org/wiki/The_Thirty-Six_Dramatic_Situations)
Now you need puzzles or you game might as well be a movie. I don't have much to say about puzzles because they are every adventure game designers worst nightmare.
Best idea is to read these:
http://www.adventuregamers.com/article/id,522 an article by yahtzee bitching about stupid puzzle design.
http://www.adventuregamers.com/article/id,332 an artile by josh roberts on puzzle design
http://www.scottkim.com/thinkinggames/GDC00/bates.html Some article i found on google after searching for adventure puzzle design
You may realise after you get the game all pretty much done, beta testers tell you a puzzle does not make sense or is too hard or is too easy. Thats bad, but you can always change it. That is why beta testers are your friends.
Ok, so you have written a plot, added some puzzles.
Start writing lists of what assets you will need. List every background, list every sprite.
You'd probably want to draw your art now.
Read this article by Rodekill as well. It's a pretty good guide, I just expanded a bit more on the storytelling side of things. http://screen7.adventuredevelopers.com/agdzine/articles_learned.htm
Oh and while I was writing this, DKH posted. Storyboarding is a very good idea after you have written the story, but a design document include the plotting of the game, as well as puzzles. I would never storyboard anything with out a story in place already.
Filmmakers use storyboards to decide on their shots, not the underlying story.
The typical "textbook" approach is to start with a concept or a previously completed game and from there create a design document. This document is intended to map out the complete game design and acts as a central resource for the development team. This document should ideally be updated as the game evolves throughout the production process.
But i've never completed making a game, so what do I know.
Quote from: Layabout on Wed 23/01/2008 16:06:56Oh and while I was writing this, DKH posted. Storyboarding is a very good idea after you have written the story, but a design document include the plotting of the game, as well as puzzles. I would never storyboard anything with out a story in place already.
This is a very good view to the situation, and in fact, I would be so bold as to offer that unless you are working as a part of a larger team as a designer, you can often skip the storyboarding stage, at the very least to some degree. With your own game, you'll have the images in your head and it's more a matter of iteration, getting right into the backgrounds & animating. This is not to say it's useless - if you find it helpful to draw actions and situations beforehand, to visualize the plot, then that's what you should do!
I'm not saying I recommend skipping storyboards, personally, but we all know a lone designer will be grasping for more time every time. I do think it is more important to flesh out that design document - the personalities of the characters (this bleeds into writing dialogue, so I find it helpful to get the personality first and the responses later) the internal logic between sjuzet and fabula ("story" and "narrative") and most importantly your grasp of the Big Picture. To make a game that really funks you need to have that bird's eye view :)