Sort of a postmortem for my game, Heart. I don’t know, I just wrote about the process and a few later thoughts. You can read it in my blog.

Also, the game is finally finished. Play the release version.

It sucks to have very few ratings and comments on your game, so here are a few pointers for next time.

Platform
The most rated games are the ones you can play in your browser. Try making your entry in java or in flash and embedding it in a webpage for maximum exposure. If you don’t want to have to suffer the horror that is (Java|AS|Flash) at least make a binary release for Windows since most people seem to have access to that platform (I don’t so please also make an OS X version ). If you’re making your game in Python (or its pale imitator ruby , or any other interpreted language for that matter) you might think you don’t need binaries but you’re wrong, people aren’t going to install a different environment for every single game. Same for Löve games.

Dependencies
If you do only release as source, or if you only release for one platform, or dynamically link libraries, keep dependencies to a minimum. If all I have to do to build the game is type “make” there’s a better chance I’ll try it than if I have to install 13 libraries which each in turn depend on half a dozen others.

Screenshot
I try to play all games regardless of the screenshot (in part because my own drawing skills are easily surpassed by those of a drunk monkey with a pen) but if the entry requires more than clicking on a shiny icon to run, I’ll definitely spend more time trying to get an entry with a cool screenshot working.

Rate other games (and leave comments!)
While I am determined to try as many games as I can, I prioritize rating the games from the people who left comments on my games first.

Of course these “rules” aren’t set in stone. You can make a game for the Atari 2600 and still have plenty of ratings. You can also make a game with an uninspiring screenshot and win best overall.
Of course you could also cheat by making a ton of games under different names to rate your own games .

DoomCake was my first LD entry.  It was developed in Lua, using the LÖVE 2D engine.

In making this game, I learned a bit about Lua, and a lot about cake.  Read on to find out what a sugary zombie invasion might look like…

(more…)

Behind The Dumb Episode 6 is out at last!  It’s the first half of my timelapse and journal for LD14!  Check it out.  You don’t need to rate it, because while I did FILM it all during the weekend, I certainly didn’t have it all edited and ready by then.  And the second half won’t be out until voting is over anyway.  Still, it should be amusing to some.

Unfortunalty I wrote the drawing code wrong* (outside of the gui thread) and this is the reason some people are getting the gray screen bug.

It doesn’t depend on your color depthor anything like that AFAIK, I will need to fix it in the code.

The good news is that I know more or less what to fix and just have to find the time to work on it again

[*] I’m a Java2D noob

Also joining the “give at least as many votes as you get” crowd.

Additionally, I generated a randomized list of the entries to play and rate for unbiased selection

If you did not play my game “The Final Solution”, you can get its win32 binaries and source code from my previous post.

This is my first LD.

I recently attended Global Game Jam [1], which was another 48-hour game competition held in 53 places around the world. We were 48 developers in Ankara divided into 13 teams/individuals, working like bees in our cubicles. My two friends joined separate groups and I started to make a game myself.

Having people around to test your game really changes the development process, as in the case of Itchy! in GGJ [2]. However, as LD is a solo competition, and I wanted to allocate my full attention to it, I did not see anyone during LD, and did not go outside except for getting food.

To mention a few lessons learned in LD;

(more…)

In response to many comments, I spent a few hours to improve Wall Girl and have released the results.

http://haitaka.googlepages.com/Wall_Girl_PR1.zip

Edit: If you have yet to rate Wall Girl, the older version is available at:

http://www.ludumdare.com/compo/2009/04/19/wall-girl-final/

If you intend to rate the game, please do so before playing the new PR1 version.

Changes:

- Most of my respondents observed that the game was too hard for them. In response, this new version comes with an Easy mode. Press X at the title screen to start Easy mode.

- The Normal mode has seen several balance changes. On the whole, the game is easier, but a couple of parts have actually been made more difficult.

- There is now music! Still no sound effects, though. I was really bummed that I couldn’t finish the music in time for the entry, but here it is. Not great, but it’s my first shot (in a very long while) at composing something from scratch.

- Several cosmetic enhancements have been made to the boss fight.

- This version has a readme! It’s actually more like a full-on manual…

I think this is really very close to how I envisioned the game when I first started work on it, apart from the lack of a tutorial mode. If you have a bit of time to spare, reviews and/or comments would be appreciated.

This past week has been pretty busy for me, so I’ve only just managed to get these up, but here are the Linux and OSX versions of Die, you Stupid Hurdlers!:

Linux (build from source – includes configure script, and MSVC and XCode projects)

OSX

Also a slightly updated Windows version that defaults to more sensible graphic options on startup.

(more…)

I came up with the idea of making a shooter based on drawing arrows after seeing a concept sketch for another arrow game by fellow LD participant Sparky. In the week before the contest, I entertained the idea and tried to think of ways to make it “themeable”. I came up with what I thought was a great idea for “Rain” – falling stars, that you would use as ammunition. When I saw the theme “Advancing Wall of Doom”, I decided to keep the mechanics from “Rain” and just work the actual theme into that. In retrospect, this might have been a mistake. Read why after the break.

(more…)

Standard Waiver, a short atmospheric first-person exploration game, was my first Ludum Dare entry. Here’s what went into it.

The foreground obelisk obscures the background one. It’s a mystery!

(more…)

Here is my time lapse video, the first version had better audio synchronization, but then VirtualDub crashed and I had to start all over again.

http://www.youtube.com/watch?v=6YqyUk5sIsE

This update addresses places some limits on density and unit counts, to address problems with the density getting out of hand in longer games. Two of the levels in the campaign have also been altered- one to make it more varied and reduce travel times, and another to keep the difficulty level more consistent.

Play Here

Update: Newer Build

I was glad to have finished an entry in my first LD, but I had two main regrets: not having music, and not getting the multiple waves of enemies that I had planned on. I had written most of the code and planned for the waves of enemies, but 45 minutes before the close of the competition, I felt I didn’t quite have enough time to pull it off and make it feel polished.

I have taken an extra 2 hours to work on my game after the competition, and with it I have made several waves of enemies, rock upgrades, wall upgrades, and corpse cleaning. The gameplay is significantly extended, so give it a try!

I didn’t have much time to balance the new waves, so it might be a bit difficult.

I wrote a post in my blog about what constitutes a game, due to the reception that my entry to the competition, Heart, got. I hope to bring a differing point of view into the Ludum Dare dissection table for everyone to discuss, and for all to come out more inspired to make games.

By the way, I’ll finish the game properly and then I’ll write a post-mortem. It’s not too far from finished, actually.

dare ludic society, your positive and helpful comments “behind the curtains” really motivated me to spend more time with the game, after the compo. thank you all! …epic blueworm award? wow!! thx

the game is not fully done yet, but i think it’s more streamlined now, probably still a bit too “sparse”, but hopefully not as frustrating as before to play (although the platforms are still randomized).

play it here

(source, mirror)

So, I decided to try LD out. I actually found it while looking for “more cowbell” pictures to put in a slideshow at school, and found a screenie of jovoc’s Cowbell Hero. I noticed: Hey, it’s going to start soon! So I decided to join.

Introduction

So, I think I did fairly well. I picked an easy way out, in my opinion: I was actually thinking Rain would win the theme (although I didn’t particuarly want it), so I came up with an idea of acid rain falling from the sky, and using moving platforms to keep the rain from hitting you. But instead, Advancing Wall of Doom won. So I came up with a quick idea: You run across randomly generated terrain (2D) to avoid some wall of sorts. I wrote some code for the laser of doom (the wall), and created a little black ball with 3 frames of animation: one with ‘J’ written on the ball, one with K, and one with L. The idea was to press them in that sequence to move the ball foward. I ran into a problem: I couldn’t get the ball to act correctly to the terrain. So, I scratched the random terrain idea and went for something much simpler: a platformer game. I got the JKL movement idea from a game called “Dick Chaney’s Sky Patrol” whereas one level you were in a wheelchair, and you used IOP to move foward. So, I made the character a wheelchair. I’m a horrid spriter, so I didn’t put a person in it. Thus, Uber Unmanned Wheelchair Delxue was born.

The creation proccess

I was currently making another game to pass the time while waiting for Ludum Dare to start. It had autotiling. So I made some quick autotiling for the walls, getting the idea from the Dream Sector in Jumper2. I also made some other colored walls.

Then, I made sprited movement. You might not be able to see it in-game, but the wheel actually “spins” when you’re moving, but it stops when you stop moving. Genius!

Then, I programmed a quick platformer engine. Nothing special, although I did everything in the “step” event instead of keyboard events, because keyboard events like to conflict with one another. Which means that you would stop for a short amount of time when you jumped. Kinda inconvenient, considering how chaotic this game is.

Next, I began level design. I made a quick introductory level, featuring 0 moving parts. A lot of people had problems with this level. Failure, because you have to beat it to play the rest of the game (non-linear level path: level designer’s worst nightmare). As a result, people didn’t like it. I thought it was rather easy, although having played the game untold amounts of times, and having 3 years of platformer-game experience, that probably wasn’t a very good judgement difficulty-wise. I also made a wall tileset so platforms wouldnt’ just float there (although they do in later levels ).

The next level introduced a gimmick used throughout the entire game: spinning sawblades! Whee! I tried to “time” the sawblades so you came up to them when they were out of the way, although this proved to be a difficult task because I could only start them at 90 degree intervals. Also, so that the sawblades wouldn’t spin off of an imaginary pivot point, I made a tileset that allowed me to make pipes. Snazzy!

The third level was an attempt to introduce the third wall color (by the way, the wall colors don’t mean anything), and the concept of waiting. Waiting. Yep, while a giant randomly-generated laser is steamrolling toward you, you have to wait. As a result, there are a few close calls. Also, the last part is kinda hard to jump over. :/

Fourth level: Giant wall of sawblades! Whee!

The fifth level introduces the pause item, which will slow down the steamrolling laser to a mere tenth of it’s original speed.

Then, the ‘game completed’ screen comes up. Party! You made it this far.

Hopefully, you didn’t quit there.

The humor proccess

At this point in making the game, I was feeling pretty worn out and silly, wanting to crank out some random gimmick, causing humor. So, I took some inspiration from Karoshi 2. If you have never played that game, go Google it. Anyways, if you have played that game, you know its random style of throwing in little injokes, or continuing the game when you try to quit. So, if you check the password box, you may notice: “Hey, I don’t remember that password being for any of the levels! So you click OK. And it goes to level six.

Level six is an abusage of pause signs. You have to go uber-fast on this level, because if you aren’t fast enough, you have to wait for the sawblade to get out of the way, and so the laser blocks off the exit. Level failed.

Then, it tells you that it’s really done now.

But it isn’t. Go check the passbox, and it’s a new password!

I had a lot of fun with this level. The original level didn’t have a pause item, yet it was still beatable. Barely. This was one of those moments when I decided to actually give the player a break.

Lookie, a new password!

This level was based off of the idea of having to backtrack a bit to make a jump, and backtracking again to win. Most levels are RUSH RUSH RUSH RUSH RUSH RUSH OMG THE LASER IS CATCHING UP OMG OMG WOAH I MADE IT HOLY CRAP, but I decided to put in a little variety.

Now, it tells you there is no new password. Don’t beleive it? Go check the password box. See? same password. You must be done now. So quit.

Yeah, I felt like being a jerk.

So, this next level is based off of waiting. The jump is kinda hard to make.

Now, for the final level. This one took a while to make/beat, especially with the sawblade at the beginning. Then, I had a lot of fun with the next part. Not only is the laser on your butt, but the sawblades are nigh-impossible to navigate. A fitting last level.

Then, it thanks you for playing and says you’re done. Trust me this time, you’re done.

What I did right

I made a game.

I made it within the time limit.

It had a main menu.

I personally think it turned out really well, for a 7-hour game.

What I did wrong

Too hard!

Not enough stuff

Inconvenient menu

Lame idea (in my opinion)

Conclusion

I think I did well for a first time, especially considering the small amount of time I had to work on the game.

Background and Pre-Compo

My primary goal of this, my first Ludum Dare, was to finish the competition. Nothing more; not to win, not to place, not to show. In fact, someone’s game has to come in last place, and I was totally OK with that game being mine.

There’s something mystical about computer games. Every developer I know has tried to write one. All of us dream of checking out from our dreary jobs after a sleeper hit that we wrote at home over 52 weekends. But though we’ve all tried, none of us ever seem to finish our games. I was tired of being in the slacker group. I wanted to join the cool kids who have finished a real computer game.

I made the final decision to participate a few hours before the theme announcement. My wife’s 9 months pregnant and could go into labor at any moment, so when I first heard of LD a few months ago, I dismissed it as too close to our due date. But by Friday afternoon (Pacific time), it was looking to be a quiet weekend, so I committed. I knew that by Sunday evening I would submit a Ludum Dare entry.

Technical Preparation

At around -2:00 (two hours before the theme announcement), I downloaded an IRC client and joined #ludumdare. I closed all my open projects in Eclipse and created a new blank Pydev project. I made sure I could draw a gray screen in pygame. I promised myself that I’d stick to 2D.

I searched Google for [royalty-free clip art]. Then I read the contest rules for the first time and was horrified to learn that we couldn’t use clip art. You might as well have asked me to sing on American Idol. But hey, level playing field, etc. etc. etc. No biggie.

While waiting for the theme announcement, I read some of the survival guides and prior postmortems. Don’t use LD as an opportunity to learn new technologies. Don’t start coding before you’ve done a little bit of design. Don’t design for lots of content. Don’t get drunk. Don’t pick this weekend to get a new girlfriend. Roger wilco.

First Night

I spent the first few hours of the competition kicking around ideas. Almost every one was too ambitious, mostly requiring level design or lots of cute icons that I couldn’t draw, or else having a bunch of vague “and then the two actors have some sort of conflict” parts that I wasn’t sure would get clearer in the remaining 46 hours. I settled on a dumbed-down Tetris variant.

This was the first decision I made in the competition, and it was probably right for my personal goal, but it doomed any chance my game had of being playable. It was the best briefly-describable game I could think of in the short timeframe. I traded the benefit of simplicity for the chance of creating something interesting.

I wrote a little code and started talking myself out of the Tetris idea. Sensing trouble, I backed away from the keyboard and went to bed.

Saturday

I woke up hating my design even more. I started typing in more Google searches: [anti tetris], [tetris variants], [inverted tetris]. My web browsing was getting more free-form. Huge warning signs. I pulled back and resolved to get back to my stupid original idea.

Six hours later, I had the core game finished. I added scoring and an in-game tutorial. I also added some animation transitions that were surprisingly effective in helping my focus group (my two kids, ages 4 and 5) understand the cause/effect relationships in the game.

After a dinner break, I made another big decision: either explore gameplay and risk destabilizing the code, or button everything up to guarantee that the entry would be finished. I picked the conservative route and promised to return to gameplay during whatever time was left on Sunday.

This decision hurt, because I knew the submitted game was now very, very likely to be trivial and dull. But last time I checked, game design is hard. Which am I more likely to do in the remaining hours: stick to my strength of writing production-quality code under deadline, or come up with a brilliant flash of creativity?

Sunday

More buttoning up: gameinfo.xml, readme, license, screenshot, hunt-and-peck testing (which did discover a few obscure but good bugs), py2exe, free-licensed font, and coming up with a suitably dorky name for the game. As expected, these details sucked up a fair amount of time. But damnit, my entry was technically complete in every sense. I’d finished Ludum Dare!

With the remaining time, I implemented two interesting features: a special tile that showed up later in the game and introduced some locality constraints on the board, and various gradients on board components that gave them some visual depth. The gradient code introduced far more CPU usage than I expected, so I spent the last 90 minutes before the 48-hour mark prerendering and caching as much as possible (while flipping through the Git documentation to figure out how to quickly revert to earlier in the day if I had to abort the gradient project to make the deadline).

What I did right

• Set a realistic initial goal and stuck to it.
• Wrote solid, conservative code.
• Added a reasonable level of polish: transitions, cosmetics, in-game tutorial, and compliance with all the LD submission guidelines.
• Stayed on IRC.
• Admired without envying the progress of my fellow competitors.
• Postponed needless risks as long as possible, while tackling necessary risks as early as possible.

What I did wrong

• Wrote a really crappy game that is wasting LD judges’ time. I didn’t realize that every entrant was expected to judge every other game. That’s a heck of a O(n^2) algorithm, and I’m sorry to be contributing to the polynomial explosion. I wish there were a “submitted for non-consideration” tag, like “finalbutdonotjudge” instead of “final” if you’re entering just to enter, not to compete.
• The one somewhat fun aspect of the game is the special tile. But I don’t introduce it until 60+ seconds into the game. Unfortunately, from the comments left so far for the game, I am pretty sure that most judges exited before seeing the first special tile. The rule of thumb is to sell the core of your game in 20 seconds, or risk your judges bailing out early. Fixing this wouldn’t have saved the game’s crappiness, but I’m disappointed that I didn’t get this easy part of the game presentation right.
• Aimed a little too low, even for my first competition. It’s my personal style to value reliability over creativity, but successful gaming is all about taking risk. That’s obviously true in game play, but it’s also very true in the development of indie games. Your audience really doesn’t give a shit how proud you are that you finished your game; that’s a given, or else they wouldn’t be wasting their time playing your unfinished game. So people expect that any finished game will reach a basic level of challenge, and mine definitely failed that test. It was a fine personal goal to finish LD once, but for a second LD, if my game were no more fun than this one, I’d decline to submit it and call my attempt a failure, even if it was technically a complete entry.
• Didn’t explore every artistic challenge the compo has to offer. I should have tried to draw something. It was fine to use sfxr for my beep-boop sound effects, but at a minimum I should have tried throwing some reverb over the wav files. I avoided injecting any kind of artistic expression into my game, and as a result the game’s not just boring, but also sterile.

I have fixed a small bug in the AFI Top 100 quotes phrase file.  It contained an elipsis character that you cannot type.  I also fixed some issues with spaces showing up before a single quote.

You don’t have to redownload the game, just the two separate phr file and overwrite the originals.

phrasesupdate.zip

Introduction

This was my first attempt at entering the Ludum Dare (a.k.a. LD48). It was a bit intimidating to see some of the really impressive games that came out of previous LD48 events, however the line on the LD48 website reading something like “Historically, less than 20% of the contestants submit an entry” was a bit of an encouragement. At least if I bailed, I wouldn’t be alone. As it turns out, I was able to eek out a ‘game’ in the 48 hours, even if the only machine it likely runs on correctly is my own.

Time Management

I got my idea pretty early on, and my game design was done in under an hour. I’d say roughly 40% of my time was spent coding what could have been reusable game engine things, such as a texture loader, sound effects loader, collision detection code, etc. Another 20% was spent on logic specific to my game such as collision response, physics updates, game end conditions, and state changes. I spent another 30% on the game resources, including artwork and music. The last %10 was spent on the initial design, some game tuning, writing a quick read-me, and finally a mad rush to get everything packaged and uploaded.

Although I had devoted the entire weekend to the event, my girlfriend had some friends in town, and I spent about 7 hours (~15% of the time). I slept also, which in retrospect, was a good idea. By then end of the event, my nerves were starting to feel shot.

Development Tools

I was doing all my coding in C++ on Linux, using OpenGL and GLUT for graphics, OpenAL and libvorbis for audio. I used CMake (a build tool) to help generate makefiles which is handy because it allows one to generate build files for other systems (Visual Studio solutions, for example) using a single cross-platform compatible input file.

Editor: I used XEmacs as my editor. I’ve spent some time using it and have it customized pretty well to suit my needs. What do you think I’m typing this write-up in?

Graphics: I used Graphics Gale to create all the artwork, which I saved as 32-bit Targa files. Graphics Gale is available for free in it’s basic version with some feature restrictions. It has a few features to make drawing ‘cell style’ animation easier, such as onion skinning and animation previews.

Sound/Music: I wanted to integrate the use of my MPC1000 hardware sequencer in to my work-flow, so that’s what I used to sample a guitar riff and some beat-boxed sound effects I recorded. I have a microphone, mic pre-amp/effects processor, and dedicated guitar effects processor to tweak sounds before I edited and sequenced them in the MPC1000. I also used a couple freeware VST synthesizers from Tweakbench.

Time-lapse Video: During the competition I was continuously saving desktop screen-shots every 30 seconds which I later compiled in to a video. To save the screen-shots I used a Linux tool named scrot, and a very simple bash script like this:


#!/bin/bash
mkdir /home/win/screenshots
for (( ; ; ))
do
scrot /home/win/screenshots/%d%k%M%S.png
sleep 30
done

Note that in hindsight, I had some problems with the way the files produced by scrot were named. Some of the files had spaces in them, which might be a bug in scrot. This was a problem for me because my video encoder (ffmpeg) was unable to deal with anything other than files that were named in sequence numerically (no gaps in numbers). I was able to use the batch renaming feature of the Linux tool GQView to rename the files sequentially based on their date-stamp, and ffmpeg was happy. The ffmpeg encoding tool was able to splice in an audio file as it encoded the 1800 jpeg frames.

Game Design

I got lucky in that the chosen theme, ‘Advancing Wall of Doom’ was already my first choice, so my subconscious had some time to mull over the design. I wanted to keep the design dead simple so I wouldn’t bite off more than I could chew. Looking back, this turned out to be a good thing, as I was working right up until the end of the compo and wouldn’t have had time to add any extra features. Even though the design was simple, I feel I should have spent a bit more time considering the playability and fun factor of the game. During testing it was very apparent that my game lacked a lot of variability, and there wasn’t much room for any real strategy or technique. Every test-play through the game took about the same amount of time, and I hadn’t exactly intended the game to be based on any time limit.

Things Learned

Overall I’m happy with my performance during the competition, mainly in that I was able to complete my project in under 48 hours. Although my personal experience playing the game is biased, I’d say it’s good for at least a minute or two of genuine fun. I was also able to take a few things away from the experience which should make my life easier if I decide to compete again:

1. I was coding at a relatively low level, and ended up spending too much time writing and debugging code to provide functionality that others in the event were essentially getting for free (image loading, sound, collision detection, etc.). I also had to be aware of some platform-specific issues (namely timing functions) that users of other APIs could also ignore.

2. Sleep and getting up for breaks is important. I even went outside and ran around the block once during the compo. A couple minutes of jumping-jacks were helpful also. I didn’t regret spending about 15 hours during the compo asleep. I get the feeling my mind was still somehow at work debugging my code while I was sleeping anyhow.

3. I should have spent some time preparing a bit of template code that is generic for any relatively simple game (2D or 3D) that I might want to quickly create. Game loop, end conditions, state changes, main input/display/audio systems all seem like targets at first glance. I had a hard time deciding how to write my code in order to keep an architecture that wouldn’t strangle itself in the short time span of the competition. I think an overall ‘game template’ even if it was just a short checklist, would have been really helpful to me.

4. Although this wasn’t an issue during my time spent in development, I realized after the competition that my code would not be immediately available to other entrants because of the development tools I chose, and the because the corners I cut in testing meant that I produced code which had problems with timing and input on other systems I was able to test my code on afterward. This is a big problem because it makes judging by the other entrants much more inconvenient of not impossible. If I had developed for a virtual-machine environment such as Flash, I suppose I could have avoided this. problem.

Conclusion

I had a great time and am looking forward to entering in the next compo if I have time. I think as long as I can view the event less as a race and more as simply an exercise in programming and design on a very short time scale, and use the experience to become a better coder.

I also have to mention that the social aspect of the event is really great. Everyone in IRC was really friendly and helpful, and it was exciting to see what people had going on at any given time of day or night. I even found out that one entrant was a fellow student at my college, taking one of the same classes even. I’m glad that my comment about his entry on the web wasn’t too harsh!

Thanks everyone for a great event. Long live LD48!

-Windsor 04/22/09