Postmortem 💀 – Magnetizer 🧲
0) What is Magnetizer #
It’s a small game that I made for a 3 hour jam. I really liked the core concept and wanted to expand upon it. It was a platformer, but you are a magnet.
I decided to go with a minimalist approach to the gameplay. Essentially there we no other mechanics added to the game.
This meant that what I wanted to do during the next few wees of development was:
– Make the game as juicy as possible
– Create levels that use the core mechanic in a lot of unique ways
– Create a good pacing for the game
– Work on “supplemental” features (saving, high-scores, achievements…)
1) What went right #
I really wanna pat myself on the back here, but I think visual juice* was something that I did a good job with. What was just a block spinning later becoming a loving rectangle that wiggeled and waggled based on the player’s input, squished when it hit a wall and splatted the floor with color when it hit an obstacle.
<figcaption id="caption-attachment-113" class="wp-caption-text">The only “feature” added to the game were optional pickups.</figcaption></figure>
Towards the end of the development I really hit the home run. Thanks to a friends encouragement I added eyes and a mouth to the magnet. While this is recommended even in the classic “juice it or lose it” I didn’t want o do it at first. I didn’t want to “commercialize” the game. I felt like doing that would ruin the minimalist aesthetic of simple
Besides this being juicy visually, I think the core mechanic of the game was really strong and I am happy that I did not succumb to feature creep. Good job me, stay lazy on feature implementation 🙂
*I believe that I could have done a much better job at audio juice as well, however, for my next project I have an audio god on my side so that’s gonna be covered.
2) What went bad #
Online stuff is hard.
When I uploaded the game to itch.io I had a high-score system that used google forms as a “back-end”. It would send data to a google form when a speedrun was completed that would submit it to a spreadsheet.
This spreadsheet was supposed to act as a sort of back-end system for the high-score that the game would pull data from.
This was a solid plan and maybe someone with more programming knowledge would be able to execute on it easily. However, I was f*ing lost. I lost about a week of development time trying to get this work, to no avail.
In the end the itch version linked to the spreadsheet instead of having an in-game high-score. This broke half way through and I don’t know how to fix it. The newgrounds version ended up using their built in highscore system, which worked quite well. Occasionally it reports an impossible time like 10 seconds, no clue how but hey I can manually remove those times so that’s nice.
Level design is also hard. I felt like one of the goals I was not able to achieve was teaching the player how to correctly play the game. From anecdotal evidence, players usually have the most trouble at level 4.
They are required to spin and then, spin again while still using the momentum from the first push, to travel further vertically. This is a core concept of the game that is used in other levels to allow the player to finish the level faster or to reach some of the hearts.
In my anecdotal user testing players completed this level without understanding what they did or they failed to complete the level.
I tried to amend this by introducing level tittles, this one being “Two spins = high jumps”. However, this was really dirty and the level itself didn’t really teach that to the player.
Reflectively, I should have put more of the obstacles that require the same trick to get the player to “get it”.
3) What I’ll do next time #
A few bullet points for myself:
- I will do even more playtesting
- I will spend more time creating levels
- I won’t waste time on high-score systems
- Make sure that my code base won’t be super messy
- Throw away the 3 hour prototype, build it from scratch next time!
Got to the end? Thanks for reading!
Now go play my damn game.
And follow me on twitter 🙂