The Misadventures of Roy (tentatively named) will be an interactive story, with music front-and-center. Eventually, I see this being like a game, with more story and choice, and less action-packed gameplay. But if I start it that way, I’ll never get it done.

So this is going to happen in pieces, in phases, described below. I hope to start releasing it as soon as possible, starting in phase 1, with the music. Everything described will be released under permissive licenses -- in particular, the music will be released under the Creative Commons CC-BY 4.0 license.

The Short Game

White music mixing dials
Photo by Alexey Ruban / Unsplash

Phase 1: Music

This project is going to need a lot of music. Specifically, I need longer ambient background tracks in addition to shorter, punchier loops I can play and manipulate -- speed up and slow down, change the pitch, pan it back and forth, make it softer or louder, etc. From there, I really need a story to play to -- this is more about setting the foundation, establishing the background and setting the stage for effects.

Phase 2: Interactions

This is where interactions come in. I’ll be building a basic set of tools to check the mouse position and keyboard events, translate the coordinates onto a normalized grid with values from 0 to 1, and manipulate sounds based on the position of the mouse or keys being pressed. Howler.js will be super useful here. I might open source the core interaction event trigger code.

Phase 3: Story

From there, the natural next step is to start writing the story to go along with this, and integrate it with the music and interactions. At this point, I’ll also start writing music to match the story. This is where it all sort of comes together. I’ll have a webpage that displays the story, just text, along with choices you can make as buttons or links. As you interact with this page, it’ll play story specific musical cues. Here in particular is where there’s lots of room for iteration before moving onto the next phase.

Phase 4: Graphics

This is where it could get really interesting, but also really time consuming and complicated. I can make this into truly interactive fiction, with graphics. This could start as static pictures, upgrade to pixelated graphics, and could eventually become a full fledged world of its own. One key aspect of this project is that it’s all open source, so people could build entirely different gameplay experiences on top of the base I build – I don't have to subject you to my horrible pixel art.


Photo by Robert Bye / Unsplash

Iterations are where the fun is, really. Tweaking the effects, building on the story, adding music to fit the mood of a particular scene...this is where the project will live or die, essentially. The entire process is one of iteration -- the key is keeping my iteration cycles short. To me, on this project, that means keeping release cycles short. I want to release early and release often.

In the past, I’ve pursued ambitious projects, but never finished anything worth mentioning personally, because I always wanted to release the whole thing at once. That’s waterfall methodology. That’s a “boxed software” mentality. We don’t need to do that anymore -- I don’t have to wait “til it’s done”, whenever that may be. Usually, it winds up being never.

This project in particular may never be truly done, especially being that this will be an open source project and I fully expect to merge good requests for changes, changes that fit in with the project. This is a collaborative project at its heart. The closest I could see to having it “done” is marking one particular version of the recordings and site as “1.0”, “2.0”, etc. That’s doable, and useful too.


What I'm getting at is, I want to provide value early and often. In the first phase, that just means writing and recording loops, breaks, samples, whatever I may want to use (just have to make sure everything is mine to use, or at least fair use). This means releasing things I'm not 100% happy with. But that's ok.

Again, this comes back to how I've spent time on side projects in the past, and how I've approached such projects, how I've broken them down into pieces. Usually the backend came first, then a thin veneer of a UI with no regards to experience or quality, that point, most of the time, I'd get discouraged, have another idea, move onto something else.

I tried to implement principles of discipline and focus on one of my more recent side projects, a secure publishing app. But since I was using the same old process, I had the same old problems.

Loops and Patterns

Photo by Reid Zura / Unsplash

Sometimes, I don't recognize patterns right away. But now, I'm realizing the value of these short feedback cycles, especially in my recent work. I just haven't implemented this on a side project yet.

Music is especially conducive to these short feedback cycles. You play the note, you hit the key or pluck the string, and you can immediately hear how the music sounds. How it makes you feel. Whether it's bright or dissonant, whether it's loose or highly structured, whether it's danceable, and a million other qualities that elude description at the moment. You can tell when the sound is what you want.


Photo by Bruno Nascimento / Unsplash

I'm thinking of this in terms of exercise, or oddly enough, cleaning. If you never exercise, or if you only clean once in a blue moon, it's a hell of a lot more work to get where you want to go than if you were to make incremental progress on a regular basis.

Of course, I'm not expecting to build Rome in a day – this is 100% a long-term project. Ideally, I'd like to have one long term project and at least one short term project going at a time. I do have a shorter-term project I'm working on, but that's another post.

For now, I'm going to enjoy my Sunday afternoon, maybe play with some samples or something.