Twine Experiment Results

Here's the latest build of Primordial Escape (hopefully this works).  It's very short and I have no intentions of continuing it.  So if anyone's interested, have at it.

Now let's talk about it (very lengthy post about Twine!  You've been warned).

I went through 3 other concepts and designs.  Each of those ended when I couldn't continue in an elegant manner.  More on that later.

Most of my time was spent figuring out how to do things.

CSS was simple to do and understand, but difficult to get right.  Finding out why some section is bolded or in the wrong color was a major time sink.  I imagine someone more adept with css won't have this problem.  As it stands for me, I'll probably either create one nice stylesheet and reuse it for every Twine game or use some other 3rd party stylesheet.

Macros was a bigger pain.  Finding out where you're missing a ) or ; is a hassle.  I suspect I may need a 3rd party program to do the javascript in the macros.  Either that or like css, use 3rd party stuff.  I think I spent at least an hour trying to find out how to pass the contents of a variable into a macro.  This isn't so much as the javascript but how Twine interacts with the macro.  It took me a while to figure out <<macro_name $variable>> didn't pass the contents of the variable.

Which brings me to the biggest hurdle.  Sometimes Twine doesn't make sense.  In the game, my plan was to change the color of the text has the player changes.  It's a common feature and should be easy in Twine.  You can apply a formatting to a section with the @@ command.  @@.header1;Test@@ give "Test" the formatting defined as header1.  Apparently you can't use variables.  @@.<<$color>>;Test@@ where <<$color>> is "header1" doesn't give it the proper formatting.
I had to resolve this using a macro, passing in the variable and the text.  The macro basically duplicates the @@.header1;Test@@ form, except with the parameters I passed in.  That resulted in what I wanted.

In other words, duplicating that form using a macro works when using variables doesn't.

Once you know about it, you can plan around it.  But that's the main problem.  You have to find out.  Words with the wrong formatting would've been very easy to miss and I doubt a tester would know it's a mistake.  If I developed a lengthier game and I didn't find out about that right away, it'll be quite time consuming task to fix it all up.  And depending on the solution, I might have to redesign several sections.

All that being said, all those can be improved with experiment.  As you get to know css more, you know where to look and how to manipulate sections to work the right way.  Same with Macros, with a good editor to point out common errors and more experience with Twine, you'll know how to they interact and how Twine behaves.

Once you get a good understanding of css, macros/javascript, and Twine, you can build some really extravagant things.  See Corrupted Dreams by vestige for example.  I suspect a lot of time and effort when into that.  Getting anywhere near that level requires a lot of expertise.

Okay, so what are the differences between Twine and Rags?  Any why did I go through a few different concepts?

Fundamentally, the difference is player options.  In Twine, player options are links that take them to a new passage.  In Rags, player options are actions connected to a character, an object, or a room.

At first, you'd think the two are equivalent to each other.  A player examining a room in Rags can be done in Twine as a link to examine the room.  However, Rags has a lot more flexibility in actions.

In Rags, to turn actions on and off, you need a command.  A command that can be in another action.  In Beth, the missing necklace quest was done without any variables, just a series of actions.  In Twine, the actions (links) are default off when you create a new passage (the passage is empty).  And to turn them off and on, you need a variable controlling it.  So creating the same quest in Beth, I would need to create a variable to track where the player is in the quest, add in conditions in the rooms to see if the action should be available, and add in new passages for those actions.  For long quests, it can easily balloon in complexity.

That's another key difference.  Rags can be complex, but Twine is on another level.  Actions are self contained.  For Twine, putting in checks to show a link means putting in multiple checks to show multiple links.  In Primordial Escape, I did a quick inventory.  To examine them, I had to check if the player has that item.  If player has item_1, then they can examine item_1.  If player has item_2, then they can examine item_2.  If I put in 20 items, there would be 20 checks in the inventory passage.

That's not to say, Twine's system is worse.   The very con is a pro is a different matter.  By default, actions are left active in Rags.  Twine uses passages and links in a different passage don't show up.  This means when you want eliminate actions that result in similar things, Twine is better.

In Seraphim's Javelin, one of the first things you do is open a lock.  There's a few actions dealing with opening that lock in different ways.  In Rags, each action has to disable all other actions so the player doesn't open the lock multiple times.  So Action A not only removes the lock for the player but has to stop Action A, B, and C.  If there are multiple steps to Action C, then it needs to stop all of those too.  Same with Action B and C.  For a short branch, it's not that hard, just four extra commands per action... for something Twine does inherently.  Later on, it balloons up.  In the first mission, there are multiple ways to get in the compound, to sneak past the security camera, etc.  Each of those ways needs to make sure they completely stop any other way to do the same thing.

Twine excels in this fashion because once the player gets past the opened lock passage, the only way back is if you explicitly add a way back.  You don't have to worry about the player opening the lock twice because you didn't add it in twice.

This is a major strong point of Twine over Rags.

I think best design to use with Twine is a more guided approach.  Twine pyramids a lot easier than Rags and handles it worse.  With a guide approach, you keep it from spreading too far apart and take advantage of Twine's strength over Rags.

Take The Collar by JoeForest.  It's broken out in chapters.  Chapter 1 is changing the player.  The options are how they change.  Chapter 2 is getting clothes.  Chapter 3 is working at a job.  Chapter 4 is looking for a solution.  What if you wanted to keep working at the job in Chapter 4?  Too bad.  You're forced into looking for a solution.

If JoeForest suddenly decides to extend shopping into chapter 3 and 4, it'll make it much more complex and difficult to do in Twine.  That kind of design works better in Rags.

My other designs quickly became too open ended for Twine.  It was expanding exponentially with difficulty at every path.  It took me a while to notice why.  For Primordial Escape, I focused on a more guided approach.

In Primordial Escape, the concept is clear and the sections work easily enough.  Adding more content won't make the design a lot more complicated.  The basic design layout is moving from room to room, facing an encounter with the goo.  The only thing left is content.


Twine Experiment...........Failed