Home | Rules and Guide | Sign In/Create Account | Write a Post | Reddit | #LD48 | #ludumdare on irc.afternet.org (Info)

Ludum Dare 31 — Coming December 5th-8th 2014! — Join the Mailing List!
Also check out the Ludum Dare 30 results!
  • Ludum Dare 31 begins: in 76 days, 2 hours, 56 minutes, 50 seconds
  • (Time might be off, we’ll have it right soon) | Real World Gatherings (Now Open!)


    Post mortem: De-evolution

    Posted by
    August 30th, 2012 1:11 pm

    Play De-evolution.

    This was my second try at Ludum Dare, and in the end it was very similar to my first attempt, Tin World — it’s a side-view shooter where you walk right and shoot enemies. But it wasn’t supposed to be like that. I spent half a day thinking about a game that would use the theme nicely but at the same time be simple enough for me to make and tweak in the limited time. Nothing. Then I started sketching things to find inspiration. Somehow only guys with guns as simplified monsters were drawn. I posted my drawings here, and somebody suggested a gun that would evolve or de-evolve things, similar to the Portal gun. Then I decided to go with similar mechanics to the last time, only more advanced.

    The good:

    Graphics. Basically, I used the same technique as the last time, but with some more time spent on the details and more character to the main character. I’m rather happy with the effect — the black-and white, sketchy pictures, with a white outline, animated by moving them around — no frame-based animation. It was inspired by the minipato anime, by the way. A lot of people seem to praise that in the comments, so I will certainly stick to it in the future.

    Scrolling. That’s something that I planned for my previous game, but didn’t have time to do. No I planned to have scrolling from the beginning, and it’s there. There are some tricks to keep it very efficient even with limited PyGame options, but I think it works quite fine.

    Level. This time I decided that I can’t just randomly throw things at the players — they need to have a level that is designed, so that they can actually finish the game. I really like the feeling I get from finishing games, so I wanted to have it here.

    Release. Last time I did some experimenting and managed to package the whole game in a single exe file for windows, and an executable zip file for all the sane platforms. I used the same approach this time, and it worked without any problems — preparing the release took me 10 minutes, including booting an old windows laptop for it.

    The bad:

    Controls. In my previous game, people complained that the controls worked sometimes, and sometimes they didn’t. After some investigation it turned out that people didn’t realize that they couldn’t move after shooting, while the weapon was being reloaded. I introduced that, because I wanted them to think a little before shooting, to make sure they will have the few milliseconds to reload safely, before pulling the trigger. It didn’t work, turns out players just want to move all the time and don’t want to plan their trigger pulling. Fine.

    This time I really made sure that you can move around freely from the beginning. I even added some nice inertia effects to make all the movement super-smooth, and I made it possible to move around quite fast. That was a mistake — people complain about the inertia making it harder to control the character. A second mistake I made — despite the experience from the previous Ludum Dare — the energy gun didn’t feel powerful enough, so I made the player character stop while shooting it. Soon enough I saw my mistake — the very first comment complains about “lackluster” controls.

    I think I have learned my lesson: never stop the players from moving their characters.

    Difficulty. My decision to have a designed level backfired at me. Or maybe it was just that I underestimated how much work it would be to make it. Anyways, the level is much shorter than I wanted, and because of a last-minute change to the last wave of enemies, the game is insanely hard — almost unbeatable. You seem the last monsters were initially very weak (but lots of them), but then I decided to add some variety, and since it’s at the end, and I didn’t have a debug mode, that part wasn’t tested as often as the others…

    Code. In my last game, I used some clever tricks to make all the animations and effects easy to code (I used python’s iterator generators for effects). This time I went with a haphazard approach, just doing random stuff that seemed straightforward. The code is a mess and much more elaborate than I would like, as a result. I will stick to the generators in the future, they work really well for this.

    In summary, I’m really happy that I finished a game, but a little disappointed that it turned out to be very similar to the last one. I hope to really get a better idea next time. I will definitely stick to this graphics style and iterator generators, but I will make sure you can always move.

    Leave a Reply

    You must be logged in to post a comment.


    All posts, images, and comments are owned by their creators.

    [cache: storing page]