My Ludum Dare entry, Sporg, isn’t very good.
I had a lot of fun writing an entire game in 48 hours. I chose to start from scratch (rather than take the option of working with an established self-created codebase or ‘game maker’ program), because I wanted to make the process as challenging as possible, and challenging it was.
I spent a good fifteen minutes designing the game, and the rest of my work time creating the media assets and writing the game. Fifteen minutes seemed like plenty of time, I had a reasonably good idea and figured I could work out the rest of the details as I wrote. This is perhaps best exemplified by me ‘finishing’ the game at around 9:30PM Sunday night, and then realising I hadn’t created any levels to actually play. So the game had no levels and had not been playtested. I threw a couple of maps together in bed, and then a few more on my morning commute, and submitted the game from work.
The levels are uninteresting. This is half lack of careful level design, half lack of assets to actually include in the levels. Some decorative tiles or animation would have compensated a little, but the limited gameplay mechanic really limited what I could do with the levels. Ultimately you’re either trying to time a dash past an enemy, or trying to have one enemy shoot another, which doesn’t create a great range of level design possibilities. Different enemy types (with different rotation speeds or patterns, or perhaps even movement or multiple hit-points) would have added a lot of gameplay options.
The game is slow. I didn’t really appreciate this until I saw someone else play the game and look away from the screen to talk to someone, without taking their hand off of the movement controls. The game is so slow that the player could have a conversation without having to worry about getting shot or reaching their destination. I could try and blame this on Pygame, (the development library used for Sporg), but it’s really an artifact of rushed development without adequate planning. It also didn’t help that I developed the game on my i7 920, and most people seem to still be running single core netbooks or something equally underpowered. I did actually do some of the work on an eee901 netbook, but obviously didn’t playtest the game enough to really notice.
Dodgy collision detection! Getting stuck on the walls, getting hit by shots that you might argue should have missed, having the enemy blast you through supposedly solid corners.. I was aware of these issues through development but postponed dealing with them. To be fair, I feel I made the right choice in prioritising the other issues which did get fixed, such as the horrible flickering issue and stuttering sound which were absent from the released version.
Next Ludum Dare, which I hope to participate in, will be different:
- DESIGN – I will give over a much greater portion of time to designing the game and it’s gameplay. I think I need to dedicate at least two hours, though perhaps not in a single chunk, in order to produce something that I actually want to play after I’ve written it.
- TESTING – Must test frequently! It’s better to produce a game with only 50% of your intended features working 100% than to implement 100% of features but have them work only 50% of the time, no?
- LEVELS – Or maps or whatever is appropriate. The game engine needs to be completed with plenty of time left to develop an interesting gameplay experience to play through.
- SCOPE – All of the above points are going to require time, which has to come from somewhere. I think perhaps the most important aspect for anyone developing a Ludum Dare game is to keep the scope as tight as possible. Focus on a small set of mechanics, features etc and do them well in a way that allows the player to experience what it is you dreamed up in that design period, rather than be distracted by incompleteness and bugs.
