I have one small bit of tiny advice with Twine… But never create a BACK link inside the webpage. Keep the game flowing forward…
That is to say, if you have a link to something that says “You see a [[chair]]”, and chair leads to a description of that chair, build something off that page. Don’t force the reader to go back to the previous page through an in-game navigation.
The only place where this works for me is howling dogs, but that was trying to create a finnicky/oppressive environment in the pod. And this isn’t to say not to use recursion, repetition, etc. It’s just this one craft aspect that can stop the game’s flow. Hope that helps.
Sequitur: I absolutely agree, and I certainly intend to take advantage of transparent statefulness! In the first bit of my current WIP, your initial reaction to an event actually colors the subsequent descriptions of an associated character, on the assumption that you’re noticing details that confirm your bias.
inurashii: Interesting! I look forward to playing that.
“You enter the room. There’s a [[chair]] and a [[table]] here.”
(clicks “chair”)
“It’s a chair. Nothing special.”
[[Keep looking around]]
(clicks “Keep looking around”)
“You look around the room. There’s a chair and a [[table]] here.”
Basically, enough change to reflect what you just did, but still letting you return. I just don’t like being whisked away from a page of links that I expected to be able to explore at my leisure.
Morgan_R, for that kind of stuff I really recommend L’s <> macro, which (as well as lots and lots of other cool things) allows you to have a link in a passage that adds more text (eg a description) without ever leaving the passage.
Thanks. I’d be way more tempted to use <> if the transitions didn’t appear to be buggy, at least for me (with Win7 and up-to-date Firefox, nothing weird). Instead of a nice smooth fade, they just pop in 90% of the time. I know that sounds minor, but I find it pretty jarring.
Yeah, it is annoying, I’ve had the same problem outside Chrome. Interestingly the Sugarcube header’s version of <> seems to work fine in Firefox! So you might want to take a look at that.
Really? tries it Hmm… seems to pop in for me. Is there some CSS I need to add, or is the transition a fade by default? Sorry, I just don’t know where to look to figure that out…
I’m on an iPad right now and Apple won’t let me look in a .zip file in case I bring about the fall of capitalism, but I think there’s a CSS snippet in the macro zip on the Sugarcube site.
That makes sense in games where the main passage is not only the description of a room, but also includes some action. If you have a room description like "Your father is sitting on his old [[chair]]. As he sees you come in, he stands up and says, simply, [[“Hello, son.]]”… then yeah, going to the chair description and coming back to this sentence is rather poor.
Personally, I hate it when I don’t know if a link will move the story forward or just pause to show me something. I never know what clicking the [[chair]] will actually mean.
What aggravates me worse is NOT including a “back” button, and then relying on the user’s browser to go back a page. Because that ain’t possible in offline playing in my iPod.
Don’t use the default twine styles. They are both hard to read. At minimum, enlarge the text.
Try to avoid choices like “Do you want to go left or right?” IMHO the best CYOA has you affecting the story at a larger level, and should avoid fiddly navigation if possible. If I need to go to the kitchen to do something, that should be part of the choice. “Go make dinner” or “Search the kitchen more thoroughly”.
mostly useless: Now I’m confused – you did mean Sugarcube’s built-in ‘replace’ macro, right? There’s a zip that includes CSS for L’s macroset, which now includes ‘replacelink’ rather than ‘replace,’ but I assume that’s unrelated…
Peter Pears: Castle, Forest, Island, Sea used color-coded links to distinguish between detail links, cycle links, and move-the-game-forward links, which I think is an excellent idea. I also have some thoughts about examining the area when there are NPCs in it – namely, they should react to you looking at stuff, not just sit there like part of the scenery. [[chair]] in that case might lead to:
“You inspect the chair closely. It appears to be an ordinary chair.
Your father looks at you a bit oddly, and clears his throat.”
…except, of course, that I wouldn’t actually link “chair” if there wasn’t anything in interesting about the chair. But you get the idea.
HanonO, I’m inclined to agree, although I think some finer-grained navigation in an unfamiliar place might be appropriate.
Sorry, I meant L’s! I use <>, which in Sugarcane is <>… Got myself confused. I didn’t actually know about Sugarcube’s replace! Anyway, you can use <> to do what I said above, and the CSS works fine for me in Firefox.
Yeah, the default CSS on Twine’s templates isn’t ideal. Particularly, it uses eye-bleedingly small fonts. Given the kind of text most Twines have, you probably want somewhat oversized type.
Truth of the matter is, the DPI that fonts are rendered at on most devices, and the sizes of fonts on most of the web, haven’t really tracked the increase in resolutions over the last 10 years. The web as a result has way too much small print,
Morgan_R, are you by any chance using an old crappy PC? My home machine is knackered and Firefox can’t keep up with the fade ins, but my PC at work does fine, both with the latest Firefox.
Draconis: I could, but justification without hyphenation tends to not look that good. Hence the existence of Hyphenator, which is supposed to automatically hyphenate words in a reasonably sensible way. I just can’t get it working with Twine.
mostly useless: Nope, it’s a newish machine. Also, the fade-ins on whole passages work fine.
It’s a Twine-style tool for CYOA style IF (no visual editor yet, so it’s more Twee-style I suppose).
It makes a distinction between “sections” (which advance the story) and “passages” (which do not). So you can set up a world-model style game like this:
You enter the room. There's a [chair] and a [table] here. You can go to the [[kitchen]].
[chair]:
Just a chair.
[table]:
An ordinary table.
[[kitchen]]:
You enter the kitchen...
You can click the chair, the text appears, and the table and kitchen links remain enabled. If you then click the kitchen link, the table link is now disabled as you’ve moved to the next section.
It wouldn’t be for everyone, of course. It’s a compromise between IF and CYOA, after all, CYOA is theoretically supposed to keep moving forward like alan said in the first place… but with enough tools at our disposal, we should be able to create the game we want to create, and bugger cathegorisation.
This moving forward thing is what buggers me about CYOA: every action leads into a new page. I don’t understand why they keep calling you “you” when you’re just a reader as in any other static fiction. Meaning: you can’t simply connect with the protagonist, feel like you’re really there, able to mess around and experiment with things at hand in your own pace.
Well, that’s with multibranching choice-based CYOA. Twine hypertextual approach effectively allows for that bond between reader and PC. You can click away and interact with stuff, perhaps even altering things here and there.
