Audiozoe Minimum Viable Product Analysis

Audiozoe (Audio - sound, especially when recorded, transmitted, or reproduced. Zoe (Greek) - Life) is a First Person Shooter / Audio visualization game that analyzes audio in real time to influence the gameplay. It allows players to input their own songs in the formats .wav, .ogg, and .mp3. MP3 support isn't perfect however and proved to be one of the handful of challenges along the way to bringing Audiozoe to its Minimum Viable Product.

I used many of the principles of Rapid Application Development (RAD) during this project, and would often push harder features to later dates to ensure the core systems were in proper working order.

When I originally proposed Audiozoe I wanted to utilize a few things that later got scrapped for aesthetic reasons(they proved to be unfun). The first of which was to have the grid, or stage actually to be a seeded cellular automata, similar to Conway's game of life that the player could interact with. It would follow different rules however, and have different "Colonies" such as Red, Blue, Yellow, Green. These would battle and be more effective with different types of songs. The player, would shoot the blocks of all of the colors aside from the color for which they were the "Guardian." I abandoned this concept for a variety of reasons, but mostly because constraining the player within a cube was rather unfun for this type of game, the bright flashing colors could be too intense when the player was trapped. This became rather apparent within the first month of development.

During the first month I achieved first person player movement, analysis of a song in realtime utilizing Unity's AudioSource and its .getSpectrumData() and .getOutputData() methods. I wrote my own movement code, and began writing my own mouse-look code. Being a solo team, it quickly became apparent that utilizing a standard asset for mouse-look made more sense than writing it myself. I quickly pivoted to different mouse-look code and began work on prototyping the weapon systems for the game. Each weapon was meant to leverage a different way of working. The weapon called BitPusher would create a stream of cubes, each scaled based on the audio playing at the current time. A rocket launcher pistol style weapon, with fast moving projectiles was the second made this had a slight bit of scaling applied to it, but overall this was the simplest weapon. I then made a rocket launcher style weapon, and a physics projectile based weapon. The player could switch weapons using their 1 - 5 keys and tab between the two most recent weapons. The weapons use an interface based component model to be easy to switch between each other with. This was further made easier to to Unity3D's own entity-component based architecture.

Over the next month of development I built the menus and background subsystems that would enable the player to input their own audio. This proved to be a challenge in that .mp3, a common file format, was not supported a runtime. Upon research it became clear that this wasn't a solution I could simply work around by writing my own .mp3 code. The issue, was that .mp3 was under patent, and thus, I would have to license .mp3 for $0.50 per user of the game. This is not a mediocre amount if you end up selling a product. This is a problem that I later addressed, but I decided to sideline it for awhile during development, as while this would make the game a better product, it wouldn't make it a more complete game at the point in development it was currently at.

I worked on making the first person camera's environment look better and added in a skybox which I made in GIMP.

I continued to develop, making a few test levels, spikes, adding a way for the player to die and adding reactive color, in addition to the already existant reactive object scaling. I particle systems that were also reactive which resulted in the "Space Kraken" visible on the games title screen. As I started experimenting on the test levels it quickly became clear to me that an iteration on the game's formula would be procedurally generated levels with a start and finish and that the player would race against their song on these levels. It also became apparent that a survival mode, where the player would live until the end of their song would also fit the gameplay well. The survival mode became the crux of the Minimum viable product. I began work on creating enemy artificial intelligence that would be able to merge into larger enemies which also proved to have a few challenges related to Unity's collision system, I eventually did get this working, but realized that having enemies just try to run into the player was rather boring, and as such gave them projectiles but made it so they wouldn't run into the player.

Generating procedural levels offered me an opportunity to experiment quite a bit. I started by using pure pseudo-randomness, with some rules to see what kind of levels would be generated. The resultant stages looked a lot like the game some children would play where they would try to cross hot lava.
I then tried controlling the algorithm for pseudorandomness a tad more, using a Mersenne Twister algorithm for pseudorandom generation. I later researched noise generation algorithms, and ended up targeting Simplex noise for my level generation, using some pseudorandomness as well. In the future I may use fractal brownian motion.

The stages consist of 3 "Levels" each which I was experimenting with installing procedurally generated stairs, or teleports on to allow the player movement between the 3 levels. The results were not as good as I would have liked so I eventually decided to pivot making one of the weapons allow the player to jet jump to the higher floors (much like quakes rocket jumping). I ended up backburnering the rush to the finish mode because it would require more complex algorithms for path finding (ones that would be really fun to implement if my time was not limited.) As such I moved on to ensuring the game looked pretty. I found some standard assets for crystals, made my own enemies in modeling software and got some particles from Unity's store which I modified to be color reactive to audio. The game also ended up with turret enemies, that shoot weapons similar to the player's weapon on 1.

When talking about the design choice of health in Audiozoe it is obvious to most player that they have no Heads Up Display (HUD) elements visible to display their health. This design choice was made for two reasons. The first of which was that in a game all about audio, having HUD clutter felt out of place and distracting from the experience. The second reason was my stetch goal of virtual reality (VR) compatibility for the 3rd mode, hud's in VR are largely distracting experiences, and this design decision was made early so as to avoid the game as though it didn't belong in VR.

I also made enemy spawn points with particles and made them puff like fire explosions that would release enemies. Enemies and Crystals dropped health gems which restored 1/4 of a players health, player health was conveyed through pitch of the song, as the players health got lower, the songs pitch would get higher.

Survival mode offered the player a concise experience where they could focus on their music and enjoying the entirety of their song. I also added in Chill Mode based on a players request, this offers the player an experience without pitch shifting or modification of their songs.

I also got in contact with Unity3D when I went to Game Developers Conference (GDC) and was trying to figure out a solution to the MP3 licensing issue. After being in contact with them for awhile and realizing they didn't have the infrastructure to allow me to license mp3 I wasn't sure how I would tackle this. Shortly after, and quite fortuitously (and out of the blue for that matter) the final mp3 patent expired. I immediately got to work using the MP3 sharp library, and got a few tips from my friend Kevin Trinh. After being able to load mp3's in, the game became substantially better, as it was easier to have a diverse set of tracks to experiment with. This also enabled players to use their own music libraries in the game more effectively.

The player's 3D model, and gun model were made by Phung, I applied the color changing script I had written to them as well to give them color. I also used shared textures to reduce game lag based on frequent shader changes, this was made easier thanks to Jared Finder pointing out the issue while we were looking at Unity3D's profiler (which is a great tool).

I took Audiozoe to the Bay Area Maker Faire Saturday the 20th of 2017 and recieved rather warm reactions from most of the people who tried it. Some asked when it would be released on Steam. I was glad to get the game in front of an audience and got to see them break it in ways I may not have found myself. For example, it seems that if they did not select a song, they could sometimes begin the game on my test stage (which was disabled). They also managed to find a few places where it could be laggy after a long time of play, this seems to be related to the fact that I may load songs in again.

Now that I have highlighted some of the points of the journey up until now. Let me discuss what I would like to do with the future of Audiozoe:

I would like to add more enemies and bosses, and a boss rush mode.
Streaming MP3s from online.
A more diverse color palette.
More weapon models so it is easier to distinguish what weapon the player has out.
Song Race mode, with proper algorithmic pathfinding to ensure completable levels.
Actually use the teleporter, spike and stair assets.
Plenty more play testing
Optimized song load in (only load in when a song is selected)
Better versions of the weapons on the 2 and 4 keys.
More textures, better 3D models

If you have any more questions about Audiozoe, feel free to contact me to discuss it on the Discord channel of the http://www.sjsugamedev.com at San Jose State University.