It is tautological that a game is meant to be played, or every game would be like FFX. Thus, it is quite important to have a means for the player to interact with the game (It's called "interactive fiction", after all). It follows that a means of creating a game is required. Which means writing code.
I can't give you any real advice of what to pick if you want to create a game: There are far too many choices that you can make, even in a niche as small as Interactive Fiction. Personally, I use
TADS 3, since I like its library and syntax. Though if you don't like C-style languages, TADS will not be your cup of tea, and if you aren't a practised coder, the code will look like gibberish to you, anyway (in that case, take a look at
Inform 7).
But before you write (too much) code, you have to do your legwork: You have to know your audience, and you have to know what the story will require of you.
Knowing your audience is the easiest part: Set up a survey to find out what games your audience has played, and what they did (not) like about these games. This isn't the gospel, of course, but it gives you an idea what the player expects, and considers fun.
The difficult part is what the story demands of you.
Map out as much of the plot as you can beforehand. That gives you characters and locations to work with, and gives an idea of how much coding will be required. Don't be afraid of leaving gaps: those will fill themselves pretty quickly as your story and code develops.
Pretty much every story can be broken down into three acts: The first sets the stage and introduces the characters, the second established the conflict, and the third act resolves the conflict. That's obviously just a rough guide, but the principle holds true: Introduce one thing after the other, and then provide resolution.
Ravens in the Sky follows this structure relatively closely. Which also means that not a lot is happening at the beginning: the player explores the setting, gets a couple of clues as to what has or might be happening, until the player sets off a major event, changing what she thinks she knows about the player character in the game. But exposition is boring, so I make exposition optional, by providing items to the player that she can choose to interact with (which is most likely to happen on the first play through), while limiting the amount of infodumping, so that every thing stays digestible. I stole one of BioWare's ideas, and
created something Codex like. Of course, this technique is used to build atmosphere, too.
However, you should not hide important information in exposition! Exposition is supposed to bring the player up to speed on the game's world and the story so far, and nothing else.
And while the plot influences the amount of code you have to write, the opposite is true, as well:
I wanted Ravens in the Sky set in a town, but I didn't want to code up the tens of NPCs that would have required. But towns aren't barren, so there has to be a
reason the town is depopulated. This saves on work, and helps create atmosphere.
Neither do I want to do too much work outside of the town, so player movement has to be limited. Keep in mind that the reason for the limits you set doesn't necessarily have to be apparent to the player in an instant: The reason can, and should, be revealed slowly, so that it can be used to build atmosphere, and drive the plot, too. The most famous example of using limits to great effect are probably the first three Silent Hill games, where the town of Silent Hill is covered in fog, which limits the burden on the console, while creating a claustrophobic atmosphere. In Ravens in the Sky, the fog appears like a sentient being, or at least as an agent of one, confining the player to the places I want her to be in, while providing (hopefully) a good reason to stay where she is.
Next time: Worldbuilding and building worlds.