Pumpkin Popper Post Mortem

First screenshot in game. Placeholder of players

At the beginning of October, whilst in the middle of a larger project, I decided to create a short Halloween project. Small in scope, lasting only the month of October. Enter Pumpkin Popper! A single-player arcade game where you smash pumpkins for a high score.

Mainly this project was created to give myself a confidence boost. I have been working on longer projects for a while and this was a refreshing break from that. A project of this small size and scope also allowed me to refresh all the skills that I've learned during my years of Game development (except for Audio stuff, there is still a lot to learn on that front). In this post mortem I will highlight the things I thought went good or bad, and then elaborate on those thoughts.

I hope you enjoy!

Planning

The planning for this project was very much akin to what I did during my studies, if not better, which is why I am mentioning it here. I can’t remember ever having a better planning structure than I did during this project.

First off I had a Hack’n’Plan (HNP) page up and running, where I constantly updated and tracked my tasks. It helped me stay on top of my work and let me keep track of how long I worked on my game. Pumpkin Popper, for example, took a total of 30 hours and 45 minutes over the course of a month to make.

Second, I had a google sheet with a schedule that showed what I wanted to get done each day. Technically HNP does have a similar thing where you can set dates and deadlines for tasks, but I needed something more visual, so I did one up myself. This way of keeping track of my days made it a lot easier to plan my weeks and what content I actually have time to fit in the game (more on this below).

The reason for why this worked so well for me is because I’ve figured out that visual elements help me a TON when making things. I already knew that I need schedules and deadlines, but for this project they worked extra well when mixing in bright colours, showing me clearly what I need to do, what is done, and what isn’t.

For future projects I want to try and find a way to make this structure even better. Perhaps using tools in real life such as post it notes or whiteboards. The important thing is that I can change and move around tasks quickly, so I can stay on top of what I am doing. If I cannot find a way to do this, I will stick to what I did during this project closely, as I believe it was a big part of my success with this project.

Decision making

First off on the list of things that went really well is my decision making. During a lot of times over the course of the project I had to cut various things out of the project, and make decisions on what to keep and what not to keep.

The first major decision I made was the player count. Initially, the game was supposed to have local multiplayer for 4 players. I actually got fairly far in making that work. I had a system that created all the players, and split screen worked fine. One major issue with this though was that I did not have 4 controllers to test with, but I did have 2, so after a little while I decided to instead switch to 2 players, using my steam controller to test player 2. The problem with THAT, however, is that the steam controller acts as the keyboard (which player 1 was using). In the end I kept putting solving that in the backlog, prioritizing other things over it, and eventually I made the decision to keep this game single player.

The second major decision was perhaps the one I regret the most. It was the decision to not include an Options menu. The main reason this was my decision was because I realized way too late that I needed one. I realized this one week before the project was set to release, and at that point I had a lot to do, so after trying to make it fit in my schedule, I eventually decided to not include it at all for this project.

One of the smaller decisions I made was to not include an announcer. Originally I had a bunch of voice lines recorded (yes, by me) that was supposed to be a quirky announcer to let the player know how much time was left or just make comments about the game. I wasn’t very happy with the audio quality as I only had a headset as a microphone, and decided to leave it out.

I would say that the reason that it felt like the decision making was one of my strongest points during this project is because I wasn’t afraid to cut things I would have wanted to keep, and because I always took my planned schedule and scope of the game into consideration before making a decision. I always tried to fit the task in my schedule, and If I just couldn’t make it work I decided to cut it. For future projects I will always try to keep this process of elimination going. Always taking the schedule and scope into account, and try to fit it in before making a decision.

Brave New Waters

During the development of Pumpkin Popper I had to work on a bunch of things I’ve never done (or done very little of) before. Some of it was nervous and slightly scary, as I wasn’t sure how it would affect my gameplay if I failed to implement it. Below is a small list of the things I never tried before:

Multiplayer

Even though this failed, I am proud to have tried. If I had had the tools to continue working with it, maybe it would have been in the game at this point. There was a lot of extra thought that went in to how the game should work just by adding one extra player, so in the end I definitely saved time by skipping multiplayer.

UE4 Release

During the years since I finished my studies (that were mainly in Unity) I’ve pretty much only worked with Unreal Engine 4 through projects at work. I’ve made a few prototypes in UE4 before, but never fully released one. It was exhilarating to check out how UE4 handles building and packaging a game, although I was extremely disappointed that UE4 can’t build on Mac unless you’re on a Mac OS. It felt a bit strange since Unity can do it, why can’t UE4?

Part of working with UE4 came how they handle save game and local files. In a way it felt pretty much like handling save games in Unity C#, just taking different steps. But as usual, UE4’s way of doing it FELT easier because it was more visual than looking at lines of code. In the end I did have a working local save system that worked, and that felt very good.

Multikills

I’ve done plenty of games that handle smashing opponents for points, but I’ve never handled moments where maybe you smash more than one at once. Like a combo system. Pumpkin Popper was the first of my games that included a “multikill” system. I didn’t have time to flesh it out as much as I wanted, but you get more points on double kills, and audio cues and visual effects plus more points on triple kills.

Animations

Following up from the past topic, I also believe that this game was the first to include around 99% of my work. The two songs weren’t mine. However every model, animation, texture, particle effect and so on was made by me, which is kind of daunting when I think back on it. Usually I’ve borrowed animations or models from somewhere else. Audio specifically, because I cannot for the life of me make music (I’ve tried).

Voice Acting

If you can call screaming in a headset voice acting, I did it. It was odd, but after pitching up and editing a little, I think it came out alright. However before I do this again, I need a better microphone as you can clearly hear the crappy quality at times. There were also some voice-lines that I cut from the game. Some form of announcer type voice that would let you know when a round started and shout “Triple Kill” and all of that. I thought it sounded alright, but I just wasn’t ready to release my own voice like that in a game just yet. Maybe for next time.

It’s no secret that trying new things makes us learn, and I learned a whole lot from the above mentioned things. It’s safe to say I’ll use what I learned to make my next projects a lot better. I will try for those projects to not be afraid of trying new things. Most of the above mentioned tasks I was ready to throw in the trash bin if they took too long, and I think that is a good strategy. Try new things, and if you don’t have time to learn or fix it, put it in the backlog for later. Some things may be worth spending a bit of extra time on, even if you have to cut something later on.

Scope

There was only really one thing I felt went bad, granted it was a very important thing. The Scope. It was a tad too big for someone with a full time job and only 2-3 hours per day to work. This resulted in me working nearly every day for a month. During this month there was one day where I didn’t work on the game, the rest of the days I worked for at least one hour.

The main reason for the scope was that I came up with the project too late. I realized I wanted to do a Halloween game right before the 1st of October. So I had to kind of rush the game a little. I’ve been told that I should’ve pushed up the deadline, which I did, but I couldn’t push it past Halloween because that was the whole point of the project. To release in time for the holidays. Yes, I had time to complete the project and it looks good, but as I’ve mentioned I had to cut some important things that would’ve made the game better, such as multiplayer and an options menu. Scope is almost always a difficult thing to sort out, but it is definitely easier when you can plan a project before you start working on it, which wasn’t the case for me.

While I believe that this was a one-time thing, I’ll definitely make sure to plan before I start working in the future. That way I can make and set priorities and must-haves like for example an options menu, or localization, or most importantly, rest. Because I found myself short on time, I gave up on rest days, which thankfully didn’t affect me too hard during this project. However I have dipped my toes in burnout territory before because of this issue before, and it is not a place I want to return to.

Not working alone is another thing that can greatly help with scope. I could’ve contacted any game field friends to for example do the audio and music for me instead of me spending 2 days working on it and it still ended up mediocre. However I did feel like the deadlines would be way too short for anyone I contacted, so I also decided against that for this time.

Final Thoughts

Pumpkin Popper was a game made to boost my confidence in making and releasing games, and also to refresh my skills on everything I’ve learned during the years of game development. This was the first game I’ve released since coming home from my studies in Australia over a year ago, and it felt good to keep contributing. A lot of things have happened since I got home, but I've managed to stay with my field of game development, and have started to work on a bigger project that gained some interest by some investors. In due time, you will know this project.

And with that, I conclude my post mortem.

Thank you very much for reading this post, and I hope that some of it may even help for some of you. Have a good one!

Final screenshot of game in current state