Play the game here.

I really hated the theme at first. Well, maybe not hate, but I had no idea’s on what to do. I started working on my “Parallel Worlds” idea instead, but I wasn’t very motivated since I knew it had little to do with the theme. After working on that for about 5 hours, I finally got the idea for this game. Thankfully most of the code and stuff I made could still be used for this new idea, so I didn’t waste that much time.

The development process went smoothly without much trouble. Creating levels took longer than expected because of the slight “puzzle” elements of each room’s unique rule.

The “hard” mode in the final game was originally the standard, and only difficulty. I thought some people might find it too hard, so I changed it to hard mode and added “normal”. (Which was also apparently too hard for some people)

Graphics turned out okay, although I wish I had time to make some more tiles and add some variety to the visuals. I like how the player sprite turned out. (So cute <3)

Overall, I’m happy with how it turned out and I will continue to work on the game.

I just uploaded the commentated timelapse for my game, Potato The Destroyer! Featuring really cool music and co-commentary by my pals Dana Gallant (creator of Terrible Magical Artist) and Justin Espedal.

Watch the Timelapse on Youtube

MUSIC USED

• “Lune” by Chris Malson
• “Megaroide” and “Death of Phamson E Chord” by Wareya
• “Hard Rain” from Mother 3
• “Nausea” by Arrow
• “You’ve Come Far, Ness” from Earthbound

A timelapse video of this weekend’s live stream is now up. Please check it out.

And, if you haven’t rated ASCII 219, what’cha waiting for?

ASCII 219 by richtx | Ludum Dare 26 | Ludum Dare

http://www.youtube.com/watch?v=9AwNQFeHhq0

Here is a behind the scenes video of the making of my LD26 game: Buggers!

You can play/rate the game HERE

Click here to PLAY and RATE MBlok

At the beginning of the project I set myself a goal, like I did in the three Ludum Dares I have participated in prior.  In my first, my goal was to finish.  I was disappointed with what I made, as I focused so hard on finishing my game, that I stripped away polish and ended up with something that wasn’t very fun.  In my second, my goal was to make something simple.  I ended up with Stargazer and was very happy with the result.  In my third, my goal was to do something I hadn’t done before.  I chose perlin noise generation, and randomly generated my terrain for A Villain is YOU!  Again, I was rather happy with the result.

This time, my goal was to make my game polished and fun above all else.

I chose HaxePunk for my platform of choice, as I wanted to be able to easily compile for multiple platforms.  I would have gone with Stencyl, as I had for two of my previous entries, however the longer I use Stencyl, the more I feel limited by it.  It is a wonderful platform, but it lacks meaningful class structure, and the interface makes it slow for me to develop in.

That said, I love the concept of haXe, and the syntax is familiar, and so I chose HaxePunk over Haxe Flixel.  Why?  It’s quite simple really.  Haxe Flixel’s API listing page is broken, and HaxePunk’s isn’t.

That said, I had a few moments of frustration with HaxePunk early on, but overall I quite like the library and would work with it more in the future.

So, let’s tackle this whole scenario in chronological order.

First, the theme.  Minimalism.  I wasn’t too hyped about it, but it wasn’t Alternate Physics, so I was happy ( though in retrospect I could have made the exact same game and it would have fit for Alternate Physics as well ).    I brainstormed for about an hour and settled on two ideas.  First, a one button game where you played a planet at the center of a radar system, and you hit the button at the right timings to fire on enemies that are revealed by the rotating radar blip.  Second, a game where you click to remove blocks, and gravity changes to rearrange the mess of blocks into new and interesting patterns.

I chose the second, as it seemed like much more fun to make.

Originally, the goal of the game was to reduce the blocks from multiple colors, to a single color.  I also wanted to make blocks fall down off the screen when they were no longer supported.  This never made it past the planning phase, however, as I couldn’t come up with a good ( read: clear ) set of rules for when a block would fall.  So development continued, assuming that the block had a bottom, and everything fell according to the gravity.

I then encountered my first frustration with HaxePunk: there is no true camera.

I originally wanted to rotate the block when gravity switched.  The stage would have been magically dynamic and interesting to look at.  Rather than rotating every single block and their positions around the center of the screen, I had planned on simply rotating the camera 90 degrees.  Unfortunately, the camera I found in the API was just a reference point for where it should be, and I could find no way to apply a rotation to it.  There were mentions of rotations elsewhere in the API, however there were no resources or examples showing their usage, and my tinkering with angle properties amounted to nothing.

If there was a proper camera, I could not find it.

Instead, I worked around this restriction, and came up with the square stars in the background.  They fall like a normal field of stars, with their speed proportional to their size so as to add depth, and they fall according to whichever direction gravity is currently set to.  I’m rather happy with this workaround, as it retained a measure of the dynamic feeling I wanted for the gravity, and was also incredibly simple, much like rotating a camera should be.

Around the 4:30pm-5:00pm on Saturday, my game was shaping up and graphically pretty, and I was working on adding actual levels.  However at this point in time, I had changed the goal from one color only ( which was far too easy ) to one BLOCK only.  Gravity was moving automatically at set intervals.  I wasn’t happy though, as the game didn’t feel fun.  It was a mechanic with nothing to drive it.  There was no challenge, very little thought, and the level design was unclear.

So I whiteboarded for a couple minutes.  My train of thought went something like this:  Minimalism as a mechanic.  Reducing the complex to the simple.  Combos are good, gravity is good, the block is dynamic, the mechanic is simple.  What makes it challenging, what makes it a puzzle?  What if I let the player control the gravity?  Could work, adding control can add strategy.  One block is pointless, one color is pointless, the former is too easy, the latter has no pitfalls or strategic feeling…  What about no blocks?  Easy to do…oh.  OH.  As few moves as possible!  Maybe as little time too!  Minimalism isn’t the mechanic, it’s the strategy!

I had it.  I knew it would be fun, and all I had to do was make good levels.

I added level select, a good level config system, five levels that I sorta threw together and calculated pars for based on running through them a couple times myself.  I have terrible problem with making games too hard, so I raised the pars a little, and almost doubled the time limits.  I probably shouldn’t have, as it resulted in the game lacking in challenge.

I’m also terrible at making puzzle levels quickly, and having them be fun.

Around midnight, I had five levels, a level select screen, and a results screen, and it all flowed well.  So I decided I deserved to sleep more than four hours, and took a good long break.

Woke up Sunday at noon, and started on the title screen and music.  I’m terrible at music, but it seems to have come out decent at least.

Then I ran into my second issue.  In cpp targets, I can only have one mp3 play at a time.  I had originally planned on only using mp3′s for sound, so I wouldn’t have to conditionally compile my sound code.  I had to use OGG files for cpp targets, which to be fair are far better, but it was a tad bit annoying.  Sound also doesn’t loop, and seems to cut out on Windows.  I’ll deal with it later though.

Then I had a fun little nightmare trying to build for windows, when my haxe install broke apart.  But in the end it worked more or less.

So, I finished and submitted my game, and I’m rather happy with the result.  For the third time, I feel like I’ve accomplished my goal.  My game is fun, if easy, and polished.

Lastly, I looked into itch.io, which is essentially bandcamp but for indie games.  I think it’s pretty awesome and I’m going to keep using it in the future to distribute games.  I’ll be posting updates to it, and possibly updating this blog when my post-compo version is done.

Oh, and I also did a timelapse for the first time.

I had a great time with this project, and look forward to LD27 in August.

Here’s my screencap timelapse movie for my game ‘m’:

It’s not as interesting as my previous ones due to the lack of graphics in my game. Watching the timelapse of the graphic creation is usually my favorite part.

Play ‘m’ and let me know what you think.

Here’s the last 48 hours compressed into 4 minutes.

Click here to play Maximalism!

The timelapse for Linewalker has been uploaded. Enjoy.

Here’s the game page:

http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=20494

The Good:

• My first Ludum Dare, and I finished a game!
• Version control saved my bacon a couple of times.
• Got a working prototype, and feedback from friends, very quickly.
• Made a timelapse of the design process.  Showed me where I spent too much (or too little) development time.
• The theme: it really enforced the idea of making a simple, solid game.
• Bfxr is the bee’s knees!

The Bad:

• “Developer Perspective” — I thought the game was too easy.  So far the reviewers think its too hard.
• I didn’t really have a plan for the music coming into the compo.  So I had to pick a program and learn it on the fly.

The Ugly:

• The code is rather… inelegant.  I put the source files up, but I hope people will take them with a grain of salt.
• I wanted the colors to be vivid, but I think I erred on the too bright, possibly garish, side.

Still, I had a lot of fun, and I learned quite a bit.  It’s amazing how motivating a deadline can be!

Happy Ludum,
Cahman

MinGW forces me to quit. Can’t bugfix the compiler in a weekend (or even in a year). Will try newest version and hope it works. Otherwise I’ll be out.

EDIT: I’m out. Allready had the newest MinGW installed (and downloaded the installer for the 3rd time). Might submit hello world to be able to rate. Will ask before. Timelapse video will follow.

EDIT2: Timelapse

Here’s the game: http://smilingrob.com/ld26/

And the competition link: http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=20689

The Good

* The biggest thing I learned was that it’s ok to sleep, eat well (no red-bull or candy), and do some normal things during the 48 hours.

* I think the audio came out good.  And the song I made was surprising because it was the first thing I played on the keyboard.  When I dropped it into the game the mood changed and made it seem like an art experiment more than a game.  So I was really pleased with that.

* The arrow puzzle controls are really satisfying.  Jumping is frustrating sometimes.  And typing letters would be better if I had time to highlight the individual letters.

* Analytics are built in, I’m tracking how far people get, and their score when they win.

* I finished something, and put it on my website.

The Bad:

* Another major thing I learned was the value spending time on just designing something on paper.  I was really stuck for an idea after the theme was announced, and I just ended up choosing a lame mechanic because I didn’t have time to think of some good one.  If I do this again, I’ll try to think of a cool mechanic first and then apply the theme to that mechanic.

* I’m disappointed that I didn’t spend an hour modeling some quick things to drop on the path besides blocks.   I wanted to have junk flying by to make things seem faster, and have stars moving over your head.  But I got stuck on a few bugs and ended up only having time to make it work.

* Aaron and Alex’s role aren’t really visualized as well as I wanted.  I set the audio to pan Aaron on the left and Alex on the right.  Good guys classically come in from the left.  Alex’s voice was much louder in my mic, so I had to boost Aaron’s character and I boosted him a bit too high.

* The capsule looks lame and beginner to anyone that’s used Unity.  I can model much better things in 3D, but I ended up just modeling some cubes.  So much for practicing UV mapping in Blender last week.

They say your prize is your game.  And I’m very happy to have made something to put in my portfolio.  Even if it’s not great, it’s way better than an empty portfolio and the excuse that most of my work is backend, behind a firewall, and an NDA.

LD26 – Simple Towers timelapse

Why aren’t you playing it already??

Barely a day after submission and already I have a lot of great feedback! Thanks to everyone and keep playing! Here’s second part of the timelapse to celebrate.

I think I’ll continue developing this a bit further before writing even a premature post-mortem. There’s lots of stuff I’d like to implement before I’m willing to declare this project deceased.

A sigh of relief! I’ve completed my title “Dungeoneer” and created a timelapse video to boot. Beware spoilers if you are going to watch it before playing!

Play it now.

Check out the description over on the entry page and leave some comments.

Time-lapse video.

So, I set this video to upload yesterday, and today I wake up to see that it’s finished.

Day one timelapse

Now for the second day, and my second breakfast for this weekend.

Oh no!

Surprisingly enough I have something that approaches core gameplay when first day is done. I wasn’t so certain about it 6 hours ago.
(more…)

Testing out my screencap workflow for LD26, using ChronoLapse, I discovered AE doesn’t understand they are a video because they are not named sequentially.

So I wrote this: https://github.com/robert-wallis/fix-chronolapse-filenames and made this video of writing it:

To use the script, just drop the py file in your ChornoLapse save folder.  And double click it (if you have Python installed).

I finally got around to posting my Ludum Dare 25 time-lapse, accompanied with some idle musings and some epic open (GPL3) music

Check it out!

http://youtu.be/90V72BQvPOo

(more…)

Voting is over, Results are out, and it is time for some introspection. LD25 was a really, really good LD for me, so take a sit and let me tell you all about it… whether you want it or not! Mwahah!

Play Namcap!

Results

After two pretty terrible LDs I knew, when I put the keyboard down, that this time it had been different. I had a pretty decent idea from the get go. And even if I had troubles with parts of the execution, I was able to sneak in a lot more polish than in previous LDs. But I’m getting ahead of myself. Here are the scores (LD22 positions are multiplied from 891 to 1400 entries).

I’m pretty happy about theme. This high score means that I was able to pass the image of my game to the players. There were quite a few “reverse-x” games in this LD — but the thing about reverse-games is that, for you to feel like the villain of the original game, the reverse game must be as close to the original as possible. This was one of my design guidelines – score, gameplay, graphics, whenever I was able, I tried to mimic the original Pacman.

Graphics and Audio are as expected. Not super high, but higher than my previous entries. I feel more confident with my toolchain, and I’m happy with the result. It is worth noting that although Audio was my lowest score, it was not my lowest placement. This shows how audio making is one of the largest barriers in this competition.

I was expecting Fun to be a bit lower, since many people complained about the controls, and the AI frankly sucked. But I guess when people “like” the game, all the scores go a bit higher together. That also goes for humor – I have no idea why I got a 3.14 score, since I did not include anything humorous in my game.

I would love if anyone who voted in my game could comment on the “mood” score. I usually rate mood based on the “consistent feel” of the game (which mine wasn’t quite there), and the “not done by my nephew” factor (does not feel TOO amateurish – decent opening, transitions, desktop behavior, etc).

Post Mortem

Set-up

LD23 and LD24 were two failures for me. In both cases I had quite pretentious ideas that didn’t live to their full potential. So even before the theme was decided I decided that I would go with a simple action game, probably a shooter. As the LD approached, the idea of making a QiX game was growing in me.

When the theme was announced, I quickly decided to make a “reverse-classical-game”, and sat down to think which classical games would be a)realistic to make and b)fun to play. Pacman and QiX were at the top of my shortlist. In the end, I decided to go with Pacman because since QiX is a really old game, I was afraid many people wouldn’t “get” it.

Making the game

This is the fourth time that I make a game using the JAVA + SLICK2D combo. Even though I hadn’t programmed in a while, I was still familiar enough with the basic API, which helped. I’m starting to feel some limitations on the SLICK2D library though. If I did this for a living, I would probably start to look for a new library about now, but I want to get a bit better at short game jams before worrying about that. I would probably get more bang for my book by learning how to properly compose simple songs, or getting a more consistent graphics style.

Development was pretty straight. I managed to add some bells and whistles such as transitions, pauses, high scores, etc. I wasted a LOT of time on the Pacman AI. My BASIC idea about how the Pacman AI should work was wrong, and instead of realizing that I should redo it from scratch, I tried many different small adjustments to it. All in all I lost a lot of time here that could have been spent on other things.

Another thing that was bad in the development is that I couldn’t get people to playtest my entry. Playtest is SUPER important. Many of the comments from the reviewers mentioned that it was hard keeping track of which ghost was selected with which number. Many simple solutions were suggested. This is the kind of stuff that a little play testing by someone other than me would have caught quite quickly.

Positives and Negatives

The good:

• I was familiar with Slick2d, and that made a lot of stuff faster. Even if I didn’t know how to do something, I knew where to look.
• I started using Inkscape a lot, which is good for non-pixel drawing (such as the game board).
• “If it is not moving on the screen, it can be drawn on the background”
• I started to get used to mixing sound effects in BFXR, for some cooler results than using single samples.
• Simple fade-out transition: draw a blank square on the screen and mess with transparency
• The simpler your game idea is, the more time you have to refine it!

The bad:

• I should have written cleaner code. My code was so messy that it was hard to add simple things such as a difficulty progression based on changing pacman’s speed/power length.
• I’m starting to get tired of autotracker’s music. People who have never heard it like it, but it gets old really fast.
• Using Angelfont in a Linux environment is really hard – I will have to find some other library to use/package fonts in my game.
• It seems that java applets are unreliable in Ubuntu. I can’t even play my old java applet entries anymore in any of my ubuntu boxes .
• Not getting anyone to playtest my game was REALLY bad.
• I lost a lot of time banging my head against pacman’s AI, when I should have done something simpler (Greedy search?).

Timelapse

This time I added the title music of my game to the time lapse! It is so much better than a silent timelapse!

Namcap Timelapse!

Curse of Goats

Finally, a little bit of a rant. I think the goat thing went overboard this LD. I saw too many games where goats were pushed in, without thought. I think this is because the optional theme was put in the announcements this time (unlike kittens in LD22, which was mostly a thing spread through word of blogpost). Since it shared the same space as the official theme, many people might have thought it was also obligatory or something. While I love silliness a lot more than the average people, forced jokes get bad real quick. I suggest that the joke theme is not supported officially in LD26.

Anyway, see you all in LD23!

Entry: Speedrun

As this was my first Ludum Dare, I only had two goals: to finish a game, and to make sure I was able to sleep both nights.

I met both goals (yay), but I was truly blown away by the judging results: my humble game placed 7th overall, and highly in other categories, too. Thanks to everyone who rated my game, and kudos to everyone else who submitted one! It was really great to meet a few of you on IRC.

What Went Well

• I finished! It may seem obvious, but this is really the primary challenge of any game jam. The beauty of the 48-hour format is that it forces me to lower my expectations — in a good way.
• Development strategy. My goal was to budget the first 50% of the time to getting the game fully playable (feature complete), then spend the rest of the time on polish (graphics, sound, tweaking gameplay, etc.). Although I fell slightly behind schedule, having a plan made it much easier to get a full night’s sleep both nights, knowing that a playable, submittable game was within reach.
• Simple gameplay. Although the theme inspired a lot of ambitious, complex ideas, I chose the simplest one that I felt would make a fun game. In fact, I initially wanted to make a one-button game, but I added steering once I decided to do a driving game. It was easy to prototype and tweak because it was so simple.
• Graphics. At first, I struggled to get a look that I liked. Luckily, things eventually felt right and the graphics came together rather quickly.
• Audio. I had trouble figuring out how to synthesize a convincing engine sound. At the last second, I managed to create decent loops from an actual recording of a Ferrari F355.
• Testing. I played the game a lot during development. Not only did this help me iron out some bugs and refine the gameplay, it helped reassure me that there was actually some replay value to the game.
• The community. On the evening of the deadline, the IRC channel was full of other participants who were eager to play each others’ games. It was a very friendly, constructive atmosphere.

What To Improve

• Make sure the game includes instructions. I planned to create a title/instruction screen as part of the polish phase, but I ran out of time. It really should’ve been included with the “core” game functionality. That way, it won’t be missing if (that is, when) I run out of time.
• Ask others to test — early and often. Although the importance of instructions seems obvious in hindsight, I totally overlooked it because I was so focused on other details. If I had asked others to playtest the game before it was ready for submission, I would’ve realized it sooner.
• Stick to familiar tech. I started out with Flixel, which I had only toyed prior to the competition, and quickly found myself frustrated and unproductive. I wasted several hours before starting over from scratch with Love2D.
• Build a web version. It’s hard to overstate the value of instant gratification. Games that are playable in the browser are much more likely to be played than other ones, which is why I initially wanted to use Flixel. I did try the Love2D WebPlayer, but there were just too many unsupported features and little issues.
• Keep my weekend clear. Easier said than done, of course.

Results

I was stunned to see that how well my game scored out of all 1,327 games (wow!). It was rated 7th best overall, 9th best in fun, and 17th best in graphics!

Of course, positive feedback is always nice, but the real reward is finally participating in Ludum Dare after procrastinating for so long. Up to the last minute, I couldn’t decide whether I was going to join in or not — but I’m so glad that I did.

I’m definitely hooked now … see you all next time!