Why arent assets path configurable in Twine 2?

Question

Well, I just did my first learning game with Twine (mockup of Mario Bros, unfortunately french only) , I really enjoyed it, I used SugarCube wich was super nice with me (thanks greyelf) but I still got a couple of questions that are mostly "why is it like this or did I miss something" 

The only big issue I had was to get my assets (images, embed css and js, sounds) working on both version, local version and exported version.

I understand that since Twine 2 is JS only, it gets its own testing server or something (the chrome extension thing) so it requires absolute path. So I ended doing a JS script that does everything for me (if http => relative path, if local => absolute path) but I believe that for a newcomer this can be a bit complicated. I mean it's already JS just to get images working. 

Why not setting such a configurable path system by default in Twine ? It is related to story format, actually, right ? So maybe there is already one and I did not seen it ? 

Best,

Charles

Answer 1

As you stated, when it comes to a HTML file there are two basic URL types:

1. Absolute: This type of URL includes all the information needed to describe where the referenced resource (in this case an image file) is stored, and what that resource is called (the image file's name). It also generally includes what protocol to use to retrieve it.

2. Relative: This type of URL assumes that the referenced resource is stored in a location that is relative to the location that the HTML file is stored in.

There are also generally two basic location types that a HTML file (and it's referenced resources) can be stored in:

1. Remotely: Host on a web-server.
Generally it doesn't matter if you use either an Absolute URL or a Relative URL when referencing resources, assuming that the HTML file and the referenced resource are stored on the same remote location and that location is commonly available to everyone viewing the HTML file.

2. Locally: Stored on a local hard-drive.
In this particular case you generally wouldn't use an Absolute URL to reference a resource because while the full path to the resource will be valid on your machine it is unlikely to be valid on someone else's. This is why a Relative URL is used, because it will generally be valid no matter who's machine the HTML file is being viewed on.

You may be asking how does the above relate to the Twine 2 application, and the reason is as follows.

I stated that a Relative URL needs to reference a resource stored relative to the HTML file, which the Publish to File option generates and you can control where that HTML file is stored so you can make sure your image files are stored relative to that location. However the Test and Play options create a HTML document that only exists in memory, this means that there is no HTML file stored on the hard-drive for the images files to be relative to, and this is why Relative URL's don't work when using the Test or Play options.

There are a number of ways the Desktop release of the Twine 2 application could be changed to support a Relative URL, each of them has their own pros & cons.
eg.
One possible solution is that the Test and Play options could be changed so that a temporary HTML file is created in a known location, this is what the Twine 1.x application does, and this would allow you to store your resources relative to that location.

A related issue, that of being able to control where each story project is saved on the local machine (and which could also be used as the location of the temporary HTML file), has been looked at a couple of times but no successful implementation has been created yet.