I completed my second game jam earlier this summer. Really, it was my first, because my first was more of a proof of concept than something actually playable. If you don’t know what a game jam is, look here. The theme was “It’s Not What It Seems” and it was a ten-day jam. I worked on it most days for a couple of hours—you can see the Git history—and I learned a lot about my process. Overall, it was fun and I will definitely be doing more of them.
With the goal of winning the $100 first-place prize, I set my aim on an end result that was very achievable. I decided on a side-scrolling 2D platformer, and my way of achieving the theme would be false walls, traps, and bullets that don’t hurt you. I didn’t come up with these ideas all at once—I spent day one and two making art assets and my player controller. The tools I was going to use were already decided: Aseprite and Godot. Aseprite is very good pixel art software that is honestly kind of boring to talk about because it just works. You can also compile it for free, and it is my favorite art software. Godot is an open-source game engine that has gained a lot of popularity recently. I had used it in my first jam and wasn’t partial to it, but I don’t feel qualified to complain or praise it. It didn’t seem constraining, but I wasn’t exactly pushing it to any limits in this jam.
I think the weakest part of my process was developer blindness. I didn’t realize how good I would get at controlling the little guy while developing the game. The overwhelming feedback from the rating stage of the jam was that my player character was too fast and hard to control. Even my playtesters on day nine told me it was too fast, and I only slightly reduced the speed. You have to remember that people are going to play your game for one or two minutes while they check it out, and if you bounce them for being too difficult to control, they’re understandably not coming back.
On my next game I will also definitely be more conscious of what needs to be in which file. I had some global scripts for player data, level loading, sound, and SFX. It’s pretty understandable that game jam code ends up messy because you’re juggling so many different things, but I would like my code to not be so unwieldy next time. For example, I can probably drop in my audio script to my next project, but my player data and level loader are pretty cross-referenced with the player movement script and will most likely just get thrown out with the bathwater.
I didn’t end up winning any money, and I’m not complaining—I don’t think the game was deserving of it. This jam taught me a lot about itch.io voting though. I figured it would be best to get lots of reviews, so I spent the first day of the jam rating other people’s games. However, the better strategy seemed to be to not bother with getting lots of reviews and instead hope that people who were interested in your game rated it. Only the eighty-nine people who submitted could vote, and a single five-star rating was better than a five and a four-star. In my opinion, the best game in the jam (the one with the most ratings at thirty-three) ended at eleventh. Something about the voting system doesn’t seem right, but I’m not sure why.
The last thing is that platformers are pretty boring. Unless you have an interesting twist, or a real hook with lots of content nobody is going to be interested. Mario is 40 years old this September, its not exactly breaking new ground. One of the people that submitted a game in the jam, went around commenting "great another platformer" which I found kind of funny but I think other submitters were annoyed.
If you’re curious, you can play the game here, or view the source and play here.
PS. One thing I forgot to mention was that all the assets were created by me, but the music was created by my brother.