When building IF, what are the trade-offs between building depth first versus building breadth first?
For example, building a story depth first would be to build a very flimsy story that can be won, but not else. Then the author goes back and starts progressively adding detail to the story as he wishes.
Building a story breadth-first would be to build a very solid first scene that was complete (or mostly complete) before building the second scene.
It would seem to me that the advantage of depth is that once you’ve got an end-to-end game, you can add detail until you are tired, and then you can release because you’ve got a winnable game. It also has the advantage of getting you to think about your entire story from end to end early so you can identify common parts of code, and avoid wasting time on fluff that’s not core to the game.
On the other hand, I see breadth-first as a better way to include other participants for testing. You can give them the scenes in sequence, like chapters in a book. Because the scenes are complete, they can play and enjoy them.
Are there other considerations? What have others done?
I don’t know how experienced an IF programmer you are, but for a newbie like me, I found that it was almost impossible to build a bare-bones winnable game all at once. When lots of things depend on lots of other things, and the winnable walkthrough is long, and you’re inexperienced at every piece, if you try to build them all at once it seems to take forever before you can even do the first test, and then your game is too big to test.
This is what I did. Suppose you have to go through a string of tasks to find and get a screwdriver, and you have to go through a different string of tasks to use the screwdriver, and then maybe a different string of tasks to use the thing you built with the screwdriver, and so forth. I tested each segment in its own “tester” project with the needed items already there, and integrated them into the “real” game once they were bug free. So in other words, I just put the screwdriver right there on the ground when building the tester for using it, even though in the final game the player would have had to jump through some hoops to acquire it.
This proved useful because as a newbie, some components of the game were easier to build than others, and some components I’d be especially inspired to build at a particular time because I’d just read about a cool way to build them in the documentation, so it was nice to build a part when you were inspired to do so and not because all the parts that came before were perfect.
Short answer: I guess I did what you’re calling breadth first. But in small, not-overwhelming chunks.
That said, I also added stuff after I was “done”: more descriptions, randomized conversational reponses, humor, etc.
I tend to get most of the game gelled in my head or in my notes first, then build it, as you say, breadth-first – implementing the first scene, fleshing it out, testing it until it’s reasonably solid, then moving on, chronologically, until I get to the end.
Perhaps, but then you run the risk of releasing a winnable, but poorly implemented game, which to my view is no more “complete” then a well-implemented game that’s only half done. Which is not a criticism of depth-first design per se – I think you go with whichever one works best for you – but I would be wary of going into a project planning to release it whenever I get tired of working on it. I won’t release something unless it’s complete, and the advantage of breadth-first for me is that it’s easier for me to tell when it’s complete.
I tend to get most of the game gelled in my head or in my notes first...
Yes… I also designed the game on paper and with a flow chart before starting. I highly recommend this. I found that even if small sections weren’t well thought out they affected other sections when I finally gelled them, and that’s no fun after you’ve already spent a bunch of time implementing things.
It’s also possible, after designing the game, to add extra loops of activity when the main game or even parts of it are well implemented. You can plan at first to allow the PC to grab a needed item out of a room, and later if you’re inspired you can create a little mini challenge in getting it.
I like the depth-first approach (although I really think of it more as breadth - to me depth seems more like how deeply you implement things).
I’m very easily distracted, and I like the sense of achievement I get from being able to say that I’ve implemented the complete map, added all the characters to it, then added the scenery and decoration.
Although I guess I am kind of scatter-brained. I really just work on whatever’s caught my interest, filling in ticks on a grid of things to implement before I consider the game complete. I do always leave the scenery and decoration and in-game nudges and hints until last because I just find it so tedious.
Ultimately, I think that no IF game ever can be ‘complete’. The simple fact of accepting natural-ish language input is that you could arguably spend forever adding responses to sensible input.
I’m with Pacian - I’d rather get the basic framework of the game in place and then go back and flesh it out. (Of course, unlike the others, I haven’t released a game yet, so…) If I implement the early parts of the game fully and then decide I need to radically change something basic, I’ll have to lose a lot of work. I got slightly burnt with this on my WIP a while back, when I decided several areas of the game needed extreme makeovers, forcing me to edit or even scrap the scenery items I’d already implemented. I try to make sure I have a good idea of the structure of my WIP before I start programming, but it’s hard to tell whether what I’ve planned will work out until I actually see it in the game. Implementing just the backbone of the game and then going back to fill in the details lets me get an idea of how it will work out before I invest too much time in details that might well have to change.
The other reason is that I’m pretty detail-oriented, and it’s easy for me to get bogged down implementing everything I can think of. “But if the player foos the bar before the baz, they should have a different response to frobbing…” Then I realise what a mess I’m getting myself into, tear my hair, and go read a book instead. I have an old prospective Art Show entry which succumbed to this obsession with unimportant details. In one of its areas (the only area I ended up implementing), there’s a hut. I wanted the hut to have a dim interior that let the player see and interact with large objects, but not small objects or details of large objects. I spent days hacking at the TADS 3 lighting model and finally managed to make it (appear to) work. At this point I realised that it really didn’t matter that much whether the hut interior was dim or not and collapsed.
I thought of something else to say about this issue. For me another benefit of doing a complete piece at a time (as a newbie) was that I learned a lot by testing one piece that saved me time on building others.
As a trivial example, I found that the articles and capitalization used when naming a person or animal (the spider, The spider, a spider, etc) affected built-in responses. For example, sometimes I’d get an awkward response like “I don’t think Spider would care for that” that taught me something about how the spider definition should be written. It was easier to fix that once and do it right the next time, I think, than it would have been to have gone across fifteen definitions and tweak them all (which is boring and annoying). Take that one example times the fifteen things I learned while building it, and that’s a worthwhile savings of time I think.
Here’s a thought I had for fleshing the primary thread. Perhaps others could comment if this would be worth trying:
Write a “winning” version of the transcript first, then start coding the story so that the winning version of the transcript can be recreated through play. Then progressively add more and more features and error messages until the game is complete.
Perhaps the value here is that you see all the connected prose together without worrying about all of the sources that have to come together to compose it. I wonder if it might help me stay “at the top level” of the story. The effort to prepare the transcript could perhaps be reused in cutting and pasting the work into the code when it is done.
In my own development, I am finding that I am getting too mired in the development and details (which is fun!!) and really haven’t put enough into the big picture. What’s resulted is a big picture that feels too cobbled.
What I don’t like about this method is that once you leave the transcript to develop the code, it would be too tedious to maintain the transcript.
I seem to use neither approach, or both. I come up with an idea for a story. I start working on it. Before long I think of some other stuff to add, or decide that some of my first ideas don’t work and change or delete them. It’s not a linear process, it’s just doing the next indicated thing.
Certain things, such as scenery in the rooms and making sure the verbs have reasonable synonyms, tends to get left until a later stage. As a result, my testers spend more time than they should need to nagging me about missing scenery and synonyms!
At any point I might decide something more is needed because a puzzle seems too boring. I can think of two major places where that happened with my '09 Spring Thing entry, but I can’t talk about it yet because the judging hasn’t even started.