Project Evaluation

Hello! 

This blog post is a post-mortem of a personal project I’ve been working on since around September 2020, called Jumpy Jumpy Life.

The first version of the game - which should be considered a vertical slice - is playable here on itch.io. If you don’t know anything about the game, I’d love you to have a play before reading further - it’s only around ten minutes long - as the rest of this will involve heavy spoilers.

Don’t want to?

That’s ok. I’ll summarise the concept: Jumpy Jumpy Life starts off looking exactly like any other hypercasual game. You are a ball, you jump through an endless, increasingly difficulty 3D level of platforms and hoops, swiping left and right to get as far as you can without falling off.

After a few fails comes the twist: the next time you miss a platform you find yourself continuing to fall, down past the level, through the void and into a “backstage” area - Jumpy’s workplace. You move through the office for a chat with your boss, make the tedious drive home, and go through mundane conversation and chores until bedtime.

The end of the day is the end of the current demo, and is the first of the three planned chapters.

I started building the game something of an impulse, and it turned into my first serious attempt at a solo project in Unity. Having hit the first chapter milestone, I’m now taking the chance to step back from the project to reflect on learnings and, most importantly, evaluate whether to continue development.

Coding was a big learning curve

Although I’ve been building game prototypes and websites for the best part of twenty years, I’m definitely a self-taught hobbyist rather than a professional when it comes to programming. I knew there were significant gaps in my knowledge, but there were also things that caught me out unexpectedly. Like the jumping mechanic - I thought this could be done in a simple, physics based way, but had to rewrite it a couple of times and in the end had to learn about lerping to make it work. Through the project, I picked up a lot of new knowledge like this, but of course each one comes with a time cost.

By far, the biggest thing I didn’t know was how to structure code. And I didn’t know that I didn’t know. I did know that things should be self contained, and started off well, but as the project got more complex the combination of lack of planning and lack of experience led to disorganised, fragile code. Which of course, adds to the time cost in bug fixing.

I actually still don’t know how to structure a project of this nature, and my most important next step is to read up on the subject and potentially refactor certain sections of the code as an exercise. That said, there are some elements I’m pleased with and plan to pull out to keep in my personal library for future projects.

It never stopped being a prototype

I mentioned lack of planning, but actually the development process has been quite organised, and I will 100% continue the habit of keeping a log in Google Docs and maintaining a Trello board for future projects.

But there was almost zero planning of the code itself as I let the project drift seamlessly from “I’ll fiddle about with this for a few days” into “I’m making this for real”. In fact, I fully expected to tinker with the idea for less then a week then drop it - and that was five months ago. When I passed that initial week, I should have stopped to evaluate my technical approach and make sure I had an idea of the structure.

Why didn’t I take prototyping seriously? I have three factors:

1. It seemed straightforward

I had a storyboard, I knew what elements were needed and I could see how to make each one of them. I made the mistake of thinking that a short, linear experience that was simple on the surface would also be simple underneath, and that was all the plan I needed.

1. Too many interactions

In hindsight, that storyboard was never a suitable idea for a quick prototype. While the jumping section itself is a single mechanic, the rest of the game is made up of small, bespoke interactions that are individually simple, but each take time to build. I severely underestimated the effort of making each one work and, even more, connecting them together seamlessly.

1. I just didn’t want to

The freedom to poke about and build something at my own speed, without having to answer to any deadlines or project process, was a big motivation for me at that stage. And initially, that was great - but it wasn’t necessarily sustainable, and after a while of slower-than-expected progress it felt less like an idea that was worth this amount of effort.

Too much code, not enough game

Overall, the nature of the game isn’t scalable. I didn’t design it with my usual ethos of a building a simple mechanic and then expanding it - I had the idea for the twist, and then designed multiple bespoke interactions that I felt added to the narrative. In terms of gameplay time vs amount of code, it’s very poor bang for buck.

I can think of other ways I could have more easily achieved the same effect and in hindsight, evaluating different options early on would have led to easier development. The “behind the scenes” section could have been much simpler if I’d started with one mechanic - such as basic point and click - and found creative ways to use it to tell the story. In short, if I had given myself clear design constraints to keep scope small.

With all that said, I’m proud of what I’ve been able to create and the project has been hugely valuable for learning, even if I did bite off a little more than I could chew for a first solo project.

What I’ll do to help my next project:

Small but scalable, mechanics-first ideas

In a sense, I’m not surprised that I got drawn to an idea that wasn’t based on a single, simple interaction mechanic. Many of the concepts I’ve created for personal projects over the last few years have been founded in a curiosity about game genres outside of my usual remit, such as simulation or idle games. But if my goal is to ship something playable in a short time, I need to choose wisely in order to minimise risk.

Timeboxed exploration

Though it’s counterintuitive, I think having multiple projects to explore actually makes this easier. When I have other ideas I’m itching to work on, I’m less likely to get stuck on any one of them, and it also means I can build multiple prototypes then evaluate which is most suitable to continue.

Learn stuff

I’ve got a clearer list of things that will help me most with my next project, and taking some time out to research and play around with those properly will hopefully help me build a more robust game next time around.

Technical planning

Similarly, I need to take the time early on to really understand the technical challenges of a project, which should be easier now that I’ve refreshed my familiarity with Unity. This will help me identify those areas that are outside my knowledge base and prioritise figuring those out before diving too deep.

Keep using Unity Asset Store

I couldn’t have made this project without the Asset Store and other free online resources, and it’s something I’ll continue to lean on to avoid getting overwhelmed by asset creation in the early stages.

The most valuable thing I’ve gained is the confidence in myself and the knowledge that I can build games on my own - and that's the main thing I'll be taking forward!