-
Notifications
You must be signed in to change notification settings - Fork 13
Online play and transcription recording
This document describes how the online-play and automated-transcription features of the IFComp web app work.
All this is implemented by the IFComp::Controller::Play and IFComp::Schema::Result::Entry modules in the source code, if you wish to dive in more deeply (or contemplate changing this behavior).
During the judging period, the ballot page (found at the URI path /ballot) will display a "Play Online" button for any entry that has a "play file". The value of this file is set by the app itself, based on the contents of entry's content directory. The play file is always just an HTML page, and the Play Online button, if present, simply redirects to it.
In general, the app chooses a given entry's play file (or lack thereof) based on this logic:
-
If there is a file on the top of the content directory named "index.html", choose that.
-
If there is a single HTML file in the top of the content directory, choose that.
-
If none of the previous apply, give up; we won't offer a play-online function for this game.
Entries always offer a Download button from the ballot, regardless of the presence of a play file (or any other criteria).
The web app processes entries uploaded as either "naked" Glulx or Z-Code files, or Parchment- or Quixe-using websites, so that they can use the app's automated transcription-recording service. (Learn more about this processing.) For both Z-Code and Glulx entries we use transcription functionality built into GlkOte.
In either case, with every line of Parchment or Quixe input or output, the interpreter calls /play/$ENTRY_ID/transcribe (where $ENTRY_ID is the database ID of the entry at hand), attaching a JSON data object describing the input-or-output. The app reacts to this call by inserting a row into the "transcripts" table in the database.
Once an entry has collected some transcriptions, its author can read them (dynamically translated into clean and readable HTML) by visiting their own entry-management page on the app.
-
Why is this written to a database, and not a nice plain textfile or something? Isn't this terribly inefficient, especially since the data's never modified, and comp games get a ton of play and attention during judging, and authors only want to read the final text anyway?
I think I liked databases in 2014 more than I do in 2017. Also, this was carrying over the way it was done in the app's previoys (pre-2014) iteration, under different management.
Yes, this too could stand to be improved (and simplified).