I saw a post somewhere once about working with RPGM that was very illuminating, and I'm wondering if there's anything similar around for text adventures (or IF in general).

The post discussed why a lot of people get sort of lost in their design process and end up abandoning projects. It presented a potential model for outlining a project, including a certain structure common to successful RPG's (essentially 8 iterations of:
explore world > new town > explore world > new dungeon).

I'm just getting back into TA design, learning about Quest 6/JS, and I was about to start laying down items (I previously made a list of the items I want in the game). Then I thought, if the items have an attribute for their location, should I should start by making the locations? Or should I do more outlining first, and then go through the game in order of play, rather than doing all the objects at once?

Point is, I'm now wondering about advice on that kind of design theory. Do I really need flow charts, for example. Is there a good wiki or article about that kind of stuff around that has become sort of an accepted traditional model?

I'm also open to hearing your thoughts on all this, of course. I think if I'm really gonna get anywhere, I need to find a rythm that works for me.

I also just noticed, upon my return to this site after a couple years absent, that I have about 8 unfinished projects listed in the Quest online editor! I don't want my current project to end up on that pile.

I don't think there is anything about "HOW" to write a game, just the how to write the code.
The problem with the "HOW" part is that 8 people can give yo 20 ways to do something, and, after a bit, you can come up with number 21.
Everyone has their own style, and few people can copy, or follow, someone else's way to do things.
I think projects get abandon because the writer lost focus or lost interest.
(I know, I've got a few that are waiting for me.)
And the problem is that if it sits too long, it would be easier to start over from scratch than to continue.
Especially, if you are still learning, and finding easier way to do what you were trying before.
I think, for a TA game, start with where the player starts and follow the player through the story. Maybe going back and adding more detail to past rooms.
But got a graphic game, RPGM, you would start with the world map. and add towns and dungeons as you go.

I sometimes wonder if it is best to start at the end and work backwards. That way, when you test you game, you are immediately at the bit you are working on, and you do not have to plough through the first half for the hundredth time just to find it still does not work.

There is also a good argument for dong the most complicated bit first. If it turns out that it is impossible, you will have wasted less time.

Never actually put that in practice though. I have great ideas for the start of a game or the basic premise, so start with that, and it fizzles out because I do not have a clear idea of what should happen in the middle.

Pixie - I always make sure I have a debug variable set at the very beginning of my squiffy code. This allows me to put in direct links to later sections of the game (and earlier set ups) as links that only show up if the debug is on.

Most of my games are highly random and it would be nearly impossible to get to certain spots without some luck and an hour of play.

I have been working on something as a sort of exercice. It is a Gamebook, actually, because I have some aims in mind like making it more "storywise" and characters driven. You know... trying to test some theories of mine.

But in general, there are things I found useful, both for gamebooks and text adventures aswell.

I strongly suggest having an outline. Perhaps you will find yourself working on layers of outline, and it is ok. The most time you spend on outlining your story and your game, the better. In my specific experience, I found myself working on a general outline for general "events" and then spliting it into scenes and then into pages. I was worried about this process, because I initially thought not having an absolute outline with everything possible would be a problem in the long run. But actually it helped me a lot on slicing the meaning of things and having a better perception of the whole game when needed and then dive into the details when convenient.

Having a general picture also gave me a boost on something essencial: the game system. Most people pictures a system and then tries making a game on top of it. In my case, having a look on the options in the outline, I could figure what sort of game system I needed both to support that narrative and make it interesting. What sort of mechanics would improve my narrative.

I faced something very interesting on the drawing of the outline which relates to vignettes. Vignettes - for those not familiar to the term - is a little piece of the game. An event. The problem about vignettes, is that they a pretty much dissociated fro the general game. They usually exists because most games are 'map based' or 'event based'. When the character goes somewhere, there is that things happening there. It is - by principle - terrible for a narrative. Entering the pirate's den should be different dependng on the previous story. For vignettes, the general setup is always the same. Vignettes works as a little side game, what makes me reject it in general. But then came my realization: I HAD events THAT HAD to be that way, doesnt matter previous actions. So, my outline gained a sequence of Vignettes.

If vignettes are small, self contained portions of the game, how could I make it interesting and - above all - relevant to the game and the story itself? I intuitively did something already in use, later confirmed by "Choice of Games" documentation. They call it "Playing by the numbers". In their case, they decide the outcome of vignettes based on attributes the character has. I twisted the concept by using the vignettes to allow the player changing its numbers by decisions inside each vignette and these numbers would influence on later scenes. So, every gameplay sees the same pages and gets the same general results, but the character changes for future scenes.

And it takes me to another crucial concept. Choices. At many ponts of the story, I faced that situation where the character would do THIS, leading to THAT. And I always had a choice in mind. The one which brings the story to the place I wanted. But what other choices could I give the player. I noticed I was having a hard time giving choices which actually were taking the character out of the story in mind. By taking a pause, I realized that most games including choices, tends to be about what the character does. Doing this or doing that. If the story is about going into the woods, why giving the option of going into the market, or the road or the castle?

At this point I realized choices are not necessarly about what the character is doing. It may be about how to do it. Or how it feels doing it. And I did dive into it. My whole story is far less about what the character is doind, but how it does these things, what it feels and what the character tells to others and to itself for taking those actions. So, expand the concept of choices. It would be about WHAT to do, or HOW to do or WHY to do.

Another important point is documenting and tracking everything. I work with a text processor to spell check my text. But it also contains my Logline, which is the games general description for I never lose the aim; it contains my charactres, their motivations and any relevant detail; and it contains a list of every single attribute, flag and piece of code the game uses, explaining where it goes, how the game uses and its purposes.

Well... these are some things I learned by doing a little excercise. I hope it helps someone, somehow.

At this point I realized choices are not necessarly about what the character is doing. It may be about how to do it. Or how it feels doing it. And I did dive into it. My whole story is far less about what the character is doind, but how it does these things, what it feels and what the character tells to others and to itself for taking those actions. So, expand the concept of choices. It would be about WHAT to do, or HOW to do or WHY to do.

That is an excellent idea.

Another important point is documenting and tracking everything.

Also a great idea, and I suspect especially so with CYOA type games, where the game engine tends to hide the mechanics so much more (or at least that is my experience of Twine vs Quest).

Thank you for the feedback, Pixie!

There was another point I forgot mentioning in my previous post.

There are three beasts you need taming. Not mastering, but taming good enough for the project at hand: Writing, Coding and organizing.

Writing is far less about verbs, grammar or vocabulary, but an author should focus on hw structure narratives. I did study a lot about script writing and novel writing, basically watched all the Youtube vidoes from "Film Courage" and "Brandon Sanderson".

Coding is ecxatly that. Know the code you need. Dont come up with highly complex engines and code scrpting if you are not 100% sure the game needs it. If you plan adding something to the game, learn how to code it and save what you learned into the documentation.

Organize stuff. Writing a branching story is like doctor Emmet Brown thinking quadimensionally. It is complex and if you do not find a way of keeping your game well organized, you will sink on unmeaningful choices and useless prts of the game.

Remember you just need to learn about these as much as your project needs to. Dont get wild to become a master degree on anything. But as soon as you fnd you lack what you need on one of those, go and grab the knowledge you need.

8 unfinished projects listed in the Quest online editor! I don't want my current project to end up on that pile.

Oh, thank you! I feel a lot better about my 5 unfinished games!

Oh, thank you! I feel a lot better about my 5 unfinished games!

I found I had 7 on-line editor games, though there is good reasons for most - testing the tutorial, etc. So then I looked at uploaded games, and found 27! On my harddrive I have 25 Quest 5 games, despite purging some only a week or so ago, and 31 QuestJS games. There is some overlap between what I have uploaded and what is on my harddrive, but surprisingly little! A lot are tests or demos, and a handful of Quest 5 have been (at least partly) converted to Quest JS, but there are a lot of games that never got anywhere. Some are little more than a character creation process...

I have actually resurrected a game I started in 2013, and I might actually finish, and submit for IFcomp. The first draft is about 95% done, so it does feel like it is nearly there.