Is there any way to build a game-specific play-in-the-browser Parchement page for a TADS3 game? Kinda like what you can do with Inform.
It’s not quite as straightforward as for Inform, but it’s not too complex.
First grab the Parchment zip: https://github.com/curiousdannii/parchment/archive/refs/heads/gh-pages.zip
Then edit index.html to specify your storyfile:
<script>
parchment_options = {
story: "PATH TO .T3",
}
</script>
And that should be enough for it to work.
You can optionally clean up the files from the zip it doesn’t use by deleting dist/single-file, dist/inform7 and the glulxe/git/hugo files from dist/web.
Note that this way of setting up Parchment will only work when running it over the web, not from a local file (file: url).
3 Likes
Wouldn’t that work both locally and on the web if you use a relative url? That’s what I do.
What would make it as simple as Inform? An install script, or something similar?
Browsers won’t load data files from file: paths. They used to, but it was a security headache so they all stopped.
Right, so the way the Inform 7 template gets around that is by turning the storyfile into a JS file. But for TADS there’s the additional issue that Parchment’s ES modules and WASM files need the correct MIME type headers to be sent by the server or else the browser won’t run them. And there are ways around that (see Parchment’s single file build), but it’s not turned into a reliable solution like the Inform 7 templates yet. This is the first request for game-specific TADS in Parchment I’ve seen so far.
And scripts like ifsitegen.py could be updated to support TADS. But they haven’t been yet.
Yeah, I was looking for something like ifsitegen.py or some other script-based solution. I can figure out how to edit things to hardcode a story file and removing the hugo/inform/whatever bits that aren’t needed. The problem I see with that is that it’s brittle: a new version of parchment comes out, and the same hand edits have to be made again.
Not the end of the world or anything, but just something that makes maintenance and so on more difficult. Basically my expectation is that parchment gets periodic updates for browser compatibility and so on, and it would be nice to not have to hand-tweak everything every time that happens.
The main index.html file is rarely updated, so that is a little less of an issue, just copy the other files.
I’ve made an issue to remind myself to eventually make a tool to support bundling all the storyfile formats. You can follow it if you want to be notified when it is completed.
isn’t difficult to set Apache to reject every non-local request, getting a secure localhost: or 127.0.0.1: environment where one can test web-based things (yes, I occasionally fool with LAMP coding…)
on every major Linux distro, Apache is installed by default as described above, together with a SQL server and PHP so, every Linux installaton is basically parchment-ready…
Best regards from Italy,
dott. Piergiorgio.
Unless I’m missing something, this doesn’t work for a work in progress, because it sends the request to https://proxy.iplayif.com/proxy with the story URL as an argument. So unless the game file is already publicly accessible it will fail.
This probably also counts as a privacy fail, as if you’re developing a game anonymously (as I thought I was), you’ve just potentially broadcast identifying information to a third party.
Oh, yeah I recently changed how it loaded files, didn’t think of this situation. I’ll change it so that it doesn’t use the proxy if it’s a same domain file. Will that be okay for you, or were you going to put the file on a different domain from Parchment?
Yeah, I usually have a local web server running on a virtual host that has all of the game-related files…basically a staging/deployment environment that looks like whatever the release version is going to look like.
I’m not sure if this is beyond the scope of discussion here, but is there any documentation for how to build emglken? I’m also toying with the idea of doing the UI elements from scratch instead of applying them as deltas to the parchment defaults, if that makes sense. Basically I want to have a consistent look and feel across the web player, the documentation, feelies, and so on, and have all of that in a bespoke web page for the game as a whole. Right now I don’t know if the best approach to that is parchment + a style sheet of the deltas, or if doing a roll-your-own thing with emglken/remglk/emscripten/whatever.
I understand if this is not a typical use case and therefore outside the scope of normal parchment support. Like a lot of modern tools for IF authoring, parchment works very, very well if your use case closely matches the normal/typical use case…and then things get very exciting when you start trying to do other stuff.
Okay, I’ve updated Parchment to not use the proxy for same-domain files. You can also set use_proxy to false to completely disable the proxy, or modify the direct_domains list to include other domains that you know are safe and should not use the proxy.
Just run npm build in the Emglken source folder.
Basically I want to have a consistent look and feel across the web player, the documentation, feelies, and so on, and have all of that in a bespoke web page for the game as a whole. Right now I don’t know if the best approach to that is parchment + a style sheet of the deltas, or if doing a roll-your-own thing with emglken/remglk/emscripten/whatever.
Yeah I don’t think you’d want to touch Emglken for that. Instead you’d mostly just be looking at HTML and CSS changes.
1 Like
Cool, thanks.
Well, part of it is just…aethetic? stylistic? not sure what to call it.
Parchment is really cool and does what it does very well. But approaching it purely as a programmer, the programming interface isn’t much like what you’d see in other game development libraries. Like consider the 2D game library Phaser. The basic usage pattern is: you include the library by putting a <script> tag pointing to it in the <head> of your document. You can then do something like game = new Phaser.Game({ config }), where config is an object that includes, for example, the DOM element to render in, stuff to control the appearance of the rendered game window, flags to pass to the underlying rendering engines, and so on.
Now I’m sure that the vast majority of IF authors probably absolutely don’t care about the programming API and stuff like that. They just want a web page they can play their game in. And that’s cool. But when I’m putting together a game page, I want to be able to fiddle around with more of the bits and pieces, so I’m more concerned about what the bits and pieces look like.
Put in slightly different terms, I think most IF authors probably just want a page to play the game in, I would rather have a parser API that I can put in the page however I want. If that distinction makes sense.
So I’m pretty much just sorta working backwards to try to get to the point where I have the absolute minimum number of moving parts necessary to run the interpreter in a browser—no jQuery, no extraneous logic for handling other formats, just a TADS3 equivalent of a hello world in a browser. So that’s why I was looking at emglken.
Hmm. Well the Glk port of TADS which Emglken uses isn’t really very flexible in that sort of way. If you want total flexibility to change the HTML/DOM/JS then something like Vorple would be better. But Vorple hasn’t been set up for TADS yet AFAIK.
But if you were set on TADS, you could construct your own system from scratch. The VM is constructed and init()ed here. If you didn’t want to use the standard WebGlkOte display library you could create your own. The interface of the GlkOte library is here.
Yeah, I’d started to work backwards through the source and got as far as importing GlkOte, which is really where the dependencies blow up and I started thinking about a different approach.
Just sticking to twiddling the Parchment style sheet to accomplish most of what I want would probably be smarter/simpler, but now that I’ve looked under the hood I kinda want to keep tinkering.
1 Like
If you’re going to tinker with the Parchment style sheets, perhaps you can share your findings. I’ve been tinkering with them, but the classes and IDs in the stylesheets aren’t documented anywhere and working out their intent fried my brain.
It’s documented here: GlkOte: a Javascript library for IF interfaces
Though there are a few differences with AsyncGlk’s implementation, such as style classes being applied to divs not just spans.
1 Like
Not sure if this is what you’re looking for, but when I first took a crack at it the documentation I wished I had was:
/* Wrapper for where most of the game text lives. Doesn't include status
line */
.BufferWindowInner {
}
/* Command line: Current command (before player hits enter) */
.BufferWindowInner .LineInput {
color: inherited;
}
/* Command line: Previously-entered command (after player hits enter) */
.BufferWindowInner .Style_input {
color: inherited;
}
/* Main text area: Room names */
.BufferWindowInner .Style_subheader {
color: inherited;
}
/* Main text area: normal text */
.BufferWindowInner .Style_normal {
color: inherited;
}
/* Wrapper for status line */
.GridWindow {
}
/* Status line: Room name, turn number, and score */
.GridWindow .GridLine span.Style_normal {
color: inherited;
}
/* Status line: Exit list label ("Exits:") */
.GridWindow .GridLine .Style_subheader {
color: inherited;
}
/* Status line: Name of exits in exit list
.GridWindow .GridLine div.Style_normal {
color: inherited;
}
You can just save that as something like custom.css and then include it in the parchment index.html by putting a line like <link rel="stylesheet" href="custom.css"> in the document’s <head>, after the stock css is included (look for the line <link rel="stylesheet" href="dist/web/web.css"> and just add the new line after it).
The stylesheet as given doesn’t actually do anything, but you can, for example, change any one of the color declarations from inherited to red (or something more useful) to highlight what each bit affects.
Also, my example doesn’t include any styling for images or other non-text stuff.
Parchment/GlkOte are a little idiosyncratic in that (as far as I can tell) there aren’t CSS selectors for the individual functional bits; you have to kinda put them together hierarchically. Which, to be clear, is perfectly acceptable CSS—in fact you could probably argue it’s optimal as far as pure CSS goes—but it does make it a bit less straightforward to tweak things.
Well BufferWindowInner is an implementation detail, Zarf’s GlkOte doesn’t have it. Better to use BufferWindow.
We’re working towards having TADS’s colour and other formatting options be used in Parchment. We’ll get there eventually.
there aren’t CSS selectors for the individual functional bits
What do you mean by the individual functional bits?