Get the latest Education e-news
 
  • Postmortem: Rage Runner

    [02.27.14]
    - Jacob Burke
  • Rage Runner is the first major release from Hypercane Studios (that's us!). Rage Runner is a fast-paced 3D obstacle avoidance game where the player hurdles down miles of trench as fast as possible while avoiding obstacles. The levels are hand-crafted (not procedural) and the player is serenaded by some pretty awesome dubstep beats from artists TeknoAXE and Credo.

    Our Vision

    When we created Rage Runner, the goal was to make a very difficult game. We felt that the current generation of gamers have it way too easy. Being from generation X - the days of atari leftovers and nintendo, we wanted Rage Runner to capture the difficulty of the games from our childhood.

    In a nutshell, this meant that when you die, you start at the beginning. To pass a level you actually have to get better at the game. There's no hand-holding in the form of visual cues indicating where to go. We wanted people to rely on quick reactions and memory to beat a level and also wanted to convey a sense of urgency that would provoke the player to higher speeds.

    For replayability, we wanted a sense of true competition within the community facilitated via a highscore server. Lastly we wanted people to be able to be build their own levels in the game using the same level editor that we built the game with.

    Postmortem

    This post-mortem attempts to analyze what went right and what went wrong during the creation process of our first game. We are still new kids on the block in the indie scene and you'll probably notice this from our game and from the content and style of the post-mortem. As there are only two of us, our comments are labeled.

    Developer: Hypercane Studios
    Release Date: March 28, 2013
    Release Platform: OUYA
    Development Engine: ShiVa 3D
    Development Timeline: ~ 6 months
    Team Size: 2


    Jacob - Art, modeling, texturing, level design, marketing


    Zach - Programming, level design

    What Went Right

    Work Style & Being Bros

    Jacob: I have heard the phrase a lot in my life that you "don't mix business with family or friends". I don't think that this phrase could be more wrong. Maybe it has something to do with the profession we have chosen, being in the game industry.

    When making a game, you need constant criticism or your work will never get better. Being brothers we both speak our mind to each other. If Zach doesn't like something I'm doing, he will flat out tell me. If I don't like a mechanic he's made, I'll flat out tell him.

    But we don't just leave it at that, we constantly brainstorm to make things better. Of course we have our disagreements but after some long silences on skype and a quick break, we always work them out. In the end I couldn't be more happy in our choice to partner up to create Hypercane Studios and bring to life our visions we have had since childhood, together.

    Zach: Throughout my career at various companies, there have always been co-workers that I or everyone else knew to be slackers. When your partner comprises 50% of the team, there isn't room for slacking, everyone needs to pull their weight.

    This is going to sound crazy, but based on playing World of Warcraft with my brother on/off for 5 years, I had complete faith in his work style. Jake was guild leader, our guild name was Relentless and we were a solid raiding guild for end-game content. Relentless is definitely the word I'd use to describe Jake.


    We are both pretty hardcore guys that are motivated by failure. We had to be willing to pick up slack on any aspect of the project, even if that meant diving in head-first in a field we had no experience or interest in like marketing.

    Having that backdrop of knowing each other so well also made it easy to vent frustrations. "Dude, this looks like ass" isn't a phrase you might hear in the professional world, but with us it was the beginning of many constructive brainstorming sessions.

    Taking Risks & Hard Release Dates

    Jacob: We turned our attention to Ouya mainly because of the developer contest they put on. We entered the contest expecting that we would not be picked. This was just a good chance to show our work. We made an Ouya level in our game using obstacles to spell out the words OUYA throughout the level (Zach built this level, and it took me roughly 3 hours to beat it).

    To our surprise we were announced the day 5 winners, which we both couldn't believe! Ouya wanted our game to come to their console and were giving us a dev kit to make that happen. This felt like a big compliment that we were headed in the right direction with the game. We also got a lot of dedicated followers out of this that really believed we were making something that they wanted to play.

    Zach: I was developing this game part-time, so getting solid time to spend on it was hard to come by. This usually meant weekends and evenings only. So, sacrificing 8 hours of freedom to enter a contest that you believe you have zero chance of winning really does feel like a waste of time.

    But we did it anyway for the publicity. I think we had 2 retweets on our entry. When we were chosen as winners this gave us a very tangible hard release date of March 9. We picked this date because it was three full weeks before the March 28th market launch.


    Having a solid date sitting in front of us every day was awesome. It was a constant driving force that made us ask the question "What is the #1 priority today so we can release in X days?". I can see how the absence of a release date could cause an indie project to drag on indefinitely.

    Iterative Design & Throwing Stuff Away

    Zach: We used an iterative design process similar to Media Molecule's game jam development style. From a high-level, we knew how we wanted the game to play but to reach that vision we had to play around in the sandbox for quite some time, tweak things, re-write things, throw things away, etc.

    Sometimes you just don't know whether a mechanic is going to be fun or whether an art asset is going to work until you try it out. For instance I remember a few trench textures where they looked great as a still image but looked like a strobe light when in motion.

    One major feature we scrapped was the ship upgrade system. I wrote a ton of code to facilitate this and created a bunch of balanced item stats for various upgrade levels as well. In the end, we decided this was too ambitious so we scrapped the whole feature.


    Being able to look at the project objectively is important. I was attached to the code I wrote, but I knew that tossing it was going to make our core game stronger. Throwing away code can be very liberating and it brought a clearer sense of purpose to the features not yet written.

Comments

comments powered by Disqus

UBM Tech