LD12 August 8–11, 2008

Towlr Update

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)

Tags: postcompo

Windows build

Keeyai kindly made a windows binary of my game.

Thanks a lot. :)

link to windows version 

Stacker High Score

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

MrPhil Stacker High Score L14

Has anyone else done better?

Tags: MrPhil

Demonic Tower Timelapse

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.

Tags: timelapse

Annoying!

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 >:)

Comments

11. Aug 2008 · 16:24 UTC
“Oh god.”
20. Aug 2008 · 11:22 UTC
Well, the game is already way too hard and frustrating as it is :)

Oops!

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.

Tags: background info

Journal, final entry

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 :°)

Tags: journal

Timelapse video

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)

Tags: timelapse

Comments

11. Aug 2008 · 18:06 UTC
Cool!

Making of (kind of…)

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.

Tags: makingof

Torrent

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

Tags: torrent

Timelapse!

Here is my timelapse!

Music somehow synced up very well…

Tags: timelapse

Voting

Tags: motivation

Tower Master ‘FAQ’

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!)

Tower Collapse Inner Workings

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?

Time Lapse!

Here is my time lapse. Enjoy!

Tags: timelapse

Post Mortem

Here is my post mortem entry. It’s a bit long so click the read more thingie to view it.

Tools used:

Platform: Win32 (XP Home SP3)

Libraries: OpenGL, GLEW (to handle OpenGL extensions), SDL (for initialization and keyboard/mouse input) and DevIL (for image loading)

Tools: Visual C++ Express 2005, Cinema 4D (with a custom export plugin) and Photoshop CS2

The many things that went wrong:

  • Rustiness: The last time I finished a LD48 game was more than 3 years ago (with 2 additional very unmotivated attempts in the next year that I gave up quickly) and since then I have done no game development, some work related OpenGL though but not recently. So I was really rusty!
  • Lack of preparation: Aware of the aforementioned rustiness, I knew I should prepare myself but I didn’t do much. I didn’t try to code a warm-up game, I barely tested that my previous entry still compiled and concluded that I had the libraries I needed installed and that was all.
  • Doing everything from scratch: I spent the first day just to get the graphics working. I really need to have a kind of library to avoid going through that again. I want to have fun making a game not write a Vector class or an object loader. And I gave in to temptation and got one or two tricky but boring things from my previous entry (only very basic stuff though like the timer class to get a good quality timer on windows since SDL_GetTicks sucks, I think I’m still OK with the compo rules considering some people use engine and physics libraries)
  • Export plugin not ready: During the compo I couldn’t find a compiled version of my Cinema 4D export plug-in. And it wasn’t compiling anymore due to changes in the application’s SDK. Fortunately I was able to solve those problems relatively quickly but I should really have tested it before the competition.
  • Visual C++ bugs: I was really surprised because I had never had any problems with it before but it kept bugging and I had to quit VC++, reopen it and then I had to put back all the windows in their place again. How annoying.
  • Things I wasted time on: I wasted a lot of time on adding fog to my shader and getting it to look just right before finally deciding it didn’t look good. Also I wasted time doing the Mario64-style camera which didn’t turn out quite alright and is not activated by default in the final game.
  • No time for animated characters: My biggest disappointment. It doesn’t take a lot of time, in my previous entry Lightstream48, I had made some cool characters in just a few hours and I wanted to do the same.
  • No sounds: I had Propellerhead Reason ready to make a small music and my microphone connected to sample a few noises but I didn’t have the time.
  • Not enough gameplay elements: I had lots of ideas to make a more interesting game but instead had to try to make levels with only a few of them implemented. So most of the levels are based on jumping skills rather than puzzles like I originally wanted.
  • Bugs: There are lots of little bugs in the gameplay like you can walk off the border of the map in some places and jumping isn’t implemented correctly so sometimes it’s difficult to control the character.

The gray area of things OK

  • Is C++ the right language for a LD? I used to be quite happy with it, but this time I was annoyed by the extra typing it requires. Header files are such an annoyance. Maybe I should try an alternative next time?
  • Time management: I worked a total of about 32 hours. That’s a bit below what I could have done. My plan was to start at 8am on Saturday morning, I slept past 10 and watched the Olympics. But it could have been worse.
  • A bit slow on slow PCs: The minimum requirements for this game are a bit higher, but considering that some years have passed since my previous game that’s normal. Off course it’s mostly slow because it’s badly coded but still… it’s time to upgrade people! 😉

The few things that went right:

  • Per-pixel lighting: it looks real nice so I’m happy about that.
  • More 3-dimensional gameplay: In my previous games it was really only 2D gameplay with 3D graphics so that’s an improvement.
  • Save points: I’m really glad I included them, it was tempting to code some other gameplay elements and leave that for later but without them the game would have been too hard.

Conclusion

I’m not entirely satisfied. I wish I could have had more time to finish my game. Now what I want to do is start a library with all the basic stuff I need for a LD48 game and publish it soon enough so that next time I can use that for my game and be able to concentrate on gameplay and content.

Tags: LD #12 - The Tower - 2008, post-mortem

Escape From The Tower of DOOM: post-mortem

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.

Tags: post-mortem, postmortem

Comments

Notch
12. Aug 2008 · 10:11 UTC
Interesting read, thank you. =)

yeah???

whachu lookin at??

I’ll enter the next one, ok??

Debriefing the Tower

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!

Comments

nilsf
12. Aug 2008 · 12:07 UTC
Arrg, I lost an hour playing the linked miner game. Really nice. :)
HybridMind
12. Aug 2008 · 17:33 UTC
Hah! I also lost an hour+ on that link to Miners.. that game was awesome too!
Morre
22. Aug 2008 · 16:25 UTC
The link to the first game prototype doesn’t actually work, it’s the same link as the google one. Shame on you for copy-pasting without swapping URLs! :)

Dark Tower Post LD fixes…

Had some great feedback on IRC so I decided to try and fix up lot of the faults people found with the game.

Now with lives, score and a difficulty curve.

Dark Tower Revisited