Postmortem: The Ramp

Author: by Paul Schnepf

Game: The Ramp
Developer: Hyperparadise
Publisher: Hyperparadise
Release Date: 03/08/2021
Platforms: Steam
Number of Developers: 1
Length of Development: 8 months
Development Tools: Unity, Blender + substance painter for 3D assets as well as Cubase for audio

Introduction

I was eight years old when everything I wanted from life culminated in a single wish: A skateboard for Christmas. The weeks before I had gotten my hands on the Tony Hawk's Pro Skater 4 demo and was pestering my parents to get me a skateboard. 18 years later I still dearly love both video games and skateboarding.

It took me a while to discover that making games can actually be a career, though. Ever since I did, taking my own shot at creating a skateboarding game has been a dream of mine. After Superflight (2017) and Islanders (2019), The Ramp was the third game I shipped and the first one I worked on entirely alone. Naturally, this presented a whole new set of challenges. In the following postmortem, I'd like to share some of my struggles and learnings from the development of The Ramp with you.

Actually finishing the game

Working on something alone is tough. There is no one holding you accountable for anything, no one to accompany you through the dry spells, no one to share all the ups and downs with. The greatest threat to any solo project is simply losing the will to finish it. At least, that's what derailed the last 20 prototypes I had been working on.

With The Ramp it was no different. Starting out as a healthily scoped project in November 2020 ("This will be just about skating a halfpipe and having fun") it didn't take long until feature creep ("There will be 25 levels and a level editor and unlockable gear and so much more") brought me to quitting in April 2021. I just couldn't stand it anymore. There was this massive pile of work in front of me, and spending the next two years conquering it was just too much. I wasn't up for it, and as always, I also had a fancy new idea simmering away that was going to be infinitely better.

It took my buddies Jonas and Friedemann, with whom I created Islanders at Grizzly Games, talking me into giving The Ramp another shot -- and they were right to do so. The foundation of the game was already 90 percent done, and it would've been crazy to scrap all that. Then I figured, the only way I'll ever finish this (or any other game for that matter) was to cut absolutely everything that wasn't core to the experience. I went hardcore minimalist. Every feature that wasn't contributing to the original vision of the game, which was capturing the flow of halfpipe skateboarding, got axed. In the end it was just going to be four levels, a unique jumping mechanic and some chill tunes. Those were the bare minimum requirements to make it a viable product. Better done, than perfect.

Next I set the most ambitious release date I could imagine without having to crunch. August 3, 2021, seemed to be doable. It left me with four months to complete the game. My birthday is also on August 10, so releasing my first solo project before turning 26 was a nice bonus. Switching from over two years of estimated development to a release date that felt in reach changed everything. It was hugely motivating. I made sure to immediately announce that release date "officially" and create a Steam page, if only to make it harder for myself to cop out again. Having at least some people looking forward to the release was fun. The strict timeline also allowed for better planning and a more efficient work schedule.

Looking back now, restraining the development time of The Ramp to only eight months was most likely the best decision I made during production. In the end, those constraints led to a very unique take on the skateboarding genre. More importantly, it allowed me to gently dip my toes into the water of solo game development. Seeing that I was able to actually complete a game on my own, I'm now comfortable taking on (slightly) bigger projects in the future.

Finding a healthy work routine

Maintaining a healthy work-life balance is crucial to long term success, but as an indie developer I often find myself struggling with this. It's not only that your income is directly based on your project's success, but that success is often connected to self worth. That notion alone often stresses me out to such a degree that I can't think of anything other than work whenever I have some down time. Occasionally the opposite is true, and there are times when I get so immersed in a project it becomes difficult to pull myself away -- which can be equally unhealthy if it becomes the norm.

As I developed The Ramp, not having to coordinate with a wider team meant I was constantly experimenting with my work schedule and habits. My overall goal was to maximize my creative output without sacrificing my health or any other aspects of my life. Oh, and it was supposed to be fun of course.

Evaluating my work routine after having finished the project, I have to say I'm quite happy with how things turned out. It might surprise some of you, but except for some days right before the release, I rarely worked more than six hours a day. To be honest, most of the time it was probably more like three to four hours, and over some periods even as little as 90 minutes each day. 

In the beginning, that was actually born out of necessity. When I started working on the project I would commit as much time as I humanly could. Sometimes that would mean working over eight hours per day. After a few weeks, however, I moved apartment and suddenly my days were filled with non game dev chores. I had become more organized, so I usually couldn't spent more than 90 minutes working on The Ramp each day. I still tried to make the most of the short time I had, and I was shocked to see that in 1.5 hours of focused work I made almost the same progress as I did in a "full day of work." That schedule also meant I was super excited to revisit the project each day, instead of exhausted when my working day was over.

During production I started reading a book called 'Daily Routines' by Mason Currey. In the book he summarizes the daily routines of artists, scientists and other creative people, and while there is the occasional person working 24/7 -- relying on amphetamines and whatnot -- the majority of people in the book worked between three to five hours a day. Some of them even restricted their schedule so they'd leave work on a high note and be full of motivation when starting again the next day. I was intrigued by that concept and continued experimenting with my schedule, leading to the following realizations.

I usually don't have more than three to four hours of productive work in me each day. When on a creatively demanding task it's even less. If I work longer days, I tend to make busy work for myself and procrastinate, and can sometimes make stupid mistakes that will need correcting the next day.  I also found that I'm most productive in the morning and evening, so I often did a 90 minute work session before breakfast -- before going to run errands, meet friends and relax -- followed by another 90 minute session after dinner.

Every now and then I just didn't feel like working at all. What I usually did during those moments was give it a try anyway for 20 minutes. Sometimes this spurred me on, but if I still wasn't feeling right I knew I needed to take some time off. I also mostly ignored weekends, working Sundays and relaxing Wednesdays when I felt like it. I could have been more productive in terms of hours worked had I stuck with a more disciplined schedule, but I figured it made more sense to adapt my routine to my natural rhythm. That might've meant I cut a few features here and there, but I don't think it hurt the final product, and it was almost certainly better for my mental and physical health. 

Creating a supportive environment

There are many parts of our environments that can't be influenced, and some people are inherently more privileged than others. I have been blessed to have many very generous people around me in my life. Nevertheless I took some active steps towards creating an environment that supported my efforts during the development of The Ramp. I suppose the smaller your team is, the more important it gets to find those kinds of structures somewhere else. Even, or especially, when working alone. For instance, I can't stress enough how important it was for me to share my work with other people on a regular basis. Not only do you get some very valuable feedback, it also really helped me establish a clearer vision of my product.

In the beginning I was very anxious about showing my work to others. Somehow it's different when working on a personal project, because it feels like giving away a piece of yourself. I've already mentioned Friedemann and Jonas above. Ever since we worked together on Islanders we kept on chatting once a week to see whether there was anything related to the game demanding our attention, but also to share what else we've been working on. That was an invaluable way to regularly get some casual feedback from people I felt comfortable around.

When I became more confident in the project, sharing my progress on Twitter seemed like a natural way to get more people involved -- especially during a pandemic. I had been on a social media break the year before, so I started with a new account and zero followers. It was really fun. Interacting with folks I was potentially making the game for gave everything I worked on a little more meaning. Putting out GIFs and screenshots on Twitter also had the positive side effect of pushing The Ramp's aesthetics in an appealing direction, something I probably wouldn't have focused on that much as a solo developer. It also helped when it came to marketing the game. Besides all of that, I also met a lot of amazing and kind people on Twitter.

Another thing I did was enroll in the System Design master's program at HTW Berlin. I'd already completed my bachelors program there before, where I also worked on Superflight and Islanders. The System Design Master gave me the freedom to continue working on The Ramp as part of the program, but it also gave me some much needed structure. I regularly had to present my work to professors and fellow students, which provided me with extremely helpful feedback.

The last building block was my collaboration with indie game marketing agency, futurefriends. They supported me with PR throughout launch, and that was such a relief. I'm not a big marketing guy anyway, but ahead of launch I was all hands on deck finishing and polishing the game. Having other people step in to carry some of the mental load that comes with publishing a game was incredibly helpful.

Losing sight of scope

Originally The Ramp was meant to be a one-month mini project. After deciding to devote (a little) more time to it, I quickly succumbed to feature creep. Avoiding that would've saved me countless hours and a more than a few headaches.

I can't really pinpoint when the original vision of the project started eroding, but working on it as a solo developer was almost certainly one of the causes. On my previous projects, having a team that would agree on an initial scope helped keep things in check. When working alone, however, it's tempting to skip some of those steps and rush straight into developing features you're personally hyped about. Normally, you'd usually have to justify new ideas to your team, and without that feedback loop it can be difficult to get an unbiased perspective.

That said, being able to move quickly has its advantages too. It allowed me to create a game that felt very personal, and it's nice not having to spend countless hours discussing each decision. I still wish I could have found a better way to restrain myself when it came to decision making, especially when those decisions could have a huge impact on the project. I did try and implement some rules for myself -- such as having to wait for two days before committing to a feature or forcing myself to discuss it with another person -- but to be honest none of those really worked for me.

Playtest early, playtest often

Being afraid people wouldn't like The Ramp kept me from playtesting enough during early development. I relied too much on my own impressions and observations from a couple of friends who were already familiar with the prototype. When I then had complete strangers play the game for the first time, I was shocked by how difficult they found it. It turns out I'd been making the game increasingly difficult during development because I was getting better at it. People were actually calling The Ramp the "Dark Souls of skateboarding games" at that time.

It was a pretty terrible outcome given The Ramp was supposed to be a relaxing experience,  so I had to rebalance pretty much the whole game near the end of the development, which was quite stressful. That then meant I didn't have enough time to properly evaluate the new difficulty curve. Had I extensively playtested the game from the beginning, I would have noticed the need for a comprehensible tutorial earlier and implementing it would have been a lot easier.

Besides making development harder, my initial aversion to playtesting likely meant I missed out on some great feedback during those early stages of development, which again could've helped shape The Ramp for the better.

Unstructured work means time wasted

There were points during development where I often just worked on whatever came to mind, particularly at the early stages of the project. But even when priorities became a bit more obvious later in development, I could rarely muster the discipline to carefully map out the next steps. I have mixed feelings about that. On one hand, I wouldn't have wanted to lose the freedom to just work on whatever was most exciting at the moment. That was one of the best parts of being a solo dev. On the other hand, however, putting together a production plan would've probably saved me about a month of work in total.

It's hard to say how an ideal process would have looked, though. In some ways, I feel like the work that eventually went to "waste" still shaped the product. As I've mentioned already, I had my difficulty adhering to most of the rules I made up for myself. What always helped me was being forced to explain my thoughts to other people. I often had important realizations either during the weekly Grizzly Games chat or whenever I had to present the current state of the project at university. I guess having to justify one's ideas to others automatically brings you back in touch with reality.

So, I suppose what might be more efficient than making up artificial rules would be looking for people to bounce ideas off, ideally in a more structured way than just posting some progress updates on Twitter. How about the idea of a development buddy? Perhaps there is someone among your friends who's also working on a project solo? How about the two of you get together for a quick chat every Monday, explaining to each other what you want to achieve this week (and how you plan to do so), and every Friday to draw a conclusion from that week's efforts. I can imagine that would be a good way to hold myself accountable, without taking the fun out of it.

Conclusion

There were many ups and downs, but in the end what made The Ramp an overall success for me comes down to two important points: First was maintaining a small scope. Like really small. So small indeed, that it might even feel too small -- it will be a lot of work anyway, and trust me, it's not like you're going to suddenly run out of problems. The second goes hand-in-hand with the first: Not enslaving myself to the project. The decision to prioritize mental health, friends, family, and fun, before seeing where The Ramp could fit alongside all of those -- instead of doing it the other way around -- is what kept me sane. 

In the end, I developed and released a skateboarding video game while still ensuring I had enough time to go skateboarding myself -- eight year old me would be very happy with that.