dot Postmortem

Posted by
April 23rd, 2012 7:13 pm

dot is a top-down 2d space game in which you control a tiny planet with a volcano during his quest to find his parents.

The style was inspired by simply rendered storybooks and the gameplay was influenced by Osmos and the early Asteroids games.

Help dot find his parents.

Play and rate dot.

What worked well:

Working Solo

This is the first game jam I’ve done where I did everything solo. This worked really well for me because it allowed me to settle on an idea very early on – during the other two jams I participated in, we spent multiple hours agonizing over interpretations of the theme and possible mechanics. As I have realized, deciding these things as soon as possible in the process is paramount to creating a finished entry. In prior jams, I had never worked with the people with whom I participated before, and that was extremely limiting because it meant that we didn’t know each other’s strengths and weaknesses, nor our collective familiarity with the tools we were using. In both cases, I started doing artwork and ended up as one of the lead programmers. Since I knew I would have to do everything this time around, I was able to scope my work really well.


Refining Assets & Keeping the Art Simple

Unlike in my previous jams, I started out with art assets I made in Inkscape in just a few minutes and focused my initial effort on creating a functional movement system. In the past, I focused too much effort on making pretty 3d models and rendering them out to sprite sheets. You can’t really make a good game if you spend all of your time on pretty pictures. When I finally did start to work on more polished graphics, I avoided 3d modeling and made black and white 2d line drawings in Photoshop. If I participate in a group jam in the future as an artist, I’ll make sure that the programmers are sufficiently familiar with the game frameworks we are using that I don’t need to take an active role in coding in order to get a playable game.


Working in a Publicly Accessible Area

I worked on dot in a lounge at my school, which made it really easy to convince passers-by to playtest the game incrementally as I was developing it. I got a significant amount of really helpful feedback from their comments and from watching them play my game, which helped me refine the control system a great deal. For example, the indicator that tells dot where his goal is used to consist of faded black circles on the corners of the screen, and the people who tried it out attempted to avoid them; they thought that they were being chased by dangerous obstacles. Doing this also gave me validation for the game when I was starting to wonder whether it counted as “fun” – one player desperately retried my nigh-impossible asset test level dozens of times despite getting frustrated and kept coming back to check on my progress.

Perhaps most importantly, though, it made sure that I actually got the game to work properly – I was in danger of wallowing in minor details near the end of the first day, and one of my repeat visitors told me to stop messing around and focus on the core gameplay.


Using Unity

I have mixed feelings about using Unity to develop games because of its lack of true Linux support and its nature as a closed source development environment with expensive add-on licenses for features that could be accomplished very easily (and for free) in other systems. However, Unity is incredibly easy to use, it has an excellent component system, and I was able to deploy to the web and Mac OS X/Windows with the click of a button. During Ludum Dare 22, we spent about 2 hours generating a working Windows .exe and ran out of the time we needed to generate more than long-winded source compilation instructions for other platforms.


Using github with gh-pages

Being able to generate new test builds every few hours and post them to the web with only a few lines of html in Vim was possibly the greatest boon ever. We didn’t use any version control during my first game jam, and that gave us a lot of headaches that we could have easily avoided.


Updating my Journal & Making a Livestream

I didn’t do this during any of my prior jams because I thought it would be wasting valuable time, but I think it really paid off this time around by keeping me on track in the game development process. My livestream solution was incredibly hackish, though, and I would like to know how the other mac developers handled this. Just before the competition, I spent four hours writing a convoluted sequence of shell-scripts to get an old version of VLC to stream a sequence of images to, which ended up taking up most of my CPU power. I scrapped that and moved to a piece of javascript that one of my friends wrote, which allowed me to display images once every 30 seconds or so as they were updated on Dropbox. Dropbox banned me from public links for 3 days because of excessive traffic, and my friend made a strange php upload script for me that allowed me to update much more frequently, but still with a really ugly system that involved using my ability to host things on my school’s servers.


Getting Sleep

I barely slept during my past jams, and I think that might have been part of the reason that I never finished something to the degree that I did this time around. Sleep is important.

I still feel somewhat like a zombie now that the competition is over, but at least I was able to think clearly while I was doing things. If I were to change the way I did things, though, I think I would have gone to sleep earlier and gotten up earlier as well – 6:00AM and 5:00Am seem a bit late to be going to sleep while needing to be productive for multiple days in a row.


What didn’t:

Level Design

I didn’t leave myself enough time for level design and ended up making only three levels, of which the third is very poorly designed because it can cause you to win accidentally.



While I did end up creating music for dot, I have absolutely no musical background and ended up repeating a sequence of four notes I haphazardly stumbled upon in GarageBand after humming something that I thought might sound interesting. I also didn’t have time to do any sound effects aside from some voiceover that I recorded in Audacity using my laptop’s built-in mic. I really need to find a better mic next time. However, I am still rather proud of the fact that no one who played the game complained about my unpolished audio and very few people realized that the voice was me. Apparently I’m just a really good voice actor?

Level Transitions

This is the largest contributing factor to wasted time during the entire competition. Making level fades properly in Unity is really challenging because of the component-based system forcing complex object interactions. When a fade starts, I needed the character to stop moving and the next level to start loading once the fade was complete. Ideally, the next level would start loading while a fade happens on top of a still image of the current screen. I’m pretty sure that the indie version of Unity doesn’t support that behavior, and I don’t really want to get attached Unity pro if I can only get a demo version. If I ever end up making a game good enough to fund my purchasing a Unity Pro license, maybe I’ll look into doing this better.

Anyway, I am still pretty unhappy with the fades between levels and worked on them instead of making more (and better) levels, which was pretty silly of me.


End Game/Story

The end of the game is pretty unrefined/confusing, and I wanted to tell a much longer story through animated cutscenes between the levels. If there is enough interest in seeing those things (give me some comments and feedback!), I’ll look into expanding dot for Kongregate during the summer.


Overall Impression:

I’m really happy that I actually made a (sort of) complete game this weekend, and I’m satisfied with the core game mechanic. I feel like I learned a lot about Unity and game design in general during the past few days, and I’m definitely going to try to compete in LD24.

Going off on a bit of a tangent, I thought it was really surprising that some people who play dot get lost in space for up to 15 minutes while others play through the entire game in under 2. Hmm…


Congratulations if you read all of that. Remember, you can play and rate dot here.

2 Responses to “dot Postmortem”

  1. joshimoo says:

    ” Going off on a bit of a tangent, I thought it was really surprising that some people who play dot get lost in space for up to 15 minutes while others play through the entire game in under 2. Hmm…”

    They probably did not figure out the control scheme.
    The Instruction should probably be Tap-Tap-Tap Space, since that Is a much more effective method of moving.

    The other possibility is, that the pointing arrow is not sufficient.
    Since on first look, I taught it’s awayFromTarget instead toTarget.

    Btw great game :-)

    • Julian Ceipek says:

      Thanks for your suggestions. As other people have already mentioned (both on my submission page and in person), helping people figure out the control system might simply involve making the speed/direction of movement more evident. I’m still trying to determine the best way to do this, but one solution might be a non-repeating infinite background of planets you can’t get to (or maybe future levels? hmm…).

      Many players didn’t recognize the significance of the arrow until they were already somewhat off target, and recovering from that can be quite time consuming, even for me. Maybe a future iteration will highlight the significance of the arrow if the player exceeds some time limit/distance from the goal.

      “Tap-Tap-Tap” Space is a possibility, but I think it might discourage players from holding down space and letting go to travel faster, which is going to be an essential mechanic once I add more levels, even if it is possible to beat the game without it now.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]