I've just uploaded a Twine game to my account here as a test, but find that sound clips won't play.

The way Twine works with audio is that you call the file with its URL when you want it to play. At the moment those sound clips are being called from the same folder on my desktop where the game's main html file is stored.

If I run the game by just clicking the file from my desktop the sound clips work as they should, but now that I've uploaded the html file I assume it's looking for the sound clips online somewhere?

I guess this means I have to find a host for them, which isn't as straight forward as hosting images, because with free hosts you only get the link to the sound file, not the actual URL.

In that sound files are uploaded as part of Quest games - meaning we don't have to host them separately - is there anyway to do this with when uploading Twine games here?

I assume it's looking for the sound clips online somewhere?

Exactly: it's looking for them in the same folder the .html file is loaded from, where they aren't because you uploaded the game proper by itself. Solution: package the game and the sound files together in a ZIP archive and upload the latter instead. You may have to rename the game file as "index.html".

Oh, brilliant. Hosting is a pain. I'll try that now. Thanks very much.

Now I can't get the sounds to play even locally from my desktop. I had it working yesterday!!

Nope, this didn't work. It uploaded the zip file okay, but won't play the sounds.

Just to check I'm doing it right. I have a folder on my desktop. In that folder I have three files: index.html, firecrackling.mp3 and outside.mp3.

I click the folder and choose 'archive'. I set it to zip and hit OK. Then I get a zip file on my desktop, which I upload here. Is that right?

Any ideas?

That's right, but you did just say the sounds don't even play locally from your desktop anymore. If it's broken on your own machine in the first place, there's no reason why it would work online.

How are you referring to the sound files in your source code?

Sorry, should have said I got it working locally on my PC before I uploaded.

The following method for playing audio in Twine is to add the files into a 'start' passage thus:

<<cacheaudio "fire_crackling" "URLfilepath.mp3">>

And then trigger it in the desired passage/room with:

<<audio "fire_crackling" loop play>>

Might it have anything to do with renaming the html game file to index?

<<cacheaudio "fire_crackling" "URLfilepath.mp3">>

What's the "URL" part stand for in the file name? If your .mp3 files are right next to the game, in the same folder, you should have just the file name there. In fact that's how it should be if you got them to work locally. And no, it shouldn't have anything to do with the name of the game file.

From the Twine documentation on using audio:

→ Cache a track with the ID "boom" and one source (mp3)
<<cacheaudio "boom" "media/audio/explosion.mp3">>

I tried just firecrackling.mp3 and it wouldn't work.

Sigh! And now it IS working with just the file name.

I'm going to do one last zip test.

BINGO!!

Thanks for your patience, felix.

This is the zip file version: http://textadventures.co.uk/games/view/ahljcnasde6lwz1mfcdb0q/twineaudiotest

Wait, are your sound files right next to the game file in the same folder, or in a subdirectory? In the latter case, of course you should include the relative path. Either way, if it works it works. Just preserve the directory structure when you archive the whole thing.

Right alongside the game file.

So you're saying if I had a folder within my main folder called soundfiles then the path would have to be changed to something like desktop/twine2/soundfiles/firecrackling.mp3 ?

Sounds works in your new test, too. And no. Relative path means the path relative to your game file, i.e. the HTML. In other words, if you have a directory structure like this:

my-project/
| - index.html
| - audio/
  | - ambient.mp3

Then your path in the game should look like audio/ambient.mp3 -- no more, no less! But since you have the files alongside each other, that of course makes the issue moot, as you've already discovered. Good work!

Ah, I see. Thank you.