+2 votes
by (2.4k points)
Hello there.

I've wanted to get ahead and learn how to produce a good quality stort with Twine.
The thing is, given that there are three different ways of coding a story, (Harlowe, SugarCube, Snowman), I have no idea where to start.
I'd like to spend time learning the most efficient way of coding a story.
(And then, where to learn ?)
Thanks a lot for your help !

3 Answers

+1 vote
by (360 points)
In the beginning, I had the same question. I just looked at the flexibility of each format and chose a SugarCube (but I'm not a great specialist in Twine, you can choose any other format)

SugarCube you can learn here: http://www.motoslave.net/sugarcube/

Good luck!
by (2.4k points)
Thanks for your answer !
Seeing everyone seems to agree on the fact that SugarCube is pretty great, this is where I'd like to start from.
Though, the link you've provided is only giving me documentation. I'd believe it would be enough if I knew where to start, but, to be fair, I have no idea what to do.
Any help ?
Again, thanks a lot !
by (2.4k points)
Oh, and when trying out stuff on Twine in SugarCube format, the text and code remains "lambda", is that normal ?
I mean, when I use Harlowe, it gets colored depending on what I'm coding, whereas with SugarCube it's just entirely a black on white writing.
by (360 points)
Yes, the SugarCube does not support syntax highlighting. I write code in a notepad++ ( syntax highlighting for notepad++ : https://drive.google.com/open?id=0BxkUfjosrAXMVU85MmFNV1lXSnc ) then copy and paste. A little uncomfortable, but I still have a clean source code for the whole project/game.

You can learn the basics of a SugarCube on YouTube:

by (6.2k points)
For learning what to do, Youtube should help with the basics, and the documentation should teach you other stuff. Also, if you have a question about how to do something or stuff like that, you should check out the original forum, cause that's got loads of questions and answers and stuff.
+1 vote
by (250 points)

One thing I wished I did before stepping into Sugarcube2:

I am also new to Twine. I learned the basics of Harlowe first then went full hog in Sugarcube2. Building a large game with graphics, code logic, sound effects and music all at the same time. 

I think now I should have wrote my story in Harlowe first, not using any programming logic except the 

[[ ]]

to build passages and outline my story structure without any CSS or macros. Once the outline is ready then change your format to Sugarcube, only the [[ ]] will work, so make sure there is no Harlowe code in the game. This will keep the structure of your game intact for the next phase of development. If you need to add image place holders do it in Sugarcube. The next phase is to code the logic of the game using the macros, javascript and or some basic CSS. The last phase is to add any images, animations or sound in your game. 

This process may save time in  develeopment by outlining your story in Harlowe first then build all the fancy code and images in Sugarcube later. 

+2 votes
by (63.1k points)
It depends on what you're doing, honestly. If you're making a longer, more complicated piece, I generally recommend SugarCube, as it's more flexible and extensible and provides more options out-of-the-box. It's a bit harder to get the hang of compared to Harlowe, but generally anything you don't understand or need yet can be ignored.

Harlowe is simpler and faster. If you're creating something that doesn't need a whole lot of advanced or custom functionality, Harlowe is excellent for that. More than any other format, I think Harlowe truly delivers on the "no coding required" promise of Twine.

Use Snowman if you're already familiar with web development and really just want to use Twine as an editor or for its passage structure. I don't really recommend using Snowman unless you're sure it's what you need.
by (2.4k points)
Same than above, thanks for your answer !

As the game I wish to code is fairly advanced, I'd love to learn SugarCube, to be sure I won't regret my choice when the time comes.
Though, where to start ?

Thanks !
by (63.1k points)
I'd recommend starting small. Create a smaller, simpler version of the game you envision and experiment with the available functionality. See where the pitfalls and limitations are. Make something playable, but don't focus on making something enjoyable or marketable. The best way to learn is by doing. Once you've got a handle on the features you need, start making the real game.

For example, say you need a combat system. Don't make a combat system. Make the parts of it. Make a dice roller. Make an hp bar. Make a command menu. Make a potion button. Make an enemy that does random things to the player. Etc. Once you've figured out the smaller components, you'll be ready to put them together.

I also recommend reading the documentation. Not all at once. Just get it in your brain slowly. Even if it doesn't make sense to you yet, you'll eventually come across a problem and go "I remember reading something about this" and be halfway to solving it. It's good bathroom reading material, if you know what I mean.
by (820 points)
Heh... I did rather the opposite when I started. I pretty much put on a blindfold and jumped off the deep end into Sugarcube with an entire haunted mansion I wanted to build. Just for a player to wander through.

It snowballed.

I would go to do something, look up how to, and then run with it.

About halfway across the first floor of the place, I ended up learning a whole new process for frames and replacing text, so the last month has been just migrating everything I already had written into a new framework... but the amount I'm LEARNING doing something huge that I WANT to do and LIKE working on is staggering.

...well... staggering to me. I'm nowhere near professional yet, but to go from zero to where I'm at now in just a few months is still kind of shocking to me. It just seems easier to learn when I'm learning in order to do something I already had in my head.
by (63.1k points)

There is something to be said for working on a project you're passionate about from the word go, but this can also carry a trap; it can turn your development process into a sunk-cost fallacy. Sometimes, the more you learn, the more you realize you need to take it from the top, and that's soul-crushing when you've poured out so much of your heart into something, and can lead to a place where you start to resent the project itself: you don't want to start over, because that's too much work, but you also can't get the game where you want it to be, because that's so much work. I think developing an MVP to help you learn and prototype a project is the best way to avoid burn out, but no matter how you go about it, you need almost inhuman levels of discipline.