Monthly Archives: September 2013

Ludum Dare 27 – Postmortem

I made excellent plans for this past weekend’s Ludum Dare. And then I ignored them.

Friday, 9pm EST – Competition begins

The theme, “10 seconds”, seemed innocent enough.  My plan was to a) spend an hour or two considering the theme, b) spend another 2 hours developing a quick and dirty prototype, and c) get some sleep before the real work began.  If I wasn’t in love with my idea in the morning I would restart the process with a new deadline of 12 noon on Saturday.

The fist hour went by, I felt inspired to work, but none of my ideas would stick.  A pattern emerged:  “what about a game based on 10 seconds of X”… too obvious… “what if I took game mechanic Y and put a 10 second limitation on aspect Z”… too forced.  This cycle repeated itself many times.  Many times.

About 2am I realized I was getting nowhere.  I had ignored my plan and wasted precious hours.  I decided to call it for the night and start fresh in the morning.  I still had until 12 noon to get back on track.

Saturday, 9am – Not so well rested

Couldn’t sleep much.  I’m exhausted. I hate this theme. I hate every idea. This is not going well.

I tried getting out of the house. I tried going for a walk. I tried watching a movie. None of these steps could overcome the fact that my head was not in the game. How did such a simple (albeit ambiguous) theme bring me to my knees? I really can’t say. Eventually, I had a breakthrough. The idea….

Let’s Remake Skifree!

nothing comes close

Now we’re talking. I can make a clone of my beloved Skifree, which I haven’t played in at least a decade. I don’t want to completely rip off the original, so I decide to add some twists:

  • present the world in 3d
  • replace the skiing with driving a segway
  • add physics-based ramps

It did not occur to me until after creating the model that I had no idea how segways actually work. After a failed attempt to model the gyroscopic forces with a pendulum, I had a better idea: add a third wheel.

A few hours later I had a tricycle

a little ambitious...

I underestimated the complexity of modeling drivable machines and their physics. My tricycle worked (front-wheel drive and steering implemented in a rather naive approach in Unity), but if you tried to turn at even a moderate speed the system would become unstable, either shaking uncontrollably or tipping over outright. After another 2 hours of research, I discovered that cars (or motorized tricycles) in video games can require the very same remedies found in their real-world counterparts. So in this case, I added a sway bar.

Each time the physics simulation ticks, I sample the amount of travel in the suspension. Comparing the values in the left and right wheel, I compute the rolling force acting on my model and apply and equal and opposite force to counteract it. This provides an impressive degree of stability, and my demo is starting to take shape. The only downside is that it took an incredible amount of time to complete.

Feature Creep

Another idea: adding real-world sounds to my game. I walked out to my car, popped the hood, and started recording short clips of the engine:

  • at idle
  • at 3000 rpm
  • at 5000 rpm
  • spinning up from 3000 to 5000 rpm

I isolated the sections of interest and tried to normalize their volumes, then I went to work getting Unity to blend the tracks at runtime according to the state of the throttle in game. This was a lot of fun, and a colossal time sink.

It’s approaching 3am and I definitely need some rest.

Sunday, 11am – crunch time

10 hours to go.

The competition was ending soon, and I still didn’t have a game. I needed to find some way to wrap my work into something cohesive, and I needed to do it fast. I think I made the same decision any great game developer would make in this situation…

Bring on the guns

tricycle with guns

I added guns.

Mix in some GoldenEye for good measure

I whipped up a faux multiplayer environment, where the player gets to control all 4 opponents at the same time.  Why create an AI when you can battle yourself instead?

There was a glimmer of hope. And then the inevitable happened: a bug. There was a bug in my camera code, and it manifested in the most painfully seizure-inducing manner possible (see my previous post for a video of that tragedy). I tried desperately to identify and eliminate this bug, but my time had run out.

The 48-hour deadline comes, and goes

At 9pm I decided to call it quits (for the night). I didn’t want to look at my work, and I most definitely didn’t want to look at any of the hundreds of successful titles that had been submitted while I was busy failing. I cracked open a beer and walked away from my computer. I was utterly defeated.

A glimmer of hope

I woke up the next morning knowing exactly what I had done wrong. Within 15 minutes I had my camera code working appropriately, and I was ready to submit my game. It was too late to submit as part of the solo competition, but the “Jam” format allows up to 72 hours for development. Better than nothing, right?

What did I learn?

  • don’t throw away the first 12 hours
  • pick an idea and see it through
  • be wary of feature creep
  • keep trying

I’ll give this another shot in December.

Ludum Dare 27 – 10 Seconds

I made dozens of mistakes during the initial 48-hour competition. With ~1 hour to go, I ran into some frustrating linear algebra problems that led to wild camera behaviors. For posterity:

I didn’t want to give up entirely (actually I did but my wife convinced me to stick it out) so I fixed things up and submitted a revised project to the 72-hour JAM.

Click here to play the game

Click here to see the competition entry page