#trnt

I should preface this Post Mortem with I entered the SpringThing on a whim. I had just come out of a conga line of competitions and game jams since last Summer (log of release/update), and had plans on finishing working on other projects instead of this one (which I probably should have... sorry The Rye in the Dark City for abandoning you...). But I obviously didn't do that because here was another new fresh game! And then another two of those just after... whooops...

The idea for TRNT just popped into my brain one day and would not leave me until I implemented it, no matter what (yes, I am still weak willed, I have not learned my lesson from The Thick Table Tavern, the one about not rushing a project and publishing it at a later date when it is truly ready). I did have that thought in the back of my mind that if I do do this, it would be very likely I would end up with a repeat of TTTT, as in: half-full drink with too much ice, and expired garnish falling from the very pretty fancy glass.

Also I did not start working on the entry until the SeedComp was in its voting round (so around the 4-5th of March?). I really wasn't kidding about the speed-running thing....

Another thing: I had never created a parser game before this point AND suck real time at playing them! This was also indicated in my Author's comment.

Nothing obviously stopped me anyway, because here we are...

1- The Idea

A few weeks before the opening of the SpringThing intent, the French IF community was streaming some older parser entries, including Aisle* and Pick-Up the Phone Booth and Die, two games where the player can only do one action before the game ends. I'd never really experienced this kind of game before (the closest being having a sudden death/continue the story choice). It packed a punch, it was funny, and also so very weird. It left me dissatisfied and super intrigued. I wanted to try and do that too someday. *Funnily, someone on the French IF discord thought DOL-OS had been inspired by Sam Barlow's work (it wasn't, but TRNT def was).

Not, I am not going to be hella pretentious and full of myself by putting TRNT on the same level as those games (because I don't think I did a good enough job to merit a comparison), but the one-action-only gameplay and multiple endings drew me in (I love abrupt endings, cf P-Rix). I've mainly written longer form of IF rather than short bites, and I thought it would be fun to try to constrict myself as much as possible, by having just one thing, one action, one outcome.

And also: parsers. I had only dabbled with the Choice-Based/Hyperlink format, so I thought it was time to try the last unexplored part of my IF journey: parsers. Since the SpringThing Festival is a nice place to experiment, I thought why not try to make one then! I could not have survived the anxiety of the IFComp reviews for that one...

Still, it was not going to be without a challenge. I had very little experience with parsers, and I honestly didn't think I could learn how to use a parser program in such short amount of time*, when I had a lot of other stuff at the same time. So I thought, why not make it in Twine**, at least I know this program inside-and-out(almost). There would not be a steep learning curve there... What could go wrong? *lol at me, having made an Adventuron game in a non supported language in about 2 weeks after that, without ever having tried the program beforehand. I could totes have managed!! **Also, when I got set with Twine, I realised how fun it would be to maybe put people's expectations upside down by doing something you're not supposed to with Twine... or parsers!

Well, it was going right at first...

2- The Story

I really wanted to recreate the same gameplay of Aisle with its only-one-action-and-it's-over, so I started listing possible actions and put them into a context where this choice of action would mean everything for the PC - because it is the only action you have. Which might not have been a good take? Aisle works because the setting is incredible mundane, and there are no stakes.

The context pretty quickly drew itself as the player will chose a profession/career path, and if they do/choose something wrong, then...😬too bad for them, they made their choice, deal with the consequences. While, in reality, we are not stuck in a life because of one choice, but with a myriad of them (and still we can change this trajectory), it's still a big pressure you get as a youth, having to choose where to go and what to do when you are done with highschool, and what path to take. It's a lot of responsibility that sometimes feels like it will affect/haunt the rest of your life. Do I still have some of that school/parental pressure from when I had to make that choice ingrained somewhere inside? probably...

But the more foolish idea was to let my brain continue to think more about that context and create a world and story further than the choice. Instead of going forward with the consequences and the hints of what could have happened or just let the choice being the centre piece, the brain just went backwards and created a society (some sort of futuristic one) and vaguely described beings (that are not humans), and the ritualistic culture of this society, etc... While it was fun to think about all of those, and maybe provided a fun setting and enticing story for the player to go through the game, there might have been a bit too much of it. I think, in hindsight, this may have devalued the choice itself (which became even more watered down when I continued on writing the first screens).

And so, the job choice soon became the player is going through some sort of ritual (v trope-y) to determine their place in society. If it has a vibe of The Giver, it shouldn't be too surprising, the book is on my shelf.

So we still have the one-choice-to-rule-them-all, but now there is a also backstory and setting... and I have to include it somewhoeeven if it means cramming it somewhere, anywhere.

Oh wait, I thought, I'll just make it like a prologue to build anticipation for the choice!

And so the brain went on zooming again to create the waiting room, and the agonising walk in the corridor, and the finding your way to the altar, before you cant finally make your choice..... only to end up with two(-ish) paragraphs for each endings. wow - what a good balanced game this is becoming...

Speaking of endings, I had originally listed over 50 actions, each planned to have a different ending.... only to end up with about 11, 7 of those were actually related to the final countdown choice. It made me sadder than when I cut onions :(

It wasn't just the player that needed to make...

At this point, we were two weeks away from the deadline. I had the backbone of the code (-ish), a good third of the writing wasn't complete (and this was mainly those 11 endings), and no one had tested the game yet. There was no way I could have included all 50 original options if I wanted to make the deadline. might have been good in hindsight to remove those choices, especially with the current command system.

So choices had to be made and a buttload of planned things had to be cut. I narrowly managed to finish the needed endings in time (which required re-writing some of those into a fake choice), at least.

At the end, I strayed quite a bit from the Aisle concept of a mini intro - one action - an ending puzzle-y feel (and making the player piece the story together from the endings), to arrive at... well... this anxiously geolian walk to one's doom (or dream). Making the story quite... well... linear.

And from going somewhat wrong, it went a little wrong-er...

3- The Implementation

Wanting to avoid the headache of learning a new program, I had settled on Twine pretty much from the start (SugarCube, because that's how I've been rolling for the past almost 2 years!).

The big problématiques of this project were:

Twine is not a parser program (duh)

SugarCube has its limitations still (and macros that don't always work the way you want to)

I had never written a parser game before and suck at playing them (thank you, French IF streams that helps me enjoy them without experiencing the frustration of not finding the right combo!)

I still suck at JavaScript/jQuery to do weird things with the page (and probably fix all those issues)

and well did I already say Twine is not a parser program?

So I tried to get to the basic of parsers (an input box and text revealing itself onto the page when a command is entered) and prayed for the best. Easy, right?

WRONG!

SugarCube has an input box, but can only autofocus* inside one specific place (so you can't lock it somewhere else but the passage itself, which means you need to add it to every screen...) and when the passage is first loaded (doesn't work if the input box is added later on). *I have also hurt some kitten by overusing autofocus, which was only compensated by offering the the SugarCube God some bug reports about it so those issues could be fixed for the next update (TBA). But you really are not supposed to use autofocus as much as I did... 😬

SugarCube has an input box, but you can only move to another passage after you press Enter. So you can't have some fancy input checks, and you stay on the same page... without some custom listener macro* that is (Bless you Maliface and your Listen Macro) - or I guess some JavaScript code, but who has time for that... I had included a button as an alternative to confirm the commands (which was how I had coded it for DOL-OS), but it would have made the parser experience much worse if using Enter would not have loaded a response (this was a criticism from DOL-OS, which now that I know how to fix, I really should do so...). *at least until the next Sugarcube update which will include a listener.

SugarCube has an input box, but doesn't have a bank of commands, or set object indicator (like with the parsers). While you can technically separate the inputed words with some JavaScript**, whether you do so or not will end with the same amount of spaghetti code at the end, with the different conditional statements for each actions on each screen to show the correct text bits (mine amounted to almost 600 lines of code for 7 screens... without included the printed text! -> see the source code). Now that I've messed around with Adventuron, I can see how easy it is to make a parser game (set up commands and rooms and interactive object), when you have a bank of built-in commands and not have to worry about how to add the new text on the screen. Twine really added a new layer of complexity to this.... Was there a better way of doing this? probably, but don't look at me to find it. *this was how the name chosenname command came to be, and how it only printed the chosen name on the following screens. That and the autofocus being messy...

SugarCube can add text bits to a page, but unlike parser programs, it won't automatically scroll down to the bottom of the page, or at least to the added element. Adding a scroll down to the bottom or scroll up to the page was not too hard (I had some leftover js code), but it was not the solution: the UI is mobile/tablet accessible (smaller screens), which means scrolling to the bottom would make those players having to manually scroll back up (and I am usually quite verbose in my writing). So very much EH.... NOT GREAT! After quite a lot of testing, broken pieces of code, way too much swearing, and re-doing the base of the UI, I did manage to find a solution.... a month into the review/voting period.

But even with those limitations, I pushed through. I knew it was possible to make it work, so I either tried to find work arounds (and gave up the scrolling, at least until the deadline), and pushed through, banging my head against my desk because of what was achievable...

LIKE BUILDING A WHOLE COMMANDS SYSTEM...

Wanting to make things easy for myself (and the players), I thought maybe removing all verbs would make it easier to go through the game, even when having to interact with objects or people around. Enter the bolded word* from the text as the input, press enter, and read the new text! *It was important for me to have some sort of "easy" mode where the interactive things were obvious to the player, coming from a scene where parsers are not the norm/favoured.

Simple right?

This idea... stopped working as soon as I introduced physical actions (sit, stand, jump, etc...), directional actions (the story might be linear but it still has multiple rooms), but most importantly as soon as I wrote flavour texts for one same object. Even if I could get away with removing X/LOOK/EXAMINE*, adding verbs at the end was a necessity (I didn't want to see all the already written variation go to waste...). *I did include look in the code, but mistakenly didn't think about its synonym <- shows the no-knowledge of parser, and not having a bank of commands built-in.

So verbs were added, and then some of its synonyms (but evidently not the most important ones 😬), and then some prepositions just in case, and noun synonyms with adjectives because of how it is described in the text, and then.... so on and so forth. And because of how SugarCube is set, I ended up with lines like this at the end:

<<if ["initiate", "look initiate", "look at initiate", "remember initiate", "initiates", "look initiates", "look at initiates", "remember initiates", "recall initiate", "recall initiates"].contains(_cmd)>>

(and this is not even a correct or complete command list, since it is missing EXAMINE and X)

Et rebelotte for all the interactive words on the page, as well as the added variations requiring another set other verbs. There's not really a verb/noun aliases list to help...

BUT WAIT

Because I always like to make it difficult for myself and not think of the amount of work my ideas/plan will require, I had to make some bits of text appear only once (even if some commands could be used more than once on that page) OR removing the player's ability to make a different action when they do a specific one AND have some bits of text only appear after a command has been used on that page. Pushing the player through extra invisible gates on top of the different rooms. I could have made it easier on myself to break scenes further than I had already done, but nooooooo

And I did this not just once. BUT THREE TIME! When the player is called to get in line, in the corridor, and just before the big doors.

I could have fed myself for a whole week with the spaghetti that came out of my code.

But Manon, I can hear the little devil on my shoulder say, Why all the whining and excuses? You could have stopped if it turned out to be a bad idea, especially if you couldn't implement it properly. Why not have made the story in something else than a parser?

Well...

because Time (wa)s running out and I wasn't going to let all this hard work go to waste by changing everything up at the last minute (it could have worked/been easier, that's true)

because it was still a fun puzzle to solve, even if frustrating most of the time,

because you learn more when you fail than when you win

I'm not a quitter :P (hiding my too many WIPs waiting for me....)

Even if I doubted myself with finishing the game on time, I still pushed myself to cross the finish line, since I knew I would not have finished the project otherwise. Thought it could have been fun to get the 12 angry men passing judgement on my Twine monstrosity making a mockery of parsers had I submitted it to the very serious ParserComp instead. /jk lovingly

So after some "extensive" testing (rushed in the last week, because I am a nightmare to people, sorry @groggydog and @lapinlunairegames for making you go through this, but also thank you for your help!!), I made it to the end!

Well... barely. Ended up with a few bug fixes update along the way.

4- The Reception

(it was like that in my heart)

Like TTTT, this was not explosion of praise and accolades. And I fully expected it. You can't make experiments omelettes without cracking a few programs/rules eggs. At least my omelette didn't have too many eggshells :P

Looking at the numbers, at the time of writing this posts, TRNT is currently sitting at 5 stars (4 ratings) on itch, and 3-1/2 stars on IFDB (2 ratings)*, with 4 reviews on the Forum (bellow the median/average this festival). None of the ratings game with reviews/comments. *When some of the reviews will be moved to the IFDB, I do expect this average to get lower. The itch one is nice (really happy 4 peeps loved it!), but most people only rate when they didn't like it or when they loved it.

As for the feedbacks gotten, they came from a few sources: the people who playtested TRNT, dms on Tumblr and the Forum, the Twine server, and the awaited reviews on the Forum.

Overall, the people who liked the game really enjoyed themselves, from the writing and the worldbuilding being intriguing, or how pretty the UI was. Even with the issues raised during the festival, quite a lot of people (who sent me comments) thought the experiment was either a success, something really cool, or impressive considering the limitations (of the festival and/or of the program). Even in the more critical comments, this experiment was seen as an interesting one to be commended (with a bit of a why did you bother... sprinkled in there). Someone told me TRNT reminded them of the Divergent series (and fair comparison, considering the whole ritual to put you in one job for the rest of your life).

The most surprising thing was that people who never played parser before (or didn't really liked them) found the game entertaining and fun to go through, managing to get to the end without too many issues; while the reviewers with more experience in the genre had a bit more restraints due to the command system I put in place.

Whether my giddiness about verbose writing was to the liking of the player or not, I was honestly happy comments about my grammar didn't make much of an appearance this time around (yay, progress!), and that I would get kudos for the vague story behind the experiment itself, and the structure of the story itself.

But this doesn't mean that it was all sunshine and rainbow here. TRNT had some obvious issues, which should have been squashed during the testing phase had this one been longer (yet again, me speed-running through comps when I should take my time... when will I learn...). There were two main ones: the commands and the UI.

The biggest issue came from the commands, being either unclear or confusing, especially when it came to the cardinal direction, the choice of synonym for the actions, or special actions like the name input. Even if you could go along the story with just a noun or press C until you reached the end, missing important verb commands did not help the game feel complete (EXAMINE/GET/the shortcuts). This is where having some Parser knowledge/experience would have come handy, he.... As for the cardinal directions, it was probably most confusing because I used them as synonyms for forward/back/left/right instead of N/S/W/E (that and it wasn't clear where you were able to go in the text either). Quite a few players were also getting stuck in the corridor (after you come to a stop, you hear some thing up front and your choices are to move to the side/jump or stand still). Special actions like the name input or the final choice were felt a bit off/broke immersion. Party due to the way SugarCube is, partly due to how I organised the game. Having a simple input where the player is asked for their name before the game start and have a say name command, might have worked better there. That and a better hinting system. Fix for those TBD.

Closely followed was the UI being annoying (which ;-; bc I pride myself on creating good UI, but it was fair critique), from the scrolling being an absolute ass, to the confusing bolding of the start of passages being the same as the interactive words (if you didn't change the colour in the settings), to the back/replay last choice command on the END screen not going to the right spot, or the responses of computing an inputted command not appearing/being confusing (in relation to the scrolling), some quirks with the UI being wonky for some screen sizes, etc... Thankfully, all those have been fixed.... but too late for the reviews already published. A quick revamp of the UI base + solving the scrolling issue + slight reformatting of the printed new text bits solved if not all of those issues. Still... too little too late... That's what you get for making a UI in a large screen and only checking different width but not different heights....

A SIDENOTE ON WHY PARSER AND NOT HYPERTEXT

Or me going a bit on a rant. Scroll down to pt 5- The Do-Over to resume coherent levelled conversation.

Still, making a parser a Twine was a CHOICETM, which didn't work for everybody. I don't know if it was because the game was put forth as a Twine game before being a parser, or because the story was maybe a bit too linear/not very interactive compared to other parsers, or because I set out to make a parser before thinking of a story and it showed for some, (or probably because the parser system was not very well implemented) but I did have a few commenters wondering if my choice of making it a parser was the correct one, as in why would you use parser when hyperlinks would have probably worked better?

Maybe a cop-out answer would be Why not. Why not try to break the rules and the codes of what is a Twine game or what is a parser? Why not push Twine to where it is probably not supposed to go (sorry, TME)? Why not blur the lines of the divides between the subgenres of IF? I wrote some part while having a bit of a fever, and my notes had Why not make parsers less puzzle-y/more linear choice-based like? and oh boi is it good to re-read yourself... Cause yiekes what a load of BS.

The other part of the answer is Because experimenting and doing weird thing is fun! Doing weird thing, writing bad code that should probably not work but it does, putting the program on a lifeline, making up stories that are nonsensical, etc... and breaking people's mind in the process with what could be done. Also it was just fun to find out whether it was just possible to do it at all. The rush of happiness when you the puzzle is solved is so incredibly gratifying. It was really fun to try something different (for me but also for what Twine can generally do), to solve a puzzle of mashing two things that don't/shouldn't go together, to find what makes them tick and make it all work, and to challenge myself to do something new (did I mention before it was my fist time making a parser?). AND, having fun creating! And the SpringThing has always been a beacon to promote experimentation with the genre and more out there stuff. So it's was kind of like the stars aligned or something :P

Also Because it was possible!That one is pretty self-explanatory...

Maybe a bit more presumptuous of me: Because experimenting keeps Interactive Fiction fresh and exciting! I'm not trying to set a trend or anything here (honestly, it's not too strange, TRNT's weirdness kind of follows my previous work with TTTT and its mixology element, or DOL-OS with it computer interphase), but isn't fun to see what else can be done in IF, or what new area can be explored now that funky stuff has been tried, or what else should probably not be done (hopefully this doesn't apply to TRNT lol, I think it should be fun to have more parser in Twine). Even if my entry was not really a novel idea even in the gameplay (exhibit A, exhibit B, exhibit C), I still think there should be more weird stuff out there, so I contribute to that where/when I can! It'd be sad if IF became same-y and stale... It'd be fun if someone did something like this because they played TRNT and thought it was neat :P

And Because it didn't fit with my original vision of the game. Even if the game changed quite a lot along the way, the parser element was something I would not compromise with, no matter how good or bad the final product was. Sorry TME for the kittens lost in the autofocus of the textboxes...

I did wonder for a while how many people opened the settings at all 🤔

5- The Do-Over?

Ha.

Haha.

Hahaha.

No.

Honestly... If I was going back to the start, I don't think I would change anything. Even if the length of the testing was more than minimal (still haven't learned my lesson), even if I rushed into the competition (again, not learned my lesson), even if I made errors along the way (well, maybe fixing the UI earlier instead) or let the story stray that much away from the original idea (honestly it was probably for the best that it ended not being too close to Aisle at the end, I might have gotten eviscerated in the reviews). It did what it was supposed to do, and checked all the boxes from what I wanted to try. At the end, to me, it was a complete (and stressful success).

Will there be some changes in the future?

Just a bit, at some point, TBD and TBA. Just to fix the commands a bit, maybe rearrange some passages, add a bit more variation/hidden codex entries, maybe even a new ending or two! But it wouldn't go further than that. TRNT was an experiment through and throuh.

==================== THE END ====================

Anyway, my weird hybrid beast of a parser in Twine and I are done rambling about my awesome show of tricks that may or may not have landed badly and with a broken skateboard. We will go collect our ribbons, now!

Make IF weird, Do word crimes, Have fun