Production processes: How do you build your adventure games?

[Uhfgood]

I'm just curious as to how you guys build your games.  Do you start with a story first, then build some puzzles/locations.  Do you start with just a setting, then build puzzles based on the setting, and then write a story around it?  When you write the story what form is it in? (ie Present tense, plot points, summary, etc).  Basically just curious about what process everyone goes through to put together their adventure games.

Currently I have a story (or stories as the case may be) in the works.  What I did was write out the specific plot points... (ie Iniciting incident, plot point 1, mid point, pp2, climax resolution), and built what would happen at those points.  I figured these would be in the form of cut scenes.  I intentionally left holes from one plot point to the next because I figured that's what the player will "play" to get to the next bit of story.  Next based on the story, I started working on locations, and puzzles to fill them in.  Does this sound like a valid way to go about it? 

Other options would be to write a virtual walkthrough, where essentially it's how the story would go, if you were playing it, and were successful (as if you were writing a walk through for a game that's already been made) in present tense...  Other would be similar to that, except in a narrative form, ie a story, novella or some such, and then build the game based off of it.  Another option could be to essentially build it in "choose your own adventure" form, and then based off of it, make the real adventure game.  (Note I'm not saying to build a choose your own adventure type game, where it plays animations based on what path you took... i'm just saying the initial story-writing process would be in this format, then of course you would build the game as normal, adding puzzles and things to conform to the multi-branching story you made.)

I'm considering rewriting my story stuff as a full story, with no blank spots... and then fashioning the game around it, instead of filling up the holes.

Your thoughts?

[LimpingFish]

It starts with a rough idea, story wise. A few plot points, maybe.

Then I make it up as I go along. Sometimes works, sometimes doesn't. This applies to everything: Characters, puzzles, graphics, music, etc.

Some people meticulously plan everything out before they ever sit down at their PC, and some people don't.

You find what works best for you, and hope things fall into place. 

[Eggie]

I quite like the Al Lowe system  of planning out the puzzles but then writing out all the in-game messages after the game's framework is actually in place.
Of course, spontaneous jokes about boobs is probably only appropriate to one type of game. I guess it all just boils down to what kind of person you are. Do you like writing endless pages of planning or do you prefer the giddy freefall of improvisation?

Bear in mind, all of my projects have heavily utilised the latter and they're all dead or unfinished so I guess this says that the planning types are the most reliable... unless they end up planning FOREVER, which happens.

[TerranRich]

Since I've never released a full game (unless you count the BTS Demo, which is technically its own game basically), I'll just go with what I've settled on while working on BTS, and what I recommend.

First, the planning and writing:

1. I plan out the back story for the game... what's going on, how will the story proceed, and how will the player character evolve.
2. I sit down and write a walkthrough for the entire game, leaving blanks when I can't think of puzzles right away. I just want to know how the player gets from A to B to C at this point.
3. I go through it all and come up with interesting and meaningful puzzles, and try to work them logically into the story. Maybe I'll get inspiration from books, movies, and other games.
4. I go through it all again and make sure that it plays like a game and not an interactive movie. Meaning, the player is involved in everything and by his/her own actions, moves the story along.

Then I get down to designing and creating:

5. I come with up the design for the main interface of the game. Do I want a one-click system? A two-click one? A verb coin? A drop-down menu of various actions? Do I want subtitles? What do I want the control panel to do? Will there be any other innovative features, such as a secondary control panel for viewing past conversations? Maybe the character secretly records everything he hears and the conversations he's in?
6. I come up with character designs. I jot down notes on each character's personality, character traits, motivations, reactions, attitudes, etc. I also come up with how each one will look, whether I want this character to be stern looking and mean, or that character to be old and friendly, or this other character to be attractive and devious, etc. This also extends to walk cycles and other animations.
7. I work on the rooms. The walkthrough already has basic descriptions of the rooms the requirements for each one. I think about how I want each room to look and then design them accordingly. I work in 3D using pre-made items, but I customize each one extensively, and aim for them to not be noticeable and recognizable as far as where I obtained them.
8. I haven't gotten this far as of yet, but I will then work on stuff within AGS finally. Once the basics are down, I will work on the interface for the game in AGS.
9. I will then create each and every room, just focusing on walkable areas, walk-behinds, and maybe hotspots, although I will try to save all interactions for later.
10. I will then import all walk cycles. Once the graphics are imported and the views are all set up, I will then work on other animations I know will be needed in the game: the PC picking up stuff from the ground, or from surfaces; maybe certain NPCs doing certain actions, etc.
11. I will then focus on room interactions, especially hotspots. I will also place inventory items and other objects into rooms.
12. I will then script everything, focusing on the actual game play. Things like, "If the player interacts with this hotspot before he has item A, say this; otherwise, get item B," and so forth. That's a very crude example.

Then comes testing by myself (alpha testing), then beta testing, then getting voice actors, music, etc.

[Makeout Patrol]

Well, I've only finished one game, but here's the order I go in:

1. Concept. This is just the fundamental, basic stuff. For The Vacuum, I wanted it to be in space, and, since I really liked an idea that I read about for an investigative game in which the basics of the crime were always the same, but it was the player who personally had to put the clues together instead of having it spoon-fed to them, and the game adapted to how much the player found. I also decided that I wanted it to take place in a closely confined space (to make building the game-world easier) but didn't want the borders to feel arbitrary and wanted the player to feel like they could fully explore it (unlike the way I feel in a game like, say, Pleurghburg, where you can't walk to the next house on the block, for instance), the interior of a space ship felt like an optimal setting.

2. Scenes. Thinking about it, I came up with a couple of scenes that I thought would be cool in this game. The ones that I came up with before I even started on it were the bit where the player puts on a space suit and steps into a corridor, only to be greeted with the sight of a massive hole in the hull and blood all over the walls, a scene where the player is in radio contact with another character who gets killed in an explosion, and a scene where the villain goads the player by making vulgar death threats on all of the other characters. Right now I'm working on an idea for a film-noir type game, and I'm planning to include a scene in which the player character is in a standoff with two villains, each of whom has one of his allies hostage; the player has to choose to shoot one villain, saving their hostage but sacrificing the other one, or lay down his weapon and face some pretty bad shit.

3. The underlying storyline. This is where I plan the whole thing out - since I like non-linear storylines, this takes a long time and a lot of storyboarding.

4. Environments. I build up the entire environment first thing, and have it all functioning so that I can walk wherever I want exactly as I will be able to during the game. I also work on character graphics when I can be assed, although that's definitely my least favorite part.

5. Storyline scripting. This is where I implement the actual cutscenes, puzzles, dialogue, and so forth, into the empty 'shell' of the game created in the last step.

6. Beta testing. This is probably the most important part of development.

[Ishmael]

I just wait for stuff to fall in place, writing down ideas whenever I can. Those written down or memorised ideas just tend to stack nicely to form puzzles, story arcs, etc. I can use this to work as I go, but I've noticed there comes a time when I just run into a wall anyway. So now I've taken the approach of taking a long time, writing down these ideas and all until I actually have a story from start to finish, and only then start thinking about the rest. But you can't call it too systematic anyway...

[Jared]

I'm currently in the process of making a small game (3 rooms) on the advice of multiple people on this forum and shelved my full-length idea. My process is a little skewed, though, because I'm not the best artist and want to make the games on my own. So I begin with

Character Sketches: I draw characters. I think of strange characters to draw. I then think about a game I could make around them. Which leads to

Backstory: Where is the game set? Who do you play? What are your goals? I don't write any of this stuff down, I just let it ferment in my mind, usually while working on the drawing.

Puzzles: This step could just as easily be 'story', depending on which one you want to give more focus to. I'm quite old-fashioned and believe in puzzle driven gameplay, though. For my longer game concept I spent time dividing the game up into the obstacles that you'd need to overcome and then brainstorm over what those puzzles would involve. Currently the game I'm working on is quite simple, with only real two goals to reach - so once I had some ideas I sat down and wrote a walkthrough.

If you decide to write a walkthrough, take your time. Think of some interesting puzzles - not just using and giving items on hotspots. Make sure you read it back a while after you've finished. Odds are you'll find some loose ends and dead wood in there.

Taking stock: Make notes on what sort of needs you have, based on your walkthrough. Read through and note what puzzles are going to need hints, what conversation topics should be buried, everything that needs to be in a room, all the character animations you're going to need along with sound effects, etcetera.

Graphics: The stage I'm going through now. Like I said, not good with graphics so I'm not one to give advice.

From there on, what I'm planning at least is the logical chain of programming and writing as necessary. I've written down a lot of dialogue that struck me as funny when I thought about it so it won't be entirely on the run.

Bear in mind I'm a n00b, but this way feels perfectly natural to me and I haven't hit any trouble so far. Could be more suited to games of a more frivolous nature but, hey, that's where my interest is.

[Uhfgood]

It's quite interesting that all your techniques are different.  It has given me some food for thought, and is making me think my idea is not that bad at all, since we all have our different ways of doing things.

Essentially I have two plot lines (plot and subplot) for about 13 characters (or thereabouts), all written in plot point format.  So now I guess what I should do is start thinking of the puzzles I should make to get from plot point A to plot point B.

By the way keep the posts coming, it's very interesting, and a great learning experience to see how everyone goes about their games.  And it doesn't matter if you're new to it, haven't finished a game, or have finished lots, it's all pretty valuable.

I'm also betting some of the more inexperienced members would really like to know this stuff (me included).

Thanks!

[Uhfgood]

I was hoping more people would contribute to the thread.  I guess it's better to post something and not reply to it, so that people won't think you're then finished with hearing the discussion and thereby continue to post.  Anyhoo thanks to all that did post already, will keep this for future reference.

[Ali]

I was hoping more people would contribute to the thread.

Okay then:

I've always found it difficult, and though I've only made one game I have tried to make more. I'm planning Nelly Cootalot II more carefully than the first one because I intend for it to be better, and longer.

1: Story
I thought up an idea for a story. Then I crowbarred things I wanted to put in a game into the story.

2: Planning
I started to write a document outlining the plot and the key puzzles using the following fomat:

A paragraph outlining the situation at this stage in the game. Also indicating the obstacles preventing the player from moving on to the next stage.

A paragraph explaining what the player has to do to overcome obstacle one. Also indicating obstacle 1a, 1b etc. which prevents the player from overcoming obstacle one.

And I continue in this manner nesting subpuzzles within puzzles. With the original Nelly I actially numbered all the obstacles and used 1a and 1b, but it became extremely cumbersome at only two pages long. So now I'm writing in more detail, but not worrying about numbering. The document is also split into the game's chapters and has notes on where cutscenes will pop up during the game. It's not finished yet, because I wanted to start on the next and more fun section.

At this stage I also spent time with technical considerations: interface, resolution, and so on, which resulted in the tech demo I released little while ago.

3: Drawing
Doing the pictures. I plan, as with Nelly, to draw all the backgrounds and main character animations before I start assembling the game. Deferring the gratification of assembling game seems like a good way of getting stuck with an almost-finished game that I don't want to finish, which is what happened with the game I was making before Nelly. Of course I had to cheat and make a tech demo to see if what I was technically and artistacally achievable.

4: Writing
I agree with the posters above that writing works better later in the process. I would naturally wait until the rooms have been created and hotspot-ted before writing look-at responses. Writing dialogues was something I did in dribs and drabs in Nelly 1, but now that I think about it, I should probably write them all in advance of scripting.

5: Scripting
I suppose this stage should simply be a matter of assembling all of the existing pieces, though based on my limited experience it's a point where all sorts of flaws in the earlier stages come to light. I agree that beta testing was very useful in this stage to iron out bugs and onfusing puzzles.

This thread gives me an idea: if lots of people create design documents, maybe it would be interesting for them to be released (after the game of course) as reference, inspiration or dire warning to other game makers.

[Baron]

This isn't set in stone, but it's usually how things go:

1) Theme -this is the seed of an idea.  It's the location, mood, main character, but all in the abstract.  It has to come first: you can't just make a game into the vacuum.  Al-Quest 1 proved that....

2) List of characters, locations & objects in separate columns -the idea being to keep everything "on theme" so it all "fits" in the story.  Then I draw lines connecting things, essentially making the puzzles.  I might sketch a character or two in the margin.

4) Draw & animate main character's walk-cycle.  I have to see him/her alive in the AGS environment before I can proceed.

3) Write up a task list for game events and estimate how long each will take.  The list is usually based around drawings (backgrounds, animations) necessary for each puzzle/plot advancement.  I will quickly (1 min.) sketch a background or a new character, but otherwise it's right down to work.  I usually start with the hardest/most time consuming task, plugging away a little bit everyday until it's all done.  I like to get one "task" done per day (it keeps me motivated), so they're usually broken down into one/two hour increments.  Draw background guy (1 hr.), for example, or animate background guy side-walkcycle (2 hrs.).  I script as I go, so that I can see the action progressing.

4) Revisions .  My projects always evolve as I work on them.  I come up with new plot or puzzle ideas as I go, so I usually have to draw up a secondary task list and start again, as per above.

5) Rationalizing .  This is where the intense writing takes place: making everything make sense after the fact.  You'd be surprised what kind of crazy lunacy/ridiculous inconsistencies you can justify with a little creative writing.  Clues/backgrounds are inserted into dialogue/messages to make puzzles/plot seem logical/consistent.

That's pretty much it.  Sounds and music are done at the very end, kind of as an afterthought since I'm personally no good at either.  Beta-testing usually happens as I'm scrambling for music, to save time.  Then there's the euphoria of the game release, followed promptly by an emotional crash because I have nothing left to work on.  Then I start again.

It is interesting to see how others approach the process.

[Shane 'ProgZmax' Stevens]

We've had such a topic before, and I daresay we'll have one again.  I'm not sure how much it helps an individual to see 20 or so peoples' different approaches to design, but I'll offer mine just in case there is some value to it.

I rarely use design documents.  In personal experience (and working with other people), I've found that most of the time you'll have great energy starting out and by the time the design document is done a lot of that initial energy is lost.  I'm not saying they are valueless wastes of time; on the contrary, they are a good way to cement your ideas and see if they're worth pursuing, but if you already have trust in your idea I find the time spent on them to be a drain.

I personally believe in striking while the iron is hot.

How do I do this, you ask?

One thing I've done in the past is to write a short screenplay rather than a design document.  Screenplays focus less on motivations and details and more on describing scenes and listing dialog.  Sometimes I just design the game as I go along, which is also fun and leaves a lot of creative latitude (if you aren't careful the game can grow to an untenable level, though).


Before everything else, there is a story.  Is it a funny story or a sad story, a story about a tough guy or a tale about an ambiguously gay dance instructor?  Once I have the roots of a story that amuses me, I start creating a cast.


With the cast, I usually try to stay away from Hollywood (or typical gaming) conventions, ie the male+female typical structure of games, the whole 'if there's a guy, there has to be a girl'.  This is completely boring to me, especially when so many of the games/movies you see the girl is just tacked-on and has no development or purpose beyond being the sexual interest.  This doesn't interest me so I don't employ it as a narrative device.

Once I settle on a character personality I open up my art program, turn on some music and then start doing designs until I come up with something that fits the character I've made. 

Usually I'll have details in mind to start with, like:

Jonas Tapfer, 28 year old American-born German fighter pilot.

Once I'm satisfied with the design of the main character I start creating the rest of them using the main character as a style and size reference.  I never design backgrounds before I have a character reference.  This is, to me, important advice that is often ignored because your backgrounds need to be made with the proportions of your largest character in mind, otherwise they are going to look strange.


With the characters made I will begin constructing backgrounds, and once I have 3-4 I will start using the AGS Editor so I can see how the characters fit with each other and the backgrounds visually.  This also gives me a boost in interest to see the beginnings of a playable game.


Once I am happy with the overall visual look, I turn to the user interface and what exactly I want the player to be able to do based on the events in the story.  Do I want him to be able to fight enemies?  Does he ever need to talk to anyone in the game?  How much inventory (if any) will there be through the course of the game?  Once I answer questions like this I'm ready to build an interface around the limitations of the design.

Here's an example of a finished gui for Our Finest Hour:

The gui design itself was made to resemble an important item found near the end of the story.  You'll see that it features many commands often found in adventure games:  Walk, Use, Talk, Take, Inv, Look.  The Inventory was made a separate gui because I did not want it taking up extra vertical space.  Above the actions is a contextual information bar for mouse-overs much like the old SCUMM interface, something a lot of people seem to like.

Additionally, since I wanted a good/evil system in the game I placed a sun and a moon on either side of the action bar that fill based on benevolent or selfish/evil actions.



This is the inventory gui, which drops down just beneath the main gui and can be toggled on/off at will.  Arrows are on either side of the inventory for moving left or right through the contents.

With the main gui designed, I still needed a cursor that had good visibility and still let the player know when they were over something of interest.  Instead of using Sierra-type icons, I wanted something more military to fit in with the theme of the game, so I made a few crosshair designs until I came up with these:

 


I was happy with the wait cursor, but even though I wanted to use a German Cross inspired design for the normal cursor it just looked too bulky and unintuitive.  It also obscured too much area, so I started over and came up with this:



The center point is clearly marked and the cursor now resembles the gui somewhat, keeping design consistency.  The cursor is designed to animate when over a hotspot, but after some feedback I decided that the Use action could use a special cursor as well so the player knows they have successfully selected an item to use:



The cursor only glows blue when you have selected an inventory item for use and reverts back to red when doing anything else.


With the main gui and cursor design out of the way, I could complete the interface by creating save/load guis and a quit gui, which are standard and not very interesting to do.  With the interface designed I could return focus to the game, create a few test inventory items and establish that the interface worked as it should.

It's usually here that I'll start creating some music for the game with a specific theme. 

When it comes time to actually construct the game in AGS, I tend to build it in a step-by step fashion from the beginning of the story to the end.  In the case of Our Finest Hour, it begins with an image of the Reichstag building, so that was room 1 of the game.  I typically make each room minimally functional before moving on (all walkable areas and important puzzles implemented for a room) and then return later to add optional interactions and fun stuff.  Going through the game in this way I have a clear idea of where I am and I can see results more quickly than if I tried doing everything a room should have from the start. 

Once the game is functional from beginning to end I go back and add details and additional animations and finish the music and sound.

[Uhfgood]

There seems to be a bit of a pattern emerging.  While a couple of you start with your story, alot of you start with your characters.  And in fact start visually with the characters.  Something I noticed while participating in nanowrimo last year.  Usually if you center your story around your characters it comes out better than if you decide on a plot or story structure first, and try to fit characters into it.

In any case this is how Enchanted Lands came about.  Well naturally I came up with the idea first about a real magic kingdom that had to resort to tourism to keep financially afloat.  But then I went in started coming up with characters I thought were funny.  Then I started their individual plot lines, and made them all cross together.  Then added their subplots, and went back and tried filling in a back story.  So my game is pretty character-centric.

So I guess the better idea for me would be to visually design the characters before proceeding.

ProgZMax - you said you write a short screenplay, do you intentionally leave holes for adding puzzles and things, or do you just write it out how the final story line would play out (ie, if you did everything correctly in the resulting game, it would more-or-less end up with what you had in the screenplay) ?

I'd still like more people to contribute.  Even if you are in the middle of making your first game, or are a professional (assuming pro's read in here), I'd very much like to hear how you work!

Thanks,
Keith