I'm currently writing a text-adventure myself and choosed the following (unoptimized, clumsy ect.) approach. Why is explained in the conclusion of the answer. For the short version, skip to the end of the answer.
My game is structured in
areas which contain
player can have
roles which allow him to do something (or disallow him from doing so).
Whenever a link in the following answer is mentioned, it is a ONE-WAY-Link. If two different links link each other, that may look like a two-way-link, but they are actually one-way-links which happen to point at each other.
When I say type contains type, I'm refering to ''contains the file name and location''. This will should be understandable from the attached pictures.
area is a folder containing four types of content. These are
exit-points An exit-point contains another areas entry-point which it links to. An exit-point can be accessed by locations and entry-points (though later doesn't really make sense). If a player leaves a location through an exit-point, he will be transported to the entry-point of the linked area.
An area can have multiple exit-points (imagine you leave a town (area) through it's east-gate (location) to the mountains (another area) or through the west-gate (location) to the meadows (another area) ).
entry-points An entry-point contains one location within the same area. Entry-points can only be accessed from another areas exit-point (or from the game-engine, to drop the player in the world for the first time at game start). If a player access an entry-point, he is immediatly redirected to the specified location.
An area can have multiple entry-points (imagine a town (area) where you can enter from the east-gate (location) or west-gate (location) ).
locations Locations are folders bundling content-files (simply some .txt). A location has a describing text, an interaction list and at least one location-exit-point (and some other stuff not important for this question).
The describing text is simply the text that is shown when a player enters the location.
The interaction list contains (in a specified syntax) the reaction Y to the players action X.
Example: LOOK AROUND can in one location simply display the describing text again. In the next location, it would trigger a change to another location (because the player fell in a trap).
More often than not, the describing text already contains hints (or big signs, when it comes to this) what is possible in a location. If the describing text says there is a huge river next to the road, the player might want to FISH.
If an action is not possible in a current location, then the default message for this command is displayed ("You throw out your fishing pole and it lands on the ground. After a short time, you realize that without water, you can't catch anything").
A location-exit-point is basically the same thing as an area-exit-point, but can only link to locations and area-exit-points inside the same area. This is simply to shorten path-names.
dungeons These are sub-areas to have less clutter in an area-folder. To everything inside an area, they look like locations, but are areas. The only special thing is that they can have at most 1 (ONE) entry-point.
A little picture (sorry for my Paint-Skills):
Shown is the way my linking works. Note that Entry C.B is not accessed currently. An Entry-Point without a corresponding exit-point can exist (for example for future expansions).
The programming is basically done in the interaction-list of the locations. The player issues a command, the interaction-list says how to react to it. Of course, the possible reactions have to be coded somewhere. Up until now, I managed to do everything with static methods, because boiled down, there isn't much a player can do (look, skill, talk, leave to another location).
WHY? WHY ALL THIS TEXT FOR SUCH A LITTLE CONLUSION?
Valid question. I'm wrking with two non-programmers. They are responsible for the story and stuff, I do the coding. I had the choice to teach them how to programm a location, or simply read textfiles they give me. As they were somehow resistent to learning, I got stuck with the textfiles. Today, I'm happy with this.
Need a new entry-point? Throw in a new file with the specifications.
Another interaction, but can't edit the basefiles (because we're modding, and basefile-edits are bad!)? Throw in a new interaction list with a running number, because the parser only checks if the file starts with
Add a whole new town into the landscape? Throw the area-folder next to the others and add some exit-points to the existing regions.
All in all, this might not be the best approach, but it will definitly ease your life when your world gets bigger, because not a single line of code has to be touched anymore!
Thanks for your patience with me.