You know how some people quit smoking just about every week? Well, I start making games almost as often: or I did before I found Twine. I’ve lost track of how many different “make a game with no coding” packages I’ve installed, tried, and given up on over the years. I’ve also lost track of how many Python for Beginners lessons I’ve got through, which is a large part of the reason why I haven’t gone back to Python for Beginners. If I’d stuck with any one of these things, I’d probably have a handful of decent, non-text games under my belt by now, but instead I pretty much just hopped over to a new one every week.
Anyway. This week it’s Unity. Time will tell whether or not this opens up any grand new gaming avenues for me to explore, but even just the first few lessons of the basic Roll-a-Ball tutorial have made me think. Largely, they’ve made me think about how mind-bogglingly difficult Unity is to grasp compared to Twine. Unity isn’t even spectacularly hard to pick up in itself–at this point I feel as though I could get an interesting (though far from spectacular) game together just by tweaking Roll-a-Ball a little–but it really highlights all the things about Twine that make it easy to get started.
I’m taking a guess here, but from what I’ve seen of Unity it looks as though everybody who’s going to use the software needs to learn how it works. That sounds blindingly obvious when put that way, but consider just about any word processor, any image manipulation program, any media player. There are actually a whole lot of things out there that anyone with the slightest bit of know-how could pick up and use, and anybody else could work out quickly enough. Unity, in contrast, seems to demand at least some understanding of Unity in particular. Typing up the C# scripts necessary to get the ball rolling (literally), I didn’t feel as though an understanding of C# itself would immediately have given me free reign. Those scripts control elements of Unity itself, and so to use those elements you need to use Unity.
When you’re using a complicated tool for a complicated job, this is fair enough. One thing I’ve noticed during my years picking up and dropping various game-making packages is that the ones that offer the most freedom tend to be the least accessible, while the ones that offer the greatest accessibility tend to be so restrictive as to be nearly useless. Unity offers an extraordinary level of freedom to do what you want, so if anything I’m impressed it’s as simple as it is. However, “as simple as it is” still demands an eight-part tutorial to get your first finished game.
In contrast, Twine is just about possible to jump into with no help at all. At its most basic, making a game in Twine involves typing [[double square brackets]] around whatever text you like. The first passage of a game might look something like this:
You are standing at the entrance to a big, scary cave.
[[Go into the cave.]]
[[Run away screaming.]]
In the example above, “[[Go into the cave.]]” would generate a link to a passage called “Go into the cave.”, while “[[Run away screaming.]]” would generate a link to a passage called “Run away screaming.”. Those passages in turn could include new links to new passages, each of which would continue the story based on the player’s decisions. It’s pretty much the exact same deal as those “To fight the elf, turn to passage 112” Fighting Fantasy gamebooks. In fact, with only these links, it’s exactly the same deal. There’s nothing stopping you writing coin flips or die rolls into your Twine game, which means that just by typing double square brackets, you’ve got the same power at your fingertips as Steve Jackson and Ian Livingstone had when they started those books in 1982.
However, Twine also offers you the tools to make those coin flips and die rolls invisibly, behind the scenes, by using (either:) and (random:). You can also do without the “If you have a scarlet key…” player options, because Twine allows you to use $variables to track whether or not the player has performed certain actions (as well as any health points, magic points, or other important stats). Twine allows you to do all these things, but it doesn’t demand that you do any of them.
Twine doesn’t really require a tutorial because at its most basic, there’s nothing to learn. Displaying one thing or another using (either:) is possible without using $variables, and you can go ahead and use $variables without (either:). Twine offers a range of different tools for a range of different jobs, so for the most part you don’t learn Twine: you learn the tools. Even having learned to construct a story controlled entirely by variables, I still find it worthwhile going back to nothing more than plain old links when that’s what feels most appropriate.
Twine gives you one extraordinarily simple tool to start off, and that tool is all you need to make your first start-to-finish game. If you want to add any bells and whistles, they’re waiting in the background. Unity clearly offers far more power–at last weekend’s game jam, most of the teams were using it–but you have to work for it from the absolute beginning, and for an absolute beginner that’s quite a price to pay.