So I’ve successfully–at least, I hope–at least, nothing looks broken–ported the prologue of Cryptic Stitching over to the Twine engine. (We’re a long way from playtesting, but rest assured, there will be a call for testers when we get there!)
(Incidentally, if you are stuck or want to ask for hints or share what you’ve learned playing Cryptic Stitching 1.0, head on over to LJ and this entry, which I’ve got set up for that purpose.)
I’m using the SugarCube version of Twine, which allows for saving the game (a function one could not do without!) and apparently won’t clutter up the browser cache in some obscure but apparently significant fashion.*
The differences between the two engines are interesting. StoryNexus is really cool and has a great interface, but has some significant limitations. Twine ultimately looks much more flexible but you have to do a lot more in the guts.
I’m not sorry I started in StoryNexus–the system made me think about what I was doing a lot, and the ultimate Twine result will be heavily influenced by those choices. Switching does allow me to rectify some rather clunky workarounds I developed, based on the fact that I started without any kind of plan. (The travel system in Cryptic Stitching is pretty much held together with chewing gum and paperclips. It will work MUCH BETTER in Twine.)
Some other useful things, at least so far–randomized flavor text and (I think) the ability to have merchants show up in camp at random, without having to visit them. (And the ability to sell ALL of an item, instead of doing it painfully one click at a time, which was clumsy as all hell in StoryNexus and wasted turns and turns and turns.)
Also, no spoilers in the “This card unlocked with:” mouseover, which I found maddening and there was no way to turn off. Also, there are no hidden variables in StoryNexus–everything must be visible to the player in some fashion–so I was making visible variables do some VERY questionable duties. (For example, your yurt, over on the StoryNexus sidebar? That value controls at least three different questlines, possibly more. And if you level your pet lungfish, your inventory says you have two of them. Necessity is a mutha.)
But there’s a couple of things I’ll miss very much–the inventory system was nice, and the ability to use objects on the fly. For example, at the moment, it’s looking like you’re going to have to return to your yurt in order to heal yourself, which is less convenient (but does have the advantage of making death more likely! And cool things happen when you die! Everyone should try it at least once!**)***
One thing this is doing it making me re-analyze how I laid the game out. Because of the way StoryNexus worked, with various “areas” that controlled what cards you got, I’m still thinking in terms of areas in the game. Each of these areas is getting a “hub” card–Wool-Tribe, Moon-Stuffing Camp, Withyjack Forest, the Steppes, etc. The hub always allows certain options, coinciding to the pinned cards at the bottom of the screen in StoryNexus. Various quests lead one away from the hub, then back to it (or to another hub.)
One truly great advantage of StoryNexus was the ability to make events seem to take time. If you’re chasing the Sinister Frog around, it doesn’t happen all in one long run–you chase him, then you do some other stuff, then that damn Frog is staring at you again, and there’s a real sense of elapsed time. You are–at least, I hope!–looking forward to getting another Frog card to figure out what happens next.
It’s an effect you don’t get nearly so much if you just keep clicking choices at the bottom of the screen, ya know?
I think one of the big challenges of Twine will be creating that feeling. If you follow every story line in a linear fashion, there’s a lot less anticipation. (The downside being frustration, because goddamnit it, I want to chase the Frog and somebody’s trying to get me to use every part of the bloody reindeer again.)
Here’s my thought–I’m bouncing this off you guys, since I know there are many coders and designers reading, so feel free to chime in.
One of the useful functions is <<display>> which lets you pull in the contents of another–I keep thinking of them as “cards” because of StoryNexus, so let’s go with that, even though they are more properly called “passages”–into the current card you’re reading. So our hub card for Moon-Stuffing has
And those are all other cards off to the side which can be full of ugly variables and if/else statements. The first one prints a text string which provides a little local color, and the second one controls the random merchant function, which I am still tinkering with.
Taking the Sinister Frog example, I’m wondering if I could get the emotional impact I want by having
<<display “frogquest”>> planted in the hub card.
and then have “frogquest” be randomized , so that, say, two out of three times there was a call to “frogquest,” you get nothing, and the third time, the next stage of the Sinister Frog pops up. (Essentially you’d need to wander through the hub and then it might or might not appear.)
If you follow it, well and good, if not, the next time you show up, there’s a 1-in-3 chance it’ll be there. (Or 1-in-4 or 1-in-10 or whatever. That’s a balance issue, and will come out in playtesting, I expect.)
(My random event design is a little clunky, but not, I think, particularly onerous–assign a random number to a variable every time the card is called, and if the random number is X, the linked quest line comes up. Once the quest line is completely finished, calling the card does nothing–well, prints a space, actually–and should be largely invisible to the player.)
My only fear is that if I do this too much, I risk winding up with WALL OF OPTIONS on the hub card, as ten different quests all fight for space. The randomization may help keep that down, but then again, it may not. I suppose I could even randomize which <<display>> options come up–assign them all a number value and roll a random number and pull up whichever number comes up, but now we’re getting into walls of variables…
I dunno, anybody got any thoughts?
* I understand nothing.
**In the game. Obviously.
***The code problem is thus–I can make an inventory button on the sidebar which displays your inventory when clicked easily enough, and then returns you to the game using a function <<back>>. This function returns you to the last page you were on without retrigging the functions on that page. (Otherwise, you could just sit on a page where you got paid and just visit your inventory over and over again to retrigger the function that increases your money.) However, if I want anything that happens on that inventory page to stick–using healing herbs, say–I have to use the function <<return>> which does re-trigger the functions on whatever page you were on, which could potentially be a game-destroying bug.
So I think I’m making an executive decision that the only way to get healed is to go back to your yurt, unless one of you clever devils can think of a workaround. *grin*