BOMBCRASH (LD18)
POST-MORTEM 

A GAMESTOP KONGREGATE EXCLUSIVE GAME
BY XANDER DAVIS
 
FOR THE LUDUM DARE #18:
48-HOUR COMPETITION
AUGUST 2010

WWW.XANDERDAVIS.COM
 
A GAMESTOP KONGREGATE EXCLUSIVE:
http://www.kongregate.com/games/XanderDavis/bombcrash-ludum-dare-18 
 
SUMMARY: 
Bombcrash, a game produced by myself from scratch in 48 hours for Ludum Dare 18, is examined after launching as a GameStop Kongregate exclusive.
 

 
 
GAMESTOP KONGREGATE RATING: 3/5 STARS - 2,200+ PLAYS
LUDUM DARE COMPETITION RATING: Unknown (TBD Monday, Sept 6th, 2010)

OVERALL POSITIVE: Difficult, but rewarding.  Cute art.  Polished.  Impressive AI.  Too short; want more!
OVERALL NEGATIVE: Hit boxes for enemies are too large.  Steep difficulty and some levels seemed impossible.  Couldn’t lure enemies as effectively as conceptually should.  Enemies would just kill themselves anyway, encouraged hiding and waiting.

VIDEO WALKTHROUGH: http://www.youtube.com/watch?v=kfUXXOJAtGY

INTRODUCTION

I heard about Ludum Dare before, the global competition to build a game from scratch on your own within 48-hours, and was caught off guard on Friday, August 20th, 2010, when I saw that Ludum Dare #18 was about to start in a handful of hours.  I became intrigued.

The prospect of trying this was intimidating.  It was not only a proving ground to the public, but also to myself.  I didn’t just want to make a part of an incomplete game or a completely broken game.  It was important to me to build a whole product in two days and launch it to the world.

I raced down the street to the nearby grocery and picked up a case of Red Bull.  By the time I got back, the theme was announced and the 48-hour competition clock had officially begun: “Enemies as Weapons”.  I opened my first Red Bull, sat down and stared at a blank Game Design Document, stared at the clock and felt the pressure ticking on.

48-hours later, I did exactly what I set out to do.  I launched my game “Bombcrash” and watched the play count go over a thousand in the first few days, the star voting tally up, and the comments of feedback (mostly positive) trickle in through Kongregate, Twitter and Facebook.  It was a great learning experience for concepting, building, and launching a game product under extreme conditions and for more robust projects to come.

WHAT WENT RIGHT

1. FORCED PRODUCTION TIMELINE

Having just 48-hours, I was forced to make decisions with the game design to help ensure I’d come out of this with essentially a completed product.  It turns out, the strict, severely limited timeline was the best factor!

The common saying, “Games are never done, they’re shipped”, is certainly key here.  Being a perfectionist on my indie game projects with no time limits usually resulted in the former part of that saying than the latter.  With Ludum Dare’s 48-hour limit, the latter was the entire point, so it had to happen.  It was the game’s one priority that superseded all other priorities.

2. FLASH & FLIXEL CHOSEN

Thanks to Flash, Bombcrash was among the most widely accessible games in Ludum Dare 18, because players didn’t have to download and install anything to play it and it worked on all platforms (except iOS).  This likely gave it a considerable lead over many games that required installing plug-ins or more-commonly Windows EXEs.  The ‘build-once, deploy-everywhere’ mantra was never more apt for this competition and Flash made it possible.

The Flixel framework tremendously expedited the engine building process, allowing me to instantaneously begin focusing all programming efforts solely on game design instead of rudimentary engine requirements like time-step or collision.

An understanding of ActionScript 3.0, object-oriented programming, and a code-only development environment was required to use Flixel.  While it was by no means a plug-n-go system, as I had to spend considerable time before learning how it worked, I definitely found myself rapidly accomplishing objectives with it.

3. GAMEPLAY FIRST, STORY LAST

Required to follow Ludum Dare’s event theme, “Enemies as Weapons”, I was forced to think first about gameplay and map a story / intellectual property to it later.  Usually, I conceive of gameplay and story often simultaneously, as I believe they both should inform the other.  This time, I literally didn’t even have a name for the game until the last forty-five minutes of the competition.

I had to prototype the game quickly with basic squares to make sure I could even first pull off the concept under programming ability alone.  After I had built a complete start-to-finish playable prototype in eleven and a half straight hours, I got three hours of sleep, and went back at it, mapping on the art, sound effects, and expanded level design.  I was drafting up story and world-building ideas, as that would determine the art, but found this to be the vaguest part.  Ironic, because I’m used to focusing a lot on story, since that’s a large reason why I play games in general.

I had grander ideas for the IP in mind, one involving a genre-blend of science-fiction and fantasy, aliens and ghosts, crystals and hacking.  But as the clocked ticked down, I ultimately refocused the IP around general sci-fi, exploding robots and an unarmed robot-engineer-everyman to stop them.  This also seemed the most conceptually obvious in the context of gameplay: hack the terminals to hack the robots, instead of hack the crystals to hack the alien ghosts.  I was going for something more unique, but the more generic sci-fi premise ultimately proved the most accessible and least risky under the tight timeframe.

4. DIFFICULT, BUT REWARDING

Some feedback had mentioned the game was difficult, but also rewarding.  The game was intentionally designed to be somewhat difficult, forcing the limited features to be more direct obstacles and extending the longevity of each of the few levels I had time to make.  I didn’t limit the number of lives or chances you had to win each level, either, to balance this challenge and keep the player always in the action.

Striking a balance between a hardcore and snacking casual experience was crucial to me.  I tried to design it as a fast-paced challenge of quick dexterity that you can jump-in / jump-out of playing.  Those are the kinds of games I enjoy (there aren’t many of them), as I find myself busier and busier.

The first two levels are tutorial levels, visually teaching the player how to win without any text, as I loathe the all-too-common instructions screen in many Flash games or written tutorials for any kind of game, even console ones.

The third level is intended to ramp up the difficulty quite a bit from the tutorials, so that there’s a real level of challenge and even panic in the player, getting that adrenaline going.  The fourth level is perhaps the most difficult, because it is the tightest of them all.

The last level was the largest and also the most open, but filled with several dozens of exploding robots, a surprise meant to panic the player in a spike of excitement.  However, due to its openness, this final level is also not as difficult as it appears, enabling the player to more easily win the game after such an adrenaline boost.  Hopefully this created a sense of great reward.

The ending is a simple screen that proclaims the player had won, and then returns the player to the menu.  I finished this screen in the final minutes of the competition.  It’s not a very good payoff, but it seems players responded more to overcoming the challenge of the levels.  The experience of just playing and winning seemed to feel like the reward by itself.

5. JUST GOING FOR IT, NOT WORRYING ABOUT IT

Fear is the mind killer.  I ultimately told myself to just go for it.  I had to tell myself not to back out of the competition, not to just go for the non-competitive and longer Jam, not to be afraid to reveal my source code.  I had to tell myself to just do it, to enter the competition with however my completed game turned out.

I had to make myself put my trust in my skills and decided to just accept whatever the outcome from there.  It’s amazing how powerful self-doubt or fear of failure can torpedo an otherwise straightforward pursuit, one in the end that turned out to be achievable.  It seems having the ability to overcome these inhibitions is just as critical as having abilities in programming and art.

6. RATED 3/5 STARS FOR 48 HOURS’ WORK

The feedback seemed to judge Bombcrash as if held to just as professional a standard as Flash games from, say, EA2D (whose Dragon Age Journeys on Kongregate got 4/5 stars and millions of plays).

Many games on Kongregate outside of the competition, with more than two days of development, did not even get 3 stars.  Judging from the Kongregate catalog, it seemed only the huge hits with fifty thousand plays or more (usually half a million or more) were the games that mostly ranked 4/5.  Virtually no game received 5/5.

While there are a few very valid criticisms over this version of Bombcrash, I feel they are placed in the context of any other game on Kongregate, so I’m pretty satisfied with the result then over two days of work.

WHAT WENT WRONG

1. ENEMY HIT-BOXES

From the feedback, the top complaint was that the hit-boxes for the enemies seemed too large when instantly triggering death upon touch.  The hit-boxes were actually correctly sized to the enemy, smaller than the sprite dimensions actually, and dodging the enemies simply required the utmost dexterity.  However, the perception of the experience clearly mattered more, so they were still not right after all.  A smaller area of collision for triggering detonation was called for here.

2. ENEMIES CAN ALWAYS KILL ENEMIES

While I found that to be pretty cool that explosions were happening nearly all the time (even if off screen) and that the player was navigating a randomly moving minefield, many players mentioned how the gameplay wasn’t as good as it could’ve been to them with this effect.

Something better maybe would’ve been arming the explosive property of the bomb-bots when the player reached a certain proximity.  At that point, the bomb in the bot would go live, and then the bot could kill the player and other bots.  That would’ve also encouraged the gameplay act of luring bots to crash into each other more, instead of just counting on that happening with or without the player’s encouragement.

I probably would’ve developed the AI even more if I was working on this longer anyway, so this definitely re-affirms that I should for an expanded edition.

3. NON-COLOR CODED TERMINALS

Some players commented that they didn’t know which terminal corresponded to which class of bot.  Other players didn’t even make the connection that the terminals were changing the enemies upon hacking.  It was always my intention to color-code the terminals to match their associated bot, but I ran out of time.  That would have likely more directly cemented the concept in the player’s understanding.

4. NO MUSIC

Even with the game’s other valid flaws, a catchy song that really got the player going could have boosted the player’s enjoyment.  Every time I play Super Mario Bros, Mega Man 2 or Zelda: A Link to the Past, I’m energized by the music, enhancing my gameplay experience.  Console games today tend to use more cinematic music, while retro games used much more melodic and catchy tunes to directly hit on a tone of excitement.

With Bombcrash, a retro-style game, music could have made up for some areas where the game fell short and possibly even made the difference with a higher rating.  People might have voted from a more emotionally energized place.

5. LIMITED FEATURES

There could always be more features.  A few players asked for a flatter learning curve to the levels (which means more levels) and more power-ups, abilities, and enemies.  Many people have commented that they liked the art, but I’d also considered even having HD sprites, while maintaining the same cartoony feel.  Some feedback also mentioned adding gibs to exploding robots and the player character, something I tried but could not get working in time.  It wanted to add these things and planned on including them in a potential expanded version.

6. ONLY 48 HOURS, NO SCRUM

While the tight timeline was a great challenge that really pushed me to do whatever needed to complete the game in two days, it was simultaneously the biggest hindrance to Bombcrash’s full potential as a fully executed game design.

However, given that the time limit was not a condition that could’ve changed, utilizing scrum would have also helped give me a better overview of what needed to get accomplished.  That way, I might not have ended up rushing things in the last minutes.  I basically just dove in head first and moved forward as fast as I could.

More time could have obviously been enormously beneficial for a more polished game.   I received feedback that an expanded version or a sequel was wanted.  With the bulk of Bombcrash’s foundation already accomplished, the prospect of doing a new edition of Bombcrash (an official release edition, instead of the Ludum Dare edition) is very appealing.

7. DARE BEHIND-THE-SCENES

This was my first Ludum Dare, and I witnessed some really cool documentary-style behind-the-scenes stuff other developers added, namely time-lapse videos of screen-capture and working at their desks.  That would’ve been great for Bombcrash, even just as a great memento.

Timelapse videos actually made their way onto Kotaku and many other gaming blogs and news sources.  See all Ludum Dare 18 press coverage.

It was ironic that people would spend even one second working on these bonus materials while racing to build their game, but after seeing the press benefit, it totally made sense.  Going forward, I definitely wanted to generate more media and make more of an “event” out it for any next jam I participated in.  That would’ve been great material to engage my social networks with and promote the resulting game.


######

FOR MORE UPDATES & INFO, VISIT:

WWW.XANDERDAVIS.COM

Xander Davis is a creative media artist, now the Senior Game Designer, Writer and Senior User Interface Designer at Xaviant for an upcoming FPS fantasy action console game with CryENGINE 3.

Xander recently completed UI Artist work on Transformers: War for Cybertron at High Moon Studios (Activision) for Xbox 360, PlayStation 3, and PC, rated 9.0 "Outstanding" by IGN.