How do you design your (full length) game?

[Dennis Ploeger]

Hi guys!

Well, yeah. It seems, that I'm... back. Wow. It's been a while. Nice to see, that this community's still blazing. You rock, people!

So, back on the track and as always there's that big dream of a full-length game and I started and started over again multiple times, but still can't get a hold on it. I ASSUME, that it's because I simply doesn't start right. There's actually one big thing, that my mind's wrapping around all the time: How do you go from a story, that you got in your head, to the puzzle-reaking game in the end?

So I thought about just asking you guys (especially the ones, that allready got a full length one in their hands) on how YOU go and design your adventure game?

Do you write a story first, slash it into pieces and fill in the puzzles? Do you use design documents? Story bibles?

Please, give me your ideas. Shoot!

Thanks.

Kind regards

deep

[CaptainD]

Um... this may not be a very helpful answer, but I kind of make it all up - story, puzzles and all - as I go along!

What I have found to be helpful in terms of keeping things going forward is to adopt a modular design - that is, design a small area of the game, get it made, test it, and move on to the next bit.  It is useful although not appropriate for all games if each module can be more or less closed off from the next and previous modules - that is, that you start and finish in more or less a condition where nothing you've done or picked up in that module that isn't strictly necessary to completing the game will carry over to the next one in an unpredictable way.

Hmm... sorry, I don't think I've explained that very well.  But basically, I do design docs for small sections of the game rather than in one go, a bit like writing individual scenes in a play I guess.

[NickyNyce]

I come up with a story, and do sections at a time to stay interested. This way I'm not overwhelmed with the enormity of it all. This keeps me focused, and I can always see a light at the end of the tunnel. When it comes to puzzles, I'm all over the place. I can go a month without coming up with an idea on how to keep the game moving with an acceptable puzzle. If this happens, I'll polish another area of the game to keep me focused. I have a very hard time trying to think too far ahead. I feel that even if I did, my game would change as I'm making it anyway.

I did notice that for me, if I draw it, it will come. Meaning that sometimes I have to create a BG and things in the room, in order to see what's going on, and then the puzzles usually come to me. Some of my best ideas came after my games were finished. I would go back and tweak things once I saw and played the whole game. So the best advice I can give you, IMO, is to create and draw. The rest of the game comes along with it.

*cough cough* Now working and almost finished with my 3rd full length game.

[Mandle]

*cough cough* Now working and almost finished with my 3rd full length game.

Stop prattling then and get back to work damnit!!! I'm jonesing bigtime for my last Agent Moss fix!!!

[NickyNyce]

98 percent done.

Update coming in a couple of days.

[moloko]

I created Ponderabilia by sketching out the world in it first. You wouldn't think so, but there's an entire Ponderabilia World Overview, laid out along the lines of the different levels of consciousness. The idea was that the player started out as being unaware, explored the dark recesses of the mind and then finished in expanded awareness. When I had that schematic laid out, I came up with different characters for various parts of the game. Every character then received a reason for being exactly where they were. Once the characters were developed, I started thinking about the puzzles. It needed to feel confusing and outlandish, but had to make sense in the global structure.

Then came the script. I handled this very much like the old Hintbooks, like the ones published for Leisure Suit Larry. I wrote out the entire game as a walkthrough, with actions, dialogue and location in place. Then I designed the Avatar for Nikee, the main character, and all her cycles (climbing, crawling, walking, being ground up... There's even a nude cycles that were never used.). Then the rooms, the objects and the other characters. By then it was an organic process, with extra details added in as went along, but still working towards the goal of the final script. I coded the entire thing together, and round about that stage, the amazing people on the forum offered their help in getting the sound effects done, with wonderful tracks written selflessly by Shansean, Eldogond, Handsfree...

Finally, we're several rounds of bug fixing later, I crammed the entire thing up on a tiny website, Monsieur OUIXX wrote the walkthrough, and I added in a different ending for good measure. Hope this helps!

[Jay Tholen]

My method for Dropsy was similar to moloko's. I'm big into lore/mythos/worldbuilding, so I drew up a worldmap and created a few documents detailing its past and present people groups, major events, economy, etc. I then used that as a setting to write the game's story in, and treated it as if it were a real, living place.

All of that was the fun stuff. Then I divided the major plot points into their own little sections, and created contextually appropriate puzzles around them. The real challenge, for me, is guiding the player through the story without it feeling like they're being coaxed into it. Puzzle+plot integration was the hardest part to plan, and is something that still changes as the game matures.

[Armageddon]

For adventure games I really like Joshua Nuernberger's approach. Since adventure games pretty much rely entirely on content and very little gameplay it makes sense to just have the absolute bare bones of the game with placeholder art. Every plot point and dialogue tree. Don't worry about the art at all, you have to make sure your story works and flows first. Then it's also easy to tweak and shift things around, rewrite sections. From there you can start drawing and designing characters.

[Mandle]

For adventure games I really like Joshua Nuernberger's approach. Since adventure games pretty much rely entirely on content and very little gameplay it makes sense to just have the absolute bare bones of the game with placeholder art. Every plot point and dialogue tree. Don't worry about the art at all, you have to make sure your story works and flows first. Then it's also easy to tweak and shift things around, rewrite sections. From there you can start drawing and designing characters.

I totally agree! This is how I am approaching a current project: I'm just going to make it with shitty placeholder graphics (stick figures and line drawings) until the game is playable from start to finish, and then go back and add all the bells and whistles of decent graphics, sound effects, music, etc etc...

After all...All the awesome cosmetic details in the world are not going to save a game if it is simply not working as a story from start to finish first...

[Grundislav]

I still don't know, to be honest...

[Creamy]

For adventure games I really like Joshua Nuernberger's approach.

It's a good way to go but I can't picture myself creating all the assets at the end of the development - or coming up with a complete design document before starting a game. As a hobbyist, I need to do different things regularly in order to keep my motivation.
« A night in Berry » was started with only a few puzzles in mind. I came up with new ideas halfway through the development and rewrote entire sections of the game accordingly. Although I've wasted a lot of time, I don't know if I could have done it any other way.

[Cassiebsg]

Like Creamy I can't seem to work with placeholders that much. I can do with "non-polished" versions, but I need my assets and art to look and be close to what I envisioned to keep me motivated to go on. I started Jake with the placeholder philosophy, but it's not working for me, I need to actually SEE what am doing and if it's looking like I imagined it, otherwise I risk not doing anything at all.
Like when I needed Jake to pickup the suitcase or have his backpack on, I NEEDED the sprites to reflect that, cause that's part of the fun of creation for me. Even if those are still only placeholder art...

[Haggis]

I came up with new ideas halfway through the development and rewrote entire sections of the game accordingly. Although I've wasted a lot of time, I don't know if I could have done it any other way.

We touched upon this one week in the AGS Anonymous group and it's nice to see I'm not the only one who develops like this.

I started by writing down in a word document the rough overarching story, and the puzzles specific to each chapter of the game (including the locations and the inventory items the player gets in each). When I started development I limited myself to working chronologically through the game one chapter at a time - one puzzle at a time. This meant that inevitably as I worked on the BG art, character sprites, dialog etc I had little ideas on how to improve puzzles (new locations, new characters, new inventory items) and in turn tie the in game world together. Now, as I come to the end of development, looking back through the original word document, the over arching story is mostly the same but some of the puzzles to complete the chapters are completely different because they naturally evolved to fit the game world I was creating.

I have a lot of respect for people who can envisage the full game, fully code it start to finish using 'skeleton' art, and then go back and do all the real artwork at the end. It requires a certain level of discipline and vision which I don't have.

[Monsieur OUXX]

One of the big questions to ask is : will you be doing it alone?
If not, a huge amount of time is spent on sharing "knowledge" (as they say in companies) about the project, and making sure everyone is up to date on the story and stuff. It gets even worse if there are brainstormings to get ideas. If not everyone knows exactly what's being discussed, it doesn't work. For example, if you're discussing the layout of a room, then the discussion fails if not everyone remembers what comes just before, what comes just after, what main puzzle is being solved, what secondary puzzles are needed, etc.

Another big issue when you work as a team are bottlenecks: when some people are waiting on someone else's job.

This can all be worked around if each person has a clearly distinct task, and if you maintain a global script (I mean the scenario, not the programming script) with as many details as possible.

[Dennis Ploeger]

Hi!

I just wanted to say Thanks to everybody for their comments. I am grateful for your sharing.

Kind regards

deep

[ManicMatt]

I didn't even know how the end would go in my last game's story, just had the gist of it thought out and then after I'd drawn the location I worked out the rest. It's probably not the best way of making a game but I like to improvise my comedy!

[Trapezoid]

For Icon Architect, after I came up with the broad strokes of my story's setting, antagonists, and conceit. Then I designed the protagonist as someone who doesn't know more than the player (and has the benefits of a blank slate), while still having explicit motivations and values. (Side note: Guybrush is the ultimate example of achieving this quickly and effortlessly. He wants to be a pirate, so he says so. The player is instantly in accord with him-- why else would you be playing a pirate game?)

When it came to actually writing the specifics of the plot and "chapters" of puzzles, I focused heavily on giving the protagonist--and the player--clear goals and motives that ramp up in importance as the game goes on. So, it starts out with an innocuous assignment, then the goals become more about saving herself, then saving her friends, then saving the world.

At every point in the game the player knows what they're trying to accomplish, and more importantly, cares about doing so (Well, I hope I write well enough for that to be true.)
Never assume that your player will want to solve puzzles just for solving puzzles' sake, or merely to progress. Adventure games are not puzzle games that reward you with story. Think of it as writing a story that motivates and manipulates the player into action. If the solution to a puzzle involves doing something cruel to a character, make that character someone the player wants to be cruel to. If a location needs to be explored, make sure it stokes curiosity.

Keep notebooks. I have a page where I just drew a ton of random inventory items that would be appropriate to the setting. I ended up using a lot of them in my puzzles later. You can do the same with ideas for characters and locations. Write freely and pick and choose from it later.

Here's a thread about puzzle dependency charts. My entire game is designed in one of these--I found myself writing out plot ideas and other non-puzzle nuggets into nodes as I went. But just for puzzles, charts are useful for pacing your game, avoiding dead ends, and designing parallel puzzle chains that interact with each other in interesting ways.

[LimpingFish]

I don't.

[Dualnames]

for limping fish.

[Adeel]

I don't.

Ditto!