When a game has puzzles that use sounds, is it better to give the sound files easily-understandable names, or is it better to make the filenames more obscure to avoid potential spoilers? The filenames are visible to the player if the player opens up the right folder, but I would guess that players who are opening up sound files outside the game itself probably don’t have “avoiding spoilers” as their top priority. Also, it would probably be less effort to solve the puzzle the usual way, within the game.
If the files are big and not embedded in something like a blorb container, a player might accidentally see them when copying the game to a new location. However, it seems easy in most circumstances to give the files names that are descriptive yet not too spoilery, like the chapter titles of many books.
If the sound names are spoiler-y it’s not a bad idea to give them more obscure names.
Within I7, you can declare them with much more easily-identifiable names that aren’t as accessible to the player.
The sound of John's Betrayal is the file "SND.09.mp3".
From experience though, I highly recommend making sure your sound-set and filenames are set kind in stone of beforehand. If you change your mind as the project evolves, it can be a little maddening and twitchy picking through and replacing the correct ones. In my case, I had about 30 sounds that I had anonymized like SND.018.mp3 Which I had foolishly named the same in my source text.
You might want to reserve the process of anonymizing the files until towards the end if you’ve got a lot of them and they might be updated throughout.
I’d forgotten this - the sounds do get wrapped in the plain blorb. They will be visible in a folder though if you publish to a playable website. But I’m not sure sounds will even work in Parchment or Quix-E.
This is not precisely respondent to the question but for Linux/Mac users changing a string throughout your project may be performed with a short script:
find ./[project_directory] -type f -name *.[inform_file_extension] | while read file do sed -i s/old_file.mp4/new_file.mp4/g $file done
This handy tool in your toolbox rips through all your files (-type f) in your project directory and replaces every occurrence of old_file to new_file.
I hope not to hijack the thread but this may be useful if you want to give the sound files “sensible” names during development and use the above to scramble the files’ names for production.
I hadn’t realized this either (or had forgotten). So if you’ve got a glulx blorb, the individual sound files are not accessible to the players anyway? (Unless they take the blorb apart somehow?)
But…if you put the game on a playable website, the player can see the sound file names? Interesting.
Blorb’s can certainly be pulled apart – after all, that’s what the interpreter is doing, and all the standards are open – but that’s not a concern if you’re just worried about inadvertent spoilers. If you put the zblorb or gblorb online for play with something like Parchment, the same applies: your players will never see any filenames except perhaps that of the blorb. Maybe all the files are put into some sort of directory structure if you choose to release with website? But I actually don’t think it will, unless you specifically indicate that these sound files should be released separately.
I7’s “create playable website” doesn’t currently export sound or image files at all. My proof-of-concept script for exporting images winds up obscuring the file names. (They wind up named pict-1.png, pict-2.jpeg, etc.) (I didn’t do this because of spoilers; it was just easier that way.)
being deaf, I must strongly discourage developing a sound-based puzzle.
N.H. Dottor Piergiorgio Maria F.P. d’Errico.
I don’t believe a .zblorb will handle sound files by design, and can’t contain them due to file size restrictions. Sound is only available with Glulx.
I think when you “release along with a website and an interpreter” the materials and figures folders become folders in the sub-structure of the website Inform produces. It does this because it pulls the Cover.jpg and Small Cover.jpg files from them to display on index.html. I believe it also puts out the “figures” folder so that during play the images can be shown. However, sounds have never functioned with any of the browser interpreters (Parchment and QuixE being the ones I know about). I can’t seem to find an example and can’t compile Transparent with its sounds to verify
However, if you just give someone the .gblorb, the sounds are in it without supplementary folders or sites. That’s why Transparent’s .gblorb is like 10MB.
This is not true. Blorb was set up to be able to handle Infocom’s sound-supporting games (Lurking Horror, Sherlock). Blorb is 32-bit even when the game file is Z-code.
I appreciate the input. This is for a game that’s already been released, so at this point I’m mainly doing bug fixes and trying to clean up the code. But, for what it’s worth, the sound puzzles are optional.
Thanks, everyone, for your feedback.
I’m sure I’m confused, and of course, you’re the expert, but Chapter 23: Verse 7 says
Once again, sound effects are supported by Inform 7 only on the Glulx platform, and even then we must be prepared for the fact that not all interpreters will be able to play them back.
Am I confused between “z-code” and “z-blorb”? Is it just an I7 thing where Lurking Horror did something special? I always thought “g-blorb” implied Glulx, and “z-blorb” did not… Along with the fact that Z is a smaller file-size and sound takes up lots of space.
(I’ve always used Glulx and .gblorb, so I never paid much attention to Z-specs.)
The Z-machine has strict file size limits, but they’re really a consequence of the word length, so they only matter for the story file (the .Z5 or .Z8 or whatever). A blorb is then a container, sort of like a .zip file, that can hold a story file along with any resources it needs (pictures, sounds, etc). “Z-blorb” is shorthand for “blorb containing a Z-machine story file”. (You can also make a blorb with no story file in it, or a blorb containing a Scott Adams game, or whatever, but nobody really does that.)
Glulx doubled the word length, which means it can support effectively infinite file size (there’s still a limit but nobody’s ever hit it—Inform breaks down in despair long before reaching that point). But that’s again just for the story file; the resources like sounds and images go outside the story file, usually in the blorb, which has the same “effectively no limits” as Glulx does.
Long story short, the Z-machine can in fact handle sound and graphics—that’s what prompted the creation of blorbs in the first place, it turns out! It just can’t handle them very well compared to what Glulx can do, so Inform 7 doesn’t bother supporting that. “No sound and graphics on the Z-machine” is thus an Inform restriction, not a Z-machine one.
Sorry, to clarify, now that I’m more awake:
- The Z-machine has a strict file size limit that’s fundamental to the design
- Glulx has (effectively) no file size limit again for design reasons
- Blorbs similarly have (effectively) no file size limit, but they’re just containers, with a story file inside them; the story file size is still limited (but that limit doesn’t include sound and graphics and whatever)
- The Z-machine can do sound and graphics, Inform 7 just doesn’t support it
That’s basically what I was getting at in my textwall.
https://ifarchive.org/indexes/if-archive/infocom/media/blorb/ has blorb files for the Infocom games (media only, no Z-code). Since the Z-code is now easily findable, one could add that in and then the blorb should be fully playable in an interpreter that supports it.
Which interpreters support it, I’m not sure. Zoom did, back when Zoom worked reliably.
Actually I’m not sure about Zoom. I was thinking of Kevin Bracey’s Zip2000. (Sounds pretty old-fashioned now, doesn’t it…)
On Windows, Windows Frotz supports graphics and sounds in Blorb files. I’m sure there are others, but I’m not certain which (and don’t have the time to check right now).
In Z-code, sounds (via the @sound_effect opcode) are supported from Z-code version 3 onwards. It’s more limited than sound support in Glulx, but is still reasonably useful - you can play sounds and stop them, and how much else is often needed? Graphics are only supported by Z-code version 6, which is a lot more challenging to use, because you have to grapple with the version 6 screen model.
Off hand, the only Z-code game I recall using graphics or sound to a significant extent (other than the Infocom ones) is Moments out of Time (https://ifdb.tads.org/viewgame?id=obx6l90zk794ef7m)
Isn’t there s a 2GB or 4GB limit on the combined size of media files? Somebody on the ADRIFT boards (at the time, ADRIFT 5 used blorb with signed values) has hit the 2GB limit.