next »

[interrupting cow]

I've been thinking a lot about text-based games and the tools we use to write them. (By text-based I mean games where the primary medium is text and not visuals - things like 80 Days, Sorcery, the Gamebook Adventures series, Choice of Games's games, Fallen London, etc.) Twine is a pretty popular tool, as well as Inkle, Undum, Ren'py (text...ish), and ChoiceScript.

When I searched through the Unity forums, I found a couple of mentions of more sophisticated software that are typically used for non-text-based games, like articy:draft and ChatMapper as well.

* Have any of you made, or tried to make games that are primarily text-based?
* What tools did you use? How did it turn out?
* Are there good tools to make this sort of game that are accessible to total beginners? If not, what do you think is missing?

[gimymblert]

You forgot excell and word (and equivalent in libre and open office)

[TheWanderingBen]

You mentioned both Twine and Unity, so I'll share my current pipeline:

• Plan in Google Doc (e.g.: write character background, plot arc, each scene, etc)
• Write script in Twine 1.4
• Import to Unity via the (fantastic and free!) UnityTwine plugin

I haven't finished a full game, but have been using this system for about a month now and am quite happy with my progress. I can preview the entire story in Twine's interface before shifting into my engine work. Keeps everything separated in a nice way.

Really, it depends on what your needs are. Ren'py, for example, is useful for a very specific type of game, and InkleWriter has a simple output format but has no concept of variables.

[interrupting cow]

You mentioned both Twine and Unity, so I'll share my current pipeline:

• Plan in Google Doc (e.g.: write character background, plot arc, each scene, etc)
• Write script in Twine 1.4
• Import to Unity via the (fantastic and free!) UnityTwine plugin

That's pretty cool. What kind of game mechanics are you using, are there any variables in there? What's the flow of gameplay like?

[TheWanderingBen]

I'm writing a mystery game, so most of my variables are flags (bools) to indicate a player's dialogue choices based on what she's seen -- e.g.: <<set FoundMurderWeapon = true>>. The gameplay involves traveling to various locations -- talking to NPCs or searching the area for clues. Thus I have both descriptions of locations and conversations with NPCs that I'm writing.

If you're considering a similar solution, here's a more detailed breakdown of my setup:

The largest Twine concept is a Story, which contains all Passages, Links, and Variables. UnityTwine is only good at importing one Story and cannot connect multiple Story files together. Thus, my game is just one giant CompleteStory.twee file. Size isn't an issue -- the whole file is plain text, so it won't ever use a meaningful amount of RAM.

But, one recent complication I ran into: the Twine interface is absolutely terrible at displaying a Story that has 50+ Passage nodes -- so writing became a huge pain very quickly. Considering the scope of my game, I will have hundreds (if not thousands) of Passage nodes -- whoops! The prospect of no solution to this problem was frightening! If you use this setup, you'll probably run into a similar roadblock.

Thankfully, there is a very easy, though highly obscure solution: A feature of Twine 1.4 (that almost nobody seems to know about!) is called StoryIncludes. It allows combining multiple Story files together -- basically, sharing Links and Variables among Passages across as many files as you want! Works very well if you have multiple writers, too! From a Unity standpoint, I just export each one of those files into its *.twee format, then I have a script that concatenates all the files together into the aforementioned CompleteStory.twee file, which I then drop into Unity and it gets automagically converted to a CompleteStory.cs via UnityTwine -- ready to be parsed by my game!

That may sound a bit too technical without any Unity/Twine/UnityTwine experience, but if you go down this road, you will thank me for the detailed description (spent a bunch of time finding the easiest solution to these setup problems).

Again, if you're making something very similar to what's already been made (e.g.: Phoenix Wright or 80 Days) try seeing if you can use a similar system (ren'py and inklewriter are great choices for those!). But if you want something different, maybe UnityTwine is the way to go. I'm fairly early in development (I still haven't started a DevLog on these forums because I don't have the complete vision just yet) but so far this setup has worked wonders! I can update if I run into further roadblocks (and my solutions to getting past them).

[interrupting cow]

Huh. Interesting. UnityTwine appears to be for redeploying text games to Unity. What does that get you that you can't get from pure Twine?

Also, I'm interested in the size and structure of a story that requires so many nodes. Is it all geographic locations?

[TheWanderingBen]

UnityTwine translates a Twine Story into Unity. A Twine Story is just a text-adventure, so yes, all UnityTwine does is give you that text-adventure in Unity. But, that's pretty powerful: you can now display the story however you want, with whatever visuals -- models, animations, etc -- that you can create with Unity. UnityTwine isn't a complete solution, but can be a first-step for many things: from just a standard text-adventure, to a more traditional adventure game, to the conversation system of an entire open-world-RPG.

A Passage node in Twine is required whenever the player has a choice. For example:

   "What colour is the sky in your world? [[Orange]] [[Yellow]] [[Fuchsia]]"

is a Twine passage that has three player options which leads to three further Passage nodes. You can see how, just in a simple conversation with a few player choices, you could use a dozen different Passage nodes. Multiply that by the number of conversations in your game, and suddenly the number of nodes quickly becomes unmanageable.

[interrupting cow]

Funny you should bring that up -- just today I was working on a draft of a Twine-like language and what it might look like, and one of the things I was thinking of doing was a two-level system for passages. So each node might have subnodes, like this:

Code:

:Living room
You are in a living room with a [::TV]. There is a [::lamp] nearby.

To the west is the [:kitchen].

::TV
The TV is showing static.

::lamp
The lamp is currently off.

Curious if you think that might be useful, as someone who's written more of this than I have.

[TheWanderingBen]

Sounds like it could be useful for smaller Passages -- but honestly, don't think I'd use it over of just the regular Twine syntax; I like the arrows showing me the graph flow, whereas sub-nodes, being hidden, would just get confusing.

Many passages was a problem when I thought I was limited to one Twine story file. But now that I can link Twine story files via StoryIncludes, I'd rather have the more verbose syntax to show me where everything leads.

Side Note: If I were to suggest an improvement in that area to the folks at the Twine UI team: I want the ability to Group multiple nodes together, so that I can zoom far out and just see the links between Groups instead of the links between Passages (e.g.: "Campfire Hub" links to "Morrigan Conversation" and "Leliana Conversation"). While I realize a certain organizational pattern might get the nodes close enough to see that at a lower zoom level, every time I've tried I end up tangled in those node-to-node fishing wires. Groups would be a great feature for organization and alleviate the need for the aforementioned StoryIncludes.

But again, whatever works for you man. It just depends on the game/tech you're trying to make and what's driving you to make it.

[interrupting cow]

But again, whatever works for you man. It just depends on the game/tech you're trying to make and what's driving you to make it.

Definitely. Would you happen to have some screenshots of story layouts you've done? It'd be pretty cool to see the tangles in a real game.

[TheWanderingBen]

Nah, I've erased all the big tangles with that StoryIncludes trick. That's not to say it won't get messy, but I'm still at an fairly early stage in both writing and development. Maybe it'll get more messy (messier?) in the new year -- I'll keep ya posted!

[SHARKvince]

I’m using Scrivener —which I also use for my novel— for organising characters, locations, research and other snippets, and I use Twine to “pre-develop” the scenario for my game. Once I finished a chapter in Twine, I go and work on my assets and make the scenes+animations in Blender and from there on get it into the Godot Engine.

That’s how I’m planning on doing it anyway, I’ve only started last Sunday and I’ve got ways to go before I get to each and every point

[gregkleintv]

Hey, I'm new here. I've made a few games with Twine. If you do make them with Twine, philome.la is a great way to host your games online without any hassle. (Plus, it gives you a count of how many people played the game and links to your Twitter.)

My site is gregklein.tv if you wanna check them out. The last one I made was kind of a mess because I made it in about 24 hours during the Global Game Jam and wasn't too familiar with the latest version of Twine. If you decide to use Twine and have any questions, feel free to PM me.

[Jordgubben]

I've been experimenting with text-based for a while now.

Depending on what you want to do and your technical expertise I'd argue for building your own tool. When I stared out I had a very specific feature set that any potential tool had do provide.

• Run on or export to html
• Potentially look ok on a smart phone
• Model an actual world (Rooms, actors, time, etc.)
• Point and click (UX not centred on text commands)
• Translatable content (I18n)

I evaluated Twine, Inform 7, Ren'py and possibly a few more. None of them passed all the above criteria, so I opted to write my own engine. Two years later I think I have something that is pretty general and works fairly well.

I'm currently using it for this game:
http://superattack.se/games/nom/

Ofcourse what you build  depends on what you need. When I started out I really did not know what to make, so I ended up creating a very general engine before i found the game idea I was looking for. In a more focused project you can probably get a lot further a lot faster with just ractive.js and some creativity.