Posted June 14, 2021 by Stopa
#gmtk #gamejam
The GMTK Game Jam 2021 is over and we have successfully finished our little game. This is the first part of an ex-post-written diary of how our team progressed during the jam. (The times are in UTC+1 time zone.)
I (Stopa) started learning about game development and Unity at the end of 2020 and I have learned quite a lot since then. Naturally, throughout my learning, I stumbled upon the concept of game jams and I dreamed about having the skills to attend such an event someday. I tested the waters together with my wife (Rozari) during this year's Level-Up Circle Jam and we had a lot of fun, so we decided to join with our best friends Pozitreo, Moutes, and Shami and together form a team for the famous GMTK Game Jam.
I was the only one who had some experience with Unity and game development, so I was very nervous that the rest of the team could get lost and we would waste a lot of time explaining Unity basics. Fortunately, the team agreed to meet for a quick overview of how to Unity on Wednesday evening before the jam and they all learned to navigate and use the engine really fast, so the collaboration turned out perfect.
Our team gathered at our place about an hour before the jam started, so we had enough time to do a proper setup, install the latest version of Unity on all PCs, set up Git repository, and generally prepare for the jam. This was useful because we did not get stuck on trivialities during the jam, but in the end, it was not super-critical as the first few hours were spent away from PCs anyway.
The one thing that was critical was setting up the render pipeline in Unity. I decided to use the Universal Render Pipeline (URP) because of the support for 2D lighting and it took me quite some time to figure out the difference between URP Forward and URP 2D, what lights work with which URP setting, and how to set up materials and shaders for sprites and other objects in the scene so that they would actually render on screen. In the end, I created both URP Forward and URP 2D assets and started with the Forward to be able to use placeholder 3D blocks in the scene and later swap the pipeline asset to URP 2D when enough sprites are available.
The whole team is watching the theme announcement video.
Joined together
Nice, we can work with that, let's go! We formed a circle around a whiteboard and instantly started brainstorming game ideas. Pick your team from a pool of characters and then watch how they join together. Two player characters joined together by a link and you control both. A map full of wormholes joining together different parts of the level...
One of the better ideas was inspired by the board game Galaxy Trucker. The idea would be to join together various parts to build a spaceship and then watch how well it stands during the flight.
Spaceship in Galaxy Trucker board game. Source
After a while, we noticed that Rozari is not really participating in our game-mechanic brainstorm and is instead in a full-focus mode scribbling her own thoughts on a piece of paper. This turned out to be really effective because we got caught in discussing the best game mechanic to make, while almost forgetting about other aspects such as the theme of the game. She stormed us with a bunch of phrases, feelings, themes, and ideas that really helped set up the overall mood for the theme.
We then felt that we have enough ideas to try and pick the right one, so we started eliminating (and erasing from the whiteboard) the ones we did not feel like making. Some ideas were scrapped as not fun enough, some as not original, others because they were too complex. In the end, the one we really liked was the spaceship built from parts. And then Rozari pitched the idea to make the spaceship metaphorical. Let there be a little kid who plays on astronauts exploring the universe in a spaceship made from household items. We would call it Homeship. We all immediately fell in love with the idea and started thinking about all the elements in the game: duct tape to hold the ship together, fans to propel forward, sling to throw a tennis ball at an incoming dog, fish in a bowl as the navigation officer, pillows as shields and much much more.
The initial idea was to have the ship parts as tiles on a grid. The ship would be stationary in the grid and the player can move parts into different cells if they have enough duct tape. As the ship flies through space, there are various encounters such as obstacles, enemies or pickups. This concept works great in the Galaxy Trucker board game, but we concluded it is not that suitable for a short videogame. The problem is there would be quite some downtime for the player when the ship just flies through space and encounters are happening. Moving parts from one cell to another did not feel like a fun and intuitive enough mechanic, so we thought about movement. We could let the player steer the ship left and right to avoid obstacles and collect pickups. This would shift the inspiration towards the famous Brick-Game racing, which we all know is super fun to play.
Brick-Game racing. Source
The last big problem was with the grid itself. What would be the right size of the grid? Is seven cells wide grid too much? Too little? How would the blocks move? Discretely? Animated? Would only the ship sit in the grid or everything? Eventually, I asked the question, why do we need the grid in the first place. Unity has built-in 2D physics, we could just put colliders on everything and don't bother with no complicated tile system.
With a pretty good idea of what we would like the game to look like, the last step was to pick out the features that make up for the Minimum Viable Product (MVP). This meant really picking up the must-have features from the feature list and plan out a prototype from them. The list ended up actually quite small. We wanted a player that goes forward and can steer left and right, an immovable obstacle (sofa), some walls on the sides, and finally, a pickable ship part (pillow) that would attach to the existing ship.
Time to get down to business! Unity was already open so we started making things. We divided the work among the team.
Making a bunch of prefabs and a basic character controller did not take much time, but the difficult part was to make Unity actually respond to collisions properly. None of us had any experience with 2D Physics in unity so it took us a while to set up all colliders and rigidbodies such that the player could not go through walls, the walls would not move when the player hits them, obstacles would collide with the player and the walls and so on and so on.
Another part was to make a way to move the player forward. We discussed both possibilities: First, the player moves only horizontally and the whole level is falling down with constant speed or the scene is static and the player moves forward with the camera following them horizontally. The latter seemed a bit harder for the camera movement but promised a much easier job for all other parts of the game, so we decided to do that.
I started working on it and quickly finished some simple component responsible for the movement called "falling" and responsible for the downwards movement of everything except that player and the camera. Wait, did I just implemented the other variant? Never mind, let me spend twice as much time on it and do it again the other way around.
Meanwhile, the team had a heated discussion about the direction of movement. I argued that moving from left to right is as intuitive as moving from the bottom up and it would provide more field of view ahead of the player. The rest of the team argued that moving from left to right is wrong and would look bad. Thankfully, I was overruled, so the classic top-down upwards moving view has won.
Midnight scribbles to explain why I'm completely wrong.
With the collisions and movement sorted out, there was a last missing step: pick up a pillow and attach it to the ship. This was fairly easy to code, we just needed some prefab to be spawned as the child of the player at the point of collision with the pillow, but it still took us nearly an hour to implement this and test out the behaviour.
At about 1 AM we started to be really tired and decided to call it a night, but we all felt very good about our initial progress because we had the prototype with the basic game mechanic finished (kind of, it was very buggy). The player could move and steer the ship, collect and attach new ship parts and bump into obstacles. We all enjoyed a night full of game-making dreams, looking forward to the day ahead.
Thank you very much for reading. I will add a dev-log from the two other days of the jam at some unspecified time in the future. If you liked it, you can leave feedback in the comments to speed up that process.