Introduction:
I’ve been writing for video games for nearly fifteen years now – something which I’m still kind of trying to wrap my head around. Most of that time (about twelve of those years) has been as a full-time professional. In that time, I’ve dabbled in quite a few systems – but I’ve only really worked extensively in three. It’s those three systems – Choicescript, Ink, and Twine – that I feel the ability to speak the most authoritatively when it comes to their capabilities, their liabilities, and their best use-cases.
First of all, the obligatory caveat: I’ll be talking about all three of these systems from the perspective of someone who’s written more than a quarter of a million words (in Choicescript’s case, a lot more than that!) in each – but this comparison is intended as an overview from a writer’s perspective for those still looking for a system to use. If you already use one of these systems regularly (or another popular system like Ren’Py), you’ll probably be biased towards that particular system to begin with. In that case, this comparison probably won’t be as useful to you – unless you find that your preferred familiar system can’t do what you need it to (which was why I picked up Twine), or if professional obligations require you to use another (in my case, Ink).
Secondly, while I obviously have a lot of experience in Choicescript, I have considerably less in Ink and Twine. That doesn’t mean I have no idea what I’m saying, but be aware that it does mean that I might have less of an idea of what I’m saying than more seasoned users might. Likewise, these are my personal opinions, based on my personal biases. There are things I don’t like doing and things I do like doing and those likes and dislikes are going to make me consider certain features or lack of features to be more or less important than you might, so keep that in mind.
1: Ink
I’m really kinda not a fan of Ink. I used it pretty extensively while writing for Burden of Command, and I personally found it a pretty limited system. While it can do all the basic stuff you need to write interactive narrative (setting variables, nesting conditions, and so on), it also felt less intuitive to learn and harder to edit. The fact that Ink’s intended editor really didn’t play all that well with my old PC probably didn’t help either.
In some ways, it’s hard for me to quantify what I really don’t like about it. Part of it was simply having to learn a new formatting and scripting commands after becoming so familiar with Choicescript (I’m a dogshit coder as it is), and some of it almost certainly has to do with the lack of features I’d come to rely on in both the editors I used for Choicescript, and in the lack of equivalents to the very useful automatic testing utilities Choicescript comes with.
Personally, I think it’s a system which does the bare minimum from an interactive fiction point of view. It can do what’s necessary to make a basic interactive narrative, but it can’t necessarily do it as well as the other systems I’ll be talking about.
That being said, Ink does have one real advantage: it can integrate fairly seamlessly as a part of a larger game. Burden of Command is obviously the example I’d go to here, but it’s actually a pretty bad example. BoC used a bespoke engine written from the ground-up in Python to accommodate Ink as its interactive fiction component, which is a really convoluted and sort of inefficient way to handle things. On the other hand, engines like Unity have plugins which let you integrate Ink scripting seamlessly into games made with that engine, which means that while Ink kinda sucks for the kind of text-exclusive pure interactive fiction which I normally write, it is also probably your best option for something more graphically expansive. There’ve been some really good visual novels and adventure games which use Ink as the basis of its text. If I were making a game with a lot of narrative text – but which also involved more traditional adventure or RPG gameplay – think Disco Elysium or Broken Sword – I’d seriously consider Ink for its open source nature and its ease of integration.
2: Choicescript
That being said, those aren’t the kinds of games which I have the resources or skills to make. One of the things which I’ve come to understand over the years is that I am primarily a writer and a narrative designer – and Choicescript is perfect for that.
Choicescript was the first of these systems I learned, which might be part of the reason why I consider it the simplest and the easiest to pick up. However, I’ve found that the way it flows and the almost stream-of-consciousness format which its individual scene files are organised make it relatively intuitive when it comes to planning and laying out relatively linear (or delayed branching) narratives. A scene file is effectively a single long piece of narrative, interrupted or split by individual *choice, *goto, and *page_break commands. Of the three systems, it’s the one which is best suited to the conceptualisation of an “interactive novel”.
Of course, if you’re not writing an interactive novel, that means you’ve got to do some more creative planning. Non-linear narratives or open-world settings are doable in Choicescript (they have absolutely been done – last year’s An Unexpectedly Green Journey for example), but you will be fighting the format all the while.
That being said, despite its simplicity, Choicescript is capable of some pretty complicated systems if you’re willing to kludge together commands in a way that might give you permanent migraines (like the Major Projects and Interest Payment systems in Lords of Infinity). As a scripting system for interactive narrative, I’ve certainly never found it incapable of something. In that context, I’d be confident in calling it ‘fully featured’, and the fact that it not only has its own dedicated editor (CSIDE), but VSCode plugins and a very vibrant and generally supportive community means that it’s probably your best bet if you want to get your start in writing interactive fiction.
Another major reason for wanting to start in Choicescript is that it comes with two very powerful automatic testing tools: quicktest, and randomtest. The first automatically runs through your build five times, checks for any showstoppers and reports them. The second can run more configurable and extensive tests (we’re talking tens of thousands of iterations if needed) to root out edge cases and other really weird bugs which can only exist through a confluence of freak accidents which players will still somehow achieve on day one. In addition, things like the *bug command make diagnosing and fixing particular issues a lot easier. When I worked with Ink, we spent more time bugfixing than we did writing. When I work with Choicescript, the ratio is more like an hour of bugfixing for a week of writing.
But Choicescript also has two major limitations, the first technical and the second commercial. Choicescript functionally has hard limits as to what it’s capable of. You’re limited to certain fonts, certain interface features, and certain formatting. While it is still being developed and new features are being added at a steady pace, that pace also tends to be quite slow, which means that things like checkpoints needed to be kludged together for years before a proper feature was added. Part of this is for accessibility purposes, to remain compatible with mobile devices and screen readers, but part of it also ties into the second limitation – as while Choicescript can absolutely be combined with CSS to create more customisable appearances and systems, it also isn’t.
This is because Choicescript, unlike the other two systems, is a proprietary scripting system, owned by Choice of Games. This means that if you want to publish in it, you have to either do so through one of their three catalogues (Choice of Games, Hosted Games, or Heart’s Choice), or negotiate a licensing deal with them (I’m not even sure if they do this anymore). In the former case, that means adhering to their release schedule, their content guidelines, and their editorial decisions – as well as signing over a significant proportion of your gross revenue while receiving only a portion of that (25% – which is better than print publishing by far) for yourself. In that regard, working with Choicescript – and Choice of Games – is probably closer to working for a traditional publisher than as an indie, which is something to keep in mind.
However, this second limitation can also be an advantage for someone trying to break in to the industry and make some money at the same time – it certainly was for me. The Hosted Games catalogue will publish just about anything short of outright garbage made by an outright garbage person. For the cut they take, Choice of Games will package your game for release, make sure its accessibility options all work, and release on their omnibus apps with an announcement on their mailing list. You probably won’t make a lot of money – certainly a lot less than you would spending the time and effort you put into that game working even minimum wage – but it will get you commercially published, qualify you for a SFWA membership (if you want that kind of thing), and probably bring in more money than you would get dropping an indie game on Steam or the App store or a book via traditional publisher without the visibility that you get via the CoG mailing list.
Of course, if that’s not what you’re looking for, then none of that matters. If you’re looking for something more customisable, and you’re not worried about handling things like release or marketing yourself, then that’s when you might want to consider…
3: Twine
Out of the three systems I’m describing here, Twine probably the one I’m least familiar with, since I’ve only been working with it for a few months. Yet even so, I feel pretty confident in saying that it is, in many ways, a middle ground between Ink and Choicescript. It has the modularity that comes with the open source nature of the former, while being not much more difficult to work with than the latter – even easier under certain circumstances.
The main reason I chose Twine over Choicescript to make Shadow of the Eagles has to do with its biggest strength – the ability to couple the scripting language with CSS features which allow for slick graphical interfaces and menus, soundtracks, and all sorts of other bells and whistles which Choicescript doesn’t allow for. However, the cost of that has been getting used to a whole new way to script narrative.
I don’t mean this just in the sense that Choicescript and Twine use separate libraries of commands (although they do), but also because the way that these narratives are formatted are different. Where Choicescript centres around the use of “vignettes” or “scenes” – large, self-contained text files – Twine uses “passages”, which are much smaller and more modular. Whereas a Choicescript scene is one long stream of text divided into multiple segments, Twine’s passages are a single ‘page’ of text, which links to other pages of text – rather than a chapter.
In theory, this makes it easier to create a more non-linear game design, with each passage serving as something like points on a map whereas Choicescript scenes are more like segments of a river or a road. This is made even easier to organise and visualise by Twine’s visual editor, which maps out passages as nodes in a vast flowchart.
However, the visual editor comes with some severe limitations. The first of which is the fact that it tends to begin lagging after about 800-1500 passages (depending on the quality of your PC). This may seem like a lot of leeway – and it is for a smaller game – but those passages add up fast. Shadow of the Eagles is currently over 2000, and will probably exceed 5-6000 by the time I’m done with it. An alternative is using VSCode’s Twine plugin, although that means dealing with VSCode’s own problems (like periodic slowdowns). In addition, Twine lacks any kind of native automatic testing system – although there are systems out there which fulfil that role.
Which kinda brings me to Twine’s biggest strength and biggest barrier to entry. As an open source system with a lot of users and a lot of people tinkering with it, Twine boasts a plethora of tools, plugins, and other “third-party” utilities which allow you to better configure menu systems, pack your output files into .exes for release on PC, or (as mentioned before) automate testing. A lot of these utilities are free or pay-what-you-want, which makes it pretty easy to get what you need if you know what you’re doing.
And that’s a pretty big if. A lot of utilities and a lot of users creating a lot of functionality means a lot of documentation and a lot of terms and best practises to wrap your head around. Even as an experienced narrative designer and IF writer, I had to beat my head against a lot of those issues starting out – only to now go back and correct all the rookie mistakes I made when I was still coming to grips with everything.
Conclusion:
Remember, these are mostly my personal impressions, as a writer first, a game designer second, and a programmer last; and as someone who started with – and mostly works with – Choicescript. I’m sure someone who started with Twine, or works more heavily with Ink in a different environment might offer different opinions. Personally, I think any of these three systems are fully-featured enough and simple enough to allow a novice to write, design, and produce a good game. However, any of these systems will still require at least a minimum of persistence, patience, and applied effort to master. Even Choicescript – which I consider the simplest – took me several years, multiple shipped titles, and hundreds of thousands of words published to fully grasp. Even then it’s a system which I can claim to have ‘mastered’ only on the loosest sense.
My advice would still be to try out whatever system interests you, work with the basics for long enough to get a feel for them, and then decide which one works the best for you.
Or just disregard all of this and use Ren’Py. I’m not your boss.
Paul Wang 