Well, I’ve never done one of these before, so here goes nothing.

What went right

Long brainstorming session

I was fortunate in having a group of friends help me brainstorm ideas when the theme was first announced. About a dozen ideas were thrown around, some interesting and some worthless, until I finally settled on this one. My first few ideas were tempting but also ultimately crappy, so being able to bounce back ideas with other people saved me from falling into the usual trap of doing the first thing that fell into my head.

Playing to my strengths

This isn’t the first roguelikelike I’ve made, and for good reason, aside from loving the genre: I’m not any good at art, at all. In almost any other genre, I’d be forced to spend long hours putting together terrible art, but fortunately this wasn’t an issue for me here.

Not reinventing the wheel

For level generation and field-of-view computation, I used rot.js, an excellent set of utilities specifically designed for roguelikes. I probably could have managed without rot.js, but when you only have 48 hours, why not limit the work you have to do as much as possible? Using rot.js also offered the huge advantage of giving me something vaguely playable within an hour or two of starting, meaning that I could spend the rest of the competition working on making gameplay as fun as possible.

Addictive gameplay

My main objective with this game was making it as fun and as fast-paced as possible. To this end, I made death be completely harmless, let players immediately create a new character in one click and jump back in the game, and provided a silly soundtrack to accompany the dungeon romp. When my playtesters (er, friends) started to refuse to give me back the computer, I knew that I had stumbled onto something.

A little bit of flair

Roguelikes are inherently rather bland visually, so small touches to make the game look good were important for the player experience. Things like smooth lighting, a shiny experience bar, and a memorial to dead characters at the end of the game were all relatively quick to implement and provided a nice distraction from the big-picture stuff for me, while making the game look much more polished. Don’t skimp on the small stuff!

What went wrong

No good plan for the second day

Most of the game features (timer, dungeon exploration, combat, character creation) were completed in the first 24 hours, which made me very optimistic about the next 24 hours. However, while there were a lot of things that I wanted to do (including items, spells, and more interesting monsters), I spent so much time debating about what order to do them in that I wasn’t able to work most of these features into the game. In the end, my second day consisted mainly of making levels and creating the boss fight and ending, as well as doing a lot of playtesting and minor tweaking. Next time around, I’d like to budget my time a little more effectively, especially for the second day.

Not enough replay value

Well, you beat the boss, and then the game is over. Several playtesters told me the game needed to have a way to continue playing after the boss fight, but, given how messy my second day was, I declined to implement this at the time. I did eventually address this issue by adding an Infinite mode to the post-compo version though.

Dungeon annoyances

I didn’t spend enough time making sure that all dungeon stairs are reachable within 10 seconds. Sometimes the stairs aren’t, though they should still be reachable if you have a faster character (speed > 1.0). And I’m pretty sure there’s a (small) chance of the boss appearing in an unreachable location on the final level, though I haven’t personally seen that. Regardless, I should have spent more time ensuring that every game is beatable, regardless of luck of the draw.

Not enough lore

The game’s story consists of two paragraphs of flavor text that I hastily cobbled together as the minutes were counting down. I suppose it’s not that big a deal for a game that seems to have more in common with Quake than with Rogue, but it still would have been nice to have an actual story.

All in all

I’ve taken part in three Ludum Dares before, but this was by far my most successful one: I made a game that most players found to be fun, which is a feat that I have never really achieved before. Next time around, I will hopefully interpret the theme a little more creatively, and I hope to address my biggest issue from LD27: insufficient planning of secondary game features. Still, I’m pretty happy with Ten Second Roguelike. Let me know what you think!

I made a quick and dirty userscript that displays a “Performance” graph on all user pages. For example, mine looks like this:

The script can be found here.

To install in Chrome, download the script, go to Tools | Extensions, and drag the downloaded script into the page. To install in Firefox, use Greasemonkey. To install in other browsers, do something else.

Let me know how it works for you guys.

Tags: browser, script, utility

For this Ludum Dare, I worked with a group of friends to create Asteroid Tycoon. I’ve done the Compo a few times in the past, but none of us had ever game jammed in a team before, and it was quite the experience. I’ve learned that doing Ludum Dare with a team brings with it both enormous benefits and unexpected challenges.

What went right

Diverse talent

Being able to work with an artist, a UI designer, a game designer, an amateur musician, etc (some people filled multiple of these roles) was an amazing experience compared to previous Ludum Dares. For the first time, I’ve submitted a game that actually looks and feels really solid.

Combining multiple ideas together

During our team brainstorming session, a few ideas became big hits: a candy-box-like about building an asteroid mining empire, something involving moles and tunneling, and a game with programmable robots. The idea for Asteroid Tycoon came about as we realized that we could combine elements from these three ideas into a coherent concept.

Constant balance tweaking

Gameplay elements underwent many changes as work on the game went on. For example, the robot upgrade progression initially was triggered by amount of minerals collected (a different mineral for each robot), but switching to a depth-based system proved to be a lot more enjoyable for the player. For much of the weekend (at least once we had something playable), at least one person (usually a team member taking a break) was playing the game at all times, so we constantly had feedback that we used to adjust parameters, and in many cases, rework entire mechanics.

Cute little touches

Little things like the marquee seem to have made a big difference in enjoyment and immersion. Also, some of our last-minute graphical tweaks, such as the beaming-down animation from the ship, improved the look of the game rather significantly.

What went wrong

Repetitive music

Once we had a short loop of music, we deemed that “good enough for now” and decided to come back to the music situation if we had time. Unfortunately, we didn’t have any more time to work on music, and the result was slightly disastrous, as the constantly repeating main loop proved to be annoying to many players. We quickly added a mute button, but the damage was already done. In the future, I’d hesitate to add music unless it was sufficiently varied to not be a hindrance.

Not enough organization

Never having worked with a team on Ludum Dare before meant that my default workflow was an informal, poorly defined task list and a single development branch in git. This is reasonable enough for one person, but proved to be a disaster when working with a team of 7 people. On several occasions, lack of communication led to two programmers separately implementing the exact same feature or our two artists stepping on each others’ toes. Meanwhile, all work being on a single branch meant that nearly every commit resulted in a merge conflict, which proved to be very time-consuming in the long run. In retrospect, we should have had a more well-defined task-assignment scheme and used feature branches.

Gameplay not explained clearly enough

The primary gameplay mechanic in Asteroid Tycoon works as follows: you first click on a robot to build and then click on a destination square for it to try to move to. However, we didn’t explain this very clearly within the game itself, which led to many players thinking that they had to click on the surface or on the spaceship — the result being that the robots reached their destination immediately and from then on proceeded to move in a way that would have appeared to be more or less random to the players.

To make matters worse, important information is conveyed to the player via printouts that regularly appear but go away on the next mouse-click. What we didn’t anticipate was that most players click around so quickly that they don’t even get a chance to see the printout before accidentally closing it (old printouts are still saved in the top-left panel, but most players never bothered to use it).

In retrospect, we should have done a better job of explaining exactly how gameplay works from the start, and come up with a different way to hide printouts (perhaps by giving them a Close button). These are both hopefully things that we will work on in the post-Jam version.

Only starting work after 18 hours

We made the conscious decision to not start work until noon (PST) Saturday, to give our brains plenty of time to process our different ideas. While this gave us lots of brainstorming time, it put us at a disadvantage time-wise compared to most Jam teams, and led to us being very pressed for time near the end (compounded by the fact that many of us had to go to work on Monday). In the future, I’d like to spend a little less time brainstorming and perhaps at least try to get a little bit of actual coding done Friday night.

All in all

After trying a Ludum Dare with a team for the first time, I don’t know if I can go back to doing the Compo! Not only were we able to build something bigger and more polished than any one of us could do on their own, but we had lots of fun working as a group. We’ll try to work together in future Ludum Dares.

As far as Asteroid Tycoon goes, we’re really happy with how it turned out. We’ll probably tweak it a little bit post-Jam — primarily to make the instructions more clear, make the music a little less repetitive, and fix some sneaky bugs that people have reported.

Tags: ld29, postmortem

If you’re stuck on a specific level or just want to see what Shattered Worlds is about, we’ve put together a trailer and playthrough video that will help:

Has your interest been piqued? Then check out Shattered Worlds, a puzzle platformer with a twist. All feedback is much appreciated.