THIS IS NOT A DRILL

Nickolas Wright

Nickolas Wright

Bloomington, Indiana

3 0
  • 0 Collaborators

THIS IS NOT A DRILL is an endless runner where you must outrun the rising lava and climb as high as you can to reach a high score. Buy power-ups and upgrade them to help you escape the mine shaft. ...learn more

Project status: Published/In Market

Game Development

Groups
2020 Intel University Games Showcase

Docs/PDFs [3]Links [4]

Overview / Usage

Project Overview

Rising lava below, falling earth above. How will you survive?

THIS IS NOT A DRILL is a mobile endless runner where you must outrun the rising lava while drilling through falling hazards to escape a collapsing mine shaft and survive as long as possible.

Development Team:

Evan De St Jeor - Project Lead, Sound Designer

Nick Wright- Producer

Jesse Riggins - Gameplay Programmer

Jacob Ringer - Gameplay Programmer

Jordan Hannon - Lead Artist

Bradley McNeil IV - QA Project Lead, Game Marketing Manager

Patrick Reeves - Music Composer

Autumn Almeida - Concept Artist

Our team's developers are looking to be hired, check out our website to learn more about each of our members and see professional portfolios.

Unique Selling Points:

  • Endless runner with consequences
    • Most endless runners offer only twitch-based gameplay, but we slowed down the pace to give players the opportunity to think through their actions and make decisions that affect them in the long term.
  • Dynamically choose to make the game more difficult for better rewards
    • Long-term progression requires a lot of coins, and the easiest way to earn them is to actively work against your objective and destroy the hazards falling from above
  • New game worlds offer challenging gameplay twists
    • Climb high enough and you can phase between new worlds! Each world has its own challenges to complete which add new gameplay experiences to look forward to.

Gameplay Loops:

We have linked our gameplay loops in the media tab under documents. Our core loop is built around the game's most fundamental decision: whether or not to destroy any given block. The player has a short-term goal and a long-term goal: first to avoid getting crushed by the blocks, then to outrun the lava. Destroying a block makes the short-term goal much easier, but each time this ability is used the long-term goal becomes that much more difficult.

This game is about striking a balance between your short-term and long-term needs.

Our progression loop is quite simple and one that is present in many games. Collect coins, to buy upgrades, to collect more coins, to buy more upgrades. Because collecting coins is tied to destroying blocks, an interesting thing happens when you combine our core and progression loops. If a player wants to collect a large amount of coins, they must actively destroy blocks. Therefore, the player can choose to make their current game more difficult to make more significant headway towards long-term player progression.

The player is incentivized to act against their own best interest.

However, this is our number one pain point for microtransactions. If there was ever a time for a player to become a payer, it would be to avoid this dilemma.

Sound Direction:

For our game, we wanted to give players the feeling that they are stranded underground facing the rising threat of the lava chasing behind them. To give this effect, we have all sorts of environmental noises to simulate a crumbling underground cavern, such as distant booms and cracks. Throughout the level you will see runaway minecarts screeching along its metal track, falling debris of rocks, metal crates, and lava filled earth. Putting the player in this environment will create a sense of danger and urgency to really put them on their toes. All these sounds have the same levels of reverb to create a consistent feeling that these sounds are bouncing off of the walls and creating hundreds of sound partials like it would in real life. Some sounds were edited from existing sound libraries and others were field recordings from our sound designer.

The sound and music in our game was implemented using FMOD. This gave us the ability to use game states and parameters to dynamically change the music based on the gameplay. We were able to design it so that all music in the game works from one FMOD event that references all the music tracks. By using parameters and volume automation, we have all the music playing simultaneously but only one track can be heard at a time. When the level changes, the volume of the previous track will lower to an inaudible level and the new track will have its volume increased to be heard. This allows for smooth, seamless music transitions. All music tracks are composed to be the same length and same key, A minor, but contain a different instrumentation to reflect the aesthetic of the level you are playing in.

Methodology / Approach

Design Methodology: Agile and Scrum

In the IU Game Design Program, students are recommended to pitch game ideas so that the staff and students may vote on which idea shows the most promise. These ideas that go through have to make it through a strenuous process where the prototypes we created were judged by industry professionals in a mock "Shark Tank" presentation.

In the beginning, one of our team members had an existing, early prototype. We built from this using an Agile Game Development process. We had to continue to add new mechanics, polish gameplay controls, and update the game's art. With this method, we had to work toward small goals as a team to later refine and polish in the future if we were to make it past Shark Tank. Our team was selected to move forward, and we gained some new team members to help move forward in the development process.

From there, we used a more traditional Scrum methodology to continue moving forward. Every meeting began with a Stand-Up, led by our team's scrum master Jordan. We would go through what work we did, what work we were going to do, and what work we were being blocked on by any other teammates. It was from there that we discussed which changes were the most important that we needed to focus on. We used JIRA to create tasks, estimate and log our work in hours, and then compile our work into burndown charts to see how efficiently our time estimations were and to also see how effective our time spent on tasks was. This kept us organized as a team and always let us know what the most important things were.

Technologies Used

Game Engine: Unity 3D, Unity IAP

Art: Maya, Zbrush, Substance Painter, Substance Designer, Photoshop, Illustrator, Figma

Sound: FMOD, Adobe Audition, Logic, Freesound

Code Software: Visual Studio 2017 for C#, NiceVibrations for Haptics

Team Management: Gitlab, SourceTree, JIRA, Hack n Plan

Builds: Xcode, Android Studio

Documents and Presentations

Comments (0)