What's the simplest technique to create a Text Adventure? One room at a time or creating all rooms first and then adding details and what not later?

Sorry for the long title. But I am curious what is the easiest technique, either for the short or long term, in creating a text adventure. I have a game I built almost to completion, but I am curious what the majority of authors do. Do you guys create a room and add all possible elements to it that you could think up at least at the time- lengthy descriptions, puzzles, etc. before moving onto the next room and repeat the process? Or do you map out your game with rooms first and then go back and fill it with descriptions, puzzles, etc.?

My game was basic, although I like to think of it as having some surprising elements, especially for a first game. But I am not sure if I were to make it more complicated (The first in the series would not be.) how that would affect it using Quest. I am not sure how coding works or the "skeleton" check mark boxes of Quest that affects the entire game and if it would quite possibly break it if the focus of one aspect was added too late. I know I had working roving NPCs, thanks to a person in the forums, but it broke once Quest was updated. So I am a bit leery on how to do things in Quest with the possibility of breaking something. Thank you.

With me it is a mixture of both. First I create the rooms I absolutely need, then I add rooms when I realize that I need them for puzzles or simply as locations

Both for parser and gamebooks, I don't touch Quest or any code until I have everything planned and all the texts already writen. Even menus or descriptions or answers to given verbs or optins already have their responses planned before start building the game. Mostly.

I when I start a game I have no idea how it’s going to end . It just seems to wander off on its own and do its own thing. I was amused once when I got a review “ A meticulously planned and constructed Game” in fact it just kinda grew.
I tend to do a section then go back and flesh it out . I then have time to collect thoughts about What happens next. My current game has my character getting in a lift . I have no idea what he/she Will find. The game hasn’t told me yet.
I find fantasy mixed with comedy and the macabre works well.

Whether you plan everything in advance or design your game as you go, I found that implementation goes better when you first flesh out a room before moving on to the next, going from where you begin the game to where the player might go next and so on. That doesn't mean polishing each room to death before continuing, just enough to make it more than a scaffold. It's a lot less daunting that way.

The only games I've finished were either remaking an older game (so not much planning needed), or pretty much just tech demos (so don't need to think too hard about the story).

In those cases, I've always added a room, added objects to it, and moved on to the next. Any puzzle gets coded as soon as I've created all the objects needed for it. Though in the case of a puzzle that needs some items that you won't find until later, I might put the items in the room for testing, and then move them to their final room once it exists.

For me, I create the story first in Word / similar, adding in the key beats and set pieces and likely scenarios which would make cool encounters or puzzles to solve.

Then I create the map for the game world in Excel / similar - places I know for sure I want the player to visit. This seems to come naturally based on the plot.

Then I put in the key puzzles before I even write any descriptions - ideas I'm sure I want to implement. My current adventure, I knew I wanted the opening scene to be an escape room kind of thing, i.e. several puzzles based around scenery and inventory manipulation that you need to solve before you even get access to the full map. This was inspired by openings such as those from Broken Sword II and Escape from Monkey Island.

Once the player has gotten outside, I knew I wanted them to have to retrieve a certain item from a certain place to progress, and I knew based on where I placed that item that the player would need to fashion their own tool to retrieve it, so I set about creating an interesting set up for that to happen. I wrote in all the object descriptions and all the flags and play-tested the puzzle in full before I'd even done location descriptions for the places the player would need to go.

Then I went back through those locations, added sounds and pictures and descriptions, and fleshed them out until I felt they were 'complete' from a gameplay perspective. Once I'd done all that, I went back through those locations again, and added a lot of colour to bring the world to life and make it feel more tactile and tangible. So for example, lets say I had a woodland clearing and I'd set up several items to help the puzzle along, and I'd finished it from the point of view of the actual gameplay. I would go back and added a load of scenery items that match with the description - a fence, the grass, clouds, sky, leaves, trees, the hilltops beyond, a building on the horizon. Each of those would have their own 'examine' description, simply to add some depth to the world.

Once I'm happy that's done, I'd move on to the next batch of puzzles and locations :)

It sounds like a hybrid approach is used by everyone depending where you are going...
If you want a "lost in a maze" game... you need all the rooms in place first, then go back and describe each one, then add the items, if any.
If you want a "story", you start with the first room... What does the player do, what dies he find, then the first connecting room, flesh that out, then the next, and so on...
As for me... start with the first room, and go from there adding rooms as I go...
As for the descriptions... They "write" themselves depending on what I "see" and I don't always know where it's going...
The problem with this approach is that if there is ever a break, you may not be able to "get back into the story", and everything is lost...
(I have 2 games in limbo because of this... actually, make that 3.)

Log in to post a reply.