I too was waiting until after seeing the final results before I would post my post-mortem.

First I’d like to say well done to everyone who took part and completed a game within the time limit, and thank you to everyone for giving me honest reviews. I had great fun taking part and learned an awful lot about game development during and after the contest.

(post mortem continues after the break) (more…)

Post mortem, thoughts on things, etc. This post is mostly just going to be me rambling about my game, and this particular Ludum Dare. Basically, I didn’t really like the theme. Sure, it’s not a bad theme, really, but I couldn’t think of anything original to do. My ideas pretty much went from “Climb the Tower” to “Tower Defense” to “Build a Tower”, and back. Honestly, both styles of games would be pretty cliche, and I didn’t really want to do that. I figured there’d be plenty of other games with these basic rules, and I was right. That said, there were plenty of awesome and inventive games made too, and games that took these ideas and turned them on their head. Congratulations to everyone who submitted a fully fleshed out game, and good job to those who worked all weekend. I am not one of those people. (Rest of this, plus solution to level 3 after the more.. link

(more…)

My 2nd Ludum Dare didn’t go as well as my first. While I managed to get Tower Defender submitted, it can’t be called a game so much as a tech demo.

What Went Right:

• Simple game mechanics still work.

  Like my LD#11 Minimalist entry, I wanted to use simple mouse-movement-only controls. I feel that mousing over your units to make them attack made sense, and while I only had archers available in the end, it seemed to work. It’s too bad there wasn’t more of a game built around the mechanic, but I intend to flesh it out after LD.

• I had an office door I could close.

  My cats are incredibly reliable. If I am doing anything that looks like productivity, they will insist on sitting on my lap, resting on my arms, and otherwise preventing me from working. Being able to close the door on them helped keep me focused on game development. Towards the end I got lax about keeping the door closed, but the cats left me to work for the most part.

• Using Test-Driven Development

  Test-Driven Development, or TDD, is great for designing your code. Also, since code changes often, you can feel confident that your changes won’t break functionality since your tests will tell you if they did break. More than once, I was surprised that a seemingly innocuous change resulted in failing tests, so I was able to keep the game working at all times. I know that I wouldn’t have caught one specific crash problem right away, and it might have resulted in a non-working game for hours, preventing me from submitting anything. Since I found those problems sooner, even in code that wasn’t directly being tested, I felt that using TDD was the right thing to do.

What Went Wrong:

• Learning Test-Driven Development while using it.

  I know quite a few people would disagree with the use of TDD during Ludum Dare, but I think what burned me was my inexperience with implementing it. I spent too much time trying to figure out how to apply it to rewriting code that I already had written. My first bunch of tests were helpful, but all I ended up with at the end was a slightly smaller Game class with a separate Timer class, and it seemed that if I applied TDD to the entire project I would barely have an SDL window by the end. While my normal projects might benefit from test-driven design, my LD game needed to get finished in 48 hours, so I had to alternate between writing tests first and skipping tests. I’m sure once I get some TDD experience, I’ll be much faster and know when it is in appropriate to write tests. For LD#12, it was a learning experience.

• I still didn’t have a good handle on SDL

  Last LD, I noted that I hadn’t practiced using SDL much, and right before LD#12 started, I realized that I still hadn’t done so. I never had to render animated sprites in SDL before, and I skipped it in favor of static images moving around, but not before spending precious time learning what I would need to do it. Again, there was too much wrestling with technology instead of game development, and this time it prevented me from finishing my game.

• Working long hours really does screw with your productivity

  It’s common in the programming world to find people working Twelves, especially in the game development industry. Crunch times are intuitive. If a project needs to get done in a week, and there are two weeks of work to be done, then have everyone work longer each day. Well, it is common knowledge, even if that knowledge isn’t applied, that working longer hours doesn’t translate into greater productivity.

  I experienced these issues firsthand with the 2nd day of LD#12. I realized I had worked about 12 hours straight by the end, and I was making sillier and sillier mistakes. Sometimes my tests would save me, but since I didn’t write tests for a good portion of my code, I had to figure out what I did wrong most of the time. Bugs were finding their ways into my code a lot easier, and debugging was painful. When I did LD#11, I got plenty of sleep and took frequent breaks, and ended up with a finished game. I wonder if I could have done LD#12 better if I took a few more decent breaks during that 12 hour stretch.

• I didn’t get game play until the very last minute.

  I knew that getting game play up as quickly as possible was important, especially in a timed competition, and yet I believe I struggled so much with the technology that the game didn’t start to form until I had minutes left to package it up and submit it. I think if I had used a few more hours in a productive way, I could have made something enjoyable.

What I Learned:

• I still have a lot to learn.

  It’s weird when you feel confident going into a competition like this and then hit a wall due to your own lack of knowledge. I was depending on TDD, SDL, and common game programming concepts such as OnMouseOver, but I didn’t have much experience with them before this competition started. I like using LD as a learning experience, but next time I’ll focus on learning only one tech or tool for LD at a time.

• Test-Driven game development is awesome.

  Yes, the learning curve slowed my productivity down, but I already saw many benefits from using a test-first design for my coding. I could see that my code base was going to be much better for it, particularly in terms of my ability to make cross-platform games, but I had to stop applying it due to time constraints. I was already trying to incorporate TDD into my main development before LD, but now I see that it’s going to provide better benefits than I originally thought.

• I need to work on my pacing for LD.

  It seems most of my productive work happens during the 2nd half of Ludum Dare, and it makes me wonder what happened during the first 24 hours. I saw that more than a few people had working prototypes up and running within a matter of hours, and I want to make sure my future LD entries are in a playable state as early as possible, too.

Once again, 48 hours resulted in a bunch of code and experience I didn’t have before the weekend started. Even though my submission can’t really be called a game, it has potential, and I had a lot of fun working on it. The next LD is in December. A few months should give me time to develop my skill and technology base.

This was my first Ludumdare entry, and not knowing just what I could manage in 48 hours I decided to stick with a simple idea and tools and libraries I’m familiar with. The original game idea was to make the player hit all the walls in a 2d space with a trickier-than-usual to control ball, although this didn’t quite work with the Tower theme. Hence, I decided to turn the walls into a scoring mechanism, and to make a tower to ascend or descend instead.

(more…)

Here’s the postmortum I promised last week.  I haven’t read the comments on my entry yet and I wanted to get my thoughts down before I did.

THis LD48 was my third, if you don’t count the two that I intended to enter and never did.  My number one goal was to finish, and the number two goal was to do something fun.  I’m happy that I completed goal number one, but failed on goal number two.

Technically, I didn’t really even submit a game.  There is no real end condition or repeatable system that goes until you fail.  I never got a chance to actually implement the “monster at the gates” scenario, as I fought with a stupid bug at the end brought on by stupid changes on my stupid part.

What did I do wrong in the LD12?  I didn’t spend enough time on it.  I should have squeezed three or four more quality hours in.  My mother-in-law was visiting, and that led to the normal distractions as she visited with us and our newborn.  I probably could have completed something that resembled a game with a little more time, and I know that the time existed.  I just didn’t use it well.

I didn’t get any real animation done with the monsters or the dude.  It would have been nice, but time didn’t allow it.  I also used some sound, and while it wasn’t nearly to the level that I wanted it, I thought it was neat to hear the monsters gargle when they died and the arrow whisp away from the dude on the tower. 

I think my usage of the angle/power aiming mechanism was a bad idea.  I think I should have gone with the “point-and-click” method, which would have been easier for the user and fits better with the action oriented design.  The arrow was made up of separate graphics rotated to the closest 15 degree mark.  I could have implemented a rotation transformation, but that would have taken longer and probably been more CPU intensive.   

So what did I do right?

I met the theme of the Tower by simply having a tower in which the dude fired from.  I didn’t stop there, and created a middle floor from him to fire from and also made the doors at the bottom open and close.  The tower isn’t just a pretty graphic.  It’s functional and strategic.

The part I liked the most about my entry was the graphics.  Most of them were sketches from my initial game idea sheet.  I scanned it into the computer and photoshopped color into it and cut it into separate parts and images.  I think it gave my entry a unique style that I’d like to use again in a future competition.  I’m not a great artist, but I think if I don’t try to make everything perfect, it comes off better.  Reminds me a little of the original South Park or other ‘construction paper’ style.

Another thing that I really think I did well was keeping the coding distractions to a minimum.  By this, I mean that I didn’t get sidetracked coding something that wasn’t important ‘right now.’  In the past, I will start to code something that may come in handy later, but doesn’t really help me too much in completing more important foundation pieces.

So all in all, I think I did ok.  I can see that I learned some things from the last time around and I really look forward to taking the things I learned here for LD13 in December.  Same goals, but I will try to think through the game for a little while before coding to make sure that it is actually a game and hopefully fun. 

I would call my game Incoming Fodder both a minor success and a minor failure.

My goal for this competition was to create sound and music in the game, and of course it must be playable. So I made a lot of sound effect, some good some bad, mostly bad when things get crowded there are so many sfx playing it’s annoying. The music, or what you might call it (You can kill the music) was a complete failure. There was a MOD player lib for flash that I though would be awesome to use, took about an hour to get it to work.

Then I needed to create music. I suck at composing, I know it, doesn’t matter what tools I use, it’s just awful. I might have a tune in my head, trying to get the music to sound like that never ever happens. So I scribble down something trying to make it sound like music, copy paste. Crap, I better sing the tune next time.

I chose flash 9 as platform, that was good. Learned a few valuable things, like it’s not easy to pause things running with event listeners without preparing for that before you build your system. I had to skip pause, lost some time there.

Game play wasn’t as developed as I wanted. I really don’t know why I didn’t have time to improve here, I picked the idea of the game so I could spend more time on polish, but I guess I wasn’t interested enough in the idea to really devote to it. I need to be quicker in this area. I need to focus on that in the next LD.

Coding OOP is lovely, I had one moment of awesomeness this time. I’ve built a tower that can shoot arrows, then I built a castle to protect, after a while I realized that the castle also should shoot arrows, so I made castle inherit tower and voilà it shoots arrows! I did have to make it own 3 more towers to make it have 4 arrow shooters.

Graphics was the least of my priorities and it turned out ok, the defeat screen it the best of the whole game.

Timelapse. You may recognize the music

Preface

Since I’m only a few months into my game dev journey, I set a few concrete goals to ensure that I would finish with a game:

• Have gameplay decided on before bed on the night the theme was revealed
• Have gameplay/art 90% done by bed on Day 2
• Finish gameplay/art, do music, menus, polish, package, etc on the last day
• Also eat a lot of unhealthy food

The Bad

My Idea: My main concern was to make my game about owls. In the end, I accomplished this, but I should have thought it through more. After getting most of the gameplay implemented, I started to realize that the scope of my game was way too small considering the time I had as well as my ambition. I was sure that it was too late in the 48 to start over, and I lost motivation.

Motivation: (That was a pretty direct segway.) I didn’t really feel like finishing my game. I didn’t put much effort into it until night fell on Saturday (awesome). That’s when I made the game’s song, and finished gameplay for the most part.

Packaging: I provided three versions of my game: an exe made with py2exe, an app made with py2app, and a source version. I guess I need more practice with py2exe. It took me a while to get my game packaged, and I even had to change some code in the game to make it work. My py2app experience was great, but the .app ended up being over 20 megabytes large. That sucks, sorry guys.

The Good

Music: I am really happy with the way my simple song came out for my game. I had a whole other song ready, but it just didn’t fit the mood of my game. The completion of this song actually brought me out of my motivation problems in the second-half of the competition.

Code: It should be no suprise that I had no trouble implementing this game. There’s really nothing impressive about the way it works. Some aspects are even quite underwhelming, such as the collision perhaps. Overall, I got to spend some quality time with vim and python…what more could I ask for?

Motivators: This section is pretty self-explanatory.

I Had A Wonderful Time: LD12 was a blast, I learned a bit and had a great time. A success overall.

Looking Ahead

I have a lot of ideas on how I can improve for my next LD. I feel like I can make a bigger and better game. I also think I can improve the efficiency of my music recording and packaging processes.

Thanks Guys

Well, I’m back from spending last week in LA at the siggraph conference. Looking forward to playing all the entries.

Here’s a link to my timelapse video. Thanks to Daz for the ETL screencap program he posted, which I used to make this (plus ImageMagick to add timestamps).

A quick postmortem: I was using this compo as a chance to experiment with Ogre3D, so I didn’t expect to end up with something too polished, but i did hope it would be at least playable, which didnt quite happen.

What went right:

• Ogre particles — easy and they look great.
• Art assets. I tried to focus on the minimum that I would need, and they turned out pretty good.
• Learning Ogre. I learned a lot more this way than just reading docs would have taught me.
• Great theme. I had a lot of good ideas for this one (maybe too many).

What went wrong:

• Camera — I spent a lot of time messing with the camera. Afterwards, i realized I should have just went with a fixed close-to-overhead camera.
• Starting with ExampleApp was more trouble than it was worth. In the end, I wasted a bunch of time rearranging it.
• Too many ideas: The theme generated so many ideas for me, I kept changing my mind and adding things. I should have gone with a straight up tower defense.
• Too ambitious. Didn’t get first-playable until Sunday.

I posted a little list of tips on LD Survival, and ended up ignoring almost all of them.  That’s okay, I had a great time and got a bunch of experience with Ogre3D.

A technical note: I was using Ogre’s OpenGL mode during development, and noticed at the last minute that the D3D mode was much faster. So the readme encourages you to use the D3D mode. However, I didn’t realize until afterwards that it blows up after a few minutes, so if you get everything flying off the screen, switch back to OGL. I probably forgot to initialize something.

Okay. Well first two days i was mostly getting feedback and trying to restore my brain to usable state Yesterday started to implement all changes that i hope will make game more fun.

You can still access old version and sources trough links in my Final journal.

And here is new version:

(more…)

It’s now Wednesday, and I finished my game Sunday evening. I’ve had a few days to think about it and my experience.

(more…)

Postmortem:

So I feel fairly recovered from the weekend.  I’ve played and reviewed a handful of the entries, and I’m pretty impressed by a lot of them.  So, here are my postmortem thoughts on the whole deal.

(more…)

Ludum Dare 12 is the first of this event that I have participated in, and I must say I had a lot of fun making my game for it. I learned a few things about game development in the process, many more to do with the actual process rather than technical details, but some there too.

(more…)

For like half of the LDs I’ve participated in I’ve said or thought that I would do a postmortem. But I never got around to it. Thought I’d do a postmortem this time to make up for it. And this time is one of those times that are perfect for postmortems, for several reasons. Like, I almost failed but didn’t. That’s great postmortem material, you know. But still, I’m lazy, so I’ll do the standard postmortem procedure of The Good, The Bad and The Other.

It’s long though, so be warned! Slightly updated 15th, new text at end.

(more…)

In one 48 hour period, I made a simple game based on the theme “minimalist”. I didn’t try to stay awake throughout the entire Ludum Dare competition, so the game was made in less than 48 hours.

What Went Right:

• Used my build script to create a distributable game from the beginning.

  I have a build script from a previous project that allows me to use a single command to take my project source, build it, and create a .tar.gz file to distribute for GNU/Linux users. Towards the end of the competition, I wasn’t spending too much time trying to figure out how to get my project into a judge’s hands since.

• Mouse control was easy to do and easy to use.

  Since I was learning SDL, I tried to make my game as simple to use as possible. I knew that using a mouse was a lot easier than expecting someone to use the keyboard, but I had never implemented mouse control in a game before. Luckily, it turned out to be very easy. As a result, the interface was very simple since you’re just moving the mouse around, and the game that this interface produced was better for it.

• I got really involved in it.

  I had food photos and a time lapse video, and I even received two trophies, one for my eclectic food choices. Hanging out with all of the other Ludum Dare participants, even if just virtually through IRC, was a lot of fun.

• I finished!

  Of course, finishing was also a lot of fun. While I could have used some more playtesting and would have loved some feedback before it was submitted, I think I put together a decent game in a short amount of time. It feels good to finish things.

What Went Wrong:

• My work environment was horrible.

  A couch is comfortable…but not for marathon game development sessions! My back still hurts. I need to clean my office. Right now, I am using it as a giant inbox:

  

  I prefer development with my laptop because the CRT of my desktop is harsh on my eyes. Still, it would be nice to sit in a real chair while working. Alternatively, I can finally buy an LCD for my desktop.

• My cats love to hang out with me.

  Even if I was sitting in my office, I know from experience that my cats would still jump up into my lap and try to rest their heads on my arm. When you’re using a laptop, there isn’t room for it AND a cat or two. Having an office door to close would help, of course, but the cats were quite a distraction for LD#11.

  

• I didn’t practice using SDL before the competition.

  It was a problem especially since I had decided not to depend on the Kyra Sprite Engine for future projects, but I really only used libSDL for input and creating a window prior to this project. When the first 24 hours are finished and all you have is a window rendered and the knowledge that the mouse handling is working (even if it isn’t visible), you might be afraid that you won’t have anything to show at the end of 48 hours. I did manage to pull it off, but by the next competition, I want to be able to work with less of a focus on technical details and more of a focus on game development.

• I spent too long in the beginning trying to mock something up in the GIMP.

  Similar to the previous point, I was spending more time on technical issues than on creation. I thought I was more familiar with the GIMP than I was, and I spent a lot of my early hours fighting with it instead of just using pencil and paper. The worst part about it was that the initial idea was one I ended up discarding, and if I wasn’t wasting time with figuring out how to do some simple things in it, I might have been able to figure it out sooner.

What I Learned:

• My kitchen goes to entropy during LD.

  When you’re focused on game development for most of your waking hours for two days, other things have to take a lower priority. One of those things was cleaning. I had a bit of a mess to deal with after the competition was over.

• Even something incredibly simple can be a good game mechanic.

  I knew I wasn’t going to be drinking multiple cans of Mountain Dew or Red Bull, and I don’t drink coffee, so staying up for 48 hours wasn’t going to happen. I needed to work on a game I could finish, so I picked the simplest thing I could. Surprisingly, it was fun, and some of the judges have said so as well. At the end of the competition I already had a list of ideas that could improve it, and I hope to release an updated version with those improvements.

• It’s possible to do a lot in a single day.

  Even though I spent some time learning how to use SDL, I still managed to make a game. The best part is that I can incorporate what I have learned into my personal library of code for my future projects. Also, there were over 70 games submitted, and it is amazing what some people were able to do in 48 hours. Some of them were learning how to program!

I set aside most of a 48 hour period, and I have a game, some new code, and more experience. If I could work on a project with a similar scope each month, I think it would go a long way towards improving my ability to create video games. Also, it’s a lot of fun, and I will definitely be participating in future Ludum Dare competitions.

I figured I’d post some more after thoughts. The contest went really well for me despite not having the whole weekend available to me. I had to go home to visit my father who was recently in a skiing accident. So, I’m happy with how things went.

Unfortunately, I posted my final entry early, and then I found a bug that evening when playing my game before going to bed after the contest ended. It was a minor thing, but apparently I would play my game exactly the same way each time, and thus why I didn’t find it until later.

Then after sleeping, I realized that while my directions on my menu state one thing, I had eased up on one game play element, making the game some what trivial. So, when I woke up Monday morning, I set out and fixed it. Looking at the comments so far, it’s too bad I didn’t think of fixing it sooner.

All in all, I think I spent about 12 hours or so on the project. I used Python + PyGame for the coding, the whole thing is under 400 lines of code. I used SFXR and Musagi for the sound effects and music. And I used my good old pals MsPaint and Photoshop for the graphics. I’m always amazed when I find myself going back to MsPaint for the really simple stuff I can’t do in Photoshop easily. I also used Audacity to convert my wav samples to off format for file size. And I used py2exe with the pygame2exe script to create the windows executable.

I wish I was able to comment to the feedback from voting.  If your confused about losing, you have to make all of the “invisible” frames (outlined in black on easy mode) appear first before clearing the screen of frames.  It was kind of a hard thing to explain.  That’s why I added the outlines on easy mode from feedback I got back from my girlfriend.  Of course, after you’ve played a couple of times, it makes more sense.  As for after figuring that out, there’s a strategy that guarantees victory, which I realized and fixed shortly after the competition.

So, I think that’s everything. For those looking for more of a challenge and how the game should have played, feel free to check out Framed! v1.2 (win).

I posted a postmortem of my experience on my blog here.  Check it out

I tried writing a post up in this thing but It kept on trying to eat it so I put my post-mortem here

well, i shoulda wrote this the day after, but whatever.

 this was my first actual entry in a competition on the interwebs, ever. HAVE MERCY ON ME! actually i couldn’t really come up with anything decent that didn’t require a physics engine. i didn’t have one ready so i had to make do with what i had. which was nothing. not even kidding. i had jack squat.

actually one of the ideas that came to mind involved a spin on games like bust-a-move and snood and all those. it was a spaceship game where you had to get to the core of a circular space station by knocking off the hull. the hull would be made of different colored hexes or circles and you would shoot colored shots that would connect to it if it was the wrong color, or pop them all and possibly break off sections. i actually wanted to have an asteroid field of random collections of these blocks that you could tractorbeam and catapult at the station. you’d have a weapon you’d have to charge and blast the core with once you had an opening. hmm. that’s still a good idea. i didn’t need a physics engine for that. why didn’t i do that one?

anyways, i pretty much kicked back and took it easy for the entire one. had alot of family trouble keeping me from the project, too. wasn’t a pretty scene there.

 so yeah. i’m sure i could have put more effort into the game, but it was a pretty crappy idea and i knew there wasn’t any substance to it. i saw it as one of the Dud entries, just there to fill out the ranks and to get my name out there. also, it was a chance to get some funnies in. i think i aughta score ok for that. got some giggles out of the gf, it did.

wrapping up, i’d say there’s no way i’m gonna beat out some of the other entries. they were looking super good and i knew i didn’t have a chance in hell. i had a blast though! good luck everyone!