Hey everybody,

I’ve never done this before and I’ve been so focused on putting my time into the game that I haven’t posted anything about it here.  Sure the competition is almost done, but I still have time for a little preview for you guys First a screenshot of what the basic game screen looks like at the start of a level:

"It is Dangerous to go Alone in the Dark"

Yup, that’s what it looks like.  Nope, you don’t play as a sentient ball of light.  I had a couple ideas to start with.  For a while, I was thinking of doing a sort of story-based game about going away by yourself to college or moving to a new city or whatever, but then I realized I wanted something with a little more gameplay.  The first thing that popped into my head was that exploring a dark cave by yourself was pretty dangerous.  I wanted to do something interesting with that though, so I decided that I should emphasize sound instead of visuals.  Therefore, the ‘this’ you take is a sonar monster detector.  The closer you are to an enemy, the faster it beeps.  Using this as well as a limited number of flares per level that you can place where you think enemies are, you must make your way through a series of caves with randomly placed, ever-increasing amounts of monsters.

Basically, think of it as minesweeper where you control an actual character instead of a mouse cursor, and where sound is your primary form of information on where the ‘mines’ are.

At this point, all the gameplay stuff is done.  I suppose I should give it another test runthrough or two, but we’ll see if I have time.  At this point, I’m just working on polish and adding assets.  More animations, sound, music, and plot-type-stuff.

This has certainly been an eye opening experience (I guess that’s kind of a pun, you’ll see what I mean when you play) and I’ve learned a lot from it.  It will also be the first game I’ve actually fully finished and released to the public, so that’s awesome!  Anyway, I hope you guys like it/at least think the idea is interesting.  Sorry for not posting more as I went about the process!

-Tim ‘fueelin’ Beck

Everything’s finished and my game is submitted!  I got just about everything done and in there that I wanted to.  There were a few sound effects I didn’t have time to make, and I didn’t have time to make barely any music (funny that in a sound-driven game, those are the two things I didn’t quite get to).  I’m happy with the gameplay and the visuals.  Maybe it’s just because I made it, but my (technically very bad) art makes me very happy

Overall I’d say this was a big success.  For the first time ever, I assigned myself a reasonable scope for a project, and not-so-coincidentally, I actually finished said project.  I hope everyone enjoys my game, let me know if you have any suggestions or if any bugs pop up.  I’d like to do some more work on the game eventually to make it a bit more polished/bigger and give it some more audio.  I also plan to clean up my code a ton, it’s very sloppy as I was in a hurry.  Any and all feedback is appreciated, thanks guys and I hope everyone feels good about their projects too!

After a few days to reflect on my game and get comments from people, here’s a brief post-mortem:

Overall, responses have been positive.  Between the comments here and from friends, the general consensus is that my game is based on a cool idea, but that there’s not enough gameplay there.  It’s too simple/easy.  Also, people have often said that the sonar sound gets annoying over time.  I definitely agree with these opinions (and sometimes hear that sound effect as I fall asleep).  These are certainly issues that can be fixed though, and I plan to update the game in the coming days/weeks to get it up to a state where I feel comfortable giving it a wider release.  On to the specifics:

What Went Right:

Brainstorming/Planning – It didn’t take me long to come up with a few ideas that used the theme, and I’m definitely happy with the one I ultimately chose.  My initial planning of the game- the general design, what pieces of code I needed to write, and what content I had to make– also went well.  Having a design that didn’t require many changes certainly helped with working in such a time frame.  I was able to budget my time a lot better because of this.

Coding the Big Pieces – Though not perfect, I got the core pieces of the game working in good time.  The level generation, sonar, and control code didn’t take too long to get working on a basic level.  Debugging and getting things working just how I wanted took a bit longer though.

Asset Creation Process – Although I didn’t get as much sound in the game as I wanted (I’ll get to that in a minute), the creation of the art and sound that did make it into the game went a lot smoother and quicker than I expected.  Obviously I’m no great artist, but I’m happy with the way everything looks, particularly the monsters death animations, and none of it took me very long.  I made the music and sound effects in the last hour of the competition, and that too was quicker-going than I expected.

What Went Wrong:

Not Enough Playtesting – Definitely the biggest problem.  I was so concerned with getting all the basic functionality and assets done that I didn’t take much time to actually play the game.  If I did, I would have realized that it’s a bit simplistic, as well as exploitable.  Next time, I will certainly leave more time for playtesting, as well as getting opinions from friends during the process, not exclusively after I’m done.

Not Enough Sounds/Music – My game ended up with one very short piece of music and two sound effects.  Not at all enough for a game based on sound.  I think prioritizing other aspects of the game was the right decision, but I wish I fit in more time for sound, especially figuring out how to make the sonar less annoying over an extended session.

Key Bugs – There were a few issues that took way too long to resolve.  For example, being a bit lazy with determining how fast the sonar should beep led to at least an hour of debugging caused by a shortcut that would only have saved me five minutes.  Though I can’t think of specific examples, there were definitely a number of other bugs that really slowed down development for long periods of time.

What I Learned:

That I can release a game!

That I can make a game with a small scope that is still interesting, and that I should do so more often.

Even though I already knew the importance of playtesting and rely on it heavily in my larger project, I learned that even on a small project it is one of the most important aspects of game development.  Especially when working in such a tight time frame, I get to know my game so well that I can’t make any objective judgements about it or consider alternate solutions.  Therefore, I need a nice dose of outside perspective.

That about wraps it up.  If you haven’t played my game yet, give it a try and rate it.  If you have, keep an eye out for updates to fix some of the issues I talked about here, as well as those which I didn’t address but that are mentioned in the comments.  I put the first (small) one out about an hour ago.  And of course, I can always use more feedback!

-Tim ‘Fueelin’ Beck

Hey guys – off to a late start but I’m in!  Had a long drive home last night so I waited til 9 to leave so I could think about the theme all the way home, and I think I came up with a cool idea.  Very excited to implement it; I definitely think it’s possible to end up with a much more finished product than my last two entries, but we’ll see.

I haven’t decided on a name yet, but I’m making an arcade-style puzzle game that takes place in the human body.  You have to coordinate your immune system’s defenses against ever-increasing waves of pathogens.  I’m going to attempt to make it as factual as possible, but gameplay will win out between the two if it comes down to that.  My goal is to get all the gameplay implemented today so I can focus on balancing, polish, and music tomorrow.  This should be much better than my previous strategy of rolling my face on the keyboard until a game comes out.  It’ll be nice to (hopefully) have real music for my game for once!

I’ll keep everyone updated!  I’m also going to try to get more external playtests during the competition this time, so I might post again looking for any interested people in a few hours.

Thanks!

This was my fourth time doing Ludum Dare, and I’ve written a brief postmortem about how it went.  Hope people enjoy the game.

Things that went right:

Theme:

Although I didn’t like the theme at first, it ended up working really well with my skill set.  I’m pretty bad at making art, and the theme required minimal art assets.  The final game ended up with only two sprites.  I’m considerably more confident with music, but the design I came up with for the theme also required minimal art assets.  One .wav file with a single note produces the whole soundtrack, with the player’s help.  The creativity this allows the player is one of the most important aspects of the game.

Lots of programming/design time:

With little need for art/sound assets, I figured I’d end up with a surplus of time for level design.  This was the main reason I decided to do a game with static levels in the first place; I wouldn’t have had the time for that if I were making more sprites/music.  This didn’t quite end up being the case, as programming took longer than I expected.  Still, this was a positive overall.  It let me fix most bugs and increased overall polish.

Quickly implementing key features:

Though I spent the majority of the competition programming, most of the ‘big stuff’ went pretty quickly.  The launchers, saving/loading levels, and the sound logic went smoothly thanks to past experience with XNA.  As noted below, physics bugs (and a couple editor problems) were the only real time-consuming issues.

Overlaps in gameplay/design:

When making a game on such a short timeframe, it’s important to get as much ‘bang for your buck’ with your time.  That’s one of the things I like about music games like this; the audio, game design, and programming are all tightly linked.  I didn’t have to spend a bunch of time making music tracks, because that was what level design was.  I could iterate on all three at the same time.

The same thing applies to Free Play mode.  I made a simple editor for myself, which was trivial to expose to the player.  This lets the player make his own puzzles/music freely, and it didn’t cost me much time to add.

Things that went wrong:

Physics bugs:

As many commenters have noted, there are some noticeable physics bugs in the game; the worst being balls getting stuck in platforms.  These bugs are extra annoying in my game because they can end up producing notes extremely frequently, producing really harsh sound.  I spent a significant amount of time during the competition trying to fix these bugs and lessen the annoyance when they do occur.  This did help in the end, but it was pretty demoralizing focusing on the issue so much and not fully fixing it.

‘Wasted’ time:

I spent more time not working on the game over the weekend than I planned going into it.  A surprise visit from a friend from out of town took up a few hours.  It was worth it, but there would have been many more levels if that didn’t happen.

Distribution:

Although the problem has been fixed, my initial release had a couple issues.  I didn’t include the XNA Redistributable so the game crashed for some, and others were unhappy that it required an install.  I’ve had similar issues in the past, but at least I did a better job fixing them this time.

Hardware issues:

One of my monitors failed comically early in the competition.  I spent some time trying to fix it, couldn’t, and was left with a sub-optimal setup.   Not a huge deal, but I’m sure it had some effect on my productivity.

Summary:

I’m really happy with the result of this Ludum Dare.  It’s a much stronger game than my previous attempts.  There are a few things I could have done differently that would have led to a better product, but those are just further learning experiences.  I’ve definitely improved my craft and look forward to LD27!

Merry Christmas, all!

My gift to you is an updated version of my game, Beat Jumper.  If you haven’t tried it yet, please do!  It’s a fast-paced 2d platformer where platforms come at you in time with the music.  Every note and drum hit in the song has a matching platform in the game.  Your job is to land on these in time with the beat (without falling off), building your score as you go.

If you have played my game, there are a number of bug fixes and enhancements included in the new version.  Some of these were things noted by you in the comments, and some were from issues I observed.  I plan to work on the game more – there’s still a ton to do – but these updates make for a big improvement!

Change List:

-Slow the song/platforms down in easy mode.

-Overhaul to the ‘staying on the beat’ system. You’re now trying to keep the bar full, instead of empty. This makes it harder to lose immediately and does not allow you to make an impenetrable buffer of extra points, as you could before.

-Can no longer wall jump after sliding up/down off the side of a platform.

-Force platforms to stay within visual bounds of game (highest notes didn’t have platforms).

-Fixed bug preventing some notes from having corresponding platforms.

-Fixed platform sizing error on easy mode.

Link