The title screen (and first level) of Sprinkle
Jason wasn’t the only Fire Hoser to participate in the Global Game Jam last weekend. I was also in the trenches slapping a game together, only I was on the other side of the river at the Northeastern University site.
The result is Sprinkle, a neat little puzzle game based on the idea of raindrops falling through a tree. The goal in each level is to move objects around to guide the falling water droplets to a flower. Once the flower has fully bloomed you’re taken to the next level. Go ahead and give it a shot — it only takes a few minutes to play through.
Looking at the game again after letting a week go by, I’m impressed with how fully developed the game seems for a two-day effort. It contains a coherent core mechanic, some interesting variations, and a fair number of well-thought-out (if simple) levels. This is all the more impressive considering that, in true game jam fashion, the first playable level came together at roughly 1:00 Sunday afternoon, only two hours before the deadline!
I was working on music and sound design for this game. The other team members were three programmers — Shakeib Afzal, Kirk Israel, and Heinz Pabst — and Zachary Fand, who created the nicely idyllic visuals.
Early on, I decided to try to put a bit of musical interactivity into the game, similar to that in a game like Elektroplankton. Specifically, the music I had in mind would go back and forth between two chords, and the sound effects would be designed to fit into these chords, so that the sound effect that any particular object makes would change depending on what part of the music loop is currently playing. The results are mixed; sometimes it comes off as intended, but in most levels the experience is a little awkward — either there are too few objects for anything interesting to happen, or there is a flood of objects creating an annoying and broken-sounding cacophony. Partly this is inevitable in a game jam, when exactly what the game is going to feel like is not necessarily determined until close to the end. But there were also some good takeaways for me.
First, as part of the sound design process, it pays to think carefully about what kinds of events will be triggering sounds, how often they will occur, and how likely each event is to repeat. If I were to revisit the sound design after seeing all of the levels that made it in, I would definitely reconsider the scheme for assigning sound effects to collisions, trying things like having collisions turn on or off a loop, or having each object emit a sequence of notes as it is hit multiple times rather than repeating a single note. Second, it’s important to pay attention to the technical details early on — can we get the music to loop smoothly? How are we going to handle repeating the same sound a dozen times in close succession? I’m happy with the overall sound of the game, but I would be much happier still if we had sorted this stuff out early! Having the technical aspects be a little bit off makes the whole experience much less polished and enjoyable.
I had a really fun time putting the game together with the team and was impressed by the level of energy, enthusiasm and creativity from everyone at the jam. If you’ve never tried doing a game jam before I highly recommend it!
