IMMORTAL HAND, IMMORTAL EYE

So here's a Tumblr post whose timely appearance on my dashboard I will gladly attribute to cosmic serendipity:

Historically, the high technical entry barriers to publishing one's own work has left indie video games vulnerable to allegations of "programmer art": that is, a tendency for the audiovisuals to be created by people who don't know what they're doing because "real" artists are barred from the medium by lack of technical know-how. In this sense, it's heartening to see that coding one's own game has become sufficiently accessible in the past decade or so that we're finally seeing the fruits of the natural yet historically largely unattested-to counterpart to programmer art: artist programming. (Prokopetz)

I will admit, straight up, that I am not "good" at programming. My code is so messy and patched-over, it may constitute cruelty against computers. Everything is a sparse array. Who needs a strongly typed language when you can just shove some parseInt()s or toString()s in there as necessary? I always use double quotes, except for when I use single quotes, except for when I need to use graves. These statements are neither pride in my ignorance nor self-deprecation; I'm saying these things to prove the point that you can do a LOT of things if you're just willing to do them badly.

The truth is that everything in IHIE, as well as everything I've ever made, is "artist art." It's artist writing, and artist music, and artist design, because my goal is to make art. I have not found it helpful to believe there's some standard of technical proficiency I need to meet before I'm allowed to make the stuff I want to make. That mindset does not result in making very much art at all. So I'm perfectly fine working with blunt tools; a bad solution I can actually accomplish is worth infinitely more to me than a good one I can't. One time I couldn't figure out how to open a plastic container of cat litter, so I stabbed a hole in the lid with garden shears. Fuck it. It worked.

This is not to say that slapdashery is inherently virtuous, or something. There's no reason to do things barely-competently if you can do them really well for the same price (of money, time, mental energy,) and you definitely should not take this approach when, like, building bridges, or managing a children's hospital. A badly-made bridge is, in fact, worse than no bridge at all, because it imperils the people who expect it not to collapse and drive over it on that assumption. A children's hospital that doesn't make an effort to keep its internal processes clear and efficient is going to result in mistakes that poison children. But the worst thing a piece of art can do is not exist.

(Okay, nuance: art that acts as justification, explanation, or encouragement for abusing other people, politically or individually, Is Bad, and would indeed be better off not existing in the first place. Those who really want to be the next William Luther Pierce but are afraid they're just not good enough writers should absolutely give up on their dreams and never try to make anything at all.)

If I may wax philosophical — by which I mean go from an already-waxing gibbous to a full moon — the creation of stories is one of humanity's neatest tricks. A story is an idea, generally imprinted in some physically-accessible medium, but which fundamentally can be infinitely reproduced in the minds of those who experience it. It's a thing that can be made to exist through the power of the mind alone, and the mind is its native habitat, where it "truly" exists. Art is a way of transmitting ideas between people through intermediary senses; reading a book, listening to a song, playing a game, are all ways of programming a story into your mind. You read some words, and an idea comes into existence, and it remains even if you forget the exact words (the exact notes, the exact sequence of keys pressed.) Those words may be arranged in aesthetically pleasing or displeasing ways, they may transmit the idea with more or less precision, and the medium through which a story is told does affect its meaning — (the same molecules of water seem different in a cup versus a vase versus a fishtank) — but they are, ultimately, subservient to the intangible. They're just carriers.

Got it? Great and/or that's fine. We're going to talk about the music now.

IHIE has a conceptually simple adaptive music system, and it works pretty much exactly as I envisioned it in those halcyon days of predev. Which is not to say that it was simple to build! Figuring out how to make a high-level idea like "music plays depending on where you are in the story" work in code is a series of puzzles, the first of which is semantic: what do I actually want to happen? Starting from absolutely nothing, what do I need to construct?

A way for music to play at all. This is an <audio> element whose source points to an .mp3 in the project's file web.

A way for the music to keep playing without being constantly interrupted by pages reloading. I put the <audio> element in the container around the actual page content, in the same place as the menu.

Music that continues automatically. I give the <audio> an onended property with a function, musicProgress(), that activates every time a track ends to immediately start playing the next one.

An ordered playlist of tracks. I make an array called playlist and go through its contents in order, making sure the delete whatever was just played, so the next track is always at the first position. For simplicity, all tracks are referred to with ID numbers, and stored like that (ie "26.mp3") in the files. This means that I can set the source of the <audio> element to "/music/"+ID+".mp3" to get the right track, instead of having to make another array to correlate ID numbers and file names.

A way to update the playlist dynamically. Visiting a new page triggers a function to queue a track by pushing it to the playlist array. I can set a priority argument that determines if this new track should go to the front or back of the line, or fade out the current track and start playing the new one immediately.

Music that keeps going even if it runs out of specifically ordered tracks. For this, there's a second array that I call "explore," for reasons I don't remember. Explore contains tracks that are suitable for playing in the lull between tracks queued up by story pages, and songs can be added to or removed from it by a similar mechanism. If playlist runs empty, the music progression function instead picks randomly from explore ...

A way to avoid playing the same song over and over. ... except not totally randomly, because there's a third array that stores the time since each track has been played. Whenever a song finishes playing, its sincePlayed time is set to 0, and all other track IDs' is increased by the length of the song that just played. When musicProgress() draws from explore, it first filters out all tracks that have a sincePlayed time of less than ten minutes, and only chooses from the ones remaining. This ensures that there will always be at least two or three more songs before any particular one is played again.

A page that displays current track information for the reader. Every song in IHIE has a name and track art, which I want the reader to be able to see without it being intrusive or distracting. The music tab in the top menu accomplishes this with a simple display of a couple HTML elements. The name of the current track is pulled from an array of correlated titles, (just like I didn't do in step 4,) and the track art is stored as "/sigil/"+ID+".png" so it can be referenced as easily as the tracks themselves. Something I plan to add in the future is a submenu tab to see a list of all the tracks the reader has encountered so far, in case they didn't check the menu while one was playing.

These seven steps achieve all the things necessary for my vision of the music system. You could copy them and build your own, if you wanted! I'm not going to say any of that shit about "creative theft." Please make a hypernovel. I'm begging you. Please make a janky fucking javascript app to tell a multimedia narrative to your exact specifications. It's good for you. It is necessary for your health. I'm a doctor.

By the way, there's a fun side effect to the way this engine works. If I mess up in the code, it's possible for the source-setting in step 4 to try to load something that isn't a real track ID. If the <audio> element can't find the file it's been told to get, it just doesn't play anything, and the music stops forever. To deal with this in testing, I made some error handler tracks to cover for invalid track IDs, by storing them in the game files as things like "undefined.mp3 ." The published version of the demo does not, as far as I know, have any remaining bugs that would cause these tracks to be played. Maybe I'll eventually release them some other way, or maybe they will be ultimate hidden forever... at least until I try to change something and accidentally break the music system again? It's not unlikely.

Is it a game? — Ultimately, yes. There are a lot of pieces of the definition of “game” that could be called into question here, but the most important one is whether or not there is a second player. Games are definitionally multiplayer, even when there is only one human involved; the other player can be a computer, or the computer’s larval form: the randomness of the physical universe (“luck”). Traditional novels are nongames because they are nonresponsive. Nothing about a book’s content changes based on the reader’s actions. Even CYOA-type books are static; they just happen to be mazes instead of labyrinths.

IHIE definitely does respond to the reader’s actions. From there, I have to question if it does so in a way that really goes beyond CYOA, or if it’s just using its computerized format to realize the “truest form” of CYOA — one where the navigation of pages is actually enforced instead of being on the honor system. You can’t, (or at least shouldn’t be able to, assuming I programmed it correctly,) go to the wrong page in IHIE; certain pages prevent you from leaving until you’ve honestly reached the end, and links don’t appear until you’ve honestly met their prerequisites. If that was all, I would say it’s just optimal CYOA. But there are, in fact, other instances where reader actions change things, and change the substantive content of the story. Not to get ahead of myself, but the order in which you visit pages determines what happens in the future. And, furthermore, there are some things that operate on randomness, which a static CYOA can’t do. Music is pulled randomly from a list of options, and a couple incidental bits also employ Math.random(). The engine is a second player. That’s enough to call it a game in my opinion.

Is it a computer game? — Yes. If IHIE is a game, then it is definitely a computer game. But I want to poke at the definition of computer game a little.

“Computer game” and “video game” are not synonymous to me. It is possible for a game to use computers and not video — of course, the definition of video is itself open to interpretation, but there are at least a few things that are absolutely not video, such as audio, which games have been enacted through. Even outside of games that are designed explicitly as non-video experiences, there are games intended for video that are nonetheless played without them. Here’s another one. You can look up virtually any game + “blindfolded” and find someone who has played it more or less to completion. (Tangential extension: playing games with no immediate sensory feedback at all is fascinating and impressive, but I think it ceases being a “game” in this context. This is a puzzle.)

A computer game is a game that uses non-human computers to do things that would be impossible for human players to do themselves. It is possible to use computers to expedite non-computer games, like using calculators to figure out numbers in a TTRPG, but in that case the computer is an external interferer. IHIE indisputably relies on the computer to track information based on player actions that the player theirself can’t see. But —

Is it a video game? — The use of video once again becomes a question of intent versus reality. If the video aspect is removed from any given video game, are you left with a game, or with nothing?

Consider a pinball machine. Modern examples can be quite advanced, even incorporating games played on a video display - but I don’t think anyone would make the argument that a modern pinball table is a video game. (Ahoy: The First Video Game, 27:53.)

Well said, Stuart. Surely they wouldn’t! Surely no one would say that pinball, or, haha, let’s just get totally ridiculous, bowling, is a video game! Surely they wouldn’t say that on my tumblr posts. SURELY.

So, um. Is IHIE a video game? It definitely has video-reliant elements, like colors and shapes, but its core is text, which can clearly exist in non-video format. It could maybe be considered “the same thing” if it was altered to, like, display all the pages by printing them out or narrating them aloud, which would allow it to be played on a computer with no screen. I consider the music an important part of the experience, but turning it off doesn’t technically prevent you from progressing, so the game could theoretically be run on a hacked electronic typewriter that takes “press 1 for x, press 2 for y”-style inputs. Is that enough to call the video aspect as extraneous as it is in pinball?

Well, the fact is that the version of IHIE that actually exists right now uses video. Versions of the story ported to non-video media are possible to imagine, but do not currently exist. For now: yes, IHIE is a video game. In the future, it might be a video game that also exists as a non-video computer game. It’s not likely. But it could happen.

Is it a Twine game? — I talked about this in the first devlog. Twine is the ubiquitous interactive fiction engine, and there are very few modern hypertexts developed without it. There are even fewer developed without a similar authoring system. IHIE, manifestly, is not made in Twine; it’s a bespoke Javascript app. But functionally, is it a Twine game? After all, today there are thousands of “books” which are written and published without printed paper being involved in the process at all, and “films” that aren’t shot on film, and “TV shows” that don’t air on television stations. Is a “Twine game” a game that’s made in Twine, or is it just anything that takes the same format in the end?

I don’t personally want to call IHIE a Twine game, but it’s not, like, the opposite of a Twine game. It’s a Twinelike, maybe. An evolutionary relative. IHIE isn’t a Twine game, but I probably wouldn’t be really mad if you called it that. Let’s call that a slightly fuzzy no.

Is it a visual novel? — I consistently refer to IHIE as a novel, and I’ve already established that it is visual, but then again so are ink-and-paper books. The term “visual novel,” taken as a single entity, currently and popularly describes a pretty narrow genre: a VN is a game where you choose dialogue options, and characters talk to you through sprite portraits. The modern VN scene is the result of interactive fiction facing a genetic bottleneck through otome games, (commonly called dating sims by people who don’t get really mad about the definition of dating sims), probably concentrated around Hatoful Boyfriend, and then attempting to rediversify out of this basic concept of picking lines to build relationships with characters. IHIE is pretty clearly not part of this genre; there is no interactive dialogue between the player and the characters, and if you want to fall in love with one of them, you will do so paratextually. Therefore, while IHIE is a “visual” “novel,” it is not a wikipedia dot org slash wiki slash Visual_novel.

Is it hypermedia? — Unequivocally yes! Finally, an easy win.

Okay, but what the hell is “hypermedia” anyway? — Once upon a time in the late 1980s, when computers could finally do things that weren’t fucking boring, people got really into multimedia.

Here is what Wikipedia shows as examples of multimedia. I think this is a perfectly succinct aesthetic summary.

Books have had illustrations since forever, and I heard that apparently there used to be a TV channel called “MTV” that showed like live action amvs for pop music? But the computer allowed you, anyone, to do it all in one place. You could have text and images and sounds and link mazes and three seconds of 144p video, and you could use them for darn near anything! This was truly the next dimension of media — no longer was information bound to the line of time, but could be navigated through freely. Holy shit. This must be The Future.

And then it stopped being cool, and started being ubiquitous, and now every website loads sixteen popup windows as soon as you enter it. But for a while there, it was awesome. Probably. The cybernovel age bloomed and died rapidly, and nothing was apparently notable enough to have the kind of genre-defining impact seen in other niches. Parser adventures had Zork, which is the kind of nerd thing that they mention on the Big Bang Theory, but cybertext had, uh, Stir Fry Texts? Which is good! But no one knows what it is.

The shadow of hypermedia continued to haunt the internet through things like Homestuck and 17776, which were and are lauded as somehow uniquely weird and ambitious twenty-first century things, and no one knew what a cybernovel was. And, gradually, as we kept seeing wild and unique forms of storytelling through the internet spring up and be misnomed as alternate reality games, I leaned closer and more maniacally in to my screen, yelling, “WE ALWAYS COULD HAVE HAD THIS! THE INFRASTRUCTURE WAS HERE THE WHOLE TIME!”

But can something really remain fringe and experimental for that long? An experiment has to get results eventually. If cybertext had burrowed its way into the mainstream entertainment industry before I was born, there would be nothing left for me to experiment on today. And I will always, to the point of pathology, need to do something weird in order to be satisfied.

Immortal Hand, Immortal Eye is a hypermedia story told mostly through (hyper)text and (hyper)music, which progress and evolve according to the actions of the reader-player-user-audience. It is a computer game, but one in which the player and the computer are not really in competition nor coöperation, and the only goal is to find more words to read.

Is it pretentious to fret so much over the specific definition of my own art like this? — I feel like it would be way more pretentious to claim I’m making something so weird it can’t even be described. An “audiotextual hypernovel” is the lesser evil in this case.

Twine comprises a couple of sub-engines — vassal states under the Twine halidom — so while authors might bicker about Harlowe versus SugarCube, the general population calls all of its products "Twine games." But in all configurations, Twine comes with its own built-in CSS rules. I hate this.

The first thing to ever motivate me to learn HTML/CSS was a desire to make cool custom userpages for petsites, on Neopets and Rescreatu and Lioden, and every time, I would run up against the same infuriating wall: I couldn't just start from scratch. Whatever I wrote was getting applied on top of the existing site styles, so while it was easy to change the colors of text and links, fuck me if I wanted to stretch my legs a little further. Everything was a mess of IDs and classes with no documentation anywhere, and I had to poke through the element inspector for hours to slap together my own.

This is the invisible maze: walls everywhere, and no way to figure them out but by trial and error. I'd been dealing with it for near on thirteen years by the time IHIE was ready to crawl out of my head and into the physical world, and I was tired of it. The fact that Twine wouldn't let me start with a blank page was an immediate frustration; I could have worked around this, maybe, by brute-forcing a bunch of !important clauses onto the defaults, but then I also ran swiftly into problems with the programming.

Twine's general ethos is to play to the author-not-programmer, the person who just wants to write and is scared to death of any code more complicated than a markup language. And that's fine! As someone who now "knows a programming language," I am qualified to say: knowing a programming language does not make you particularly cool or intelligent, and it certainly doesn't make you better than anyone else. I don't think you should have to know how to code in order to make interactive fiction — but I would like to have the option to. And there were non-negotiable parts of IHIE's design that I just couldn't make with Twine's tools. Chiefly, the music.

Twine's musical capabilities are limited, and basically just exist to let you have a looping background track or incidental sound effects. IHIE, however, is a nonlinear concept album, where story progression affects which tracks play when and where; the music isn't tied to each page, necessarily, but some pages have specific associated songs that will get mixed into the playlist once you've visited them, or start playing immediately if they're particularly important. Otherwise, the music system will choose from a pool of atmosphere-relevant backgrounders. In order to do this in Twine, I would have had to download a js library dedicated to handling audio, and then fiddle with even more already-written rules to get it to do exactly what I wanted. At which point — why am I even doing this in Twine at all? If I have to write from scratch, I can at least do it actually from scratch, not over a bunch of other people's shit I had to erase first.

So I said my goodbyes and left Twine behind. I considered some other engines that would let me work more closely with Javascript while still providing some backbone, like Iffinity and Monogatari, but ultimately, I'm just more comfortable working without them. Straight-up Javascript is better documented than anything else could ever be, like, tautologically, so when I do run into problems — which is often, because I'm bad at code — I don't have to deal with the invisible maze. MDN has maps on file, baby.