Time for an update. Also, hi.
I am the programmer who is kept busy by the needs of the writers. I make the dialogues tick. If I had a card, it would say “Systems Designer”, but it is a made-up name. I’m a university-grown systems administrator/lecturer-turned-programmer (I still work in TUT). At some point I’m probably also show our rules system and then I get to talk about my background with D&D and larp.
Bootstrapping the Writers
I have been working on the project since August, but a lot of it has been what I’d call explorative programming: you hack on something, get something working and at the same time develop ideas of how they should work in reality.
This is how a writer likes to work (and yes, this a fragment of our office in warmer times; I just burned wood to make it slightly warmer as there’s still a winter outside and we burn wood to make it warm). Note that due to Articy being Windows-only, the visible laptop has been replaced with a less Mac one.
My current goal for the past three months has been bootstrapping the writers. We need a way of testing and playing through the mass of dialogues while building an engine. So: for the writers to be productive they need both a way to import them into dialogues and also a finished-looking dialogue windows which behaves like they expect. So they can see when their own dialogue does not behave expedtedly.
Articy: Draft 2
During the early days of the project we understood that we have neither the time or resources to create our own dialogue producing program. We dreamed about Obsidian’s tools; looked into Chat Mapper, Twine and then settled for Articy:Draft 2 from Nevigo.
Chat Mapper had severe interface problems (it’s extremely “clicky” program and it requires you to click around a lot while lacking keyboard fluency); it also looked slightly uneappealing like it could break at any minute — it meant that we met some resistance with selling it to the authors.
Twine was interesting, yet it wasn’t exactly forthcoming — we needed something else.
We went for Articy: Draft 2, since the writers liked it and we as programmers also liked it — it has a strong templating system, has support for cooperative editing with its lock/unlock logic and seems stable enough for our needs. The interface of the program has been designed to be flexible; there are annoyances like when invisible dialogue windows appear and lock it up, but all in all it’s a solid piece of software. It is also really graphic-heavy: your small mobile graphics-processor will not zoom out your full-sized dialogue tree.
If I was a single-person programmer/writer I’d recommend the program highly since its solo license for an indie is absolutely adorably well priced. For slightly larger dev-teams and text heavy rpg-s I’d be extremely cautious, as currently I have three writers an occasional editor and occasional myself, who share the trio of lower-priced floating licenses and it’s getting rather crowded, as you might imagine. If you are well-funded I think the software is the way to go: Think of the full price per seat at your max cast before commiting to the software.
On the image above you can see a smallish dialogue. From Articy we export to .xml. We tried and looked into Articy:Access and it is a nice thing for what it does, but since our import pathway goes through a Unity tool called Dialogue System, we passed on the opportunity of spending more (remember our frugality: I burn goddamn wood to keep my fingers flexible). That brings us to the:
Made by Pixelcrushers; it is a tool for Chat Mapper and Unity integration and maintains feature parity with it, but since it imports well from Articy and the dev is one of the most friendly-helpful support persons you can meet, I think that this choice is solid. You can trust Dialogue System to show dialogues for your custom RPG. It even includes the source, but so far I have only read it to understand some of the intricacies of its inner workings.
After importing from the Articy, we had to make some adjustments to the behaviour of some dialogue lines: in essence, and this will be a separate text, we have some new ideas of how an RPG check system should work and this means that there is some processing that is done on every dialogue line to see if the line is seen by the user and if the line has some side-effects on the stats or story. Basically any ability checks are handled using a custom interpretation of Dialogue System’s lines. For the technically inclined: we use and abuse OnDialogueLine and OnConversationResponseMenu to their full potential.
This is what I have been building for the writers so that they can import their .xml into the game without ever running Unity. It has a list of dialogues which you can run. Currently it also contains an amount of testing-out-stuff and Estonian comments. It also shows our dialogue window, as it stands as of now. From this tool we, at some point, will change the dialogue variables.
You can also see the current in-progress state of our dialogue UI. There will be an eerily cool dynamic background to it which has been programmed, but still needs some integration.
So now the writers have begun playing through their dialogues and I occasionally laugh myself to tears when reading what they have made.