BaconGameJam5 & löve

by , under General

löve

About a month ago I participated in the fifth BaconGameJam, which is a game jam that started as “RedditGameJam”, but had to be renamed due to copyright issues, so it’s the former actually unofficial official reddit game jam and now more of a official unofficial reddit game jam. To get to the point I have to mention that I wasn’t really sure what technology to use, because using Kiwi is way too stressfull since C++ is not a very productive language for very short amounts of developement time (My opinion at least.), so Pywi (the Python version of Kiwi) was actually my weapon of choice just before the jam started, but I knew that Pywi still had a few problems with sound and that I was not very keen of distributing a 48h-game with a rather huge Python interpreter + Pymedia, Pygame, numpy (we used this in collision detection and a few other parts), so I spontaneously decided to use löve, which is 2D game engine, which is implemented in C++, but used in embedded Lua. And I must say, that löve is probably the most *awesome* framework I’ve ever used. I already tried using some other engines rather than my own, but every time I had the impression that there was something about them that bugged me so much, that I didn’t really want to start any kind of project with them, but löve is almost exactly like I would like a game engine to be (API-wise). After using it for a while I noticed quite a few things that were not entirely to my liking, but most of these things are going to be changed in the next major release 0.9.0 and the rest is either not very important or something I could fix myself, since löve is open source. One of these more important things I decided to tackel myself was the integration of some proper games-oriented network library (in my case: ENet). Thankfully a bunch of people already made some significant progress towards integration ENet into löve, namely leafo with lua-enet and Martin Felis with love-enet, which my integration love-enet-new is largely based. The differences are mostly things regarding the “how” rather than the “what”. The API is more “lövely” (commonly used as “fitting with the löve-API stylewise) and the integration of the added enet-module is mostly just like and other löve module is integrated in the engine. A working version of this was proposed about two weeks ago in the issue tracker (link), but was yet not responded to, which is kind of a bummer, but I hope that this will workout somehow and someday ENet will be available in löve officially.

BaconGameJam

Of course there is still game to talk about (BaconGameJam), which was nameless until the very end. This story is equally unimpressive since again, but this time even worse, I didn’t really finish in time. I wasn’t really enthusiastic about the theme or my idea from the beginning and actually only chose the idea from my list of ideas because there wasn’t anything else I even remotely wanted to do.

(By the way: The theme was “Lights Out” and I decided to make a game in which you would wake up and walk around town discovering dead people and devastation, collecting clues and talking to people uncovering that the guy you play actually became a monster last night (when the lights went out), which is then replayed as kind of a “reconstructed memory” backwards “creating” the clues you collected and ending at the point the game started as a human, but as a monster.)

I don’t intend to show you what I managed to finish, but rather summarize what I learned about participating in a game jam. I don’t have very much to be proud of then, but I have learned a lot more, which does not feel as good, but is way more valuable.

  1. It’s not a good idea to make a game with a strong emphasis on story, because.. 48 hours. How am I am I supposed to make a game and invest at least twice as much time in content (levels, dialogues). Instead I should make games which center around a core mechanic or are very easy to make content for.
  2. I’m alone and a programming guy, so I should make games that can be done by a programming guy alone. Needing tile sheets, character sprites etc., which I am not capable of making in a game is just not a good requirement to start with and bound to not work out very well. I should stick to simple sprites, stylised graphics, which are easy to make or boxes/circles/lines.
  3. Probably the most important: Accepting defeat. If I don’t have a good idea or it’s probably not very realistic to transform the ideas I have into a enjoyable game in 48 hours I should probably not even start and waste a weekend, feeling bad afterwards. Maybe I should even deign to make the most obvious and easy game to a theme I can think of because in the end I would have an obvious game that no one is exceptionally ecstatic about, which is not so great, rather than having no game, which no one will be at least a bit ecstatic about, which is not even great at all.

Yep. That’s it. The next Ludum Dare is next month (actually just a little less than two months), so I will see how much these lessons actually taught me. 

Leave a Reply