The day before the jam began, my lead artist (@radonkalmer) sat me down and said we needed to scope down on art this time. She didn't want me to work her or our other artist to the bone again.
Now, as the Project Lead, do I have an interest in keeping my artists happy? Hmm, let's see what Voyager 1 would look like if I drew it:

OK, not bad. Only took me five minutes. I'm pretty proud, not gonna lie.
Let's see what one of my artists can do:

Oh.
So I want to tell a moving, emotional narrative, but I can only squeeze so much content from my artists while acknowledging that they are humans who need to eat, sleep, and go to the sauna. (My artists are Finnish.)
What's a Project Lead to do? If you can't tell by the wordiness of this blog post so far, I turned to writing. Typically, the best way for a video game to set mood and atmosphere is with visuals and audio. Unless we're doing a purely text-based game, people expect a video game to take advantage of the "video" part of "video game." I'm blessed with talented artists and a talented composer, so I can lean on them for maximum value. But my artists were tired this time around, and my composer was participating in a virtual convention on the same weekend. Who else can churn out content? Me. Typetypetype. Writing words.
I asked my programmer (@sheldonzs) for a simple text parser. The last time we did a text-heavy game (Ludum Dare 44, Maeko's Memories, a visual novel: https://ldjam.com/events/ludum-dare/44/maekos-memories), I made the mistake of not asking for one. My programmer created a super cool engine using Unity's Inspector, where you could just slot in the speaker's name, the image, the dialogue, any other commands (display choices, play audio, etc.), and move on. But the engine was buggy and difficult to write in. Worse, it meant that everything in the story had to be done twice: once when it was written, and once again when it was pasted into the engine. Never during a game jam had I wished so hard for someone with the skills of a Data Entry Intern. My wishes went unanswered, and I ended up spending more time pasting writing into an engine than getting writing done, leading us to only implement 40% of the planned story at submission time.
So my programmer wrote a parser from scratch. Because why would we use something like renpy when we could just force him to lose sleep too? Look, we're all masochists here. Some of us are just more willing to admit it.
Here's what the text looked like before parsing:

Here's what the text looked like after parsing:

For a parser created in less than 48 hours, it was more than serviceable. My programmer even threw in some code to tell me when I was missing colons at the ends of labels. There were a few functionalities missing, though.
* Advanced Conditional Logic. I could tell the game to go Story Branch A if X was true and to go to Story Branch B if Y was true. But we didn't have time to implement anything more complex, like go to Story Branch C if X and Y are true, but not Z. Or Go to Story Branch D if X, Y, OR Z are true. If I wanted to do anything complex like that, I had to stitch a bunch of If statements together or just give up and write something easier that wouldn't require any complex logic. After the jam, my programmer asked whether we should consider just writing the story in a C# script so we could take advantage of the advanced logic already baked into C# with && and ||. Once I realized I could word wrap in Visual Studio, I couldn't see any reason why not. Adding \ in front of every quotation mark would be annoying, but less annoying than trying to replicate complex logic with nothing more than if/else. Of course, it helps that I already know basic C#. What am I missing? Is there some reason not to do this?
* Keywords reused in the story. If a paragraph began with "if," the parser automatically interpreted it as an if statement, even if it was just meant to be part of the story. I thought this was fine, but then I learned AFTER THE GAME JAM WAS OVER that my programmer had made key words non-case-sensitive, so that if I forgot how to capitalize, the code would still run. Thanks, programmer. I knoW how to Capitalize, so please stop worrying about me ever introducing any user erroR. For our next parser, we'll probably just make the keyword "/if" so there's no chance it ever shows up in the story. Right?
* Difficulty Editing. There were so many story section labels that a word processor like MS Word wouldn't recognize that if I ran spellcheck, I would spend most of the time mindlessly hitting "Ignore all." For this game jam, I decided to just hope that the editorial part of my brain was still working on two hours of sleep. Fortunately it seems this strategy was acceptable, because my playtester only found three or four typos in a 13,000-word game. (Or are there more typos but my playtester was too tired to catch them? We'll never know! Wait, we'll know when people give us feedback.) But is there a way around this? Could the parser be programmed to strip away all key words and labels and produce a text file on which we run spellcheck? My programmer also pitched the idea of a parser that would parse a spreadsheet instead of a text file, so all the labels and key words and such would be in different columns, and you could just spellcheck the columns with story. Is this a better approach for the next jam? We don't know yet.
Did anyone else use or create a text parser? Let us know in the comments how you dumped your blocks of text into your game.
And if you're up for reading another block of text like the one above, check out our submission page here: https://ldjam.com/events/ludum-dare/48/bucket-a-space-odyssey
Happy rating!