About Doddler


Doddler's Trophies

Doddler's Archive

Nefarious Space Pirate Postmortem

Posted by
Friday, December 21st, 2012 7:28 pm

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.


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!

Space Pirates WIP

Posted by
Sunday, December 16th, 2012 1:55 am

This’ll be for the jam with a couple friends, working in unity.  So far, there’s space police, a couple civilian vehicles, transports, swat ships, and other fun things. You go around wrecking stuff while trying not to get blown up by the law. It’s turning out pretty good, although it still needs a lot of work. Here’s hoping we can finish it up tomorrow!




Timelapse Tool

Posted by
Wednesday, December 12th, 2012 11:00 am

I’m in for this Ludum Dare, and needed a tool for making a timelapse.  Chronolapse is awesome, but it only lets you use either the primary display or all displays, something that didn’t work for me, so I made my own! It’s simple, and doesn’t have a lot of the features (you’ll need something to stitch them all together afterwards), but it does let you specify which display to capture, or all displays if you want. I figure maybe someone might find it handy for this weekend.  It lives in the system tray, just right click and hit start after running to start capturing.


Grab the program, or the messy c# sourcecode.

Prison Planet Trench Escape

Posted by
Monday, August 22nd, 2011 10:45 am

Now that I’ve had an evening to gather my thoughts, I wanted to write a bit about the game I built for LD21. I submitted my entry into the Jam so that me and a friend could work together on it. That said, we limited ourselves to 48 hours and followed by the rules of the competition the best we could.

Overall the project went smoothly from start to finish and didn’t encounter any major issues, so I’ll go over some of the things I think went well for our project.

When we first got word of the competition’s theme, we just sat there quietly for about 10 minutes. I pitched the idea “You’re an escaped prisoner or something, piloting a ship down a corridor, where you have to break down these gates and dodge bullets while being chased by a big bad guy. Maybe with giant saw blades or something.” The game was more of a ‘chase’ game than an ‘escape’ game, but escape is a pretty broad term, and we figured we could hit the theme if we provided a little background to the characters prior to going into the gameplay portion of the game.

We used Unity for development. I must admit, while unity is awesome, the best part of it is the rapid prototyping. We took our idea and made a playable game within 3-4 hours of the start of the competition. We identified a lot about what would, and what wouldn’t work about our idea. You can see the prototype HERE.

We ditched the idea of gates, since we liked the idea of constantly accelerating gameplay. Gates required you to be able to shoot, something we got rid of, and also required to slow down, which we felt would probably break the flow of the game. The obstacles in the test version were entertaining enough, so we kept them around. We thought the game was way more interesting when the enemy was on screen rather than off, so we made it so that the enemy couldn’t fall too far behind.

The way I set up the game’s movement (as in the speed the stage scrolls) is kind of interesting. The speed the game was moving at was handled as two values; the target speed (the speed the player should move at) and real speed (the speed the player is really moving at). Getting hit dropped your real speed by a % (in the final version you slow by 10% for bullets, 15% for obstacles), and you recover speed by a set amount per second. That actually let us increase the difficulty by simply adjusting the speed the player moves at, since getting hit while moving faster would penalize you more. The enemy, his speed remains at 98% of your target speed, until he hits the bottom of the screen at which he matches it 100%.

Some really interesting things happened with this set up though that we didn’t originally intend. Getting hit just once didn’t really set you back very much because you recovered the speed you lose almost immediately. Consecutive hits would slow you down more, and more importantly, for much longer, which penalizes you much more. This meant that we didn’t have to make a game where your goal wasn’t to get hit… we could make the goal to try to avoid getting hit multiple times in a short period of time.

I was a little disappointed that actually slowing down was not noticeable. In the final version, even hitting multiple objects in a row, you won’t actually notice a change in speed, even though the scroll speed slowing down is what lets the enemy catch up to you. I think the shaking that occurs when you get hit hides the slowdown, but we needed the shaking to make it obvious that you got hit, since the explosion audio queue also sounds when an obstacle is destroyed by the enemy.

The enemy creeping up on the screen had gameplay implications that we hadn’t really foreseen, but once we saw it we kind of ran with it. I didn’t really notice much until a player mentioned on twitter that he enjoyed the way that the enemy’s position acted as a health bar of sorts. That made my day, and allowed us to make it a bigger part of the game. As you make mistakes, you’re given less room to work with, which makes further mistakes more likely. It reminds me of messing up in a game of Tetris, as the blocks pile up, you now have less time to plan your moves. It’s kind of invigorating, and while it wasn’t originally in intended feature, it was just one of those things that we were like “heey, that’s pretty interesting, lets see if we can make this a more important part of the game.”

It’s kind of amazing just how much a game, even one as small as a weekend competition game like this one can change over the course of development. We kind of had an idea where we wanted to be right from the start, as the prototype we built at the start looks fairly similar to the final product, but the actual gameplay was refined a considerable amount to make an interesting experience.

So yeah, I guess the take-away was that because we had our plan and working game so early, almost the entire 48 hour process was polishing and tweaking to make it more fun.  That’s a really good way to do it I think, it would have been much more stressful if we hadn’t had something running early on.

I want to thank Mike Paulson for helping me out with graphics, his art added a lot to the the game and it would have been a much uglier game if I had to do it all!

I hope you enjoy the game, let me know what you think!  Web/Windows/Mac version are available, as well as a timelapse and source code.


First Night, Progress

Posted by
Friday, August 19th, 2011 10:19 pm

Well, I’m going to pack it in tonight, even if it’s just 4 hours in, it’s time to get some sleep today, so I figured I’d share what I had so far.

Being my first Ludum Dare, I wanted to start off small.  I’m doing the Jam since it means I can have a partner-in-crime.  I’m programming in Unity3D (I love you rapid game development), and my friend is doing the art and game models.  With the Escape theme, we tried to make it match what we’re familiar with.  So this is what we came up with:

Your main character is a prisoner on a prison world, who manages to get free and hijack a small shuttle.  You lift off into a corridor on your way to escape, while you are chased by a massive menacing security craft.  From a gameplay perspective, your ship continually gains speed while traveling down a corridor, while dodging fire and collisions with small security drones.  getting hit only slows you down, but if you lose too much speed, the great big menecing object chasing you will catch up and take you down.

So really it’s a chase game expositioned as an escape.  I wonder if that’s cheating, they’res an awful lot of overlap between the two themes.  Oh well.

So far, our game looks pretty unexciting with just stand-in graphics:

At this point it’s already playable, although it’s lacking a bit in the fun department.  The exposition part is also completely abscent.  Still, I think it’s a promising start.

I have a playable build up right now, feel free to try it out and let me know what you think!


I’m In~!

Posted by
Thursday, August 18th, 2011 9:53 am

Hello, this’ll be my first Ludum Dare, I’ll be working with a friend for the Ludum Dare Jam. We will be using Unity, Photoshop, probably Blender and maybe Audacity. I hope to finish, but even if we don’t I hope to have a good time! :)

[cache: storing page]