Tag: game-design

Magnetizer Postmortem 💀

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.

The only “feature” added to the game were optional pickups.

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

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 🙂

Making games in 3 (+3) hours

During the last month I challenged myself to get better at prototyping games. To do this I decided to enter a gamejam every week – the jam I chose is Trijam, a 3 hour game jam. I’ve noticed that I developed some interesting patterns during these jams and I will discuss these here.

Sketching out ideas is how I start

Sketching out ideas is the way I start my designs

Let me preface this that the structure of Trijam allows you to do “some” parts of the work outside of the allocated 3 hours. This primarily includes brainstorming ideas so usually I come into the 3 hours having a good idea knowing what I want to make. However, I do try to keep the brainstorming time limited to a span of 1 hour and I primarily try to look for inspiration outside of games. I do this as I try to avoid doing the “easy” 3 hour prototypes that don’t really differ from each other – endless runners, top down shooters these are the most common of Trijam entries.

Bare basics

Because of the 3 hour time limit I am forced to strip the game to it’s very core idea. This means that any sort of “extras” and “variety” is stripped away. Does your game include different “extrapolations of clicking”? That’s not going to be included in the prototype. Is there a randomly generated level in the game idea? That is not going to be in the prototype.

Variety makes games fun, without them they would be dull – I mean imagine if you could only pick between 5 champions in league of legends or play only with one gun in CS:GO. It would not be nearly as interesting as it is right now. However these are 3 hour games and the goal that I have here is to create a GAME and not a system! I understand that 3 hours might be enough to code 3 quick variations of an enemy or a system that generates a level – however it is not enough time (at least for me) to do that and make a GAME.

Basic gameplay for heal the peasants was programmed in 1 hour. It just pressing the right button, not the right combination, there is no “holding” buttons just one button.

Core mechanics of my 3 hour games:

Heal the Peasants – Press the correct button to heal the peasant, pressing the incorrect button wounds him.

A cozy storm – Point and click on objects to get descriptions of them.

Bomb the gum – Turn based movement with bombs that destroy their surrounding.

The Night Shift Cycle: Reach the end of the map however you only see things when you move.

Six Waves: Tower defence where you need to defeat 6 waves of enemies.

Late Time: An evil twin mirrors your moves with a delay. Kill him without killing yourself.

Making Games

The reason why I am capitalizing “GAME” in the previous paragraph is that I am trying to create a full game prototype. So something that you play and feel like it is actually a game, with some sounds, graphics with some juice.  This is why usually I try to limit myself to 1-2 hours of programming and the remaining time being dedicated to polish. Fig. 1 has the exact same gameplay that Heal the Peasants had in the end, however it does not feel as much of a game as it did at the end of the jam.

The good

The best part about this is that every weekend I end up with a working (for the most part) prototype for a game that tries to capture some form of vibe. It allows me to experiment with some mechanics and it is visibly making me better at quickly prototyping games. I (almost) always get something tangible at the end of the 3 hour cycle and I feel like I am always impressed by the amount of things one can do in 3 hours if you plan correctly.

When I really enjoy a game and feel like I have a good groundwork I usually spend 2-3 more hours the next day making the game feel better. Just small, juicy changes.

A bit of parctiles go a long way

Adding a bit of particles and smoother UI transitions made Cosy Storm a bit more cosy.

Interestingly enough, I feel like I started valuing sound and music inside of games a lot more since starting to participate in Tri jam. Having a game with sound makes it feel a lot more like a game and music is key to creating a good atmosphere. I usually use SFXR to create quick sound effects and when I’m set on the theme I try to spend some time on the Newgrounds music portal to find a song that would help “sell” the game.

The bad

While this definitely made me push myself in prototyping speed one thing that I became a bit more afraid of is trying out completely new concepts. This is the most apparent when I try coding something completely new because OBVIOUSLY it is going to be way worse than something I already

No cycling was done that night

know. With The Night Cycle I ran (cycled?) in a bunch of bugs which caused me to not have a working game in the end.


While Late Time managed to be exported in the end I wouldn’t necessarily say it is a stellar game considering I spent 2+ hours working on a mirroring system that did not end up working.


The results

After 6 weeks of active participation in Trijam I am more than happy with the results. I’ve became much more swift at transforming ideas into code and  I’m more confident in my abilities to actually code a game into existence. I’m looking forward to attending more Trijams – they have become a good habit that I look forward to over the weekend. I would encourage you to do the same and if you wanna see some of my results go ahead.

The games: