I’m going to go out on a limb here and suggest that it’s not impossible to start creating a text adventure from the very first room referred to as the startroom.
Traditional IF calls for you to usually construct a well planned map and idea on paper before even reaching for the white space to begin coding.
I dare to differ by having the white space call out ideas to you. After you have created an intro and your first room. Sit back and think what should happen next. What would be logical? What would be interesting? Let things develop and enjoy the ride of imagination. Then, as ideas flow in, and become more intricate, then you can go offline and construct solid concepts and perhaps maps.
I believe this formula is good for beginners because you will spend alot of time learning to code. It wouldn’t be good for morale if you created this vast world on paper and then couldn’t get it down on code.
I don’t think I’ve written a game yet where I had the whole thing planned, or even mapped, out before I started it. Being spontaneous is good sometimes as it allows you to start writing the game “now” and not “in 3 or 4 weeks when you’ve got the thing planned out down to the most minute detail”.
I do that to some extent, but I really try not to. When I’m working on something that’s going to take weeks, I’ll forget what my original idea was if it’s not all planned out. I mean, if I’m setting something up at the beginning that’s supposed to come into play at the end, and I haven’t thought out what’s going to happen in the middle yet, I might not even remember how everything fits together.
As a learning excercise, or maybe if the game is going to be really linear, it might work. But then it’d be tougher to spot and prevent mistakes in the design. I usually start with something rough – the concept, and a few key points I need to happen along the way. Then I’ll fill in more detail, figure out the geography, the objects players will need, etc. I try to get that done (or mostly done) ahead of time, but I generally add the extra scenery stuff as I write the game, unless it was integral to the game by design.
Sometimes I think too much planning can kill a game even more efficiently than too little planning. I know some people who spend weeks and weeks planning their game out before doing any coding or actual game writing. They write the entire plot out, they draw a map, they list the location of every single object and NPC, they work out their puzzles and which objects are needed for them, they detail every little minute aspect… and then, months later when they get around to the game writing side of things, they found they’ve lost all interest in it.
At least if you start writing a game spontaneously, you can generally be quite a way into it before the initial burst of enthusiasm dies out. And it’s easier to find renewed enthusiasm for a game that you’ve already completed part of then a game you haven’t even started.
Well, I usually start games spontaneously. I’ll take the title and concept, build the frame and maybe add some verbs I think I’ll need, bring in utilities from prior games, etc. But as for actually coding rooms and objects and relationships between things, I like to get that designed ahead of time. It can go in stages, though. A game like Trading Punches – which had different “chapters” – I could just have a top-level concept for each chapter, and then design the next chapter after coding the prior one.
It’s probably the software engineer in me. I’m just conditioned to documenting and planning. At my job, we’re working on a huge new project with multiple developers. We had multiple design meetings, I wrote the scope document for my part (which took weeks), the use case diagrams, class diagrams, and database/relational diagrams. It was four months later before I wrote a single line of code.
For me, this would have to depend on the tools I’m using. If it’s as accessible as, say, Inform 7, where compiling and running the game is handy.
That’s why I stuck with TADS 2 before - it’s easy to just change the source code using a separate editor, run the HTML TADS Debugger to compile the source code, and test-drive the output. (Same goes for TADS 3.)
Well, of course, one can set up a batch file that can run the compiler, but…
This is how I started my game. I agree that it forced me to learn more coding as I went along, and encountered things that I wanted to do. As I learned, I became more confident, and kept writing. Now all my rooms are done, and my whole game is almost finished as well!
