I’m working on a CYOA-style game in Twine, and I’d love any advice people might have, as writer/designers of these games or as players. Things you think should be avoided, things that work particularly well, etc. I’m sure a lot of what I need to know I’m only going to learn by trial and error, but it’s always nice to learn from others’ mistakes. 
You should write whatever you feel like, of course, but one thing that’s nice is to use a bit of custom CSS to make your story look different from the default appearance. If you don’t know CSS, there’s some easy to use stylesheets here:
http://www.glorioustrainwrecks.com/node/5163
Game wise, my personal preference is don’t just kill me all the time for no reason. That’s always nice.
Good luck!
Ah yes, the classic solution to the problem of branching: prune the majority of branches with death! Don’t worry, that’s not my style.
Thanks for the link!
Awesome, thank you!
Forum regular maga wrote a series of interesting articles on CYOAs with cool diagrams of their structure: http://maga-dogg.livejournal.com/tag/cyoa.
For a wide variety of players’ opinions, you could also browse the IFWiki pages for the annual IF Comp and sift through the linked reviews (but most of the IF Comp games are parser-based, the recent increase of CYOAs notwithstanding).
There’s also the IFDB: Here’s a list of games tagged as CYOA with at least one review each. I don’t know how much concrete advice can be extracted from the reviews, but I think one can glean a rough picture of what people like in the medium.
1 Like
Thanks!
whatever you do, don’t pull a Porpentine
yeah it’d be a real pity if you made an aesthetically unique, emotionally effective work with inventive interface mechanics that help alter the language of the medium
Who is Porpentine? 
But as namekuseijin has pointed out, blah blah blah I hate CYOA blah blah blah Twitter generation blah blah blah not even interactive blah blah blah.
I know that’s a little harsh, but if you hate CYOA as much as you repeatedly state you do (except of course in the one review for a CYOA game you really liked (which was incidentally the only review you’ve written that I could see being of any use to anyone) but seemed to instantly forget about in your next review) why offer “advice” on a CYOA design thread?
Gosh, I’m snarky tonight.
if by inventive interface you mean hypertext, yeah
truth be told, I’ll revise my review on CYBERQUEEN over at IFDB. It’s intriguing enough, using the static nature of hypertext to great effect in imposing psychological limits within the plot… guess it deserves 4 stars
I really doubt that anyone but Porpentine could be Porpentine.
ifdb.tads.org/search?searchfor=a … Porpentine
She’s written quite a few games in Twine. howling dogs won Best Writing and Best Story awards in the 2012 XYZZYs. ifdb.tads.org/viewgame?id=mxj7xp4nffia9rbj
Unlike a regular CYOA or gamebook, Twine allows for statefulness. I think that for any Twine work of significant length (E.g., a comp-length game), using that is absolutely key, as it allows for more diversity of outcomes and more impact on the plot without making a huge, sprawling branching narrative. In particular, statefulness can help cut down on ‘lawnmowering’ as exploring the game’s outcomes is no longer an exercise in clicking every link.
This is not unique to Twine, for what it’s worth: more or less every extant tool for computer-based CYOA allows basic state-tracking (and some foreground its use a good deal more than Twine does.)
(And so did many paper gamebooks, for that matter - in fact, when I hear ‘gamebook’ as opposed to ‘choose-your-own…’, I think primarily of books that included character sheets and required the use of dice. The thing that computers allow is inobtrusive state-tracking.)
One really nice thing about Twine (And other computer systems) as opposed to physical gamebooks is that they allow for transparent statefulness; the player doesn’t know whether an action is being tracked, and the player also doesn’t know whether a prior event is being referenced by the story. This allows for things that don’t work in a paper gamebook, such as simply not presenting an option to the player at all if they don’t have the requisite item, or making a passage totally different depending on what’s gone on in the story previously.
Also, because the content of passages is dynamic, it’s a lot easier to have a looping structure where a passage may be revisited at a later point in the play session, with remaining branches closed off or opened depending on what’s gone on previously. You could for example have ‘ending’ passages which vary depending on what’s gone on previously in the story, allowing for more variation in endings. Think like Slouching Towards Bedlam, which had six ‘classes’ of endings, but each ending could be slightly different depending on how it was arrived at. Twine not only makes this easy to implement, it makes it possible to hide from the player exactly what impacts the ending, which can encourage exploration and replays.
The silent statefulness and ability to alter and/or nest passages is one of my favorite things about working in Twine.
I’m currently writing a game that’s a kind of prototype for a procedurally-generated CYOA – every single playthrough will be different, and even each encounter you have will change depending on decisions you made in previous ones. Twine may be simple, but its tools can be used to create fairly powerful mechanics.
It also bears mentioning that writing in a CYOA language doesn’t preclude you from doing things that are typically considered ‘parser territory’ – you can still build environments and exploration, and if you pack enough changing info into your text you’re less likely to run into the “click don’t read” habit that some players report.
That was sorta my focus when I wrote Quit Your Job Simulator 2014 (http://philome.la/inurashii/quit-your-job-simulator-2014-a-horror-game).
1 Like
Heck, you can even rig a twine game to accept text input. Haven’t seen anyone use it yet, but there’s a macro for that.