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.

If you were waiting for the Windows versions of my game, Entar was gracious enough to compile a version for me. I put together a Win32 package, and the link is on my final submission post.

Thanks again, Entar!

My first time lapse was over 10 minutes long, and so I had to cut out a lot of the repetitive images to shorten it. I also found a way to combine music with it.

Ludum Dare #12: GBGames Time Lapse

Since I can never remember the magical incantations for getting mencoder to do anything, I created a Makefile and uploaded it to the LD wiki:

http://www.ludumdare.com/wiki/ld12:linuxtimelapsemakefile

Here it is. I’ll say more later.

Tower Defender. EDIT: This is a source only version, and it is 8MB!

EDIT: Get your smaller Linux-binary here: Tower Defender for Linux

EDIT: Get your Win32-binary here: Tower Defender for Win32 Thanks, Entar!

Unfortunately I only got game play in at the last few minutes, and there are problems. For one, there is no way to win or lose. The enemies don’t know that they’ve already stormed the walls and will keep going until they hit the sky, but they do this cool floating thing…which is a bug. Mousing over the archers will make them fire arrows, and they take a bit of time to reload before letting you fire again. The arrows do hit the enemies and make them disappear.

I’ll have a post-mortem up soon.

Gizmo tends to like to hang out with me whenever I’m doing anything related to programming. I nicknamed her Hacker Kitty. She’s helping me eat my vegan pizza and apple juice.

Diego, on the other hand, just wants to know when I’ll be done.

Well, I’m not done yet, but I have a few more unit tests, and quite a few more lines of code without tests. Progress is being made.

I was sketching out some of the interactions and just trying to make myself aware of what it is I am tackling with only 8 hours left.

Based on these notes, I think my schedule should be as follows:

• Code to draw tower based on height (determined by difficulty, a nice to have later on).
• Draw an enemy sprite.
• Code to move enemies up the tower.
• Code to determine that game is over if they reach top of tower.
• Code to mouse over an archer.
• Draw an arrow.
• Code to move arrow.
• Code to handle collision of arrow and enemy.

And after all of that, I should have a good base to work with. I’ll see how much time is left and make further plans when those are done. The cool thing is that I can start writing unit tests again for the classes I’ll be writing.

It’s strawberry flavored!

My kitchen is a mess and I’m out of clean glasses, but at least Jarritos doesn’t need a glass to be enjoyed!

And while taking the picture, I realized I have a bottle of…grape juice…and some clean glasses for it. Hmm…

The Knight Owl!

He’s 32×32, and I’m worried he won’t show up too well after all the work I put into it. Note to self: learn how to use the Gimp better.

Like last LD, I’m having a peanut butter and pickle sandwich.

Note that my LD-ification of the sandwich has serif fonts.

I was up until 3AM trying to get some functionality in my program before heading to bed. I woke up about five and a half hours later, showered, and am waiting for toast for my breakfast. As of this writing, there is a little over 12 hours left in the competition, and I don’t have game play yet.

I’ll be getting this submission in under the wire.

I’m starting to wonder if I’ll ever get back to TDD, but for now I have a main menu background.

I plan on starting this game by mousing over the start button, the same way Minimalist did. I like the idea that the menu gets you used to the mechanics of the game. Maybe I’ll have a mini tower drawn in with one archer waiting as the start button.

There are only 19 hours left, but I need some sleep. Good night!

The sad thing is that most likely I’ll end up using this background and the castle in the finished game. The stick figures will have to go, though. I didn’t mock up the archers, knights, or boiling oil, but that can come later.

I decided that I need more practice with TDD and so skipped quite a few unit tests to get a blank SDL window up that I can close. The 10 passing tests I currently have were great for splitting off a Timer class from my Game class, but I can’t afford to spend too much time making existing functionality work better.

When I start working on the various game entities, I know TDD will be a big help, but for now I have put it on hold to get the really simple run() loop going. Of course, in order to get to the point where I can write more code than the basic boilerplate, I need to sketch out a rough design.

I ordered the vegetable entree from a Thai restaurant, and the person on the phone asked me what kind of meat I would like. That’s why there is chicken. I also asked for vegetable egg rolls, which were smaller than I expected, but they did have only vegetables in them.

As of this writing there are only 23.5 hours left in the competition.

And my project is in bad shape. I have some decent notes, but the actual implementation is lagging. I have to remember that I still need to create art and sounds, not just code.

Will I make it? I should, even if it means cutting back on the scope of my initial design. I haven’t been writing as much code as I would have liked, but I’m not sure how much of it is due to the fact that I’m still learning TDD and how much of it is due to the fact that I’m practically reimplementing code that I’ve already written. Still, before my last break, I found that my coding time has been very productive, so perhaps I’ll see a working game sooner than I think.

I took a little longer than I expected to get back from lunch.

That’s a Turkey Twister sandwich on pretzel bread and fries, and I ordered a basket of tater tots. As you can see, I tried to make a tower. Maybe it is more like a ziggurat?

Here is the initial design I’ve come up with. Over a year ago I wrote down a one-liner idea about defending a castle, and these notes flesh it out a bit more.

I want a microphone because I really do want my knight to say “STAB!” when you mouse over him.