My Timelapse is finally ready (compiled from over 20GB of images taken every second):

Also on Vimeo

Play and rate dot

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.

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 twitch.tv, 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.

Music/SFX

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.

Sorry for not posting any new builds. I added some simple music (I am not a good composer), some nice voiceover, and made 3 levels. I don’t know whether I’ll get a chance to add more or fully integrate my storyline. In any case, here’s a screenshot – there is now an arrow pointing in the direction you need to move.

Good luck, everyone!

Final screencast: http://students.olin.edu/2012/czwiebel/webcam/

Isn’t it great when you can actually win or lose? I think so at least, especially because I didn’t have the chance to add that functionality into any of my previous Game Jam games.

Follow the corner indicators to the goal!

You can actually lose? Incredible!

I feel really exhausted after all of the stuff I did today, and I need to get some sleep.

Stuff to do for tomorrow:

- Make the volcano indicate your fuel level

- Make the transitions work properly between levels

- Art

- Story

- More (real) levels (the current one is just a stand-in to see if stuff works)

If you happen to be up while I’m in bed, you can always try out the latest build:

http://jceipek.github.com/LudumDare23/

I got tired of coding non-stop and decided to work on the main menu and graphics. I’m pretty pleased with how things look at the moment – I’m trying to go for a storybook style. Oh – and I’ve decided on a name for my game:

dot

I really need to start working on gameplay again – I’m afraid that if I continue on art, I’ll have a really pretty, non-functioning game. However, I’m starting to get rather tired again, so I don’t know how that will turn out.

One thing is pretty much set, though – I’m going to get much further than I did on a team for LD 22.

Try out the latest build: http://jceipek.github.com/LudumDare23/

Livestream: www.twitch.tv/jceipek

Screencast: http://students.olin.edu/2012/czwiebel/webcam/

Goodbye…

As I hinted in my last post, the planet now has the ability to die a painful death if it builds up too much pressure while getting ready for a powerful thrust. Nothing happens yet, after the planet is gone; the game just keeps on playing, waiting for you to refresh it. I’ll probably tackle that issue soon.

Before that, though, it is time for me to take a break to get something to eat and replenish my stash of bananas.

In the meantime, you can try out the latest build here: http://jceipek.github.com/LudumDare23/

My screencast and livestream probably won’t be very exciting in the meantime, but maybe you’ll see something interesting happen in my absence. Who knows?

Livestream: www.twitch.tv/jceipek

Screencast: http://students.olin.edu/2012/czwiebel/webcam/

I just made the planet you control shake as you charge it with the thruster. This way, the player won’t be incredibly confused and frustrated if the planet explodes. This feature also provides feedback about how far the planet will move during a thrust. The animation seems to be a bit large. What do you think? Should I keep the animation tighter to the center of the planet’s movement? (Try it here: jceipek.github.com/LudumDare23)

Video on Vimeo

The screencast appears to be working now thanks to Colin (go to http://students.olin.edu/2012/czwiebel/webcam/), so you can watch me work in close to realtime (update cycle is once a second) at an incredible resolution (my actual screen size). Unfortunately, the screencapture command in Mac OS X Lion seems to only capture the main monitor, so I’ll try to keep the interesting stuff on that one and look at documentation on my other monitor.

Screencast!

Try out the latest build: jceipek.github.com/LudumDare23

Watch the screencast: http://students.olin.edu/2012/czwiebel/webcam/

Watch the livestream: www.twitch.tv/jceipek

If you read my post from earlier today, you know that Dropbox blocked me from sharing files publicly via web links because I was getting too much traffic. Colin just helped me set up a new shell script to broadcast my screencast. You can now see it again at http://students.olin.edu/2012/czwiebel/webcam/ (It’s slightly broken right now while images are loading, but it should be fixed soon. If it asks you for a password, just click cancel).

Screencast!

I got the camera to follow the player. It was much simpler than I thought – in the game I’m developing outside of Ludum Dare, I used Unity’s example camera follow script, and it has a lot of superfluous features.

Anyway, here are some new screenshots, and as always, you can try out the newest build at http://jceipek.github.com/LudumDare23

I’m floating away!

Now I’m all alone…

The screencast will be back up soon, and you can still see the livestream at http://www.twitch.tv/jceipek

I just implemented black holes in the game by generalizing the BigPlanetController code I wrote to work for all objects with gravity wells that affect the player (in fact, I’m pretty sure that I could make repulsor objects using the same script… food for thought). This is the first time that I actually managed to get 360 degree rotation to look smooth – in Blender, it is apparently possible to change the extrapolation mode for IPO curves.

The player now also has a limiting maximum charge rate – eventually, I want to make the player explode if the volcano is charged too much, but I’ll leave that for later.

As always, you can try out the latest build here: http://jceipek.github.com/LudumDare23/

Next step:

Get the camera to track the player.

Screencast is still not back up; sorry everyone. However, you can still watch my Livestream here: http://www.twitch.tv/jceipek

After five hours of sleep, a bowl of cereal, and a glass of grape juice, I am back!

…Oops

Apparently my screencast was getting too much network traffic because I just got this notification from Dropbox. I’m trying to see if someone can help me host it somewhere else, but in the meantime, you can still watch my livestream here: www.twitch.tv/jceipek

Also, I’ll be posting my screencast to Vimeo after the compo is over, so you’ll be able to see the parts that I wasn’t able to stream live.

Goals for today:

- Improve gameplay

- Nice art

That’s enough of a break. Back to work!

Just finished Build 01. I added a big planet object that exerts mass on the player using Newton’s Law of Gravitation with an arbitrary G:

(Source: Wikipedia)

I also implemented collisions with the planets: when you hit a planet, the large planet disappears.

This gave me a lot of trouble, because I haven’t tried to detect collisions in Unity before (not counting cases where a trigger object detects if another object enters it). For example, I couldn’t get the OnCollisionEnter function to register any collisions at all, regardless of whether I attempted to perform collisions between rigid bodies or sphere colliders. Eventually, I just told the player script to send messages to any objects that it hit via the OnControllerColliderHit function.

You can try out my latest build here: http://jceipek.github.com/LudumDare23/

I think it’s time to go to sleep for a bit.

Livestream: www.twitch.tv/jceipek

Screencast: http://students.olin.edu/2012/czwiebel/webcam/

Slowly but surely, I am making progress.

I have now implemented basic character movement in a style similar to the old asteroids games.

For some reason, the movement is very jittery at times, and there seems to be no correlation with the amount of particles. I’ve noticed this happen in other games I’ve been working on too — does anyone know how to address this problem?

I just created the first test build, which you can try out here: http://jceipek.github.com/LudumDare23/

Livestream: www.twitch.tv/jceipek

Screencast: http://students.olin.edu/2012/czwiebel/webcam/

I actually misread the theme and spent the first few minutes coming up with ideas related to “Tiny Word”:

When I realized my mistake, I started to think of different interpretations of the theme:

- There is one world in the game and it is tiny. Does it want to get big?

- The protagonist is all alone because he is the only big creature in a world of small people.

- The “world” is a microcosm consisting of microscopic, atomic, or subatomic inhabitants.

Eventually, I decided to go with a very literal interpretation of the theme. My concept: you are a tiny planet surrounded by other planets that don’t take you seriously. Consequently, you decide to destroy all of the other planets.

Genre: 2D Action/Puzzle game

Off to Coding!

Livestream: www.twitch.tv/jceipek

Screencast: http://students.olin.edu/2012/czwiebel/webcam/

This’ll be my second LD and my first solo Game Jam.

Tools: Probably Unity Indie, Blender, Inkscape, Photoshop

My goal is to publish something on the web so that people can try it out without a lot of effort.

My Setup:

Watch my screencast here: http://students.olin.edu/2012/czwiebel/webcam/ (The process of streaming to twitch.tv was using too much CPU power) and my livestream here:

http://www.twitch.tv/jceipek