http://www.youtube.com/watch?v=9IjsHysbTUk

I can’t believe how long it took me to reboot to get rid of that Windows Update dialog, hahaha.

Next compo I’ll get the webcam going, too… much more interesting when you can see the person I think.

Tags: timelapse

This is my first LD so I don’t have anything to compare to, but I actually think overall I did pretty well. I’m not sure I can say what I did write and what I did wrong, being new to the compitition and game developement in general, but I can say what I did at least.

Ideas

I didn’t really have much trouble coming up with an idea. My first thought was to make the game incredibly happy looking (flowers, smiley faces, etc.) and then have a freakish wall of death, but it relied on graphics and I had no thoughts for game play to back it up. Really, it seemed you could either take the theme literally and make a wall of doom chasing you, or you could interpret it to make some sort of art game.

I chose to just make a wall of doom. I didn’t really think of the game play mechanics at first, just started making the player graphic. I guess I did that wrong, but I just wanted to start coding and see what I’d end up with. The final version ended up pretty well balanced, I think, but so many things could have gone wrong to ruin it entirely.

Code

Using Construct made the coding pretty easy for someone as new to game developement as me, although I do hope to enter LD some day using “real” code. The game required a lot of things I’d never done before. The player remained in the center of the screen the entire time and the ground went on for ever, so instead of programming the player to move I moved everything into a family that moved when the arrow keys were pressed. I started making animations for the ground to move, but it didn’t look to great and skipped when you stopped or changed directions. I ended up scrapping the animations and applying a warp behavior to the ground so it would scroll endlessly, which looked much smoother but did have some slight tearing issues but not a major problem.

The main thing I had trouble with was spawning buildings and enemies randomly, and I never entirely got all the bugs out, but it worked pretty well in the end. The main issue was buildings overlapping each other, and I never entirely fixed it. Enemy AI was easy until I found some game breaking glitches in my code I couldn’t fix. I ended up just skipping it and comming back later, but I did find a solution. 

Overall it went pretty well, there were a few stressful moments where the game seemed to destroy itself and I wanted to give up but nothing to major.

Sound

The sound might have been the easiest part of the game. I used sfxr for all the sound effects and Musagi (along with a tutorial) to make the music. I’ve had complaints on the music being repetitive, due to the fact that I’ve never made music before so I just looped the 30 seconds I had throughout the entire game. And thats pretty much it for sound.

Graphics

Graphics were easy to, as I just made a sprite whenever I needed one. I decided to keep everything simple because a) Complicated art takes time and for me wouldn’t even end up looking to good and b) (basically the reverse of a) Simple art can be made quickly and often ends up very eye pleasing. Most of the graphics I made at the begining of development, except for the helicoptor blob, which I threw in at the end to varry the game a bit. Only complaint anyones had with the graphics so far is that the magic looks like blue sperm.

Conclusion

I’ve been very pleased with the feedback from people in LD14 and from others I’ve showed the game to. We’ve been having competitions in my web design class to get the high score (currently at 6000 something) and its ended with some pretty awkward quotes, to (“I had mad money but I couldn’t find a dude castle.”). I went ahead and fixed some of the problems people had with it and updated the game post LD. One complaint was that the game isn’t varried enough, to which I have no excuse. I finished the game around 4:00 on Sunday (I think) and uploaded the final version. I had plenty of time to add some more features, but I guess I was just to burnt out. I worked almost nonstop on the game, and the break I had on Saturday was to go outside on a hot day and shovel mulch for two hours. But overall I’m happy with it. I actually managed to take everything I had in my idea and work it into the game, and it worked out pretty nicely. The game is far from perfect, but I’m fine with it.

Hi people, I had some trouble with my home server where I was hosting my LD48 #14 entry, and so I’ve moved it to my domain host’s server.  If you want to test/play/vote on my code, the download link is here (Linux source + i386 binary):

http://windsorschmidt.com/dl/winferno_LD14_youfirst.tar.gz

I’ve also got my desktop timelapse video up on YouTube here:

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

Or, if you want to download the original 8MB video file (mpeg video + audio), you can get it here:

http://windsorschmidt.com/dl/ld48_14.mp4

Thanks everyone for a fun event. I’ll definitely be putting the next LD on my calendar!

-W

I recorded a timelapse of my game which Fiona uploaded to youtube for me – hurray!

http://www.youtube.com/watch?v=nkbvkhGOR-0

The analog clock in the corner looks awesome 😀

Hmm I didn’t know how to get the video to be embedded in the page – is there some trick to it?

Tags: embed, timelapse, youtube

Okay, I’m calling the game done. The biggest addition is a campaign of semi-random levels which introduce the game a bit more gradually. I’ve also added in some special case rules that help regulate the game a bit and keep it from breaking quite as frequently. This build also includes a few small graphical changes. After playing through the campaign, the game creates an endless string of more random arena levels. Here are some directions:

Purple creature- this is us!

Red creatures are enemies.

Green creatures are our allies. They produce two types of helpful offspring:

Purple followers can be collected for additional firepower.

Green eggs can be gathered and planted to make new allies.

<arrow keys> – move

<space> – plant eggs

Our character fires and heals itself automatically.

Play the game

Edit: Updated Version (fixed a sound glitch)

Edit again: A New Version (fixed a couple bugs that affected creature reproduction)

These are two examples of the new levels:

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

Tags: writeup

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

Tags: entry update, ld48_14, supershred

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.

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

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.

Tags: laser, post-mortem, wall of doom, wheelchair

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)

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.

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.

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

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

Tags: timelapse

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!

PREPARATION

While I’ve always been great at not finishing games, I hadn’t even started a project for months. I’d gotten a boost of inspiration from an article on Cactus’ GDC lecture, and then LD14 came along at a perfect time. I decided to use this event as an opportunity to get back on the horse and actually complete something. I almost never finish anything which takes more than a couple of days anyway, so short competitions are brilliant. Looking back what Google remembers of my suddenly-dead website it seems I even took part in a 28-minute compo once.

Knowing that I focus best when I’m trying out something new I also decided to give Construct a proper go. I’d been messing about with it for a few weeks and was fairly comfortable with the transition from MMF, and Construct is itself a far more pleasant environment to work in. Taking into account that it’s not quite reached v1.0 yet and occasionally crashes it’s now at a very useable stage.

My pay came on Friday, in cash. That allowed me to purchase the new microwave I needed in order to remove the time-consuming issue of food preparation from my weekend. It also allowed me to pick up the TV I’d resolved not to buy until Monday. Fortunately I managed to resist playing the big pile of console games I’d picked up on the previous weekend.
Also on Friday I was informed of two things which would give me complete freedom of sleeping pattern: I didn’t have to work this week, and my girlfriend would be staying with relatives on Saturday night.

DAY 1

Advancing Wall of Doom wasn’t my first choice, but the ‘DOOM’ part did suggest that I try out one of the ideas I’d been wanting to experiment with: reproducing an FPS engine in Construct, which is intended as a 2D game authoring package with only very limited 3D support. In fact the only true 3D that comes built-in is the ‘3D Box object’, so that’s what I’d be using. Graphically that would limit me to making not much more than a Wolf3D-era game, so that was my aim.
When the theme was announced I was in the middle of a class with some of my tutorial students. After they left, excited to begin, I jumped in and started working with only a loose idea for a shooter set on a space ship in mind as that would let me do some fun Zerg impressions when it came time to record sound effects. Crushing pushwalls and stuff would satisfy the theme.
I quickly ran into my first problem. I had for some reason assumed that Construct’s Families would be a little more DWIM than MMF’s Groups, but my attempt at simplifying the code with them did not behave as expected. I weighed the unknown period of time it would take to find an alternative (which would let me add new wall types very easily) against simply duplicating a few lines and elected the latter, with the intention that I could simply replace the textures of the walls for each level without touching the code.

After that, getting the basics down was surprisingly easy. I had a Wolfenstein-type engine, managed to add headbob and angled walls–which can actually do all kinds of fun stuff like being pushed and rotating during play but I forgot to use any of that in the levels–and I even added jumping at one point before deciding that first-person jumping puzzles suck and dropping it.
I bought some plastic guns on sale at the toy shop downstairs (to ‘digitise’) before deciding not to have weapons at all in favour of making an atmosphere-centred exploration game. This decision was brought on partly for the time it would save, partly for the theme-related doom it could add, and partly because I discovered that if you suck air through the sweets I’d been eating it makes a fantastic ambient wind noise.
The game would take place on a planet now rather than a space ship, because I found I could make a landscape from the cubes easily by giving the cubes random heights.

I had a great feeling of being ahead of schedule. Day 2 would be for building levels, so I decided to take a break to wind down before sleep. But after some snacks and a movie, my excitement was still pushing strongly enough that I finished off the first level in bed.

DAY 2

Jumped out of bed an hour before my alarm went off, snatched up my laptop, and dove back in.

I learned something new when I began level 2. Construct doesn’t handle ‘frames’ the same way MMF does: it doesn’t isolate objects, allowing each frame to be fucked with totally independently. Thus my small problem with Families became a big problem of copy/pasting a handful of action lines for a dozen new cubes and updating the references manually. Manually because the find and replace feature of Construct doesn’t seem to work properly yet.

Towards the end of level 2 I discovered a new problem, when for the first time I got an error without an abrupt exit. This time it was whining about vram. Looks like Construct readies all the 3D Box object textures at the get-go, and stupidly I’d been pasting in my textures without scaling them down from the original sizes I made them at. A strange feature of the 3D Box object is that you can’t simply reuse textures, you have to include a separate one for each face, and since I wasn’t sure which faces were the unseen tops and bottoms in my game I was adding them all. So not only was each texture four times bigger than necessary, they were being duplicated in memory six times over. I went back and replaced all the unseen faces with 1×1 black squares and scaled down new textures as I added them from that point on.

I made a few tough decisions here about gimmicks I wanted to use for building atmosphere. There’s one section that is supposed to confuse players, even frustrate them slightly, but if they get stuck too long that will backfire. I tried to fine tune it but couldn’t get the game online for people to test, so I had to just guess at the optimum difficulty. In hindsight, making the layout more linear might have been smarter.

With level 2 and 3 finished I thought up a title, updated a bit of text, and added a ‘feature’ which would keep people from wasting their time trying to outsmart the endgame. I anticipated criticism on that either way, but this would make the feedback more interesting.

The biggest challenge of the last three hours was trying to get the damn thing online. My new ISP, as it turns out, is worthless on weekends. Thanks to Morre reassembling the 8-part rar archive I had to email him the day was saved.

The left faces are half the resolution of the right faces. Or is that the other way around? I’ve forgotten.

GOOD

-Jumping right in without a solid design in mind worked well and saved me a bunch of time. It restricted my options for the design, but isn’t that a good thing for a 48-hour timeframe? It certainly prevented me biting off more than I could chew.
-I’ve never tried to focus on atmosphere before but the feedback I’m getting has been positive. It seems a little atmosphere adds a lot to people’s impression of a game, so it was a good investment of time and overall was much easier than adding weapons and a bunch of foes.
-A weakness of mine is animation. I’m never happy with the results so I tend to waste a lot of time on it. This game has almost none. Doors move and plants pulsate with a sine behaviour, and that’s about it. Yet that too contributes to the effect. I think.

BAD

-Working with inclomplete software with minimal documentation wasn’t that bad, but I still had to deal with crashes and weirdness. The transparent areas of the boxes acting as sprites obscure other sprites sometimes, and I have no idea why.
-Being unfamiliar with Construct lead to problems such as the texture issue, and the problem that started with Families which was a direct result of me still working in an MMF mindset. Overall I doubt that wasted more than half an hour though, and I learned something.
-I got the game uploaded in time, but I could very well not have. My website went down without notice some time in the past and I had no plan at all for getting my entry online.

CONCLUSION

Motivation up. That’s what I wanted from LD14 and that’s what I’m feeling. I learned a few things and I’m happy with my entry and the feedback I’m getting. There are things I’d do differently next time with the help of some testers and for that I’d probably need a new ISP. But the most important thing for me is that I’ve finished a game, had a great time doing so, and I’m hungry to make more.

Tags: postmortem

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.

Game evolution

On a scale from “Amorphous Blob” to “Rigid Idea”, this is where my idea fits in:

Despite being relatively sure about what I was going to do, I didn’t get as far in the first day as I have in past contests. I more or less had my technology working, but no game to speak of. The second day, I woke up with a terrible headache that prevented me from working on the game for a couple of hours. Something was clearly wrong (see the image to the right).

A bit of technology

Before discussing a few gameplay issues, I’ll try to explain how the underlying technology used for the arrows and stars works. The stars are in fact controlled by a vector field with relatively sparse density (every 20 or 30 pixels or so). Each vector will turn downwards and change its length according to the strength of gravity over time. When an arrow is drawn, a new vector (that points along the arrow) is added to the vector field at every point in the arrow. This means that multiple arrows will create a stronger effect. For each star, the closest four vectors are then interpolated and added to its velocity once per frame.

The vector field without gravity looks something like in the screenshot below. Note that the arrows faded out a bit too quickly compared to the vectors when I took this screenshot.

What went wrong

Shooting mechanics: I spent a fair bit of time tweaking the rain, gravity and arrow effect mechanics, trying to make it fun. Despite this, a lot of people have said that the arrows did not work as expected. The general sentiment seems to be “I expected the stars to follow the arrows closely”. I can appreciate this, and I did have this plan in mind briefly. In retrospect, I should probably have abandoned my attempt at making a somewhat more “correct” physics model, and instead let stars follow the arrows.

Rain: Having the stars fall down from above seemed like a great idea, but in reality it just made sure that the bottom of the screen never got any “ammunition” to use. A few alternative approches that I could have used are:

• Letting the stars be “attached” to the sky, leaving a limited amount of ammunition per screen. With this approach, one would need to be more careful with arrow drawing (to avoid wasting ammunition). Perhaps stars could also grow back over time.
• Having stars come from particle sources to the left or right, thus avoiding the “no stars in a given area” problem.
• Creating stars for each arrow – perhaps they’d stick for a while and fire a couple of stars before disappearing? This could be coupled with more limited arrow-drawing and enemies that can only be shot from below, or behind, or at a certain point.

Lack of variation: The game lacks variation. There needs to be more enemy types and more variation in the shapes you’ll use for the arrows.

What went right

Visuals: I am primarily a coder, and not an artist. Despite this, several people have said that they liked the visuals of the game, and that is something I am happy with. While the arrows don’t quite match the pixelated style of the rest of the game, I think that the overall style is rather coherent.

Proof of concept: Having more or less settled on the idea in advance, I knew turning it into a fun game would be a challenge. However, I think I got at least halfway there, and I feel confident that further experimentation with the concept could yield a fun game. Several people have also told me that the mechanics may be suitable for touch screen or Wiimote-style controls.

Polish: Even if I didn’t have time to fully develop the gameplay, I think the game feels relatively polished; I’m happy with both the title screen and game over effect. I often skip both of these when making games, but taking the time to make them was well worth it.

Conclusions

Visually and polish-wise, I am happy with the results. I’m also relatively satisfied with how the game turned out overall, but I feel the gameplay could have used another day or two. A little bit of variation and better shooting mechanics could’ve made this game a lot better!

This was my third time participating in Ludum Dare. Once again, it’s been a lot of fun! I’m looking forward to competing again soon. 😀

Here’s a screenshot of the title screen from the final version:

…Okay, I exaggerated a bit in the post title. There’s just one stick figure. Sorry :/

Tags: LD14 - Advancing Wall of Doom, PM, postmortem, Sky Upon Us, tigs, wall

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.

I’m quite pleased with how it all turned out.  It’s not particularly great as a game, but I’m really happy with the style and the wee story, and the fact that I was able to get it finished within 48 hours without having to cut any major corners   The whole experience was a really good one, and I definitely plan to take part in the next one.

Given the comments, I should probably explain a little about the positioning of traps and hurdles.  Basically the main problem is that I didn’t paint the lanes straight, which means that the game will often place traps slightly away from where you’d expect them to be, because it works with straight lines as opposed to my wobbly inking.  I didn’t find this much of a problem myself, but in retrospect what I should have done was draw a wee icon that showed you exactly where your trap was going to end up.  Also, the hurdles can only be moved one ‘step’ to the left or right of their original position.

Some other notes; the game uses OpenGL for the graphics, which means you might find it a bit slow if you’ve got an old graphics card.  There are various things you can do though.  First, make sure anti-aliasing’s not turned on (it doesn’t do anything in this game anyway, since it’s all just bitmaps).  The versions I posted above have it off by default, but if you downloaded the original Windows version it will be on.  To switch it off, open the GameTemplate.conf file (see the latest readme), and change a 6 to a 0.  If that doesn’t work, try reducing the resolution, with the w and h parameters in the GameTemplate.conf file.  Finally, there is a buggy 2D renderer you could switch on, but in my experience it’s quite a bit slower than the OpenGL renderer because it does everything on the CPU (to switch it on, set s to 1 in GameTemplate.conf).  To be honest I’d be surprised if you need to go that far though – the game runs just fine as is on my old G4 macmini.

Finally, here’s a shot of most of the graphics for the game, in their original form (warning: SPOILERS 😉 ) :

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.

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;

1. A designer’s perspective conflicts with a programmer’s perspective. If you focus predominantly on subjective game experience (which I did), you acquire a less objective mode of thought that prevents you from rigorously perfecting your code. Thus, you’ll either make elegant classes/interfaces and end up with a regular game, or you can tweak and play with the game elements until it becomes something unique and consistent, and end up with a spaghetti of enums and ifs.
2. You should keep a journal to keep track of your development, and be open to comments to keep your development on track; especially if you are alone (like me).
3. Tools and tech can be reused, generators are okay, but the content is part of the art. So you must use original content (and sound, as I had to).

In the beginning was void

I woke up a few hours after the theme was announced. I tried to think of ideas. I joined #ludumdare, briefly looked at the blog posts of the first hours, and I was surprised to see how early people started prototyping and sending screenshots. One of the first posts by Comtemno was about magma [3], which reminded me of this fluid dynamics code [4] I wanted to use in a game.

At first, there was just a piece of smoke that grew and filled the screen. I painted it red, and it reminded me the flood of blood filling the hallway in The Shining [5]. I put new tiles to form a container, and modified the fluid simulation to make the blood fill it and pour out of it, adding gravity. This required me to modify the simulation so that the walls bounded the fluid. I had no idea of the gameplay, but this seemed to be a good direction for the theme. However, the code did not simulate a liquid but a gas, so I had to find a compatible scenario.

Gas, walls and agents

Gas and “wall of doom” reminded me of gas chambers. So, the container became the topdown view of a corridor instead, and the gas diffused from one direction to the other through the corridor. There was also people inside, and they had a basic AI that allows them to flee from the gas if they smell it, i.e. the gas density gets over a critical threshold. It took me some time to implement the agent behaviour and collision detection. Agents approximate the gas density gradient from a few grid cells around them, and then flee in the inverse direction. Agent positions are floating point coordinates, but walls and gas densities are based on an underlying grid, so is the collision detection, and that’s why the collisions seem a bit wrong.

As I was programming the agents, the game felt like going out of control. I had no idea where would the player fit in this picture. I was playing with the gas by adding/removing walls, so I thought this could be what gameplay is about. The player would be changing the wall structure to kill some agents and rescue others. I even added a sink object that could be put to suck the gas. At this point, I released the prototype and asked for ideas from friends and LD community.

You can escape the gas, but not its connotations

Then, I saw ManTis’ comment in favor of the “political incorrectness” the game acquired, and also one of my friends wondered if we would be “playing Hitler trying to build the most efficient gas chamber?” Eventhough making a simulation of genocide did not really pass my mind, my prototype had evolved into one before my eyes (I’m serious. Well, I know about Hitler and fascism from movies, but it’s not like being taught about it in history lessons). The holocaust connotation was so strong that it required no explaining. In fact, there was only a poisonous gas and some living beings escaping it. It could as well be fish escaping pollution, vampires escaping light, fairies escaping a dark cloud, etc. Whether it was the poverty of my imagination, the strength of the connotation (see Godwin’s law [6]), or the non-existing artwork to suggest an alternative interpretation; I was actually facing the necessity to finish and submit a game that eventually presented itself as the simulation of genocide.

The big decision was putting the player in the shoes of a regular agent, i.e. a prisoner escaping the gas. This introduced a huge emotional load to deal with, so I needed a soundtrack to capture the atmosphere. There was an ambient audio file I previously saw on freesound.org when we were looking for a background sound for Itchy [7]. I did not know original sounds were required, so I picked this sound for the game, and put it on VLC player in loop mode until I finished the game. I like these kinds of atmospheres, like in Dungeon Keeper or Thief. I wish someone had made an ambient sound generator that I could play with (though I’m not sure to what degree generated sounds can be considered original). I know some pd, and I’ll be playing with supercollider, so I may come up with a generator some time.

Seeking meaning in despair

Anyway, there was this little problem about the game: What meaningful aim could a holocaust victim possibly have? Rescuing other people would clearly be an unrealistic fantasy. Achieving some kind of score would be ridiculous… So, it could not be an aim of collecting or winning, but only of simple exploration. This reminded me Mirror Stage [8], where you lit up places by walking around and touching boxes to complete a level. I decided to adopt this as touching people, other prisoners. The idea was the player having the courage to get close and see people just before they died. In the beginning, other prisoners were colored identical to the walls, so they were the part of the prison around you until you got close to them and each of them lit up, as a person like you. The color metaphor triggered other ideas, like randomly generating a particular color and name [9] for the player, which was elaborated further while writing the story.

The game obviously required no explanation for the context and the gas, but the little colored boxes needed some meaning to relate to. I chose a font from GLUT’s functions, and began writing sentences on a black background. I changed the level#.txt files to include an explanation for the level and two ending messages in addition to the map. About my decision on narration, my example was Judith [10], in which all the story was told in first person, the gameplay did not involve a challenge other than exploration and collecting pieces of the story, yet managed well to put the player in the shoes of the character(s).

A rejoice in death

In this framework, I now needed an actual storyline that spanned a few levels, was compatible with the social-historical facts and meaningful enough for the player to pursue. I wandered in pages about the gas chambers in Auschwitz, looked at pictures taken in former chambers [11], searching for something that I can represent in my game. The best I could find was a report about prisoners’ lives in Auschwitz by Witold Pilecki [12], the only person known to go there as a volunteer. He organized prisoners to improve their life. Anyway, it’s a long story. Here is a passage from that report that felt like the key to make a meaningful game [13]:

“Many prisoners, while going to the gas in a car, cried to his friend recognized in the row: ‘Hello Johnny, hold out!’ He waved his cap, he waved his hand, he was going in cheerful spirit.

All in the camp knew where they were going to. So, why did he rejoice? It can be supposed, he was so fed up with what he had seen and suffered, that he did not expect to see anything worse after his death.”

Thus, the title, “Final Solution” primarily refers to Endlösung [14], but it has a secondary reference to the death as a final relief for the prisoner.

The variations in story

When you start the game, four things are generated for the character: A color, a name, a number, a daily activity (“..when they got me”), and a close relation to the person that is being looked for (mother, daughter etc.). Other than these, the story is identical. What the game switches is only who the story belongs to, not the story itself. I avoided major variations, because the story was already about the fading of these particularities of the subjects in their shared fate.

As the game evolved into what it came to be, I played it many many times in all its stages of development. To me as its developer, the game gave a weird feeling that it lived in a separate reality, condemned to an endless repetition. It went on and on, like the ambient sound in the background, each time about the similar fate of a different person. The game stubbornly held these made-up stories against me, as if it acquired an attitude of its own. Every time, the story began like this with a new name:

Story of Peter
-I was reading the paper
when they got me.
It was not unexpected,
but still a surprise.
They brought me here,
to this building.
Shown this door,
where can I go?

And after each time it started, it demanded the player to direct the character’s actions to what must happen.

Character as mind, player as body

I believe that, in the game, there is a divide between the player who determines the actions of the character’s body, and the character’s mind facing and interpreting the consequences of these actions. This divide is emphasized by the duality between story and action. The player either controls the character, or follows the story through his/her mind. This looks like the common conflict of immersion: What does the player want? A character to relate, or an avatar to embody? I think you don’t have to solve this conflict, you can directly incorporate it to enhance immersion. After all, there are times when we feel a divide between our mind and body. Especially in the extreme circumstances of a unpreventable fatal threat, we can imagine a body that cannot help but feel a useless anxiety about being there, and a mind that frees itself from self-worries. In the game, despite the obviously desperate conditions, the character (as the mind) rarely uses negative words and never mentions the gas directly. This avoidance inversely effects the player (as the body), forcing her to undertake the anxiety that is missing from the character’s mind.

To conclude

I owe to everyone that played my game, found it interesting, dramatic, depressing, not-fun, or any other adjective that bears a strong meaning, as it was what I sought to achieve.

fidaner

~~ References ~~

1. Global Game Jam
2. Itchy! The adventures of a bug fleeing the very creature it is walking on!
3. Comtemn’s post
4. I used Jos Stam’s fluid simulation code
5. The Shining by Stanley Kubrick
6. Godwin’s Law @ Wikipedia
7. archi_soundscape_cavern2.wav by Argitoth
8. Mirror Stage by increpare
9. I used name list for 2009 in this page
10. Judith by increpare & Terry
11. Auschwitz Scrapbook on Gas Chamber
12. Witold Pilecki @ Wikipedia
13. Witold Pilecki’s Auschwitz report
14. Final Solution (Endlösung) @ Wikipedia

Tags: post-mortem, postmortem

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

Tags: voting