The 19th of April marked the end of Ludum Dare’s 46th Game Jam, a competition in which developers are challenged to create a video game in under 72 hours. Even though my team spent the entire weekend frantically coding, animating, and designing, the competition ended up being a ton of fun and overall, an experience that I would highly recommend to anyone interested in game design. Even though we were all rather new to the craft, we were still able to create a product that we were proud of.
This isn’t going to be an inspiring story nor will it be filled with tips and tricks on how to make games, but rather a telling of a true story about how a group of people only lightly familiar with game design managed to create a video game in under 72 hours.
Play Our Game!
Ludum Dare always starts with a theme; a stepping off point to help developers generate ideas for the their game. The theme is always left purposefully vague in order to allow developers to come up with their own ideas as to what their game should be, and this year was no different as the theme was simply keep it alive.
Sitting on a discord call, my friends and I began to toss ideas back and forth in order to quickly come up with different avenues for the game. Using a Google Doc and white boarding program we quickly listed out a couple different ways we could create a game based off of the given theme. Below are the ideas (copied verbatim from our shared doc) that we were able to generate.
Our Chaotic Idea List
- Keep it alive
- Keep plant growing on the plant
- Trying to keep a companion alive really bad escort
- People, devices, energy, yourself,
- Keep a flock of birds alive
- Tower defense and rogue-like
After around fifteen additional minutes of deliberation the group decided to go with a variation our third idea which was trying to keep a companion alive in an escort mission. We also used some ideas from the other list items in order to develop a game that we felt added a cool element of strategy to a popular genre of games.
Using all of the ideas that we were able to generate for our game, we finally decided to create the following game. The game would be a roguelike-like, utilizing a room-based environment, permadeath, and a top down view while abandoning the use of procedural generation. Staged in a medieval setting, the user would be tasked with transporting a “torch” through a dungeon and defending it from the foes within; all while making sure the torches light doesn’t go out.
However, there were a couple of features that complicated the game play. First, the dungeon is completely dark, the only light coming from the “torch”, the player’s candle, and torches placed throughout the environment. Secondly, the player only loses once the light of the “torch” goes out, the players candle going a dim red rather than going out completely. The final twist is that the player can only defeat the enemies of the game by shooting them with fireballs. Yet, the only way to shoot fireballs is by using up the light of either the player or the payload. The idea was that the player would have to balance out their use of fireballs with keeping the payload alive in order to add a bit a strategy to the gameplay so it wasn’t a traditional escort mission.
If this explanation was confusing I would suggest playing the game to help it make a bit more sense.
On the first day we actually managed to get a lot done. We first started by splitting the work among the four people in the group; a friend and I took on coding, while the other two people took on music and artwork.
To start, I began to use Unity in order to lay the ground work for our game. Before I went to bed that I night, I wanted to get a working light draining mechanic along with a basic movement script. After creating a placeholder character sprite within Aseprite, I started to work on the character movement.
While I worked on that, my programming partner used the above enemy placeholder sprite to begin implementing a 2D pathfinding library for the enemies. The idea was that the enemies would seek out the payload in the environment in order to put it’s light out.
After a little while of working, I was able to get a basic movement script working as can be seen below.
Then my coding partner reached out to share that he had gotten the enemy of the game to pathfind their way towards the payload. It was a bit buggy, but it was something.
As I began work on basic projectiles for the main character the art lead on our game reached out with a tile map that he had created for the game.
At this point, it was around 3am, so everybody headed to bed in order to work the next day.
Moving into the second day, by around 2pm my coding partner was able smooth out path finding while I was able to get projectiles working. These parts of the game were honestly not to hard to pull off, but it was around this point that our documentation for our progress began to get a bit more sparse.
In terms of art, our art lead reached out at around 4pm to share that had not only finished the tile map but created the payload, main character and enemy to be implemented into the game, which he shared in the picture below.
Now that the sprites were complete, the rest of the day simply involved implementing the torch mechanics working along with getting the animated sprites into the game. I took control of the lighting mechanics of the game and the main character sprite while my coding partner worked on the payload and enemy animations.
Closing out the day, we had some basic animations in the game along with working torch mechanics that all sat on top of the previous days tile map. We had also created a game plan for level creation to be implemented the next day.
The final day was such a rush, that there isn’t a whole lot of documentation for it, so I will try to recount to the best of my ability. To start the day, I began to rework the torch lighting scripts in order to make it modular enough for other people to understand. The idea was that once I got the parts of the game simple enough to understand, I could have other team members make the levels.
As a result, I ended up taking on the bulk of the work until around 3pm, when I managed to finish my level creation methodology and offload the level creation to other people.
Once I had the art lead in the project working on creating the levels, me and my coding partner worked on creating the level transitions screens and scripts in order to allow for the player to experience different levels. The video below shows the tutorial level that we were able to create working within the screen transition framework we created.
At this point, it became a mad rush to complete the game. Once the art lead finished creating a second level, we took that and implemented it into the game. Then we added in music that we had obtained from our music lead who had received help from another friend into the game. We finally built out the game and uploaded it to Itch.
Overall, frantically developing a game turned out to be a lot of fun and something that we all really enjoyed. While we didn’t do as good of a job at documenting it as I would have liked, I’m glad I was still able write about what we did so I can forever remember what it was like competing in my first game jam.