Here is my timelapse video.

A few epic moments: the big ABBA chat (0:38), the epic failure of creating the level graphics in Blender, then Inkscape (2:48), the time when my friends came over to play Armaggetron and Jump’n'Bump while I was drawing the levels (4:34)…

Soundtrack: ingame music + surprise song from a band that enlightened the IRC channel with all its splendor…

http://www.youtube.com/watch?v=j1PSloOTokg

Wasting the Night

The Tower. Seemed pretty straight-forward, but I still googled it for inspiration and to see what possible alternative meanings there are. I saw something about a tug boat, as in “someone who tows”, and thought that was sufficiently out of the box to be considered clever, and would allow me to make a game that really stood out from the rest since it wasn’t about a big circular stone building.

After considering boats dragging other boats, an idea formed about a space game in the style of Elite 1 / Wing Commander, where you played the role of a Tower responsible for rescuing stranded ships. I had some vague ideas about trading as well.

Instead of going to bed after seeing the theme as I had promised myself, I stayed up another three hours, building a first prototype of the game (you can try it here). I didn’t go to bed until I realized there was no reasonable way I would be able to finish the game with all the art it would require.

Starting the Game

After some six hours of sleep/dreaming about a new game idea, i suddenly woke up and realized what direction I wanted to take.

Just before I woke up, I half-dreamed about the Yoshi’s Island title screen, and that type of rendering would fit perfectly with the code I already had. I had the code to render hundreds/thousands of z-sorted sprites fast, and I had the basic code for mouse interaction and applet support. I also knew from earlier that I could do tiny pixel art fairly successfully in short time.

It seemed a game like The Settlers would fit fairly well in that style, so I took the obvious route and decided that the task was to build a huge tower. I mean, it WAS the theme after all, so why not just slap one in there? I made some art, did some basic interaction, and coded together a horribly hacky Job class for giving the peons tasks, and things were going great.

Fixing the Balance

Of course, by now the game was horribly unbalanced, and there was no win condition, not to mention that The Tower wasn’t all that central at all. I thought about having higher tower mean you could have a higher maximum population, I thought about having a timed game that rewarded points for how fast you could finish the tower, but nothing really worked. And there were no enemies!

But then it hit me. Why not have the tower spit out the enemies? Then the task would become to bring the tower down, and there would be a natural way for the game to become more difficult as you came closer to your goal (the tower would spit out more and more enemies). I decided to keep the time based scoring, and went with this idea.

Unfortunately, random maps would have to go. There was no way for me to be able to write a good enough level randomizer that made playable maps in the short time I had left, so I kept the hand drawn test map I had made and kept the randomizer using the fixed seed I had used for testing. This really helped a lot for making sure all users had a similar experience.

I toyed a bit with the idea of having the user read some instructions before starting the game, but since most people just click past those and the fun in the game was mostly about trying to tame the very peculiar AI, I skipped that and just added tool tips to the houses. I chose not to mention how to Break the Tower since it had the same color as the rocks you were already trained into mining, and I figured that clue would be good enough.

Then there was pacing and balance testing, and heaps and heaps of tweaking.

Adding the Polish

As final polish, I finished up the intro screen and added a win screen. I decided against a loose screen, as detecting when the player had lost (out of rock and no barracks? no more peons and no residences?) was too hard, and in reality the player would’ve lost long before those conditions happened, and the besides, the game was simple enough that the player would rarely lose once he had built some momentum.

I like that, by the way. Games don’t have to be hard, as long as they’re interesting. There’s really not that much interaction in Breaking the Tower, it’s mostly about taking care of your little ant farm of tiny pixel people, and it seems to work fairly well.

With just a few hours left, I decided to add sound. 22KHz, 8 bit mono sound, for maximum retro feeling, all generated in run time. Surprisingly, it went really well, although in retrospect the death sounds are confusing and sound too similar to the spawn sounds.

I had estimated the play-through time at about 30-60 minutes, and decided that was good enough, so I packaged it and released it.

Morting the Post

* One very nice thing with making games for a competition like Ludum Dare is that you know exactly who the target audience is.. it’s yourself. It’s people insane enough to write a completed game in 48 hours. This makes it a really fun experience. Instead of asking myself if the player would appreciate some detail, I just asked if I would.

* I probably should’ve spent more time on the pathfinding. Right now, it’s

10 Walk towards target
20 If not collide, goto 10
30 pick random direction, walk for a second
40 goto 10

And that’s obviously not very advanced. It works surprisingly well most of the time, though, and it does give the peons some apparent personality.

* Making the houses give out jobs to peons in sight works OK, but it would’ve been better to build a big global task list that free peons pick jobs from. I realized this far too late in the development.

* Many people don’t get how to Break the Tower. I should’ve made it more clear that you have to use masons. And some people take over 1.5 hours to beat the game, which feels like too long.

* The art direction was perfect for the duration of the competition and the level of my art making skills!

Before the competition started, I made a list of ideas for all the finalist themes. Luckily The Tower was pretty much my first choice (along with escape) so I had a pretty clear image of what I wanted to do right away. In the end the game turned out to be pretty close to the one in my head .

My development process was rather odd, as I did pretty much all the coding on my mac and all the graphics on my ubuntu box. I think most people would expect the opposite. The reason for using ubuntu for the graphics is that I’m used to the gimp and it kind of sucks on OS X, however I don’t have a really good reason for doing the code on the mac, I guess I just like using this machine more.

What went right:

I had a pretty clear plan in my head for this theme so I was able to get started right away and have something playable very fast. After that I had a lot of code-test-fix-test-refix-code-… cycles which I think were a pretty good way to make progress fast while not breaking everything along the way. Python is probably a good choice for this kind of development since with no compiling and linking to do I often felt free to test after even very small changes. Btw, by test I mean playing the game and trying to make it misbehave, not automated unit testing.

The game was not too ambitious. I figured it would be better to have a small rather polished game than a big unfinished and buggy one, so I tried to set my aim rather low to something rather simple but that I could pour a lot of chrome on. I feel I did pretty well here with the small details. The game was almost done on the first day and the second day was spent mostly on fixing little details and tweaking the levels.

The sound, this was the first game I included sound in and I think it worked out pretty well, I used three tools to make the sound effects: cfxr an OS X port of sfxr; say a text to speech tool; and Audacity.The level 2 sounds were recorded in Audacity along with one of the robot’s killing sound, the robots were done with say and the beeps and jump sound were made with cfxr. Then I used Audacity to transcode to vorbis.

What went wrong:

The collision code was horrible for a rather long time. I tried doing single rectangle to rectangle collisions and figure out where to place the character depending on his current speed. That didn’t work out for me as the player would often pass through walls or get stuck in ceilings when changing direction or jumping into walls. So I made a new system with two rectangles for the player, one tall thin one for vertical collisions and a short fat one for horizontal collisions. That didn’t work either despite quite some time lost fiddling with it. In the end I just made 4 rectangles for the player, one on each side, and tested them against all the walls. I feels horribly inefficient, but it was simple and it seems to work.

The levels are a background image and a list of rectangular walls, that seemed like it would be much easier to code efficiently than collision against a black and white bitmap, but it made making levels much harder. In the end I wrote a level tool that displayed the level image and let you drag rectangles onto it and spit out the list of rectangles. This made it a bit less tedious to make levels but it was still a pain.

Difficulty, since I was testing the game a lot, I got pretty good at it so I think I made the levels too hard. My girlfriend did some testing, but since she doesn’t play computer games a lot I didn’t didn’t weigh her concerns about difficulty as much as I should have.

Bits left out:

Originally I had planned to include a gun in the second level where the owl head is now and have a mass of zombies on the bottom floor that you couldn’t jump over, but in the end I figured it would break the flow of the game and that it wouldn’t be that much fun. 

Another idea that didn’t make it was having boxes the player could push around. Unfortunately I had that idea rather late and while I probably could have coded it in fast enough, I would have had to redo a lot of the levels or make new ones and that would probably been too much work. I wish I’d thought of that at the beginning since I think it would have allowed for some more interesting “puzzles”.

Finally, in my first image of the game there would have been a first level without monsters but just rather static fire to avoid. I decided to cut that very quickly though because there is no way I could have drawn decent looking animations for fire (and I didn’t add animated characters until rather late and wasn’t sure I wanted to deal with it) so I left it out. I’m not sure whether it was really a good idea since it might have softened the learning curve. On the other hand it might have been less fun and players could lose interest right away.

Lessons learned:

Make proper resource loading right away, for almost all the development cycle all the files, code and media were in one big directory and were all loaded directly. First I noticed that when the sound didn’t initialize that caused crashes so I made a quick audio module so I only needed to do error catching in one place instead of all over the code. And do get some caching as before sounds were reloaded almost every time they were used. Finally near the end I decided to put all the media in a subdirectory to make things cleaner and have an image module to cache images. Which brings us to lesson two:

Don’t make big wide ranging changes right before you release. Changing the way I loaded images was a pretty straightforward thing, but it required changes in tons of places all over the codebase. Inevitably I missed a few, usually that would be a problem because I test a lot, however I wanted to get the game out of the door, so I didn’t test it nearly enough. So the first version I released would crash in some common conditions. Thankfully it was still well before the deadline so I managed to fix it in time but it was rather embarrassing to ship something so broken.

There we go, sorry for the wall of text.

Here is my time lapse. Enjoy!

Since there have been a few question regarding the “simulation” i’ll explain a bit:

There is no grand simulation inside. It’s all tile based. I refrained from using a physics lib (there have been enough entries with one already) because i’d have to learn it during the compo time.

Every tile has two damage counters, one outer, one inner. The outer is mostly used for the appearance (cracks in the window) while the inner is responsible for the strength left. Once the inner structure value is down to zero the tile collapses.

Collapsing is done by moving all the tiles above one tile down. The tile below the collapsed one gets a damage applied which is calculated by the number and “health” of the tiles above it. This can lead to nice chain reactions of a column collapsing in itself.

Since the collapsing code only works vertically i have the particles. Half of the particles are able to inflict damage when hitting other tiles. Therefore it’s also possible to have columns affect each other.

Oh, and about Twin Towers: You actually have to raze the two towers on the left and right and protect the building in the middle. That’s probably the reason why some can fail spectacularely in that stage.

Did i mention that the game also has flying toilets?

Just because sometimes some things aren’t as clear as you thought they’d be.

Q: I’m just one person, I can’t test a multiplayer game! When I try to play myself, it says “name already in use”.

A: Go to server.txt and edit your name. Each time you click host or connect it reads data from this file. So you just have to change it by alt+tabbing to it.

(Will make edits if more crazies pop up!)

Here is my timelapse!

Music somehow synced up very well…

H’okay, here’s the timelapse.

Music by me.

Also, if you tried (and failed) to run the newer Win32 version I uploaded this afternoon, I redid the changes with py2exe and it should all be working properly now. Linking with pygame.mixer.music turned out to be a matter of sending the correct options flag to py2exe. You can get it here.

Here is the link to the torrent for LD12. All the games are in it, as well as the compo game loader. All the games have been hand edited where necessary to make them work well with CGL.

http://keeyai.dnsalias.com/ludumdare12.torrent

Papper also put up a regular mirror of the torrent content if the torrent is down.

http://www.kekbur.se/ludumdare12.zip

About the submission:

The owliver.love file is really a renamed zip. If you unzip it, you’ll find inside:
- the Lua sources
- the images
- the sounds
- the three musics

So: archive, check; source code, check.
Custom library code: none. Everything is either the Löve engine, or code written during the compo.

List of tools and libraries:

- As stated before, the Löve game engine (a Lua wrapper for SDL). Awesome stuff. Never coded things that fast. In fact, it’s almost magical. Idea -> code -> working feature. Of course, there are always a few bugs you have to correct, but the power you feel in your hands is really amazing. Lua is amazing anyway. When you need something, just make a table. It always works ;°)

- Text editor: gEdit, with autocompletion and symbol browser plugins. Plus, of course, built-in syntax coloring.

- Compilator: none, this is Lua! (ah!) Save your Lua file, and rerun the game from the closest console. In fact, when Löve detects a crash, it doesn’t quit, but instead goes in crash mode. A “restart” button is available so you don’t even have to do “up arrow + enter” in the terminal, once the bug corrected. You gotta love Löve.

- Graphics. For the levels: pencil, paper, sharp marker pen to increase contrast, scanner, Inkscape to vectorize, resize, re-bitmapize, GIMP to colorize. And for the ingame thingies and text, Inkscape. For the intro screen text, made a screenshot of text in Abiword, then included with the guy in Inkscape.

- Level making: hand coded in the source. But made extensive use of Inkscape to get coordinates of stuff. I drew rectangles and dots in Inkscape, read their coordinates there, copied them in the level files. Them during level loading, the coordinates are converted into game coordinates. I supposed it could have been even better to parse the SVG files, but no time to explore this.

- Sound… I made all audio during the last hour… Sounds are all randomly generated with the great sfxr, in about 7 minutes. Music is made with ZynSubAddFX, a marvelous synthetisor for Linux, and QSynth, a soundfont player. Both apps controlled with my MIDI keyboard. Drums are from Hydrogen (awesome drums app for Linux), and the “mixing” is done in Audacity.

Additionnal things:

- IRC with X-Chat
- Timelapse video capture with two shell scripts:

while true; do scrot -e ‘convert $f -resize 50% $f.jpg; rm -f $f’ & sleep 20; done

and

mencoder “mf://*.jpg” -mf fps=10 -o timelapse.avi -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=900

- Far too many motivational posters with http://wigflip.com/automotivator/
- Photos with my Kodak EasyShare C713 (stupid battery charger that I can’t find…)
- Everything done on a GNU/Linux machine running Ubuntu 8.04, except scanning the levels, since the scanner is plugged to the family’s MacMini.
- The pizza! I’ve been asked several times what kind of pizza it is. I sure looks good, but well… Just a pizza So, it’s a Buitoni “Four à pierre” Royale. I don’t know if the name is the same outside France, though.

I don’t see anything else to add yet. I’ll work on the postmortem now.

If you’ve already experienced Towlr, you don’t need this.  But if you plan to sacrifice any friends to Towlr, I’ve made some useful fixes and changes.

http://junk.mikekasprzak.com/Research/Towlr/Towlr2.zip

First off, I’ve removed the ESC and F10 keys, since they’ll just make the player sad (or relieved).  Next, I changed the background color to gradually become more red over time, to add to the “driving you crazy” factor.  Finally, I named the executable correctly, so in the future people can stop asking me if it’s towel-r or t-owl-r.

Enjoy.

EDIT: Linux Version (Experimental)
EDIT: MacOS X Version (Intel) (Experimental)

I’ve been playing around with VirutalDub and Ulead VideoStudio and here is my timelapse video:

http://www.youtube.com/watch?v=YVyJVQU9mLk (2:31)

20:37
Back from dinner. No photo, batteries dead.

22:22
Colorized three levels. I hope I can make it…

23:02
One level to go. IRC log:

<Tenoch> Codexus> only 6 hours left ._. PANIC! PANIC!!!!!! –> me too buddy, me too…
<Dragowlene> what say you
<Deepflame> It’s 40mb and xvid encoded
<Dragowlene> with 7 levels
<Dragowlene> can I call my game final?
<Tenoch> !D
<Dragowlene> somebody who’s tried it
<Tenoch> my levels are empty…
<Tenoch> like… empty
<lexaloffle> Edwardowlka – I had trouble getting anything to work too. That’s not haXe’s fault though — I really don’t understand Flash. Or OOP for that matter @_@
<Tenoch> Are there logs of the chat during the compo time?
<Tenoch> that’s something I’d want to show my children.
<Tenoch> when I have some.

23:43
All levels colorized. Made a clouds background, with multi parallax. Oh yeah.

05:41
Yeah right. Finished. Now a bit of sleep before completing blog, journal and postmortem.

In the 23:43 -> 05:41 hole, I made a loooot of things. That is, all the gimmicks inside the game, the trooper, the winning conditions, texts, interlevels barriers, some gameplay, difficulty ajustments (too much adjusted, apparently), etc.

Then in the last hour or so, sounds and three musics. Oh my gawd.

I don’t have photos for this last part, since I had other things to do, and also, because the batteries are dead and I don’t have a charger.

See you soon for the postmortem :°)

Ok, here’s a little background info that I forgot to provide. The game’s name is “The keys to the Tower”. The game takes place in a tower, just not a good one. And you play as a block of… something… with a keyhole in it.

If you were waiting for the Windows versions of my game, Entar was gracious enough to compile a version for me. I put together a Win32 package, and the link is on my final submission post.

Thanks again, Entar!

Hey everybody,

The 48 hours of Ludum Dare 12 have come and gone.  I’m pretty sure we’ve collected all the entries by now.

The final count: 57+1 entries

I say “+1″ because we did have a team that decided to join us and make a game this weekend.  You can check out their game here:

super-tower-smashup

As for the other 57, you can check out the final posts and a lovely arrangement of screenshots here:

Image Grid and Voting

For the next 2 weeks it’s voting time (until August 24th, see clock).  All entrants that submitted a game can rate the other entries.  If you didn’t submit a game, feel free to leave a comment in the respected final posts.

Also, trophies.  If you feel a game deserves a special mention, something silly, something tasteful, feel free to award them a trophy.  Anyone can give trophies, so if you didn’t get your game in but feel an entry deserves a special mention, go ahead and give it a trophy.

- – - – - – -

As for everyone else, our next major compo will be in December.  Date TBD.

Coming up sooner than that, we’ve started doing monthly Mini LD compos.  A Ludum Dare veteran can choose to host a month.  They host can pick a theme, and choose to change/try out some new rules.  Like our previous “unofficial compos”, they are not judged.  You can learn more about it, or sign up to be a host on the Wiki.

http://www.ludumdare.com/wiki/

Of course, I’d like to take this opportunity (and a few more) to shamelessly promote Mini LD #3 hosted by me (PoV).  It’ll start Friday September 5th, but I’ll really be abusing the rule change privilege.  The first big change, I’ll be announcing the theme on Monday September 1st.

The theme is different than our usual Ludum Dare fare, and could certainly benefit from a couple days to think about and plan what you’ll be doing.  Then on the weekend, you do it.  The nature of the compo is a little more forgiving than usual, but a weekend for most is the perfect time to do it.

If you’re up for a very different Ludum Dare, stay tuned.

I just realised that none of the traps are functional in my final entry – damn! I commented them out of the code at the last minute to test the final section of the game, and forgot to put them back in afterwards. Ugh, frustration.

Well, obviously it’ll be judged based on the no-trap version, but here’s a version with working traps anyway for anyone who wants to compare:

Tower Rescue v0.2

They actually make the game a hell of a lot more punishing, but that was how it was intended >:)

I actually enjoy playing my game! I finally beat level 14!

Has anyone else done better?

Demonic Tower – Source and Win32 Binary - fixed!

I’ve made a bugfix release that fixes a fatal error. I’ll leave the previous versions up (see my last post), in case you want to see it as I submitted it, but everyone should play this version as there is a nasty crash that happens only when you pick up a certain card on a certain level. I also got the music to link correctly, and the package now works with the Compo Game Loader. No gameplay was impacted.

Enjoy!