It’s been almost a week since we started Ludum Dare, and have had a bit of a time to cool off since then.  Our team of three were able to put out a reasonably fun game for the Jam.  Some things went wrong, but I think we made a fun little game and the whole thing was an overwhelmingly positive experience.

What Went Wrong

Thematic Squabbling – We spent a lot of time on this. The theme was weird, we wanted to take ‘villain’ to mean ‘antagonist’, but we couldn’t really make it into something that worked or would have been fun. Eventually we just ran with the ‘badguy’ idea, but it would have been better to have something that was a little more clear cut.

Lack of Practice and Setup – Before this Ludum Dare, I was very rusty with unity, I hadn’t worked in it in almost a year now. Our other programmer had only a passing familiarity with it, and our artist wasn’t so much an artist as he was simply the most artistic of our group. We also didn’t set up any of our tools prior, which lost us a bunch of time.

The maths – We got stuck for a good while to make the angles work. The game relies heavily on knowing the angle between the player and other actors, in relation to their current heading, but we spent and unreasonable amount of time just figuring out how to make it all work.

What Went Right

Simple Setting – We chose to have the game take place in space. Space is a great setting, since there’s absolutely nothing there. It saves us the time from having to do pathfinding, collisions, or obstacles. The trick is to keep it looking empty and to make it feel like you’re moving, but I think we handled those well. It might feel like a bit of a cop-out, but

Build and Refine – Our primary goal was to have a working game as early as possible. I think we had a semi-working game with a player (an untextured cube at the time) and an enemy by the end of the first night (about 5 hours after start). At each step we would play it, think of what we could do to improve it, and work from there. While such a lack of direction might be considered a detriment to a bigger project, the fact that we had something working so early on meant that it was less directionless and more of a non-stop polishing process. If a feature looked complicated, we wouldn’t add it.

Relaxed – We never felt rushed by our pace, we took regular breaks, slept normal hours, and even took time to watch some anime.  We also ended our jam after 48 hours, so it wouldn’t cut into our Monday. The fact that we had a fairly solid, playable game without suffering from burnout when we went in to work on Monday was a good thing, and probably resulted in a better game.

Randomly Interesting Technical Bits

– The background is just a plane that faces the camera, that is movement locked with the player. There are two materials applied to it, which have their texture offset adjusted to a multiple of it’s x/y coordinates, to give the impression that you’re moving through space, with the stars move slowly, and the dust moves much faster.

– All the ships are actually cubes, because we had pains making the planes face the camera properly, and never went back to fix it.

– If you look at the above picture, you’ll see lines pointing from the police ships to a point near the player. What’s actually happening is the police ships actually lead the player by a random amount. It’s not really obvious in the final game because the shots are way too random to see it, which is a shame. When I first started testing, the enemy ships would all clump up when chasing you since they all had the same parameters and target, so I made the actual target random as well as randomized speed and turning rate.

– The message box was originally going to be used for communications, as we were going to have both civilian and police ships send messages, but as the game pace increased, it ended up being difficult to follow while things were going on. Originally, we had messages simply flash at the top of the screen, but it became fairly annoying as a new message would appear every 5-10 seconds.

– Collision detection doesn’t work at all if the player or target ship isn’t moving at all. I have no idea why this is, and it drove me insane while working on it, but since there’s no way to actually come to a stop after you start it’s not actually huge issue. Maybe it has to do with the way unity handles triggers. If you have any idea, I’d love to know.

– The arrows that point to each entity, probably one of my favorite features, was one of the easiest to code, taking maybe 30 minutes to do. Unity is kind of sexy that way, that it’s so easy to make such a thing. Check out that code.

– The AI on the swat cruiser tries to fly along beside you and shoot at you from the side. It also cheats a lot, if it’s off screen it’s speed and turning ability is greatly increased, and if it can’t get to the player for long enough it basically is launched high speed towards the player. I had thought the arrows would make it obvious it’s cheating, but it seems fairly natural from your point of view aside from the odd “wtf how did he get there”. Or maybe you don’t notice cause you’re trying too hard to not explode.

– I’m especially proud of the taxi behavior. The taxi groups all start parented to a group object that moves on its own with the taxi’s inside. When the group object detects a projectile nearby, it transfers the current direction and velocity to each of it’s children and removes itself as the parent, at which point each of the ships starts moving independently.

Timelapse

A timelapse video from my computer perspective. 1 frame every 5 seconds, at 30fps. I should have used a dark theme for visual studio, don’t watch if you dislike flashing images.

The game

Give our game a shot!

Thanks for reading!

Tags: ld25, postmortem, unity