From Game Jam to GDC, Redesigning a Game
This past fall, I was involved on a team that was competing in a local game jam hosted by RIT. My team and I went into the competition knowing we wanted to make a rhythm game, but nothing more. We did not discuss the art style, the game system we thought of developing or really anything of importance about the game before we had to begin its development. As you could imagine, the game was developed purely off what we thought would work in the moment. Ultimately, our plan worked in terms of us winning the Imagine Cup Game Jam at the end of the weekend. We had no intentions of doing anything more with the game until the MAGIC center at RIT took interest in the project. They liked the concept and look behind the game and offered to take us to GDC 2018 to display the game if we continued development on it. Of course my team and I were thrilled to accept this offer and pick up on the development on the game immediately. However, continuing to work on a game from a game jam is something we were not prepared for.
The common practice behind making a game is to design it fully before development starts. With our project, we had only done the development aspect of the game and had no idea what direction to take the project. There were major consequences from this that we needed to fix before the game could progress. Firstly, when programming in a game jam, usually the developer doesn’t worry if the code is the most efficient or flexible. This is because a lot of the time, the game is only meant for the game jam and not for further development. We were certainly one of those teams that did exactly this. So, once we decided to continue development, we had to redo most all of our code to make it efficient and flexible for future systems. Furthermore, we had to come up with an actual theme to the game with a consistent art style since that wasn’t needed during the actual game jam. This process also took some time to complete and even now we run into issues from some of the initial development that was kept. Finally, trying to figure out what and why you did something in the project is a nightmare when there is no documentation for the reasoning. Who would waste time in a game jam documenting, right? Figuring out what our formal sleep deprived selves did at three in the morning was quite the adventure as well.
Redesigning a rushed game into a fully polished project is kind of like doing the complete opposite of what game designers recommend doing. It’s always encouraged to design before you develop, but with our game, we developed before we designed. It has been a fun but also at times frustrating experience taking an un-designed game and turning it into something that is very polished and has an in depth design to it. I would not recommend doing this with any future project you decide to pursue, but if you do, just remember that continuing development with the project will be more than expected.