Join us on Twitter and IRC (#ludumdare on Afternet.org) for the Theme Announcement!

Thanks everyone for coming out! For the next 3 weeks, we’ll be Playing and Rating the games you created.You NEED ratings to get a score at the end. Play and Rate games to help others find your game.We’ll be announcing Ludum Dare 36’s August date alongside the results.

New Server: Welcome to the New (less expensive) Server! Find any problems? Report them here.

I’m leaving for a 2300 mile road trip on Monday morning, so I wasn’t planning on participating in this LD. But since I couldn’t sleep last night, I spent a few hours throwing together a VERY quick entry. Its called Polo, and its sort of like a single player Pong.

Last week I was at the Unite conference in Seattle. Seeing all the cool stuff going on there really got me fired up, so even though my entire Saturday was wasted flying back home, I really wanted to take part in this Ludum Dare. Sitting on the airplane on Saturday I decided that I wanted to make a Flight Control style game, but with space-ships and galaxies instead of airplanes. At the time, my idea to make the game unique was to implement a wormhole system that could be used to transport the ships across the map, but I eventually ended up scrapping that idea.

Even with only Sunday to work, I originally intended to make this a compo entry. At the end of the day though, while I had something playable, I wasn’t really happy with it, so I switched to the jam and took full advantage of the relaxed ruleset. Here is what the game looked like Sunday:

Monday, with the game now intended for the jam, I added some great music my brother recorded for me a long time ago. I’ve used it a couple of times, each time changing the pitch slider in Unity, and I’m always amazed at how different the mood can be at various speeds. I used the rest of the morning to polish and refine, adding textures and models, as well as a very basic UI using the new uGUI system in the Unity 4.6 beta.

At this point I was still intending to add wormholes, but while play-testing I decided I preferred the game without them. The way I had scaled everything in the game made the screen kind of full, and I thought having things instantly transported around the screen would be too messy. Instead I briefly started on a system to warn the player of impending collisions, but other engagements came up and I had to stop early.

What went well:

I’ve used LineRenderers in Unity dozens of times before, and had some sort of issue with their behavior literally every time. I was prepared for the worst this time, but fortunately they worked exactly as I wanted without any headaches.

I’m really happy with the way the Sun looks. It’s still basically just a solid yellow sphere, but I added a particle system at the center that slowly emits particles with a radius just slightly larger than the sphere and slowly rotates them. I lazily used the same sprite as I did for the explosion particle system, and I think it looks great for the amount of time I put into it.

Even though its dirt simple, I like the way drawing paths feels. I would have liked to add some smoothing to limit how sharp the ships could turn, but hey, it can’t all be prefect.

I did a good job of limiting scope. If you look at the source, you’ll see that everything in this game is extremely short and simple. This LD experience was much more relaxed than the serious time crunches I’ve had in the past.

I spent a couple hours avoiding making the skybox. In that past I’ve always either used solid color backgrounds, pre-made skyboxes, or made 2D games, so I’d never actually made a skybox before and was kind of dreading it. What I ended up doing was making a particle system that emits long lived particles from the shell of a very large sphere. It looks ok, took all of 5 minutes to set up, and I didn’t have to do any actual “art.”

What didn’t go so well:

I wish I had taken more time on the models for the ships. I made what was intended to be a placeholder model in about two minutes, but I didn’t end up improving it. What’s worse, I lazily reused the same material from the planets on the ships with no modifications. I also did that as a placeholder so that I could identify which planet the ship was supposed to go to, thinking I’d come up with a better system later, but I never got around to it.

Since the ships, planets, orbit plots, and flightpaths are all the same color, it can be difficult to see the ships when there are a bunch of flightpaths drawn near each other. I could have solved this easily with a real texture on the ships.

I’ve made “orbit” games in the past, and have a library of code that uses physics to simulate the orbits of planets and moons around a sun. It works great, but since I originally planned on entering the compo, I didn’t use it. The planets simply rotate in a circle around the sun, which isn’t too terrible. The moons, however, are just children of the planets, and rotate along with them. Many players probably won’t even notice, but it REALLY bothers me that the orbits of the moons aren’t accurate. On the red and green planets, the moons don’t move relative to each other, and it looks horrible. I wish I had at least used the same system on the moons as I did on the planets, if not done the whole thing realistically.

In the end, I’m pretty happy with Space Traffic Controller. I’m even more happy that I’m getting much better at setting a realistic scope in these game jams, and making a good, fun game within the those limits.

In the hour leading up to the theme reveal, I was landing a rover on Minimus in Kerbal Space Program, so the idea for a rover game dealing with transmission times seemed very obvious and unoriginal as soon as I had it. Still, my other ideas were way worse, so I went with it. I spent the rest of the night fiddling with Unity wheel colliders, as I’d had very little experience with them in the past. I called it quits around midnight with the game looking like this:

Saturday

Let’s get this out of the way. I am in no way an artist. I was very nervous when I woke up on Saturday, because I knew my idea would require textures for rocks and terrain, which I had never made. I didn’t even really know how to go about making them. For about an hour, I went back to work fiddling with the steering controls, thinking I’d probably leave the solid color look alone.

When it came time to move on to a new task, I decided that the whole reason I do these game jams is to push myself and learn new things. So, ground textures. I took a picture of my kitchen counter, opened it in GIMP, and just started clicking things until I had something that looked reasonable. (The Make Seamless filter in GIMP is awesome). I did the same for a few variations with rocks, and was thrilled with the results.

Moving on to level design. At this point, the intended gameplay mechanic would have the player driving around taking samples from specific parts of the map. I spent a lot of time designing the map, with hills, valleys, and obstacles that would require careful planning to negotiate in order to get to certain locations.

As my last task of the night, I added an articulating arm using hinge joints. It was terrible. I fiddled with it for a while, then gave up and went to bed with it looking like this.

Sunday

I woke up Sunday in a bit of a panic. I had spent most of Saturday on art, which is totally backwards from how I usually work. I sat down, threw away the hingejoint arm, and rebuilt it using configurable joints. These worked much better, though still far from perfect.

I spent the next few hours modeling the rover, adding a nod to Kerbal Space Program, the game that inspired me.

This is where the real problems began. I at this point had a playable game. The level was done. The rover model was done (although pretty bad). The controls worked, and victory conditions worked. BUT, I hadn’t yet added the 10 second delay to the controls. It was easy to do, and as soon as it was done, I realized I had a huge problem. The game was WAY too hard. The first time I played it through with the delay, it took me 20 minutes just to get to the first sample site. There were nine more to beat the level! In a snap decision, I decided to scrap the sampling, and pick up rocks instead. I tacked a basket onto the back of the rover and replaced the dummy “sensor head” of the arm with a grapple. I ended up putting the rocks very close to the rover spawn point, because anything else was just too difficult.

Crisis semi-averted, I threw together a quick menu screen and timer. With two hours left, I had two things left on my to-do list: audio and online leaderboards. But I also knew the 49ers game was getting ready to start, and I was not about to miss that (GO NINERS!). So, Signal Delay was done.

Monday

I wasn’t feeling very good about my submission on Monday, mostly due to the last minute and rushed changes. The HUGE lesson from this Ludum Dare is to implement your core mechanic as soon as possible. It is so terrible to get that far into development to find out that it doesn’t work.

But, all was not lost. The feedback I received was much better than I expected. Hearing from people that have played my game is by far my favorite part of Ludum Dare.

What Went Wrong

I waited way too long to implement my core gameplay mechanic

I skipped audio

Unity hinge joints suck

I focused on art too early

I wasted a lot of time designing a large level that ended up being unnecessary

Stopping a couple hours early so I can get ready for the 49ers game (GO NINERS!). Because of that, I didn’t finish any audio or the online leaderboards, but the core gameplay is done. My idea was controlling a rover with a 10 second signal delay. That turned out to be pretty difficult, so I included a few easier settings to get the hang of it before taking a crack at the real deal. Play it here.