Rapidly prototyping games is one of my favorite aspects of game development.Thus, game Jams are some of my favorite events to attend. From two hours to forty-eight, game jams bring with them harsh time restrictions for creating games. Therefore, it is very important to have a good understanding of the rapid prototyping process in order to bring a game jam project to its full potential in the allotted time. Last weekend I attended Global Game Jam 2017 in Pittsburgh, created BeeBall with a four-person team, and we ended up taking the Pittsburgh IDGA prize for “Best Theming”. In the following, I will discuss some of the key points of our development process and how they translated into us having a fun and successful Global Game Jam.
Make the Toy First
After our initial brainstorming session, my team agreed to move forward with a simple idea: A two-player game where each player attempts to knock a ball toward the other. Each player has access to a row of flippers which can be used to flip the ball as it rides open a wave. For our game to work we needed to answer the question, “Is flipping a ball over a waveform fun for two players?”Thus, we prototyped this as quickly as possible. Before the end of the first night, we had this prototype.
As it turned out, the mechanic was fun! However, the wave needed better implementation. During playtests, the winner was determined more often by randomness caused by the wave rather than player skill. Which brings me to the next point.
Iterate, but Don’t Be Afraid to Try New Things
The time pressure in game jams can often cause people to shy away from changing their initial design decisions. However, some of the most interesting ideas will often occur during development, even if they don’t work out. One example from BeeBall was causing the wave to move based on the music.
The wave acted as a visualizer for the game’s music. It created a really cool effect, however, it wasn’t very balanced. During playtests, we noticed that the left side would often not move as much as the right.We liked the visualizer enough to keep it as an aesthetic feature but decided to not have it impact gameplay. Even though this iteration failed, it helped solidify our design. From this iteration, we decided that the waves needed to be player controlled, in order to reduce the randomness and add an additional element of skill. Try new ideas, even if they fail, they may still give you helpful insights about your design, and you never know when you will discover something truly amazing.
Make It Pretty at the End
Unless you have an aesthetic choice that is necessary for proper gameplay, don’t worry about art implementation until your closer to the end of the project. Your artists need time to work anyway, and if you wait for them to deliver you sprites or models, you will waste precious prototyping and iteration time. Primitives exist in Unity and Unreal for a reason, use them to their fullest extent. The majority of your game can be prototyped using primitives and not your artist’s models. Additional programming and testing during deadline crunch time are way more time consuming and stressful than implementing art. Do your best to prototype, program, and iterate first, and the art implementation will be easy later.
Thanks for reading, I hope this article was interesting or at least insightful into our development process. And of course, much love to my awesome teammates: Christopher Weidya, Sunil Nayak, and Kuk Kim.