What Went Wrong

1. Lack of Early Direction

In 2010, when the project was still called lifelike, it was crippled by a confused artistic direction as to where it should go. If we had a strong artistic vision early on, we could have avoided building features we would end up not using, and we would have built tools that let us get the visual effect we wanted. Since we didn't have that artistic vision, we had to build very generalized tools that produced a rather generic visual style.

In an attempt to make the editor more artist-friendly, we used GameMonkey to expose a lot of in-game models' behaviors. Unfortunately, we exposed too many parameters and variables, which took down the frame rate. A great example was the jump behavior designed to make small circles jump in time with the music.

Over time, the jump behavior became bloated with a variety of other requests like interpolating color based on height, rotating on a pivot point, and other small artistic touches. If it so happened that none of them were being used, the cost of one jumping circle could be astronomical for the visual payoff. This was the price though of wanting flexibility in the visuals but never nailing down any one element.

Many of these behaviors were things that could have been (and eventually were) written far more efficiently and optimized for the SPU once we knew exactly what we wanted to make.

As a result, early incarnations of the editor on PC were a monstrosity, making it almost impossible to use without an intricate knowledge of each behavior's roots in code. (The original programmer moved on shortly after the prototype, so there are probably still things lurking in there that no one will ever know about now.)

The GameMonkey behavior method of using the editor was largely tossed out following the prototype, essentially binning a vast amount of resources and time.

2. Text Tutorial

We knew that 4am had so many new gameplay concepts and controls that it was going to be hard to explain how to play it. At game shows and events, we found people picked it up extremely easily, given the tactile nature of the Virtual Audio Canvas (vibration feedback).

Explaining this idea with just text and images, though, was a completely different story. Even after repeatedly refining the current tutorial and running "blind tests" on new people with every iteration, we still haven't really achieved a 100% understanding rate for the controls after one tutorial play-though. 4am introduces many new control concepts with no easily available mental reference points -- there's nothing like it we can compare it to -- so it's kind of like asking players to read a book and then play a saxophone.

The player can really only learn how to control 4am through play and experimentation, not a tutorial -- just like a regular musical instrument. However, since we call it a "game tutorial," people expect to understand everything about the game after they're done with it. While it's nice to see many players just "getting in there" and quickly picking up the rest of the controls, it would still be nicer to have a gentler tutorial experience that gives people time to acclimatize first.

3. Artist vs. Player

4am began as a passive music visualizer. When it started coming together as more of a music creation tool, a fundamental conflict arose: Players want to manipulate the music, but the artists want to preserve their original idealized state of a track. When we began experimenting with DSP effects, we quickly found that people like to warp music and make it their own. The dichotomy within 4am is that we want players to find their own sound, where traditionally produced music aims to have already achieved that for you by the time you hear it. So when making tracks for 4am, should they be prepped for "finishing" inside 4am by the players using DSP effects, or should they be ready to go right out of the box?

This internal tension had a direct impact on the ranges available to players within the DSP effects. A flanger or chorus DSP might have a wide frequency or feedback range to play within, but by carefully setting a min/max range under the hood, we could safely trim the performer's freedom space to something we knew would produce the kind of sound we wanted.

Unfortunately, some of these ranges are probably still too subtle for the average user to enjoy, since they can be difficult to hear depending on what track is playing. We had to create effects that were audible and interesting to players, but at the same time stylistically acceptable to the artist. In hindsight, these are two completely opposed ideas, so it was always going to be difficult to satisfy both. The player still needs to have fun, but not at the cost of being a passive appreciation tool for the artist's benefit.