About me, Banana Jam and 2D2D2D

Banana Jam is an event organized by Nerd Monkeys® that this year lasted 1+ months. I didn’t have time this year to work on a big project for so long, but I decided to join it at the last minute anyway.
There were some obstacles. “A game that explores what it means to follow your dreams, using no words only mechanics” is a theme/challenge that can easily end up being “cliché”, while remaining hard to pull off; I’ve been struggling with depression lately, April has somewhat been an hard month for me, and that didn’t help; on top of that, the last game jam I’ve been was a terrible experience: my code was a mess, and in the end the game wasn’t working. This time, I wanted to do something meaningful but really simple, something that would play with the player’s expectations; I joined the contest nearly 48h before its end, and I didn’t code for 24h after that; I wasn’t sure how to approach the “using no words only mechanics” part of the challenge. My original idea for the game is nothing like the final result; after making art assets, and prototyping a bit with post-its, I realized that even though the game was simple, it needed to be even simpler; so I scratched everything, and re-thought the game; I had another idea: I would use “no words”, but I would also use no art, mainly sound. Platforming in Unity is a no-brainer; I recycled some of the ideas into this new concept and started binge-coding yesterday. At this point, I had a clear picture of what the game would be: a platformer about depression and anhedonia; about contrast between the colorfulness of dreaming and the emptiness of everyday life.

Deconstruction

In retrospect, despite the game’s visuals and lack of text, I think that meaning of the experience is clear, and that makes me happy (I feared the metaphor could be too obscure/convoluted). The game is divided in two paired/alternated parts: a colorful platformer and a grey press-space-continue screen. The more platforms the avatar touches in the colorful part, the lengthier the grey part is; as a everyday-life-analogy, this could make the avatar not leave his/her bed (a depressive-like state); as a dream-analogy, players will instinctively consider making less actions/jumps at first, but they will eventually realize it’s useless: it’s frustrating either way.
The grey part wasn’t supposed to be boring (in the current version it still is a bit: there’s not much audio variety), but irritating. The purpose of the alarm clock sound was to “haunt” the player, making him/her slowly used to it as he/she plays, but never quite acceptant of it. The audio is sequenced randomly: while every day isn’t the same, they all feel the same; the colorful/dream part not only gives more agency than the grey/everyday part (which has none), but it also doesn’t “reset”; real life becomes a frustrating cycle of meaninglessness: there’s only meaning in dreaming.
So as the avatar/player follows himself/herself into that rabbit hole, focusing on the dream-part of the game, trying to forget real life, the avatar’s apathy grows, he/she stops caring about things, taking risks; this is symbolized by the invisible steps on the big final stair of the level. Also, by the time the player reaches the final step, he/she has already figured out how the game will end; climbing those stairs makes the player pessimistic about what’s to come; every invisible step feels like it could be the last one; until it is.
In many ways, dealing with depression this month helped me shape this game, both in the teme interpretation the its execution; it somewhat lacks creativity and borrows a lot of elements from other games I’ve worked on (http://gamejolt.com/games/other/manic-depressive/41038/) and it’s not, by far, my favorite work; the platforming physics are sloppy, the minimalism/emptiness of the dream-part’s art feels like wasted potential, and there should be more audio variety.

Lesson I learned while making this game.

1) I now have definitive empirical proof that taking time to think things through instead of rushing into development has much more positive results;

2) trusting Unity inspector for assigning gameobjects to scripts is better than using “GameObject.Find()”;

3) GUI objects in Unity 4 are a mess and should only be used in last-case scenarios, when nothing else works; more often then not, childing a 2D sprite to the camera to make a HUD element is “cleaner” and more efficient.