Concept, Prototype, Publish:
The History of THIS IS NOT A DRILL
Introduction
​
I remember the night very vividly when I decided that I was going to pitch a game to my University’s Game Design Program. It was very early in the semester and students were encouraged to pitch games to the class where only a select few games get picked to move forward. It was probably 3AM and I had trouble sleeping and suddenly a thought came to me, “Why not just try?” And that split-second decision would later lead to a published mobile video game titled THIS IS NOT A DRILL, available on Google Play and iOS.
​
The semester before I was taking a class called Production I, and in this class, we were learning the basics of game development in Unity and coding in C#. At the end of this class, we had to make a final project where we designed our first game without the help of a tutorial. At first, I remember this being incredibly daunting because I had no clue what I wanted to do, so I started to look at some other games for inspiration. And that is when it hit me, I wanted to make a game kind of like this flash game I loved in middle school called Avalanche. In this game, you control a white rectangle, whom my friend dubbed “the stick of gum”, and you would platform your way up falling blocks while escaping the imminent threat of rising lava. I always thought this game was fun, but it was lacking any kind of systemic depth and had some incredibly unrewarding gameplay features. There were moments where you could get trapped underneath the rising tower of blocks and you would not be able to climb your way out, so you would just have to accept death and hope to not have bad luck next time. And that is all there really was to this game, but for some reason it still stuck out to me and I thought it was cool. It was then that I said to myself, “I think I could make this game…but better” so I set my mind to making this my final project for Production I.
​
Lavalanche
​
It started off with coding the player movement. In Avalanche, you could only move side to side and jump. However, you could sort of stick to the sides of falling blocks and then wall jump from them. With the help of my professor I was able to get the player movement working in the most basic way. My wall jumping’s physics were a lot worse than Avalanche, but it still worked. After the player movement I needed the raining blocks to spawn in from the sky. This was as simple as creating a range on the X axis that was capable of instantiating block prefabs. Originally, I had them spawning in on screen because I didn’t know how to get it to make it happen off screen; I later found out that you could just spawn in the blocks above the player’s Y position at a distance high enough so that the instantiating didn’t appear on screen. All that was truly left after this was creating the rising lava. To do this, I just made a giant cube and gave it lava texture and gave it a Box Collider and marked it as a trigger. When this trigger collided with the player, it would check the tag to make sure it was colliding with “Player” and if it were, the player would be destroyed and the game over menu would pop up. I then just quickly made some 3D terrain in the background and added a height score and this final project was basically complete. I titled this game “Lavalanche” and this is what the game ended up looking like:
Evalanche
​
Fast forward to the next semester and I continued to work on this game a little bit more for another class called Sound for Games. I used this existing project to implement sound using FMOD. I basically duplicated this lava level and made another level that was pure ice. All that happened in this part of the project was that I demonstrated that I could compose music that would adhere to a specific aesthetic and add in sound effects for basic interactions like button clicks and player death. Lavalanche then evolved into Evalanche, and this was the game that I chose to pitch to my Production II class.
​
The night I decided to pitch I began writing a bunch of notes in my phone, so I didn’t forget the things that were on my mind. Here is a screenshot of exactly what I wrote and what I imagined this game to be at the time. Originally, I wanted this game to be a mobile tilt-controlled game. I thought doodle jump was very fun and my game was somewhat like this, so I thought tilt controls would be a cool way to play. It wasn’t until later that my professors and other students thought that tilt controls were a terrible idea for this game. At first I was really hurt and hard headed about wanting tilt controls as the main way to play because I thought it would work perfectly fine, but I soon figured out myself that they were right and tilt was not the best way to play. This was mainly because in this game you must be really precise with your movements and keeping completely still was almost impossible with tilt. I wanted multiple differently styled levels with a progression similar to Rodeo Stampede. In this game, you complete a myriad of challenges and collect enough coins to buy a new level. These new levels introduce new standard animals and a new environment to traverse. I wanted to mimic this with having different objects fall from the sky but have them agree with what level you are in. For instance, falling icicles in the ice world, toxic waste buckets in an industrial acid level, or a lava block that burns you when you stand on it. It’s cool to see that this idea ended up staying with our game in the long run. To make this long introduction short, I then gained the confidence to try and pitch my game to my peers and professors. It was tough for me because I am not the best public speaker and I hardly knew anyone in the class, so I was incredibly nervous to put myself up there and try, but I did. I ended up making it through the first pass and we moved on to the next phase in development which I like to call “The Shark Tank Era.”
​
After my game went through the first pass, I gained two more team members to have a group of three that would begin taking my prototype and improving on it to make it through the second phase of weeding out. In this phase, all the games that made it through the first round would then participate in the Shark Tank Pitch where each team would create a presentation and pitch to three industry professionals in the commons of Indiana University’s Media School. In this phase we made some of the biggest changes and updates to our game that stuck through to the present. Evalanche soon became temporarily named “Grouplanche” mainly because I was not the only developer anymore and I had a team. Pretty lazy name, I know.
​
Grouplanche
​
Our team was comprised of me, Bradley, and Jesse. Bradley was a sound designer like me, and in the beginning, he mainly helped with designing new mechanics and gameplay features. Jesse is a gameplay programmer and was able to add in all the new, cool ideas into our game. The first of these new additions were new blocks that had different interactions than the basic blocks that fell. This included the spike block, slime block, and trampoline. The spike blocks had spikes on the side that would kill you if you touched them. The slime block did not have a fixed rotation and would bounce around and slide between other blocks and the trampoline would just let you jump higher if you jumped from it. However, it was soon after this that the biggest change from Avalanche came about: the ability to destroy blocks that you jumped and hit from underneath. This works a lot like how is its in Mario games when you jump into blocks to destroy them. This made it so that players could no longer just get unlucky and die because they got put in a bad spot; now you could simply destroy blocks above you so you could always find a way up. However, you didn’t want to destroy them all because the threat of the lava was still imminent. The player is pitted with choosing what to destroy and what to utilize to get higher up. Soon after this, we implemented a few power-ups that you could use to help you in game. The first two were the Jetpack (who doesn’t love a good jetpack) and a shield. The jetpack would just propel you up higher as you would expect, and the shield would prevent lethal damage that would otherwise kill the player. Everything was beginning to come together, and our game was becoming more and more game like as time went on.
​
One of the other teams in my class was disbanded so there were now some free agents in the class looking to work on the other projects. It was then that Nick wanted to join our team and help with the development of our game. He was a programmer and a designer much like Jesse. I remember distinctly meeting as a team soon after where we would discuss the overall theme of our game and how we wanted to stylize our gameplay experience. It was then that we came up with the idea to make our game take place in a collapsing mine shaft and our main character would be an old prospector who dug a little bit too far and hit lava. Nick then came up with the idea that I think changed our game forever. He said, “What if when you destroy the blocks, coins spawn out of them?” I don’t think anyone really realized at the time how huge this change was and how much it truly turned our experience into an actual game. This then created an amazing gameplay loop that I think defines our game’s core experience.
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
On the left is our game’s core loop and on the right is our progression loop. Adding in coins to spawn from destroyed blocks connected these two loops and soon became the defining gameplay experience for our game. We soon made the power-ups upgradable, and this was basically where our game was right before our shark tank presentation. We created and rehearsed a presentation and the rest was history. The judges saw promise in our game, and we ended up moving forward and gained confirmation that our game was soon going to be published by the end of our college experience.
​
THIS IS NOT A DRILL
​
We started off this new phase by making a completely new Unity project and migrating everything over and cutting off some of the bad coding that was still lingering from the early prototype I created. Jordan began the creation of the mineshaft, our main character Eustace Diggs, and all the other blocks that were in the game earlier. However, it was around this time that I began having a lot of issues working with FMOD. For some reason, the sounds would not work for any of my teammates that did not have FMOD installed. For their game to work, they had to install FMOD and build the game every time to play it for Unity to not be completely busted. We soon found out that during our migration that the FMOD build data was somehow added to our repository’s .gitignore. After we fixed this, FMOD became a little bit more manageable, but we still ran into issues with FMOD all the time. I could talk about all the changes my team made from this point onward, but instead I will now focus on just my work with the game moving forward.
​
It was soon that Grouplanche became THIS IS NOT A DRILL after a long brainstorming session with my team. For the game’s soundscape, I was faced with simulating what an actual mine shaft would sound like. I did a little research on how sound works in a close-quarters area like a rectangular mine shaft and came to the conclusion that I was going to have reverb on almost every sound effect that takes place in the game world. This is because sound bounces off everything and creates smaller, quieter sounds called partials. To make it sound like a mine shaft, I needed the everything to sound like it was bouncing off all the walls. I used the FMOD reverb tool to give most all sound effects a consistent reverb so that I could maintain continuity between everything. I also have some background ambience to help set the mood that this mine shaft is collapsing. These sounds all have a heavy low-pass filter on them to make them feel like they are in the distance as opposed to right in your face. I also did not want these sounds to take priority over gameplay, so I made sure they were mixed lower than the most important sounds. These ambient noises include big blasts, cracking rocks, falling broken pipelines, and echoing booms. You can hear these noises at all points in the game as they are scatter events attached to the main camera. This was a design choice I wanted to make because I wanted to get across to players that you are not in a safe environment. If you stay idle on the main menu you can hear these sounds play randomly and this lets you know that shit is going to hit the fan when the game starts and this is no ordinary mine shaft. I think these sounds helped create a dangerous atmosphere that my team wanted to express in our game.
All the power-ups, except the TNT, have looping sound effects. In order to get sounds to loop seamlessly, I used Adobe Audition and put the audio clip on a multitrack mixdown. The trick is to cut the audio in half and set the second half to start the sound and then crossfade the end with the beginning of the other half. Since the end of the first half is now at the end of the clip, it will seamlessly loop into the itself. I used this method to make sure there weren’t any hiccups in the audio for each power-up. In FMOD you can then set loop regions above the sound clip and it will continuously loop until you tell it to stop in the code. Of all the sound effects I made for the power ups, I am most proud of the ghost power-up. For this sound I used my guitar with a slide and gave it a lot of reverb. I moved my slide back and forth between two adjacent frets. This sound creates a harmonic dissonance and sounds like a ghostly wail. I think this sound is very cool to me because I already knew in my head that it was going to work before I even tried just because I understood the theory behind it.
​
Music in FMOD
​
Lastly, I want to talk about how I approached our game’s music. Our game has multiple different levels: mine shaft, ice, and factory. In order to reach these alternate levels, you must make it up high enough until you see a glowing white block. When you destroy this block, the level will automatically change to one of the other two levels. Since it is such a split-second change, I needed to find out a way to get the music for the levels to transition as smooth as possible. I was able to make the music work all from one FMOD event where I referenced the other events that contained the music.
​
​
​
​
​
​
​
​
​
​
​
You can see here that there is MainTrack, MenuTrack, IceTrack, and Factory track. When the game starts, you are in the main menu and that is the first purple region you see. The game will infinitely loop this track until the game starts. Then, the gameOn parameter is set to 1 which transitions the menu music to the main level music. You can see in the green region there are lines that section off the area; these lines represent every 8th note in the music. This way, a transition will only fall on the next available 8th note beat of the song, and this makes it so that the transition happens as quickly as it can since this is the smallest interval FMOD will let you transition on. Once it transitions from the menu track, gameOn is set to 1 and then all of the main level themes begin to play at once. These tracks are all in the same key, time signature, and tempo so they will be perfectly in sync at all times since they were triggered all together. The difference in these tracks lies in the instrumentation. They all have the same chord progression and song structure, but each track was created to fit in the area its played in. The mine shaft is more of an acoustic approach with inspiration from Wario’s Gold Mine in Mario Kart Wii. The ice level contains inspiration from Metroid Prime’s Phendrana Drifts and Undertale’s Snowy. I really just liked the high-octave, reverbed piano keys that ice levels tend to have. The factor track was originally the main level’s track, but we felt it had a stronger percussive drive and felt more like the factory than the main level. All these tracks play simultaneously but you can only hear one at at time, and that is because the levels that you aren’t in are at in inaudible level of sound. When the levels transition, I automate the previous track completely down and the new level’s volume comes up. This way, the music always transitions smoothly and on time with the switching of levels as seen below.
​
​
​
​
​
​
​
Conclusion
​
In the end, this project ended up becoming a dream come true. I never expected my prototype to come as far as it did and I am incredibly proud of each and everyone who is on my team. We put an immense amount of passion in this game and I am happy to see all the positive feedback we have gotten post release. So far, our game has around 300 downloads and 65 five star reviews in the app store. It is not much, but to me it is amazing. My advice to anyone in game design is that you have to be passionate about what you are working on, and if you believe in the idea, you can make it a reality. So, if you ever find yourself thinking, “I think I can do that” or “I know I can do that”…just do it. Believe in yourself and believe in your idea, and you will make it into a reality.
