(GL#1) How I almost broke the game before the competition deadline.
This is the first post in the series, “How I made Got Light?” as outlined in the Prologue. Here it goes:
Context
As you may or may not know, Got Light?, was originally built for a one-month competition at MIT, starting on January 8th and being judged on February 3rd, 2013. Considering that the first week was spent learning the tools of the trade (of note, the Cocos2D game engine), we were left with little more than three weeks to design and build the game of our dreams.
Working on the game quickly consumed my days, and often lasted late into the night. Time was split between programming the core gameplay mechanic, adding usable menus, designing puzzle levels, iterating on the tutorial, making things look pretty, and debugging. Juggling this variety of tasks is one reason why game development can be so challenging, but also rewarding.
The Deadline Approaches
As the deadline drew closer, I decided to keep adding more and more to the game. During the last week of the course we had a hackathon that ran from 5pm to midnight each day, with free food and code-help from the instructors. I was there each night, trying to achieve the high standard I had set for myself. On one of the last few days, I noticed a bug with the way my code was handling physics, which caused certain light beams to go through planets without casting a shadow. Not content to work on a bugfix for the last few days, I decided to add an additional six levels to my current set of twelve. And to top it all off, I was messing around with a lot of things to try to improve performance, with little idea what I was getting myself into.
Working on too many broken things right before a tight deadline isn’t typically the best idea.
The day before our “code freeze” deadline, I was trying to fix everything up but was unable to fix the light-beam bug. I changed a lot of things to try to fix it, and at the last minute I removed a bunch of older code that I hoped wasn’t still needed. I tested out the game a few times, and things seemed fine, so I submitted the build to the competition.
Later that night I realized that I hadn’t tested the build nearly enough to justify its submission. I was pretty sure there was nothing wrong with it, but “pretty sure” isn’t good enough when your game is about to be judged by a panel of industry experts, and their first impression is paramount to your success. I also didn’t test my game on any older devices than my 3rd-generation iPad, so I spent the entire day of the showcase worrying about two things: 1) Whether my game had crashed due to something I changed at the last minute, and 2) Whether the judges used older test devices with poorer performance.
Lesson Learned
Don’t try to do anything too big right before you submit your game for an important deadline. Chances are, you broke something, and you won’t know until later when it conveniently appears at the worst time. I got lucky, and everything worked out for me — but it could have ended much worse. Thoroughly test the final version of your game before you submit it, and resist the temptation to change that one last feature before the submission.
Keep this in mind, and you’ll have a happy game launch!
