Everything is connected: A Dev diary of Pixel Jam 2024
Published on 03 Mar, 2024 by Magí Romanyà Serrasolsas.
Pixel Jam 2024
With some friends we decided to start 2024 by forcing ourselves to spend the last week of our holidays building a game from scratch. We wanted to have a deadline that would force us to work on the project, and encourage us to finish our project in a limited time. So we took part in Pixel Jam 24. This was a small one-week Jam hosted on itch.io, and it had a compatible schedule, which was all that mattered. All the games in the Jam had to have pixel art, but this was not a constraint for us, as we wanted to use pixel art for the game anyway.
We ended up with a team of 4-5 friends working on the game. Fortunately, not all the team members came from technical backgrounds, so they could focus on making the art and worry about making the game fun to play. Meanwhile, in the more technically inclined part of the team, we decided not to use a game engine to make the game and have a bit of fun. We ended up writing the game in C, and using the fantastic raylib library, which freed us from the tedious parts of graphics programming and came with some really handy functionality already implemented.
The development of the game
The theme of the Jam was revealed to be everything is connected. After some brainstorming we decided to make a puzzle game about a character who has to connect various devices to power with a limited length of cable. We also decided to make the game a platformer, as the puzzle idea felt too simple.
I included a short devlog here, which is oversimplified and mostly wrong. You could say that it is inspired by the real thing.
Day one: Implementing cable physics
Initially we thought of the cable as a physical entity that could be bend and collide with the environment. The challenge in the game would be keep the cable from becoming too tangled in the level so that all the appliances could be connected to the power outlet. As the main mechanic of the game, we started the game by researching how to model and implement this cable. However, after a day's work, we had nothing resembling a real cable, and we realised that this alone could eat up all the development time we had available. To solve this, we had to go back to do some brainstorming and come up with new ideas.
Day two: Solving the physics with staples
We liked the idea of connecting appliances with an electric cable and we did not want to give up on this idea yet. So to solve the cable physics problem, we removed the physics from the equation. The cable will always follow a straight line from its origin to the player's hand. To avoid obstacles, the player had to staple the cable to the wall. This in itself was an interesting mechanic, the staples could be a limited resource, which in addition to limiting the length of the cable, could lead to interesting level design.
Figure 1: Screenshot of the game showing the cable being stapled to the wall to avoid the obstacle and connect the washing machine to the power outlet.
Day three: Reading the levels from an image file
With the core mechanic implemented, we needed to work on a way to easily create and iterate game levels. Since we decided to write the game in C and not use a game engine, we did not have a level editor at our disposal. Building an editor from scratch with the limited time we had was not a viable option and would have been overkill for our needs. We decided to go for simplicity and create levels in an image file and make a level loader that could generate all the tiles, colliders, appliances and player starting position from the file. This is not an original idea by any means but it ended up being very helpful. All the members of our team could just draw the level that they wanted and just test it in the game, without ever having to know how to code. We also realized that our levels were hot reloadable, which allowed us to iterate on different levels without ever having to recompile the game. The level loader was definitely the most useful part of our game and it is the part that we are most proud of.
Day four: Making the levels (and hats)
With the level loader and the cable mechanic implemented, we only needed to make a few levels to have a playable game. This was an interesting part of the development process, and also maybe the most difficult. Making good levels is hard, and we did not have as much time to implement new mechanics as we wanted in order to make the levels we wanted. Tuning the difficulty curve was also a challenge, as we as level designers felt that all the solutions were obvious. In the end we made a total of 8 levels, which we think is a good amount for a Jam project. The levels are by no means masterpieces, but in the end the game was quite interesting to play.
Making levels was not out greatest strength it this project. To make up for it, we introduced a game changing mechanic which we estimate it improved the game's quality by orders of magnitude: player hats. By pressing a key, the player could cycle between different hats for the main character, and in every level, the starting hat was different.
The completed game
The final game is published in itch.io and it is free for anyone to download.
The code is publically available in github, and it compiles for Windows and for Linux platforms. We have not tested making a build for MacOS, but it should theoretically work, as raylib is a cross patform library. Because of time constraints, we only ended up publishing a Windows build in itch.io.