mklee

LD14

My first Ludum Dare

This is my first Ludum Dare and I look forward to it!

For my tools, I’m keeping it simple:

  • Flash/Actionscript using FlashDevelop and the SDK
  • For art I’ll be using Photoshop
  • Audio will be done with sfxr and Audacity
  • I’m using a few libraries such as Casalib and the AS3DS to aid development unless these are not kosher

I’ll try keeping a live blog going from my own blog and hopefully after the 48 hours I’ll be back here with something cool for everyone.

Tags: flas, hello world, LD #14 - Advancing Wall of Doom - 2009

LD15

Falling further and further down the rabbit hole

So I’m pretty happy to finally post my first ever completed entry for Ludum Dare. Check out Into the Pit: The Endless Caverns here!

It’s a game heavily-inspired/influenced/ripped off from level 2 of Battletoads for the NES (which was one of the more sane levels in that game). You basically go around avoiding spikes/traps and killing bats with a simple dash attack. Like Battletoads you can juggle the bats for extra points and to regain health. The game goes on forever until you die. Right now there’s plenty of chance of that due to the lack of end stage balancing since I ran out of time near the end and wanted to get things like menus done.

This time around my goal was over the first 24 hours to come up with a fully-playable prototype and to spend the last 24 hours adding graphics, audio, and polish. Surprisingly enough that actually held true for the most part. I managed to come up with the basic game late last night and I spend most of today on things like finer gameplay details and working on sprites and sounds. You may notice my explorer sprite is a little too close to comfort to a certain famous indie game character. Forgive me for that, I really suck at pixel art and being derivative was the best I could do.

One thing I’m actually really pleased with is how at the very end (literally the last 2 hours) a more ominous feel entered into the game. On a whim I added in some rumbling sounds that I looped continuously on the menu screen. Combined with screen shaking I really dug the “collapsing cavern” atmosphere that was being generated so I ran with that. If I had a little more time I would have liked to have added touches like falling debris and other signs of collapse.

Regardless I hope people enjoy it. Have fun and feel free to criticize and comment.

Note: It was made using Flixel which I understand is perfectly fine for this competition. And I can safely say that without Flixel there’s no chance in hell I would have had anything completed.

LD16

Warning warning incoming Ludum Dare

COMPETITION APPROACHING

slippy
Take him down Fox!

peppy
Use your blasters!

falco
Don’t screw this one up Fox.

It’s too powerful! It’s like it’s… invunerable to all our attacks!

Hint hint hint.

Let’s not be hasty

No ideas = no problem. I got my newest version of Flixel, some cheap beer, and a whole lot of time this weekend to churn something out. This time I will be recording a timelapse thanks to Keeyai’s awesome Chronolapse. And I’ll try to keep people updated on progress.

So it’s good to go tonight. Let’s rock!

Comments

echeese
11. Dec 2009 · 20:30 UTC
Hey, you should practice with the new Flixel. They’ve changed a bunch of things from 1.25. No more FlxArray and they also changed some of the collision functions and how keys are accessed.

Something something untitled

desk1.small

So exploration it is. I have an idea for the game which is still yet untitled, but rest assured that starting bright and early tomorrow morning I will get cracking on it. Until then, here is my still relatively untarnished work space ready to go!

Breakfast and a game idea

desk2.small

While sleeping for the night I came up with a solid game idea that will definitely work in both theme and being limited enough to be created in a little over 36 hours. So now to make the damn thing. But not before a hearty breakfast fit for a champion. Eggos!

Talking about AD2030

So the game I’ve come up with for exploration is something I’m calling AD2030. It’s my way of thinking of an exploration game where a lot of the exploration in this instance is indirect. For better or for worse I haven’t had much visual progress as a lot of the game is done through non-visual communication. Additionally a lesson that worked well in the last Ludum Dare was I used placeholder graphics as long as possible so I could focus on getting gameplay in there.

ld_early_1

Meanwhile here’s what I had on my lunch break. It’s like I’m back living in my college dorm again!

dev_1

Revamping with less than 9 hours to go

After a breakfast of tea and waffles I’ve realized that completing the original scope of the game with the time left is going to be impossible. In lieu of my original planned game I’m taking a small part of that and remaking that into a complete whole. Far less ambitious, but more plausible to complete within 9 hours.

4 hours left ARGHHHHHH

ld2

Need to get the procedural level generation system working now. After that it’s about implementing the menus and game over state.

Going to be late to the party

title

Unfortunately my attempt at creating a procedurally-generated map for the game is going to require more than an hour to properly debug. The only consolation I have is I essentially started this game today after scrapping what I was working on for the 1st day.

In the short-term I’m definitely going to submit the early prototype I had of a level with a few baddies and limited exploring. Not great, but at least something to show at 9 PM!

Echolon

ld3

Hey, it’s a game! And I happened to decide to call it Echolon for no real good reason.

This game was made in around 8 hours today after ditching most of the work I did for another game yesterday. The theme of exploration was so broad I had a few ideas that are probably worth pursuing. What I originally was going with was a game focused on indirect control of a navigator that explores, but I ended up ditching that for something a little simpler.

Echolon plays a little like Asteroids where you’re exploring a really large room that that only gets illuminated when your bullets (made of light!) collide with walls. Shots have the ability to bounce off walls. There are enemy turrets scattered throughout the level that will shoot at you (natch). Destroy all the turrets to win!

Originally the game was going to be series of rooms and there was some vague idea of a limited upgrade system. Additionally I wanted other abilities and weapon types that would help illuminate the map in more meaningful ways. I didn’t have the time for that, but I sorta like the idea and may pursue that further.

Tools/engine used were Flixel, sfxr, Audacity, Photoshop, and FlashDevelop. I’ll have a timelapse video and a larger post-mortem up later.

Play the game here guys and gals. Thanks!

Just another post-mortem: Echolon

postmortem_title

Entry: Echolon (check it out here)
Timelapse: http://www.youtube.com/watch?v=U_toZ_YeZ6U

Summary:
Nothing is a more effective motivator than a hard dose of reality and time constraints. Also it’s way easier doing something you’re familiar with than trying something new in 48 hours.

What Happened:
Developing what eventually became Echolon was a tale of two games. Saturday was spent on one idea that failed to pan out and Sunday was spent primarily on what ended up being my final submitted game for Ludum Dare. This essentially means that I gave myself around 9 hours to go from near-scratch and create Echolon.

This was my 3rd attempted Ludum Dare and my second consecutive successful one (along with caverns from Ludum Dare 15). There were two points during the weekend I was unsure if I would finish, but some radical redesigning and acceptance of certain limitations allowed me to push until the end.

The initial game attempted to approach exploration in an indirect way. The basic idea was that you as the player never went exploring yourself. Instead you used a rover/robot that would explore in your stead. There would be little to no graphical component, most of the exploration would be conveyed in text reports and other feedback. As you explored the landscape outside you would find equipment to modify your rover and allow it to explore new areas, carry new items, and extend its capabilities in general.

I spent most of Saturday working on the background mechanics and trying to figure out the best way for the player to interact with the rover. The game ultimately started becoming heavily UI-dependent which was the worst thing possible. In my experience user interfaces tend to be time-consuming and tedious to craft and ultimately are the biggest time sinks in any project I’ve done. The trade-off between UI creation and time is pretty piss-poor.

The first game on the left and an early image of Echolon on the right

The first game on the left and an early image of Echolon on the right

This wasn’t help by overall poor time management on Saturday. Part of Saturday night was spent going to the movies with my family (Princess and the Frog) and doing other tasks unrelated to Ludum Dare (you know, the important stuff). So by the time I had crashed on late Saturday night/early Sunday morning I basically only had the fragments of a game in hand.

Waking up Sunday it quickly dawned on me that at my current rate the first game would never be complete on time. After this realization my mind quickly scrambled for a second idea that could be implemented in a short amount of time. I ended up thinking about a game where the player explores a cavern with no lighting except his own bullets. I added on the idea of illumination through shooting along with some basic reflection mechanics and I had a game idea to implement.

Afterward development was fast and furious in the final 9 hours of the competition. The basic game controls are pretty much Asteroids and Flixel pretty much allows that kind of gameplay to be implemented immediately. Things like shooting and reflection were also implemented with little to no problems and basic enemies quickly followed.

Echolon in its near-final state

Echolon in its near-final state

The biggest obstacle in that 9 hours was spent on creating a procedurally-generated level. I originally had planned a more ambitious generator that would construct various rooms of differing sizes that would be connected with hallways at various points essentially creating a large maze. Over time this became less and less feasible as I had a hell of a time figuring out how exactly to create “screens” that didn’t conflict with each other. I spent roughly an hour on this before abandoning it near the end for a much simpler solution. What I ended up implementing instead was one large room that had random blocks placed inside. There’s no real smart logic to the placement, but overall the result was passable for the purposes of the competition.

To demonstrate how much I was pushing time in this case level generation was complete with about 45 minutes left in the competition. The final 45 minutes I had to create a pretty terrible menu screen, victory/game over screen, add the final sound effects, finish up the UI, and make sure everything sorta worked. I pretty much finished with 2 minutes left before 9 PM.

The big question in my mind is if things had gone exactly right would I have been able to complete my original idea? Possibly if I had worked the full 48 hours, but even then I feel like nothing of the scope I had imagined would have been completed. The idea was a radical departure from any thing I’ve done before – attempting to create a limited simulation game with a heavy emphasis on stat manipulation and menus. When this failed to pan out my second idea relied on simple game mechanics I’ve done before and could easily mock in before focusing on newer ideas. I still really like the idea however and would like to return to it in the future.

Overall my feelings on Echolon are pretty muted. It’s not very fun nor very playable and it comes off slight (although for 9 hours I don’t know if I personally could have done better). I like some basic ideas, but having even an extra hour to tweak some of the gameplay variables would have been nice. I had some additional ideas I would like to implement and I wouldn’t bet against me returning to the game in the future.

What Went Right:

  • There was a game. After everything I managed to submit a final game. That by itself is a win in my book.
  • Accepting failure. After realizing the first game would never be completed on time I completely shifted gears to developing Echolon and never looked back.
  • Not rebuilding the wheel. Echolon was a game well-suited to the tools I was using and also similar to other games I’ve created. Getting to first playable took little time.
  • Rush rush rush. With 9 hours pretty much uninterrupted for coding I managed to get in the zone and almost never left it until the deadline.

What Went Wrong:

  • The first game. Oh god did that not work out.
  • No playtesting. Echolon as you may note is not balanced in any sense. Chalk that up to limited dev time.
  • Remaining overambitious the second time around. Things like trying to implement the full-fledged procedural level generator and an upgrade system was far beyond the possible scope of a 9-hour game.

What I Ate:
4 Eggos, a Jimmy Johns sub, some chips, popcorn, lots of tea, some lemonade, and a roast beef sandwich.

Finally:
Still an awesome experience. Plus I made a game! Score!

Tags: postmortem

LD17

Island Skate Delivery Boy submitted!

ld48

Island Skate Delivery Boy is (semi-)complete! A stunning achievement in realistic island skateboarding action, Island Skate Delivery Boy features no actual delivery mechanic whatsoever. Forged in darkness, completed in around 3 hours, and featuring islands, Island Skate Delivery Boy is guaranteed to at least provide 5 seconds of interaction.

You can view and play the game right now.

LD18

Back for more punishment

Oh Ludum Dare, just when I think I’m done you pull me back in.

Tools I’ll be using this time include:
* The Flashpunk engine courtesy of ChevyRay
* To help build maps I’ll be using Ogmo
* To add some sound to the project I’ll be using the dual tools of Sfxr and Audacity
* And FlashDevelop is the IDE

Good luck to everyone this time! And here’s hoping for a really awesome theme (that isn’t double rainbows).

Aiming for the jam!

Looks like I’ll be submitting my entry for the jam and not the competition this time.

But everyone can try out what I would have submitted to the competition! Jump to this link and play the prototype for Cannon Hack.

Comments

23. Aug 2010 · 00:23 UTC
That’s spectacular, I love it! I’m excited to see the final version, and I hope you really put some work into designing creative levels. Even as just a prototype, it has a really good feel to it.

Cannonon is done!

Although it’s not as finished or feature-complete as I would have liked (what is with Ludum Dare), here’s my jam entry Cannonon. A simple top-down 2D shooter where you hack weapons to take control of them. Includes 3 simple levels and two different types of weapons.

View the entry here or play it here.

LD19

Ready to do this thang

Declaring myself ready and willing for another awesome Ludum Dare.

Coding:
-Flash w/FlashDevelop IDE
-Main engine library is Flashpunk 1.5
-With an assist from Noel’s Advanced Platforming Engine

Art:
-Adobe Photoshop CS3
-Color palettes from Adobe Kuler

Sound:
-The immortal Sfxr by DrPetter
-Audacity for editing
-Sound effects from freesound.org
-Public domain songs from archive.org

Will be listening to:
-Anamanaguchi

Will be playing:
-Team Fortress 2

Let’s do it!

Edit: Since the question of public domain/sample materials has come up I should clarify I’m probably edging more towards the jam portion rather than the competition one. I will adjust accordingly depending on how I feel about the game near the end.

Comments

17. Dec 2010 · 17:12 UTC
Could anyone confirm whether public domain sound or music is allowed according to the competition?
sfernald
17. Dec 2010 · 17:19 UTC
No, you can’t use any assets not created during the competition. That includes public domain stuff or stuff you may have created previously.
mklee
17. Dec 2010 · 19:27 UTC
There’s some gray area with regards to things like using samples as long as they’re legally able to be used. Regardless I should have clarified in my post that I was planning on doing the jam portion rather than the stricter competition one. I have edited my post to reduce confusion.
7Soul
17. Dec 2010 · 17:48 UTC
Will be listening to:

-Anamanaguchi

Corpse Runner

Play it here or grab the source.

Corpse Runner, a (very) simple maze game is finished enough for the competition entry. Made today after scrapping my initial project, it’s just a maze game with a single twist. Your goal is to find the exit to your maze within the time limit. However your time limit very very short (just 15 seconds). Plus the maze is very dark and you can only see your immediate surroundings.

The twist is that at any point you “sacrifice” yourself for the next maze-goer. The next person will be able to “use” your corpse to extend his time limit and each corpse leaves behind a small amount of light.

I started this game this afternoon after scrapping my previous idea which had a neat mechanic that just wasn’t feasible within the time limit. The maze was going to be a bit more full-featured, with keys that needed to be found and multiple doors to unlock before escaping. However the game is so simple that adding any more tedious mechanics just made it even less fun.

I like the mechanic of dropping corpses and using them in future player runs even if the execution here is pretty limited. I might take some time and investigate it a little further in the future with a different game.

Anyway Ludum Dare as usual was stressful, frustrating, and yet simultaneously a blast as usual. Best of luck to everyone else and I look forward to seeing what gems other people have made.