Wait a minute, that's not really what I mean
Yes, but you shouldn't
Gah! That's not quite right either...
OK, look: I've been thinking about this since I first saw the question posted and I've been chewing over why my first, gut answer was just no and trying to get at the reasons why. I think I've finally got it, so brace yourself:
I'm in software. So I think of things like...software. There are two structures that are kind of like a CYOA and I'm going to explain what they are and why one of them is OK for you to make, but neither of them is OK for you to present to your player. Here we go!
A graph is a structure that consists of two types of entity - nodes and edges. So let's say you've got a diagram like this:
| the | | The |
| pub +------->+ old |
| | | mill |
The boxes with "the pub" and "the old mill" - those are nodes. The arrow from one to the other is an edge.
There is nothing wrong with condensing the adventure into a graph like this, for yourself. GMs have been making and using crib sheets for adventures presumably since the very beginning of adventures.
Now, take a graph one step further, and make each edge describe how you get from one node to the other. Kind of like this:
+------+ Chat with the +--------+
| the | barmaid (charm 1) | The |
| pub +--------------------->+ old |
| | | mill |
talk | +--------+
to old | | the |
man | | burned|
withers +--------> | chapel|
(charm 3) | |
Now you have a state machine, where each node represents a state for the adventure and each edge represents how you can transition.
This is not a good idea - not for you and not for your player.
Here's why the graph is OK but the state machine isn't:
If you want the reassurance of a quick reference, the graph gives you an at-a-glance summary of the people, places and things, in other words, scenes, you need to keep in mind. But...
The state machine is too much work. You're going to boil this adventure down, try to imagine every pathway, and decide ahead of time what the necessary rolls are. Some of that work is going to be wasted. Just in the example above, if your player talks to old man Withers, the work you did on the barmaid path and the old mill node is wasted.
- It anchors you to solutions. Anchoring is a phenomenon where the first value you attach to something sticks with you - no matter what you learn afterwards. If you associate the exit to a scene with a given action, you're going to anchor yourself to it - making it harder for you to react in the moment when your player does something different. That's a problem because...
- No matter how thorough you try to be, players will surprise you. That is the truth of being a GM and that is exactly as it should be. If you knew what was going to happen, why bother having another person there? Just go write your book.
Neither of these things is OK to show your player. Much of the magic of tabletop RPGs comes from the feeling of freedom - from not having the constraints of menus, options, and limited action that come from game books and computer games. Give your player a menu of A, B, or C and you've just murdered that freedom - congratulations on ruining the magic.
Your job is to present the world and let her act upon it, not to keep her on the path you predetermined.
I hope that's a better explanation than just no, even though it largely boils down the same.