Grape Escape - Postmortem (Patreon)

“You’re a grape. She’s a grape stomper. You can do the math.”

Grape Escape is my very first fully completed game. I’ve started many game projects before it, but this is the only one I’ve actually concluded and publicly released. It’s a weird feeling working on something for so long and suddenly… not. It’s a bittersweet feeling.

Grape Escape began development on June 26, 2019 -- 6 months before I uploaded the demo to Itchio and created my Patreon. This postmortem is my fond farewell to this project and a reflection on what went right, what went wrong, and what I’ve learned along the way.

What Went Right

In game development, there's an infinite number of possibilities, and thus an infinite number of things that can go wrong. So when something goes right, it feels like Christmas!

One such example from Grape Escape is the upgrade system, specifically the design and balance. This was a rare occasion where upon execution, everything just clicked together -- no upgrades really interfered with another (save for one, which we’ll talk about later); on the contrary, they synergized to make the gameplay much more dynamic and fun! I’d like to take credit for designing it well, but I feel like a large chunk of it came from luck, and I thank that luck every time I look at the upgrades.

One other thing that comes to mind when thinking about what went right is testing. Out of all the hats I’ve had to wear as a solo game developer, I feel that “tester” is by far my most competent. No matter how obscure the issue is, I’m always capable of tracking and pinpointing the problem area (again, with one exception mentioned later). Fixing it is an entirely different issue, though; I’d place that under the “programmer” hat.

When you’re working in a field as complex and expansive as game development, you need to be able to recognize when something goes right, otherwise all the wrongs will begin to wear on you and drain you. I mean, just look at how big the “What Went Wrong” section is compared to this one!

What Went Wrong

I experienced a wide variety of bizarre and outright logic-defying bugs over the course of this project. Some of them I managed to solve in a matter of minutes. Others took me hours and made me think I was going crazy. However, none of them compare to the big one; the one that halted game development for two weeks; the one that I still haven’t solved, but merely swept under the rug.

The purchase bug.

To put it simply: everyone else was having issues with the Upgrade Lab -- the purchase button wasn’t doing anything, and thus none of the upgrades could be purchased. I tested in Unity, with a new build, with the build I released, heck I even tested it on my Mac laptop and every time it worked perfectly! With the help of two dedicated individuals, Egroj and Infinite Kaioken, we finally deduced that overwriting the save file was what was causing the issue.

The “sweep under the rug” solution I had was to have everyone start the game anew every update, but with a “wine care package” included so they can at least buy some upgrades off the bat. It was not an elegant solution, but it did the trick when nothing else would.

Bugs weren’t the only thing to go wrong in the project. There were two design complications I faced, both stemming from the same feature: the dynamic ground.

The first complication was the ground itself. It squishes down into a crater wherever the foot stomps down. Or does it? In actuality, the game just creates a crater object there and turns off the ground collider whenever the grape enters the crater, allowing the grape to fall in. That wasn’t the main problem with it; the problem was the art. With an ever-changing ground, how does one make the goopy texture update with the random crater placements?

I tried a great deal of things, but ended up going with a mask system that operated on hopes and dreams. It’s so complicated and convoluted that it would take me pages to fully explain it. I have yet to see another solution to this problem in a 2D setting.

The other complication is something you probably didn’t think much about: the refill grapes. A bunch of purple grapes that fall from above and land on the ground. What could be complicated about that? Well, with craters that could appear anywhere and all these colliders and trigger volumes that come with them, what the game considers “the ground” becomes a bit of a gray area.

I did a loooot of number tweaking, collider organization, and possibly some deals with the grape devil to make these things fall correctly. And even now they still sometimes don’t!

The moral of this story: 2D dynamic grounds are kinda the worst.

So, we’ve covered what went wrong with bugs, art, and design. However, there’s still one thing left that went wrong with this project -- something so big, that it gets its own section:

The Feature Creep

I have four tiers of game sizes: mini, small, medium, and large. Grape Escape started off as a mini game: simple mechanics, quick one-and-done gameplay, and a scope of about 1-3 months. As time marched on, I forgot about the simplicity of Grape Escape and gradually kept adding more and more features -- feature creep.

In its final form, I’d chalk Grape Escape to being a mini game presented as a medium game; its gameplay is simple and repetitive, yet its outlying features -- upgrades, CGs, different modes, and even a friggin’ ending cinematic -- all significantly increased the amount of time and work required to finish it.

Do I regret it? Absolutely not. Grape Escape turned out almost exactly as I envisioned it when I was first writing out the design document which is just an incredible feeling! With that said, I don’t ever want to do that again. I need to be very careful to keep the entire game within the scope of its intended size, otherwise 1-3 months turns into 25 months. 25 months of development for such a simple game… It’s still crazy to think about that!

Near the end of Grape Escape, I decided to embrace the feature creep. I decided to create a mini game within this supposed mini game. I called it “Break Time.”

I made it in part because I wanted to fulfill my full vision of the game, but also as a test; a test to see if I could make a mini game quickly. And you know what? 11 weeks isn’t half bad, especially considering that I was working on other features of Grape Escape alongside it, like the upgrade drawings.

Break Time is the ideal size of a mini game -- quick, to the point, can be replayed as much or as little as the player wants, and most importantly (to me), it can be made quickly. That is the entire point of my mini game category, after all.

The Ups and Downs of Solo Development

Solo game development is rough. It forces you to either create or find every single asset that you need in every aspect of the game, and then know how to implement them. It’s difficult, exhausting, and a lot of the time downright frustrating. But the feeling of catharsis and joy of finishing and releasing it is unmatched by anything I’ve ever done before.

Developing Grape Escape by myself has taught me more than my university game design course ever could. Every little thing that went wrong was a lesson and every little thing that went right was a reinforcement of what I knew. However, even if you’re the smartest person alive, it means nothing if you don’t actually put in the work.

In the beginning, back before Grape Escape even had its name, I did maybe one thing on my to-do list each week. Lethargy was my biggest opposition. Over time, however, thanks to the motivation I received from Patreon (a combination of positive motivation and utter fear of disappointing others), I managed to get into a rhythm. It was rare that I finished fewer than three things on my to do list each week, and many times I finished around ten! Even to this day, my work ethic is improving more and more, and it makes me genuinely proud of myself for making it this far.

I owe all of you for that. Seriously, thank you for believing in me. Thank you for even being here, reading this. It means the world to me!

What the Future Holds

Grape Escape is the first of many, many ideas I have running around in my head (and in an “ideas” document that’s 32 pages long and counting). It’s vitally important that I take the lessons I’ve learned thus far and apply them in the future.

The biggest lesson I’ve taken away is to avoid feature creep. From now on, mini games will be finished in a matter of months, not years. They’ll be simple but as fun as I can make them.

On a more technical note, I plan to make the change from Unity to Godot for a number of reasons, including but not limited to Unity slowly starting to hate me and everything I stand for. Also it takes absolutely forever to open. This switch will not be easy or quick for me, but I think for 2D games it’ll be for the best. Only time will tell, I suppose!

And with that, it’s time to conclude this postmortem and say my final goodbye to Grape Escape. It’s been a wild ride, especially for my first official game! All things must eventually end to keep everything else moving forward.

I’ll see you guys next game!

PS: If you'd like to see just how much work went into Grape Escape, attached is a "Weekly Progress" Notepad file. Starting halfway through 1.4, I documented everything I did each week. Give it a read if you want to! :)