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 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.

Tags: postmortem

Because there seems to be a lot of talk about creating a multiplayer game for LD. Thanks, jolle!

Tags: motivation

I’ve been waiting for this day since the last LD.

For GNU/Linux users, don’t forget there is a handy-dandy Makefile I created on the wiki to make creating timelapse videos a cinch! http://ludumdare.com/wiki/ld13:linuxtimelapsemakefile

Good luck to all involved!

So the theme is Roads. According to the voting results, it was the only one with a positive number of votes overall, and yet the IRC channel is erupting with people surprised that it was the theme that won out.

What are some ideas?
– Building roads between cities to facilitate commerce.
– Managing traffic congestion.
– Planning/Acting on The Road Ahead for your life.
– Maintaining a small town’s roads.
– Transporting materials along a long road.
– Find your way without a map, searching for a lost road.
– Strategically shut down certain roads to guide a getaway car to the police.

There are plenty of ideas, and I’m sure I’ll come up with more.

Tags: motivation

I liked the idea of the police strategically blocking certain roads so that the criminals can’t get away. Road Lockdown is my current name for the project, but it might change. B-)

From this mock-up, you can see the red getaway car of the criminals as well as the squad cars blocking the roads. I think I’ll keep the road images for the final game, and the cars seem to have come out fairly nice, I think.

I think I’ll go to sleep now. Tomorrow morning I have a lot of coding to do.

After getting some boilerplate code down, I took a break to have lunch:

Peanut butter, cinnamon, and raisin sandwich, plus some blue corn chips and hummus, washed down with Tutti Frutti flavored Jaritos. Also, some carrots (not pictured).

I spent lunch and the hour after trying to nail down a specific direction to take this project. Here are my design notes:

I’m still hoping to get basic game play by dinner today. We’ll see how ambitious a goal that is.

Tags: foodphoto

I finally got the game to include buildings and roads. As you can see, the cars don’t know about them yet, and in fact they drive over them. Now that the game is aware of the concept of intersections and buildings, I’ll be able to randomly place the Bank and require the cars to only make turns at intersections.

It’s hard to see from this partial screenshot, but the getaway car has reversed direction after hitting the road block. The road blocks are temporary and disappear after some time, and you place them by pressing the space bar.

Only six hours left to go. I still want the getaway car to rob banks, make turning decisions to avoid road blocks and the player’s car, and, you know, get away. Oh, and I need to put roads back into the game. B-)

Here’s the final entry with link:

The binary-only download is about 1.5MB in size.
http://www.gbgames.com/downloads/ld13/roadlockdown-gbgames-linux-r71-test.tar.gz

FIXED SHORTLY AFTER THE DEADLINE: http://www.gbgames.com/downloads/ld13/roadlockdown-gbgames-linux-r77.tar.gz

I’ll leave the old version up in case anyone is worried about cheating, but I managed to fix all of the little bugs that were preventing it from being a real game. I’ll have source and a Win32 version up soonish.

EDIT: Source! (8.3MB)

ANOTHER EDIT: I have updated the build scripts for my game so that I can build both the GNU/Linux and the Win32 version at once. For both versions, the game should run as expected instead of requiring some tweaking on your end. For the GNU/Linux version, if running “roadblocks” doesn’t work, you can try the “roadblocks.bin” file assuming you have the right libraries installed.

GNU/Linux tar.gz file (1.5MB)
Win32 .zip file (1.7MB)
Source .zip file (9.9MB) Hey! It includes the custom libraries, too. The actual source is much smaller.

Tags: final

Don’t forget to get crackin’ on themes!
http://www.ludumdare.com/wiki/ld14:themes

I’m ready. As always, I’ll be using C++/libSDL, building on my Linux-based systems for both GNU/Linux and Windows users. I’ll be using The Gimp for art, sfxr and Audacity for sound, and good ol’ pen and paper to jot down ideas and designs.

For Linux users interested in creating a timelapse, I’ve provided a simple Makefile that should work for you, linked from the LD Wiki: http://www.ludumdare.com/wiki/ld14:submit#optional_fun_things

I already posted about LD #14 on my blog, I’ve tweeted about it @GBGames and I’ve double-checked that I had all the tools I needed.

Unfortunately, I have a birthday party to attend tonight, so I won’t be there for the start, but I will be receiving a text message from my lovely girlfriend letting me know what the theme is once it is announced so I can think about it while I drink.

Good luck to everyone! Have fun!

Tags: twitter

Tags: motivation

A healthy breakfast: a banana, a bowl of Trader Joe’s Twigs, Flakes, and Clusters (which sounds horrible, but tastes great actually!) covered with blackberries, and washed down with good ol’ orange juice.

Another idea came to me while eating: Remember the game Rampart? How about building walls to surround resources that you use to defeat your enemies instead? BRILLIANT! Maybe.

Tags: foodphoto

I was originally planning on sketching out some basic designs for each of my main ideas, but I had a lot of fun making the one I started with that I decided that it was the game I was going to make.

As you can see, I had some snacks while working on this one: blue corn chips with garlic lover’s hummus.

And here’s a close-up of the initial design:

Tags: foodphoto

I woke up, decided to start coding, and saw this. It was slightly disheartening, but I’m trying to look at it as a good thing. Somehow.

Tags: motivation

One of my favorite things to eat is a crispy, crunchy Granny Smith apple.

Ok, so if you saw my previous post, you know that I have absolutely no code, and the first 24 hours are almost up! So as soon as I decided to start filling my project directory with brilliance, I’m attacked for my ambition:

She always does this. I could be idling away online for hours, but as soon as I want to do something productive, guess who is crawling on my lap and over my shoulder, preventing me from computering? Gizmo, you’re lucky that you’re cute.

Tags: foodphoto

I had a good night’s sleep, got some coding in, and have decided on a plan of attack that should result in a completed game. But I have less than 7 hours left. It’s going to be tight.

First, I moved the laptop from the living room to my office. I had to clear a place for it on my desk, which meant moving papers and books to the coffee table in the living room, but what’s the point of having a dedicated work space if I don’t use it? It will be a lot easier to focus just by knowing I’m in a place to do just that.

Second, I showered. It’s almost subconscious, but knowing in the back of my mind that I hadn’t done so today is distracting.

Third, I had lunch:

That’s an awesome-tastic peanut butter and Nutella sandwich that I washed down with apple juice. Note the shout out to all LDers, everywhere, especially those who are essentially making an entire game in the last 7 hours of the competition. This sandwich was for you.

So, I’m clean, I’m full, and I’m in an environment conducive to hardcore concentration and hacking.

Now imagine I put on shades when I say, “Let’s do this” in as bad-ass a way as possible.

Let’s do this.

Tags: badassery, foodphoto