6 Lives in 60 Seconds

Title: 6 Lives in 60 Seconds Development Time: Approximately 15 hours (spread across 3 days) Team Size: 1

Link to project: https://amac50000.itch.io/6-lives-in-60-seconds

*Audio in video is slightly distorted due to recording software

Throughout my game development journey, one of my biggest regrets is that I have been unable to participate in more game jams. It’s always fun to take a weekend and focus on making a game. Unfortunately, it seems as though whenever I found a jam I wanted to join, a snafu in my schedule would prevent me. One of the biggest tragedies of this has been my failure to participate in Ludum Dare (the world’s largest game jam). However, when Ludum Dare 51 rolled around my schedule was finally clear enough to participate. 6 Lives in 60 seconds was my submission for Ludum Dare 51. It's a minute-long 2D Platformer where the player controls six characters during the last moments of their lives. Succeed or fail each level is over in 10 seconds. The game has a dark tone and is meant to make the player reflect on their mortality. Will they spend their last moments with loved ones? Helping others? Or just stumbling alone in the dark?

What Went Well?

My greatest accomplishment was creating a game that required no tutorials. Because each level has a ten-second timer, it is vital that players immediately understand the game's mechanics and goals. Nevertheless, I wanted to avoid tutorials as they would disrupt gameplay and ruin the game's dark tone. Thankfully, the game’s simple controls and informative sprites made tutorials unnecessary. GB Studio is an engine I’ve wanted to try for some time. I was drawn to it due to its unique ability to make rom files for the original Game Boy. However, the engine did present a series of challenges. It has various restrictions to ensure that all created games can run on a Game Boy. These included small obstacles, such as limiting the number of actors on screen, to larger challenges, like forcing all sounds to be in 8-bit mono format. Fortunately, the engine provided documentation to help users work within these restrictions. I was able to get a fundamental understanding of the engine and created a game free of technical bugs. One of the issues I faced in past projects was over-ambition. With the challenges that this project presented, I knew that if I over-scoped even slightly it could lead to disaster. As such, I purposely restricted the scope of this project as much as I could. This decision proved to be vital as it allowed me to quickly create a minimum viable product and spend the rest of my time polishing it.

What didn't go well? Many of the game’s issues stemmed from the lack of available work time. Even though my weekend was more open than past, there were still responsibilities that took my attention away from development. Ultimately out of the 72 hours available for the jam, I was only able to spend 15 of them on development. Creating interesting levels proved challenging for me. I had to make sure each level could be reasonably completed in under 10 seconds while still providing a challenge. I chose not to include anything in the levels except the player, the platforms, and the goals. Because of the ten-second timer, the player had to immediately know the purpose of everything on screen. Keeping the levels simple accomplished this goal and helped to reduce the project’s scope. I had a hard time working with GB Studio’s process of importing sound files. Since all GB studio projects can run on the Game Boy the engine has to convert sound files to a format that it can accept. This process destroyed most of the sounds I put through it. It took a fair bit of time to find acceptable sound files. Because of this, the game had very few sound effects.

What can I do better next time? For future jams, I will decide to participate further out so I can take care of my responsibilities ahead of time. Joining the jam was a last-minute decision leaving no time to reschedule engagements. As stated previously, many of the game’s issues stemmed from a lack of available work time. Better planning would resolve many of these and help to lower my stress during development. Deciding earlier will also give me more time to do preliminary work. While development is limited to the time of the jam itself, there are still things I can do to prepare. Tasks such as researching game engines and setting deadlines can be completed beforehand. This will limit the amount of work I have to do during the jam so I can focus on development. I will also limit the scope of my art assets or use premade assets(provided the jam allows them). While making all the assets was a fun challenge, it hurt the game as doing so took almost half of the total work time. I want to challenge my art skills, but I don’t think a game jam is a proper place to perfect them. In the future, I will limit the scope of it to allow myself to be challenged in other areas.

Final Thoughts Overall I have mixed feelings about this project. On the positive, I created a game that was free of any major errors and challenged myself in various areas. On the other hand, the game was pretty forgettable and didn’t have any major draws besides its tone. In the end, my main goal of this jam wasn't to create a masterpiece but rather to challenge myself in unique ways. That is a goal that I succeeded in.