Here’s an old one – the winning(ish?) entry from the 4th LD48. The theme was Infection, here interpreted by a cheeky wave of communism spreading through cute icon-based conversations! From the readme:

In a quiet, foreign country, all hell is about to break loose.

The populace are being infected by a deadly evil – communism, spreading through the country like a tide of blood. Enemy agents are on the prowl, converting civilians to their cause by rational argument and quiet discussion. This propaganda operation MUST be stopped. As a responsible and patriotic American soldier, it is your duty to protect these innocents from themselves. Should they side with the communists, annihilate them immediately. For as long as they do not – keep them safe and friendly.

— IN SOVIET RUSSIA, COMMUNISM BELIEVES IN YOU.

(NB. In the interests of exploring both sides of every issue, a Soviet Campaign has been included – whereby you, as a responsible and patriotic Russian soldier, are charged with keeping a neutral country free of the influence of the imperialist pig dogs.)

Commies took home a couple of Pellies – gold for Overall and Sound, silver for Humor and bronze for Completion, so I guess people liked it! Mostly, though, it was just a blast to make. I’m not really sure why I’ve missed all the LDs since… probably laziness. Still, I’m usually lurking in the wings to check out whatever people make.

Go download it!

Tags: final

So here’s how I wrote Bacon Beacon.

What I did:

I started LD19 with ambition, ‘flu and no preparation or basecode. I wanted to do a sprawling content-driven platformer, both to practice storytelling and to see how big a scope I could hit within the 48 hour limit.

My initial goal was to build a fairly linear “Metroidvania” type game where you’d explore and then get to an exit. I figured I’d come up with a narrative using the theme within that game structure once I’d started.

Then my internet connection was cut off forever.

What went right:

Ongoing scoping

About a third of the way into development, I realised I might not finish the game in time. I started logging work done in timelog.txt to help me estimate further work. Having a good idea how long it’d take me to tile a new zone or draw a new full screen image for some area helped me keep the scope realistic, letting me produce a relatively complete game – even if I missed the mark slightly. But more on that later!

I got better at tile mapping/level design as I went

I’ve never done any tile mapping or serious level design work. I rapidly picked up experience over the weekend and I’m quite proud of some of the later areas I crafted compared to the first few. I also got much quicker at it. If I hadn’t, I’m not sure I’d have had time to put the ending together.

Delivering story through text

Just as this was my first attempt at level design, it was my first attempt at storytelling through gameplay. I was originally considering an intro cutscene to set up the story but decided to jump straight in and leave clues instead, communicating the relevant information by text. Text-only content was extremely quick to implement, and since I’ve had comments praising this aspect I conclude the text-heavy approach helped to establish the mood very efficiently.

Low-fidelity graphics

Beacon’s native resolution is 400×225. The main character is 24×24 and its tiles are 16×16. The high-res structures and objects are very simple and stylised, with straight lines, a very limited palette and banded gradients (if any). This low-effort approach to art let me create a great deal of bespoke art for scenes in the game in just a few hours, even with my crappy art skills.

Beacon doesn’t have any lighting, shaders, full-screen effects, particle systems or other niceties. Skipping this stuff helped me focus on my priorities of content and tight, simple gameplay.

What went wrong:

No preparation

I started without any basecode, so my first task was writing windowing code, input, basic texture loading, rendering and so on. It took me about 6 hours to reach the point where I had a character moving around in a tilemap and could render text. If I’d invested the time to prepare (within the limits of the rules) before the competition, I’d easily have had 4-6 more hours to work on the game while I was still well rested.

Internet failure

Two hours into working on the game, my Internet connection cut out.

It took over an hour on the phone to Virgin to find out that they’d disconnected the old house two days early for our requested house move, wouldn’t reconnect it, and couldn’t connect the new house across the street until Monday. (Jerks.) Without internet access, I couldn’t get tools/libraries I needed or check reference, and I wouldn’t be able to submit at the end.

I almost gave up at this point.

I resolved to keep working on the game and, on Sunday evening, packed my desktop into the car, drove 60 miles to *my* new house – which already had internet access – then finish the game and submit it from there. In the end, talking to Virgin cost me an hour; packing up my PC and driving down through the snow took two. When I needed a font/font renderer, I couldn’t search for one, so I wrote one; another 30 minutes or so.

No sleep

I worked through the night. By Sunday evening, I’d been up for over 30 hours. Staying on task was getting tough!

If I’d napped for an hour or two around halfway, I feel it’d have been worth it. Instead, I got through enough coffee that I still couldn’t sleep until five or six hours after the contest ended. That kept me awake, but I’m not sure it helped me stay focused

Slightly too ambitious

This ties into the ‘sleep’ thing. All that scoping stuff above was useful, but I didn’t factor in how I’d slow down as I got tired. In the end, I was a few hours short. I had to cut music and also some minor bits of art polish, but fortunately I’d got all the essential stuff done.

Non-power-of-2 textures

I really should have known better, but I used 24×24 images for a few sprites – like the astronaut! This worked perfectly fine on my machine, but apparently the way DevIL handles loading these images makes them blurry on some hardware.

What next?

I’m currently working on a revised version of Beacon, with gameplay and art polish, music and some minor visual effects, for freeware release some time next week. I’m also collaborating with an excellent friend on a much larger non-linear platformer building on the Beacon codebase.

I’m taking my first steps as a fulltime indie developer now and LD19 has given me a few projects to warm up with. More than that – it’s made me remember why making games is fun! I got more out of LD19 than I expected and I’ll definitely see you all in four months.

Technology

Beacon was programmed in C++ in Visual C++ 2010 Express using SDL, OpenGL, DevIL and FMod. All content was created in Photoshop CS5 trial, notepad, and sfxr.

My game Beacon came 2nd in LD19 back in December. Since then, I’ve been making it better! I promised I’d post here when I got it done, so here it is:

It’s got its own page now over on my site. If you liked Beacon, I’m fairly sure you’ll like this version more!

I already wrote up a quick post mortem on my blog. This is a longer version with more info – if you’ve read the other version, skip down to “What went wrong” and read from there. Cheers!

The theme this time was pretty weird, so I was maybe considering skipping, but I got inspired and then I did it anyway. And I am SUPER PROUD of that because I got to do some cool sprite animation, script some cutscenes and make a game in a genre I haven’t tried before: the genre of PUNCHING.

PLAN

Every time I do a Ludum Dare, I have a vague idea of what sort of game I want to make or what skills I want to develop before the theme’s even announced. This time, inspired by playing Nicolau Chaud’s Beautiful Escape: Dungeoneer (review) last week, my plan was to make something contemporary and human. That led me straight to the idea of making a game where you punch people who don’t have rape alarms until they’re scared enough to want rape alarms. For their safety.

Consequently my entry “Vigilance” is a game about suspect charities, lonely women walking through empty parks at night, and pretending you’re a ninja.

Below the jump: my dev process, including roughly how long it took me to do the various things in the game, and a quick post-mortem.

DEV PROCESS

OK, here’s something I feel a little guilty about: I was even less organised this time than I was for the last one. I didn’t even do a timelog, didn’t really bother with scheduling and cutting scope until I had about two hours left, and the whole thing’s frankly pretty hazy. Here’s what I remember, though:

I started off working on the graphics, as always, and then focused on character movement and response. Because the characters in “Vigilance” are normal humans and move about a lot – this is a gritty, realistic brawler of a fighting game – I ended up doing a ton of animation work. Including writing a decent animation system. Between this and rewriting my basecode because I never published it, getting a controllable character running around on a blank screen took me about 12 hours. But it was great! I learned a ton about animation, and making a controllable character with that fidelity and level of animation was enough of a victory that I could have stopped then and been happy.

But instead, I soldiered on! I set my character up so you could give a few NPCs with no AI a kicking. Here’s a playable version of what I had after day 1.

– Next I added the AI and game rules for the brawling part of the game, since I felt that part would need the most polish and balancing. (Also, I didn’t have a firm design in mind for the daytime scenes yet.) Getting the night scene into a decent state took about 3 hours, and I was polishing it and adding to it for the rest of the weekend.

– I now had about 14 hours left. The daytime scene came next. My original design called for conversations with each of the NPCs where you’d choose dialogue options, but for the sake of getting something in there fast, I built a minigame where you had a time limit and had to go interact with as many NPCs as possible. The whole conversation part of the interaction was abstracted out, so the NPC just gave you a final outcome at random. With a time limit added this turned out to be fun enough, so I dropped my further plans and focused on refining what I had!

– I spent a while here balancing the night-time combat, setting up the day-night-day-night game flow and putting in little bits of conversation text.

– I started work on the first major cutscene (“This asshole town!”) with about 8 hours to go and spent the next few hours adding context and jokes to the game.

– I added the ending screen to the game with about 4 hours to go. I think this is roughly when I managed my last start-to-finish playthrough. I don’t really recommend doing hours of development and then releasing without thorough testing, but I just didn’t have the time to make sure everything worked before I submitted. 😀 (I got lucky – everything did!)

– Started work on the sound effects (with bfxr) with 3 hours to go.

– Started work on the music (in Reason) with about an hour and a half to go.

– Tidied up a few loose ends with about 15 minutes left, like adding palette swaps for the NPCs so they weren’t all redheads with green shirts and putting in the mandatory “It’s dangerous to go alone!” conversation with an NPC… and submitted seconds before the end of the 48 hours. Result!

WHAT WENT WRONG

– I ran out of time. I could really have used about six more hours, just to draw better quality backgrounds, add a few more cutscenes/conversations, flesh out the ending, sort a decent title screen and polish the AI a touch.

The worst part is the night-time park background, which isn’t even identifiable as a park. Thankfully the location’s explained in conversation, but I’m still very much unhappy with it.

This was largely my own stupid fault for, again, not having basecode ready. Lesson learned – I’ll definitely be prepared next time.

– Focusing so much on fluidly-animated characters when I’d never done them before meant it took me hours of experimentation just learning how to animate them nicely! I went through a few iterations of the character and the run cycle early on before it started to come together. That kind of experimentation’s paradoxically the funnest part of Ludum Dare, but it’s a poor use of time vs. developing concepts that rely on skills you already definitely have.

WHAT WENT RIGHT

– The animation. This is the first time I’ve done this much character animation in a game! Beacon had about 9 frames of animation total – this has 32 frames per character, across two characters (generic boy, generic girl) and one variation (Night Marcy). I spent a few hours on the first day setting up a sweet little animation engine that let me string together frames from the sprite sheet and muck about with timings, and that really paid off in terms of making the character control nicely and the combat feel good. More than that: the animation was probably the most rewarding specific thing I’ve done in any LD, and I’m super glad it came out this well.

– The “feel”. Though the game’s obviously inspired by decades of beat ’em ups, I wanted a gritty, realistic, sadistic feel to the fighting. It was tricky coming up with a system that didn’t use flashy kicks or combos, but little things like being able to kick people when they’re down to make them run away really built up the atmosphere of random, cavalier vigilante violence.

– The music. I literally wrote three music tracks in under an hour. I am so incredibly happy they’re not terrible! By all rights, they should be.

– The script. The concept deserved some serious work on humour and characterisation, so I spent a good chunk of Sunday bouncing jokes off my awesome and eternally patient girlfriend to make sure they were funny to someone other than me. That seemed to pay off, and it’s a real pleasure to see people enjoying it. 😀

WHAT’S NEXT?

My current plan with “Vigilance” is to clean it up and do all the things I sadly couldn’t find time for during the competition, like decent background graphics instead of those placeholder scribbles, better sound and about a 50% bigger script. If you want to follow its further development, follow me on Twitter or check my blog. I’ll try to get the final version ready in time for the judging results three weeks from now in case this ranks highly. Fingers crossed