Comparing launch months of my first game and my first album

(Nerve Damage is now available on basically every music platform in common use. I've embedded Spotify below, but you can pretty much find it everywhere that streams music.)

In the final weeks of 2021, after what is roughly 20 years since I started playing and making music, I released my first ever album. I wrote, recorded, mastered, everything on Nerve Damage (except for the stellar artwork which was created by Matthew Wegner). I released the album independently, which was always going to be the case, and allowed me access to all of the data regarding its performance.

In 2017, I released a videogame entirely on my own through the Steam PC platform, Starship Clicker. I had spent roughly the past 2-3 years learning how to make videogames, including teaching myself to program. Being another independent release, I have access to that data too!

Now the real question: Which of these would allow me to make a living? Short answer: Neither, and the question of profitability is complicated by various factors.

Without getting into raw numbers, let's establish some key facts:

Nerve Damage (Music album)

• Released Dec 2021.
• Comprised of seven tracks, created over the course of 2021.
• Priced at USD$7 (in line with Bandcamp's recommendation), with the ability to pay-more-if-you-want (I don't know the official term for that, and I don't care to look it up).
• Took me basically the entire year to make.
• Cost me a small fortune in music gear.

Starship Clicker (Videogame)

• Released November 2017
• Is a short, replayable arcade game.
• Launched with a price of USD$1 (a few friends and I were all releasing $1 games on Steam to learn about the platform during that month). Its price was raised to $3 last year.
• Took me roughly seven days to make, from scratch.
• Cost me virtually nothing, minus my time, and maybe USD$100 for a Steam app release credit.

Show Me The Money

At the 30-day mark, Nerve Damage actually out-sold Starship Clicker. A music album made more money than a videogame, and sold to far, far fewer users. In terms of revenue, it is reasonably close, but Nerve Damage outperformed Starship Clicker by roughly 25%, and sold to around 5% as many people. That's pretty surprising!

Now, what does this all mean? I dunno, I just thought it would be interesting to write it down for posterity.

20170516 Game-y systems added

Tonight we added a few methods to implement game features in the scene. This gives the player a goal to aim at, but doesn't yet explicitly direct them to do so. There remains pretty decent potential to keep this concept open, to not too strongly direct the player to do anything in particular, so that they may have fun as they see fit. The split here is between what is a 'game' and what is a 'toy' - right now we're on that knife-edge, and are in no rush to close off either option.

To truly embrace its game status, of course, we added particle effects. You know you're doing something right when particles start firing, right? My suggestion that upon reaching the desired score, we call Application.Quit() was totally worth implementing, but did not remain present in the project for long. It's like an escape room - to leave the game, you have to win the game.

20170502 Inertia!

Inertia, what a beautiful thing. Updated Reset script to also reset object inertia!

A funny bug this created was that if you reset an object at terminal velocity, then upon Reset it would move so quickly that it would travel through the floor. We think this is possibly due to it spawning at such a velocity that it spawns inside or beneath the floor. But hard to tell exactly without really digging into it.

20170425 Reset QOL

Tonight we decided to implement a Reset functionality that enables smoother puzzle solving, as well as improving other feature testing without needing to completely restart the game.

The script is straightforward - a selection of objects in the scene are tagged 'WillReset', and the script resets their Transform information when triggered.

This introduces some new avenues for potential puzzle creation, too.

20170413 Playtesting

Tonight we did a rush-job on some objects for testing, and then brought in two friends who had not yet seen the prototype, and invited them to check it out and provide us with some feedback.

One of them had trouble learning and picking up the techniques, while the other tester understood the mechanics pretty immediately.

Both overall had fun, but with the caveat that it's pretty bare-bones right now.

It wasn't immensely productive, but it's always interesting watching people experience something you've created.

20170411 Checklist stomping

Tonight, we continued the momentum, and added a number of QOL improvements for testing and experimentation.

We fixed a physics bug that, as with all good physics bugs, did not possess an entirely apparent cause. We removed some early Debug.Log statements that were no longer useful, and were clogging up our console window during tests.

We fixed a prefab deletion error - this was something we had written but never properly investigated. It was not a huge surprise that it needed some TLC.

We adjusted a key system to allow for better cueing, and then out-did ourselves by doubling our feature set possibility space straight after that.

All in all, pretty solid work.

20170406 Bug fixes, recalibration, and design whiteboarding

Tonight we got a lot done. It was good to have an evening of few distractions. We worked pretty solidly from 7pm until 10pm fixing bugs, recalibrating some problems with room tracking and our general feature tests, and we even squeezed in a whiteboarding session to map out a few directions that we are going to take our existing feature set.

My partner and I outlined three use cases that we feel will serve as a decent suite of concept proofs before we take the plunge on more hefty quality-of-life work that will follow, should these prove as enjoyable as we hope.

The plan from here is to spend two weeks on each of the three prototypes, moving onto the next if we happen to finish early, and then likely running some friends and colleagues through them to see what they think.

Things are looking good, and I still have to keep reminding myself that we've only been working on this idea for about a month (and very casually, time-wise), and yet it's moving pretty steadily. It'll be interesting to see how our first proof-of-concept works out!

20170404 Unexpected first playtest

Tonight we accidentally stumbled into our first playtest! We were testing hand capture, and added a few spheres to allow for small-scale juggling testing. As we were working, a colleague brought a few of his friends in to check out the office, and one of them happened to be a keen juggler.

Before we know it, she's asking to check out juggling in VR. This was really useful to us, as we'd been testing out the juggling/throwing/catching for a few minutes, and were having trouble figuring out why it felt so inaccurate. After 30 seconds or so, she had figured it out - our system to joint the spheres onto the controllers was creating joints not in line with where the hand typically would be holding something. As a result, when players chose to release the sphere, they were releasing it on a trajectory that did not match their desired angle, resulting in the sphere most often moving out forwards from the player.

This was great, however the real excitement came from her playing with the primary mechanic of the prototype. An initial question I had been exploring with this mechanic was related to something I'd considered regarding medium-scale player populations in locations such as social areas in MMOs - When server data is not available, could it be possible to feed players their own actions on a time delay and have them believe they are watching someone else?

The answer is yes.

20170330 Short session, good outcome

We only had a single development session this week, but it went very well.

This past weekend, the office we use for work, Indies Workshop, relocated from SoDo to Capitol Hill. With that move came the loss of our previously large VR development space. In its place, we must (at least temporarily) make do with a small converted conference room.

With the help of another member of the office, I spent the late afternoon getting the room ready for work. This meant that part of tonight's work was focused on figuring out how to most optimally arrange the room in order to facilitate getting work done, and not getting in each other's way. It has enough space for about 4 people sitting at a table, but 2 people can only just walk around without getting in each other's way.

That said, we found a setup that worked for the most part, and commenced the next steps on our prototype. Namely, refactoring some code and breaking things out into their own scripts (at this stage everything was running in a single script, which was messy for a whole bunch of reasons), and adding the next 'ability' that we wanted to explore. It went great. Our initial planning was way over the top, and we were happy to see that Unity does exactly what we want without the slightly complicated vector math that we had planned for.

Another successful evening! If things continue on this path, I think we'll have something demonstrable by the end of June.

20170323 Prototype progress

Tonight's session was probably our strongest so far. We've really found our rhythm when it comes to approaching and solving problems, whether they occur during fiddly programming tasks, or while thinking through design challenges.

We have outlined a few tasks, and spend our development sessions tackling them top-down. Tonight finished with us solving a problem so quickly, completely, and immediately that we looked at each other in surprise (and joy!) and decided to stop while we were feeling good.

20170321 First day back after pause

Tonight was our first evening back in action since the month-long break for a few work commitments.

As expected, our previously-compiled list of research into 'what works and what doesn't' for VR on small projects with small teams and small budgets proved extremely useful. We spent most of the evening poring over it, and agreeing on a few principles for our experiments going forward. The previous window for work was 3 months, give or take, and since things worked well, we agreed to continue for another 3 months on a few 'idea++' concepts - taking things that worked well during our initial tests, and building upon them.

The evening finished with a clear direction in mind, and we began work on our first 'proper' prototype!

20170216 VR brainstorming

Tonight, we revised the games and experiences we had previously examined, and created a rough set of guidelines laying out what works, what doesn't, what's feasible for a small team. This covered art direction, animation, art, mechanics - essentially we're trying to find a recipe for what to make, based on our limitations.

Scheduling is in flux for the next few weeks, as a number of large video game conventions and conferences are looming, so we likely won't get back into things until the end of March.

However it's good to be pausing at a stage where we have a bunch of options for what to do when we're ready.

20170209 VR porting experiment

Tonight we tried porting a friend's Unity first-person project to VR - not the whole thing, just testing a scene.

Ran into a litany of weird Unity errors - this is our first time interfering with someone else's project, and it was pretty offputting!

Something to do with Unity versioning, and/or plugins.

20170207 Vive Camera experiment

The chaperone effect is pretty neat if you like Glowing Edges in Photoshop. I do.

Tonight, we ran some experiments related to the HTC Vive's built-in camera, mostly riffing on how possible it might be to use as a real-world camera in which one might place virtual objects.

From what we can tell, the camera simply isn't high-definition enough to be useful for this, and given our three-hour session limit, it felt like too much of a rabbit-hole to re-fit the camera's image output to be suitable for use within the headset. My inclination is also that someone has already done this part somewhere out there.

We also took a side-trip and made a little cube character who would mimic your movements in reverse, thus mirroring you. Its name is HeadFriend and it is strangely compelling and 'life-like' despite being obviously not lifelike at all.

One fun little thing we ran into tonight was the weird feeling of watching the Unity Game view as someone else wearing the headset approaches you from behind. It is a chilling feeling, even though you know they are there, to watch someone approach you! Pretty interesting.

The overall outcome of tonight is that we're really starting to pick up the pace on the idea-implement-execute cycle. Some things this evening barely took 20 minutes to go from 'what if' to 'oh, cool!'. That feels good, for sure. Not bad for just 4~ weeks of VR experimentation.

20170202 VR testing

Audioshield is a lot of fun.

Tonight we completed our testing that we had begun on Tuesday. Our conclusions remain mostly the same, with the exception that we saved a few 'best in class' entries for tonight, to avoid overly coloring our impressions of the others in the line-up.

Space Pirate Trainer is an excellent shooting gallery that results in quite a cardio workout as wave difficulty and intensity increases.

Budget Cuts has a particularly cool idea for modifying what the tracked controllers do, and I can almost definitely imagine using it in the future.

Overall our impressionss were:

• Lots of physics and scripting is good and works well
• As little animation as possible is fine - the player is largely more interested in how they can affect their surroundings.
• If you do have loads of art and animation, it is very impressive but also looks acceptably very expensive
• Games where you walk the least are the most engaging
• Teleportation does not feel like 'the answer' to VR movement