More Twine Thoughts…

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

<<display “randomcampflavor”>>

<<display “randommerchant1”>>

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*

4 thoughts on “More Twine Thoughts…

  1. B. Moore says:

    I’m unbelievably glad you’re continuing Cryptic Stitching as a game…yes, even as a book/comic it would have most certainly been wonderful but there are some ideas that must be explored by the individual and this is one of them. :) I’m currently playing through Act 1 on StoryNexus and it’s still very fun. I look forward to the completed version!!

  2. Don Hilliard says:

    I will freely admit that I understood no more than 50% of this post, but it still sounds brilliant. Go Wool-Tribe!

  3. Bookwyrm says:

    It seems like you could get into nested if-then statements using random variables, so that ultimately only a few quests are available (or none, if the chances all work out) even if someone is involved in lots at once. So something like IF(1-in-5 chance FROG, if not then IF(1-in-3 chance SHAMAN, if not then IF(1-in-5 chance KINGFISHER if not then nothing))) (I’m making up quest names because it’s been a while since I playtested). And you could have a couple of those stacks, so there might be more than one quest available at once. The probabilities get a little complicated, since, all else being equal, the further down the stack the less likely it is to happen, but someone who likes crunching probabilities could probably figure it out for you without too much difficulty.

    I’m super excited to playtest again. I liked my Mouse.

  4. Victoria Earl says:

    I expect you’ve probably received the answer to your question elsewhere, but this is how I would handle the problem presented in this post:

    Make a Master Quest card that handles all other quests. Make its function like:
    if (random chance is met)
    select quest
    display quest

    If you wanted more than one quest, then you can add a “for” structure to iterate through a for loop a few times, like:
    for (i = 0; i++; i == 3) (in plain speech, “do the following 3 times”)
    if (random chance is met)
    select quest
    start quest

    You can compress this a bit – and remove the need for the if/for functions – by putting all the quests in a “chance” range of numbers. Let’s say, quest 1 is numbers 3-5, quest 2 is numbers 6-9, quest three is number 10. You then select a random number between 1 and 10. If a number between 0 and 2 is selected, no quest. If a number between 3 and 5 is selected, quest 1 is displayed… so on and so forth. You can select this random number however many times you like to get 0 to n quests. Of course, in reality, you’d probably want to have it something like numbers 0 through 50 being ‘no quest’, but you get the idea.

    The last thing you would need is a to prevent selecting multiples of the same quest. Checking for duplicate quests shouldn’t be TOO hard. I hope. You would just have to store the quests you selected so far, then check new quests against them. If there’s a duplicate, don’t add it.

    Anyway, you just display the Master Quest card in the main card, and it handles the selection of the quests for you and spits out “0 to n” quests.

    I don’t know about the back/return problem, that does seem like a limitation of the engine… but perhaps others have found a solution already?

    PS: I have absolutely no idea how Twine works. Also, I don’t code on a regular basis, so a Real Programmer could probably give you a considerably better solution. That being said, if you want to talk about this problem or anything else with the game, I am happy to chat and/or give useless advice. :’D

Leave a Reply