LÖVE Jam 2019 - Speed it up!

A few weeks ago, I participated in my first game jam - LÖVE Jam 2019. It is basically a hackathon for video games! All the participants have 3 days to create a game using the LÖVE framework, and the optional theme is ‘friction’. It was a lot of fun for me, and I wanted to share some of the stuff I learnt during the game jam.

I wanted to quickly mention that I am still relatively new, so take what I am about to say with a grain of salt.

  1. Tips & Tricks
  2. My game & Level design
  3. Game issues & How I plan to tackle them
  4. Closing thought

Tips & Tricks

1) Plan ahead

If there is a theme and it was given before the game jam begins, you can start early by thinking about what game you wanted to create. Once that is decided, start looking for some libraries or tools that can speed up your game development process and learn how to use them (do read the rule to check if libraries are allowed)! Optionally, search for similar games and try to think about what makes them fun. Study their formula and design choices, then try to incorporate them while you make your game. Finally, I found it helpful to list down the things I want to implement in a to-do-lists prior to the game jam.

2) Simple is better sometimes

Since there is a limited amount of time, try to make something you know you can complete. A fun game does not have to be big and complicated. Making smaller game will also give you more time to refine the gameplay, sound, graphic, etc.

3) Team up with someone

Having more people to make a game together is usually better! Exchanging idea and giving feedback to each other can all lead to a better game. Having a team also means more people to playtest which is a vital part of game development. Plus, it allows us to focus on doing what we are good at. A solo participant will have to do the art, sound, and programming all by themselves which can be time-consuming.

My game & Level design

Quick playthrough

So here is the game I made during the game jam - Speed it up! It is a challenging platformer with a small twist - the player can move faster but the objects around will move faster as well. Each object has a different speed up rate, so players will have to speed up/slow down depending on the situation.

Link to the game page

I think it is a good idea to talk about each level before I start talking about the game’s issues. Most of these levels are designed with the speed up mechanic in mind, and I tried to provide something different with each level. I will briefly go through the purpose of each level and how it can be improved.

Level 1
Level 1

Level 1
This is actually the first level I made and it was used to test the movement, collision, obstacle, etc. It ended up being a level that can only be solved if the player speeds up after jumping. This level immediately shows the player that the obstacles will speed up together with them, which is the main reason I decided to keep it even though it is just a test level. But I realized this was a mistake later on as it was simply too difficult, and I should have moved this level to later stages.

Level 2
Level 2

Level 2
Speeding up allows the player to jump further away, and the goal of this level is to demonstrate that to the player. The player gets a chance to learn this mechanic on this level as it is impossible to make the jump without speeding up.

Level 3
Level 3

Level 3
After speeding up for two levels, I wanted to make a level where the player would have to stop speeding up and navigate the level carefully. But after some thought, I think this level is not very well designed and let me explain why. Many good platformers allow the players to go as fast as they want (especially for people who wanted to do speedrun), and purposely slowing the player down might make them feel unsatisfied, and this level does exactly that.

Level 4
Level 4

Level 4
This is easily the hardest level in the game. In this level, I want to showcase obstacles have different speed up rate and going slow sometimes might be a better choice. This first part of the level requires the player to speed up all the way to clear it, while the second part does the opposite (walking only). And the final part can be cleared by walking for the first half, then speeding up and jumping near the end.

One of the reasons this level is so difficult is that the player can never see when the spikes are coming up. I could have rendered the spikes on top of the tiles to make it more obvious. In addition, I think the last part of the level definitely needed some more refinement. It is quite unreasonable to expect the player would figure out the solution without any help.

Level 5
Level 5

Level 5
This is a level I made by “accident”. While I was designing the levels, I noticed that if the spike has a height of two, the player would have to jump and wait until they reach the max height before pressing right. Most players would most likely start by pressing jump and right at the same time, and discover that it won’t work. But after a few trial and error, they should be able to figure out the trick and finish it. I thought it would be kinda fun to include it as the final level.

Game issues & How I plan to tackle them

When the game jam ended, all the participants can download the games and try it out. After that, they can give a rating or leave a comment if they wanted to. This is easily the most exciting part as I get to collect the player feedbacks, and learn how I can improve! So here are a few things that I learnt about my game:

1) Difficulty

The number one feedback I got is that the game is too difficult. I didn’t realize this while designing the levels mostly because as a developer, I know all the solutions and this made the game relatively easy for me. This is where I think having other people to playtest the game will help to reduce this kind of situation.

The difficulty ramp also needed to be revamped, making it a bit easier in the beginning. When the first level in the game is too hard, the player might quit when they can’t get past the first level. Ideally, the first few levels should be slightly easier to let the player get familiar with the controls and learn the mechanic of the game.

Currently, most levels only have one solution, it ended up being a “rinse and repeat until you find the right solution” type of game. Once the players know the trick it becomes really easy, which inadvertently eliminate the “skill” element in my game that many great platformers have. Making a larger level with multiple approaches might help to remedy this a bit. Perhaps adding some shortcuts that can only be done with speeding up is a good idea too. This allows people who wanted the challenge to go for it, and players might feel good as well when they find a shortcut by themselves.

While designing the levels, I need to avoid making some of the solutions pixel/frame perfect, it can become a “precise control simulator” or a game of luck (pressing buttons until they made it). Making a platformer is much harder than I anticipated as there is so much thing to consider. If it is too easy, the player won’t be challenged, and if it is too hard, it can cause frustration. Finding the sweet spot is the key here.

Finally, I think the game mechanic can be improved by making it more obvious when to speed up. This will make sure the player won’t spend too much time speeding up/slowing down trying things that are not possible. I think level 2 does this very well while level 4 (especially the last part) does a terrible job of it.

2) Collision

For this game, I went with what I am familiar with and used the Bump library to implement axis-aligned bounding box (AABB) collisions. But this leads to some problem for objects that is not a rectangle. Sometimes, objects will be colliding when it should not because the collision box is bigger than the sprite itself. This can lead to some frustration for the player as their character will die when it is not touching an obstacle. The picture below should demonstrate this well enough.

Collision box is bigger than the sprite
Collision box is bigger than the sprite

This can be easily improved by using multiple smaller collision box or by using a collision library that supports arbitrary polygons (such as HardonCollider). In addition, this game can be made more forgiving by making the collision box a few pixels smaller.

Closing thought

Score for my game!
Score for my game!

Each category (Graphics, Sound, Gameplay, and Mood) in the picture are rated on a 1-5 scale. There are 37 entries in total and I got #19! Not too bad for my first game jam, and I can only improve from now on! I definitely plan to participate in more game jams in the future after having so much fun in my first game jam. For some unknown reason, it warms my heart knowing there are people out there making games with me at the same time just for fun.