How We Made Our First-Ever Video Game in 72 Hours
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!
Ideas
Ludum Dare always starts with a theme; a stepping off point to help developers generate ideas for 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 whiteboarding program we quickly listed out a couple of different ways we could create a game based on 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 on 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.
The Game
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 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 gameplay. 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 the game once the light of the “torch” goes out, the player's 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 of 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.
Day 1
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 groundwork for our game. Before I went to bed that 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 path find 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 tilemap that he had created for the game.
At this point, it was around 3 am, so everybody headed to bed in order to work the next day.
Day 2
Moving into the second day, by around 2 pm my coding partner was able to smooth out path finding, while I was able to get projectiles working. These parts of the game were honestly not too 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 4 pm 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 day's tile map. We had also created a game plan for level creation to be implemented the next day.
Day 3
The final day was such a rush, that there isn’t a whole lot of documentation for it, so I will try to recount it to the best of my ability. To start the day, I began to rework the torch lighting scripts in order to make them 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 3 pm, 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, my coding partner and I 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 leaders who had received help from another friend into the game. We finally built out the game and uploaded it to Itch.
Conclusion
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 to write about what we did so I can forever remember what it was like competing in my first game jam.
