Wow, what a weekend. This was my first Ludum Dare, and I can certainly tell you that I was not prepared. Deciding to do the LD48 in the spur of the moment, with about 3-4 hours of prep time is not easy. Attempting to code it using a library you have never worked with, in a language you have barely used, is even more so. Doing all this when this is the first actual game I have ever made, even more so on top of that. Honestly the only thing I’m actually proud of for this is that I managed to actually complete a full game in such a short period of time. I personally don’t feel like the my game is very noteworthy in any particular way, except maybe its ability to frustrate with the precision jumping room, but I feel great for having actually completely a game, and in 48 hours no less! (though actually much less than that, due to various reasons that you will see) Alright then, let’s have a look at the breakdown of what happened during those 48 hours:

Day 1 (including prep)

At about 2pm my time, with the LD48 kicking off at 9pm, I remember it suddenly and go check the website. Having always wanted to get in on this, I suddenly decide that now is the time. Having recently been doing some web development stuff and enjoying Javascript with the little bit I have used it, I decided to just go all out and code entirely in Javascript with HTML5 technology. The only problem with this being that I did not know any good libraries I could use to actually make the game with. So I did what any developer would do: googled. I ended up finding some huge list of engines, and eventually settled on using the CraftyJS engine. This was a huge mistake.

Don’t get me wrong, the engine itself seems like it’s fine and probably works well. However, the documentation is currently lackluster, there are barely any tutorials, and worst of all, the basic movement bits of the library that it provided did not work with the type of game I wanted to make. I am stubborn though, so I decided to just push forward anyway. Eventually I managed to cobble together some basic code that allowed me to move about and go into a new area. A new area that lagged all kinds of horribly even though it wasn’t even that large. At this point it is 5am, I am frustrated, and my small level is lagging a lot. It was time to go to bed.

The next day, with about 3-4 hours of sleep, I made the smart move of switching to another engine, one that has good behaviors built in for sidescrolling. This time I was using the Stencyl program to create a flash game. Unfortunately I had not used Stencyl in a long time and had to re-learn a lot of stuff on the fly. Beginning all over again is frustrating, and I begin to worry that I will not finish my game at this point. Doubly so because I have social obligations for that day, ones that would end up consuming a good number of hours during the dare. However it is while I am out, hacking away at some behaviors with my laptop, that I start to feel like progress is being made. I only make a little progress today, but what I do get done feels like an actual accomplishment.

Final Hours

I got around 6 hours of sleep that night, and still felt kinda like crap. But I had a game to make, and nothing was going to get in my way. This is honestly the day where pretty much everything got done. I pretty much put most of the game together between 9am Sunday morning and 8pm Sunday night. There were a few hours that I was productive on Saturday, but most of it happened on Sunday, particularly after the scrap of the first engine and everything I had to do on Saturday which was not making games. Honestly, this period of time was the most enjoyable of the entire dare. I had started to gel with the tools I was working with, and they are easy enough that adding content was an absolute snap. At around 7pm, I was feeling like the game was pretty much done, so I managed to spend a little time with SFXR to get some sound into my game. Then I discovered a few more bugs here and there and managed to quash them with an hour to spare. The most annoying and irritating part of this entire process was the fact that Stencyl kept spawning these invisible tiles that were totally unselectable from the scene editor, and I had to re-design a couple scenes several times either trying to get them to go away, or to work around them. They’re still there in the final product, but I designed the levels in a way that it is impossible to notice them.

Last Points

I really learned a lot of things during this, as short a time as I got to spend on actual development of the final product. The most important of those being that knowing the right library/framework to use BEFORE the dare starts is incredibly important. It is also very important to know the language you will be using fairly well. Attempting to basically learn a new language with all its little issues and workarounds on the fly is a bad idea. It is also a very good idea to know you will be entering the dare in advance so you can schedule your life around it. If I had been able to commit myself to the dare for those entire 48 hours, I think I could have created something a bit more interesting, a bit more refined, less frustrating, etc. It is also a good idea to try and keep in high spirits the entire time, always saying that you WILL finish your game no matter what, even if you have to cut lots of features or levels. That is much harder than anything else, but if you want to actually complete the dare it needs to be done. You can spend a nigh infinite amount of time polishing some small aspect of the game, but getting a full and cohesive game out there, even if it isn’t perfect, is much more valuable in the end. Particularly if you have never done this, or never made a game.

All in all, this has been very fun, even if I was discouraged for a bit in the middle, and I did not get to spend nearly as much time as I would have wanted focused solely on game creation. I’m going to use the time between now and the next dare to learn more about Stencyl, as it really is wonderful to use, so that next dare I can actually be prepared. This might have been my first LD48, but you better believe it won’t be my last. I can’t wait for the next one, and next time I’m going to attempt to create something much more interesting.

This will be my second Ludum Dare. Last one was a few competitions ago, sadly. Real life tends to get in the way of being able to dedicate an entire weekend purely to making games. But the planets have aligned and I actually have the time, and it is totally on!

Who knows how much I’ll actually get done though. I’m being a rebel with how I’ll be making my entry. It’s going to be an almost entirely barebones wrapper around SDL2. However, since SDL2 is such an awesome library, it does allow for quickly being able to throw stuff on the screen. Hopefully that’s enough! My full tech stack will be as follows:

Languages: C/C++, Lua

Libraries: SDL2 (+ SDL2_Image, SDL2_TTF, SDL2_Mixer)

Graphics: Pixen

Sound: SFXR (no music, as I can’t compose worth anything. but I can click a button until I get something that sounds good to me!)

Sadly, I was originally going to try and compile everything to Javascript so I could just dump my game onto a website and be done with it, but Emscripten doesn’t work with SDL2 yet. So it will be initially submitted as an OS X application, and I will get it working for Windows as soon as possible after the final version of my game is uploaded. Thankfully, Lua is super easy to compile across platforms, and SDL2 has binaries for almost every platform under the sun, so it should be super easy to get it working for Windows. I’ll just write basically everything in Lua and I’ll be good to go.

Looking forward to it, let’s make some awesome games this weekend everyone!

Per the (newly rewritten) rules of the competition, I am posting a link to the code that I have already written in preparation for Ludum Dare 29. It is freely available on my Github at: https://github.com/Freezerburn/ld29-engine

Please note that it probably isn’t that great. It’s mostly a light shim over SDL2 so that some functions can be used from Lua. I’ll likely be modifying it slightly during the competition to add support for some things, such as sound. Right now it will only work on OS X, and should generate a nice standalone app which will “just work”. It statically links in all SDL code, and the xcodeproj declares all the dynamic libraries it needs to link against. (which should be available on all distributions of OS X, as they are super common libraries/frameworks) main.lua is the starting point, and all you need to do is add logic in there, or add some more Lua files into the “lua” group in Xcode which you can require. Don’t touch the topmost line of main.lua, as it sets the path that Lua will be looking for source files to require.

I’ll be updating the code after the end of Ludum Dare to also be able to build for Windows. I need to be able to release my game for Windows so people can actually play it

So it’s been 24 hours since Ludum Dare started and I furiously started hammering away at my keyboard, hoping my facerolling would somehow end up with a playable thing on the screen. A lot can happen in that time, so I’d like to share what my first half of the journey has been like so far. Both good and bad.

The good:

• My choice of tech. Lua is a wonderful language for getting things done quickly, and with the work I put in before Ludum Dare started, I was able to get simple things up and running in an extremely short time. (or at least what felt like an extremely short time) Adding new features and putting the various bits and bobs my game needs together has been an absolute pleasure and very easy. It has only taken me a couple tries for each thing to get something most of the way, if not all of the way to where it needs to be. SDL2 is also a fantastic library to build on top of, and puts in basically all the features I need. I don’t even need to create bitmap fonts, because I can just generate all the glyphs I need at runtime, in any size, color, etc.
• Choosing to do a top-down perspective for my game has been great. While the perspective is wonky for putting together the graphics, the basic movement mechanics were basically done within a few minutes.
• Low-resolution graphics + blocks for all the things = simple collision and almost no performance penalty for drawing. Make the code ALL the sloppy, and still get away with it.
• Working with code I wrote the entirety of makes it so easy to do things. I don’t have to look up some method to do something for me, or scour the internet for some odd/subtle bug/feature, I know everything that is available at all times. I can even go modify it quickly and easily, because I know every line. This doesn’t outweigh the benefit of really knowing an existing engine, but it is a nice benefit as I don’t really know that much about most engines out there, and that could cause me to take a very long time to implement something that only took me a few minutes with my own code.
• Using mixins with a bunch of reusable components/entities. I need to throw up some debug walls quickly, and don’t have any graphics? Mix in the ColoredRect component, and I’m good to go. I need a bunch of animations for my main character? Animated takes care of that. Very nice indeed.

The bad:

• Using my own handrolled “engine”/code definitely adds a lot of complexity to getting from the start of wanting to do something, to having finished that thing. I have to craft all of it by hand, right then. Not only does this take time, but it adds bugs. I didn’t have a library which can lay out lines of text for me, so I had to make my own for speech bubbles, and they don’t handle word separation correctly. It will just jump to the next line in the middle of a word, or not correctly align words in the middle of the bubble, etc. As a bonus, some of those bugs actually help with the general theme of what I’m going for, so it isn’t ALL bad.
• Not having a premade camera system/collision system sucks. Especially with a limitation of SDL2 where it won’t draw images outside of the window’s area, causing me to have to track two global variables and add them to every entity before drawing them. Also the massive performance drain of brute forcing collision detection, ugh.
• Without optimized game loops, collision, etc., it’s easy to run into massive performance issues. I’ve had my collision take greater then 30ms (when I shoot for 16ms) per frame, causing huge slowdowns. On top of that, with my current schema of disabling garbage collection in Lua so that I can manually ask it to collect garbage every few frames, but only when time is available, I can hit problems where enough time is taken that the system decides it doesn’t have enough time to collect garbage, and pile up garbage infinitely. It hasn’t been too uncommon to see my game start taking 700+MB of memory suddenly, because it didn’t have enough time to let Lua reclaim memory.

At this point, I believe the game is largely “feature complete”, in the sense that I don’t really need to put together many more features in order to finish making it. I largely need to make a bunch of assets, define all the levels, and put together some rudimentary story. Hopefully it all turns out relatively interesting, and I can complete everything I want before the time runs out tomorrow. Honestly the full game is still going to be pretty darn simple. If I get lucky, it might even have some fighting mechanics at the end, if you can even find the actual end

On the topic of this year’s theme “Beneath the Surface”, I went a little bit less literal. My game has nothing to do with subterranean exploring or the deep ocean, but instead is going to have a main part of the game you play, with something hidden “beneath the surface” that you have to find. You might get subtle hints while playing the game as to what’s really going on, but you might have to pay attention to see them.