Now that Ludum Dare 33 is over it seems like a good time to look back on the first game we made. We made it for Ludum Dare 32 in April and continued to work on it for a week after that to release one more update. The game was designed by Gege and me together, the graphics are made by Gege and the programming was done by me. Since it was a Ludum Dare Jam game, the initial version was designed and produced during 72 hours, you can see what we changed in the week after that in the changelog on our game page here.
Goals & Expectations
Before taking part in this game jam we already made a few concepts for games and put together some prototypes, but we did not really make a game. What I mean by that is: “start with a concept and release it when we are done”. That was our main goal for the jam. We were also hoping for some feedback on how well our ideas worked.
We used the following tools:
- Unity (this does most of the work)
- Visual Studio (I prefer using C# for Unity)
- git (preferred way to back up, plus all the other DCVS advantages)
Yes, we decided to do a local multiplayer game for a game jam. Yes, we knew that very few people are going to play it the way it was intended to. But the appeal of being able to playtest “against each other” during the weekend and having an idea how we could incorporate the theme mechanically were important enough to ignore this fact. The game is built around the idea of having “weapons with feelings”, which we thought fit the theme of the jam (“An Unconventional Weapon”). The mechanic that emerged out of that was the ability to sweet talk the weapon (yes, two players – one weapon) to get it from the other player. Using the weapon should remove affection and when a player is more liked by the weapon than the weapon holder it would switch possession. Initially we also wanted to add a heat parameter for the weapons but this idea was one of the few ideas that did not make it into the game.
Since we made a prototype for a 2D platformer in Unity a couple of months before the jam there was no need to do everything from scratch. Yay, less work! Nothing we have happening in the game is really complicated and for me it was mostly a matter of putting things together and looking up the occasional fix for a problem. To get a nice movement system (and interactions with the dynamic objects) I tinkered a little with Unity’s physics engine but I did not get anywhere (probably because I did not know where to go with the movement, no pun intended). Gege also helped a lot with that physics stuff in Unity and did even more there with lights.
In the concept phase we decided on simple 2D graphics with smooth and pleasant colors making the scene look visually appealing without adding many details. The creation of those images was a piece of cake, it took not more than few hours since all the level elements consist of rectangles. The character is an 32x32px pixelart sprite and the animations consist of only a few frames. All the power ups and items were very basic shapes and done within minutes. Lighting was the tricky part. Most of the time was spend into finding the perfect intensity, location and color of the lights. This was also the part that changed our mind of using 2D level elements into using 3D elements that look 2D instead. We did that in order to have nice shadow effects. And I must say, it improved the look of the game a lot. Having ninjas as characters was not a conscious decision, it just happened.
I’ll use the term “production” for anything else that is part of making the game and is not related to design, programming or graphics. Since we did not make the music and just generated some simple sound effects ourselves I did not mention sound anywhere else. But I did that now (*check*). Deployment (aka taking that stuff out of the engine and putting it in a form where people can play it) was easy for the three “classic” (or old, I don’t know who to categorize that) operating systems, Windows, OSX and Linux. With Unity it’s usually as easy as clicking “Build” and leaning back, if you did not do anything too crazy. But of course we know that anything that runs in the browser will get played by more people since it requires even less effort. Sadly we did this at a time where the classic Unity Web Player just stopped being supported by Chrome, but WebGL builds, the new and conceptionally probably better alternative were far from ready (still have some way to go, but they are coming along nicely). This combined with our idea of making the game for controller first caused a lot of problems. We even stuck with controller-only for as long we could lie to ourselves about the fact that no one will be even able to play it because they don’t have two controllers, let alone two people to use them. Keyboard controls were added too late to make them work well, but even apart from that we had issues with how the WebGL game was displayed in different contexts (browsers and websites) and people not being able to focus the game and the like, all things that we probably should have figured out earlier with some test builds. Maybe we should have even done a whole session on just figuring out possible problems with different build configurations, it just is very frustrating to have stuff like this come up in the very end when it is basically to late for any drastic changes.
We also learned during submission time that it can come in very handy if you think of preparing some promo materials at some point during the jam. Screenshots are required, video is highly recommended, I also count “tutorial images” and things like that as promo materials here, because it is a jam. We had a buffer planned for that but since this had to happen at the same time we made builds (and had a lot of trouble doing so) all of this suffered a little and would have deserved more attention.
Rating other games was a lot of fun and we also got some feedback ourselves. Apparently our idea of embedding the theme mechanically was not understandable for most people (we got that feedback from some comments, but especially from the score), that was very suprising to me. Our graphics score was very good for a first time, but I did expect this a little since we had the advantage of actually having someone be able to make graphics. But the most important thing I learned about the ratings is that they are pretty much worthless in terms of improving your game. Without any idea what kind of people gave which rating for each category there are way too many factors that we’d have to take into account to gain information from this. I also saw a bunch of weird ratings/comments for other games, such as text-only games with moderately high graphics ratings (kind of like rating a game without sound for its sound).
We achieved our main goal, since we made the game and published it. We also learned some things, even though while writing this post mortem I start to get the idea that I should have done this before we took part in Ludum Dare 33 (some mistakes were repeated …). It was as exhausting as it was fun and we’ll do it again for sure (already did, actually).