Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
(3 edits)

So, progress report: Stormtouched is currently at 8500 words and I would say I have a quarter left of the game to write (or potentially a little less than that). I've also divided the game into four distinct chapters, and to compensate for a lack of saving system, the title screen has links to the beginning of each chapter. There's exactly ten days left to the Jam and all is left is for me to write chapter 4 and edit/polish/play-test the whole game. I should be finished in time at the pace I've been going, but I'll unfortunately not have the time to have the finished game be beta-read before the deadline like I said I wanted in the first post of this thread. 

But! I've made a replacement for that plan with a quick demo for Stormtouched that I initially made in order to gather feedback on the game's representation of asexuality and aromanticism, but I figured, hey, this can work as a demo for the game in general, so here it is for anyone who wants to check it out!

I recommend playing it before reading the rest of this post if you want a clear picture of the mechanic I want to talk about and that I've tried using for the first time. For now, I'm calling it the arrow mechanic. It allows me to control the pace at which sentences, or even parts of a sentence, are revealed, and has proved a very useful tool for helping me set up the mood of various emotional beats, or create suspense as the narrator unravels an information or their feelings. Initially, I implemented this mechanic to make the game more accessible to people with ADHD, based on what Nadia did in her own game for Yuri Jam 2017 "can you say my name again." But in the end, I also took inspiration from visual novels where the text is often revealed sentence by sentence in order to achieve the effects described above.

The way it works is extremely simple, the code look something like this (I'm working with Harlowe, I don't know if it would be any different with something else):

(link: ">>>")[Some text. (link: ">>>")[Even more text.(link: ">>>")[  [[This is the usual link in Twine leading to a new node]]  ]]]

The more "links", the more closing hooks at the end of the entire sequence. 

Also, it makes the code looks like (even more) garbage, but I like to press the Enter key just before each arrow (within the "") in order to put all the arrows in a relatively fixed position at the start of the next line, under the current sentence. Otherwise, each arrow will be right at the end of the currently shown text, making it move horizontally a lot and requiring more mouse movements of the player.

Now, the initially unforeseen complication of this seemingly simple code is that it's everywhere as I've implemented it, so it requires a lot of polishing to do when editing. It's easy to forget a space between two sentences, or to misjudge how a line should be paced, necessitating to add or remove links (hopefully without forgetting to adjust the number of closing hooks at the end) and play-test the entire sequence again until it feels just right. It took me around two hours just polishing this demo, and the full game is going to be about 15 times bigger than this, so yeah. The way I use that mechanic turns out to have a noticeable cost in time. 

Also, this makes the implementation of If Statements harder, as I have to pace them within the confines of the links' hooks. Because every link is necessary for the player to progress the text, I can't have a link be optional within a block of text added by a If Statement. The way I dodge this problem is by making as many micro If Statements as necessary within the hooks of each affected block of text that is added by a link.

Also², while I find this mechanic very useful for the effects I've talked about, and hopefully the increased accessibility it brings to the game, it might not be usable in every type of narrative structure possible for a Twine game. For instance, it wouldn't work in one of my previous work, The Ghost's Drum, which has a very cyclic structure where the player goes through the same node several times and doesn't need to re-read the entire text of that node every time and is instead expected to directly scroll down to the choices at the bottom.