About Gjarble (twitter: @Gjarble)


Ludum Dare 35
Ludum Dare 34
Ludum Dare 31
Ludum Dare 28
Ludum Dare 25
Ludum Dare 24
Ludum Dare 23
Ludum Dare 21

Gjarble's Trophies

Gjarble's Archive

Making good progress!

Posted by (twitter: @Gjarble)
Saturday, April 16th, 2016 11:30 am

I promised myself I’d finish the core gameplay mechanics within my first 4 hours of work- and I did! I’m feeling really good about this one.


I’m In!

Posted by (twitter: @Gjarble)
Friday, April 15th, 2016 10:34 pm

Here’s my tools this time around:

  • Language: Haxe
  • Engine: HaxeFlixel
  • Text Editor: Atom
  • Tilemaps: Tiled
  • Art: Piskel*
  • Music: Bosca Ceoil*
  • Sound Effects: ChipTone*

Tools marked with a * are completely new to me. On a whim (and after seeing what some people on the IRC were using), I decided to replace a bunch of my tools just a few hours before the compo started. It’s a recipe for disaster, I know, but I familiarized myself with each of them briefly, and not only are they pretty easy to use, I think they’re far more appropriate for the job of creating a HaxeFlixel game than what I was previously using.

I’ve got an idea, but like usual, I don’t know it it’ll be any good until I prototype it. Here’s hoping it works! For those of you still without an idea, I leave you with some inspiration:

Jam entry is going well…

Posted by (twitter: @Gjarble)
Sunday, December 13th, 2015 5:53 pm


space beards

Only YOU can shave the galaxy!

I promised myself I wouldn’t get too outlandish…

Posted by (twitter: @Gjarble)
Saturday, December 12th, 2015 1:01 am

I’m in! This is probably my 10th or so Ludum Dare, and I hope to produce my 7th actually-submitted entry. I’ll be entering the jam instead of the compo this time, due to the support of my girlfriend. In past Ludum Dares, I have been plagued with two major problems: I get too distracted, and I choose a gameplay concept that is too experimental or that my tools aren’t really built for, so it ends up taking the whole period of the jam just to code, leaving no time for art, sound, levels, or polish of any kind (sometimes failing to produce a playable build at all, sometimes submitting just the barest skeleton of a game). I’m hoping working with someone else will help with the first problem by keeping me focused.

To combat the latter problem, I tried to think of an idea for a more conventional game that would allow me to more easily use the tools I’m already familiar with- I really did! But I just finished brainstorming with my girlfriend and, well… given our shared sense of humor, I should’ve guessed that the resulting idea would be something really friggin’ weird.  We managed to include both themes, too. I hope we can finish it!


  • Programming language: Haxe
  • Game engine: HaxeFlixel
  • Editor: Atom
  • Art: probably GIMP (I was planning on also using assets from OpenGameArt, but let’s just say I don’t think we’ll find very much that is applicable to our game)
  • Music: GarageBand if I have time, finding some CC-licensed stuff if I don’t
  • Sound: bfxr

Good luck to everyone!

Progress Update: not much…

Posted by (twitter: @Gjarble)
Sunday, April 19th, 2015 12:03 pm

Well, the Nape stuff didn’t work out- turns out HaxeFlixel’s integration with Nape hasn’t been updated with the rest of HaxeFlixel, and trying to fix it only brought on more bugs. Now, it’s time for me to follow through on that promise I made to myself yesterday and drop Nape entirely. I’ve gotta find a workaround that doesn’t use a “real” physics engine for my core mechanic. I have an idea, but I can only hope it’ll work…

Since I got next to nothing accomplished yesterday fiddling with that stuff, I’m entering the Jam. I guess the 48 hours comprised of today and tomorrow will be my “Compo” period.

I’m in again!

Posted by (twitter: @Gjarble)
Saturday, April 18th, 2015 8:45 am

Man, it’s been years since my last decent entry into Ludum Dare. The past few times I’ve done this, I’ve shot for something overambitious, or something that required a tool I wasn’t very familiar with, and gotten very little of substance done by the deadline- so little that it soured me on playing and rating other people’s games because I didn’t want to draw attention to my own. This weekend, I’m hoping to end that streak, working more efficiently by sticking to what I know. As per the keynote, that’s what I’m doing differently this time: using exactly the same tools as last time. Here’s my tools, literally copy-pasted from my last “I’m in” post:

  • Programming language: Haxe
  • Game engine: HaxeFlixel
  • IDE: IntelliJ IDEA
  • Graphics: GIMP
  • Tilemaps: Tiled
  • Sound effects: bfxr
  • Music: probably GarageBand

There are a couple caveats. The core mechanic from my best idea does seem to require the use of Nape, the physics engine I struggled to use for the first time last LD, and have gotten no more familiar with since then. I’ve sworn to myself that if I don’t completely tackle the Nape stuff today, then I’m cutting it and figuring out an easier-to-program mechanic. Also, HaxeFlixel’s HTML5 target is completely broken with regards to text, and I didn’t get the chance to finish writing the code I need to compensate for that before LD started, so that’ll set me back a little time. That said, I really like my idea, and however difficult it might be to program, it’s at least simple enough in design terms for me to feel comfortable attempting it.
Good luck to everyone!

I’m in!

Posted by (twitter: @Gjarble)
Saturday, December 6th, 2014 7:10 am

I’m doing my “I’m in” post now because of how I always approach LD: the first night, I brainstorm for 2 hours, pick a best idea, then immediately go to sleep. Now I’m well-rested, well-breakfasted, and ready for 14 glorious hours of game dev before I go to sleep again! I’ll be using:

  • Programming language: Haxe
  • Game engine: HaxeFlixel
  • IDE: IntelliJ IDEA
  • Graphics: GIMP
  • Tilemaps: Tiled
  • Sound effects: bfxr
  • Music: probably GarageBand

Interestingly, this theme was the second most divisive theme in the final round (as measured by fewest number of 0 votes) after the snowman. I was one of the ones who voted against this theme (boo technical restrictions), but I think I’ve got an idea that’ll work! I just feel bad for the people who wanted to make a first-person 3D game, an interactive fiction, or one of a few other things that don’t work well with the theme (though I see a few people still determined to make it work). Good luck to everyone, and I can’t wait to play what you all come up with!

Fly On The Wall: A Postpartum

Posted by (twitter: @Gjarble)
Saturday, January 4th, 2014 7:19 pm

I’ve always thought the term “postmortem” to be an odd one.  A game doesn’t die when it’s released; it’s more like a birth!  So, I’m calling this a “postpartum”.  Not that this is necessarily the best time to start using that term- my “finished” game isn’t really a complete product, and I’m not too proud of its current state.  But anyway…

Instead of trying to create the most polished game I could in 72 hours, I focused on using the jam as an excuse to force myself to learn something I’d otherwise put off- in this case, developing a mobile game (which I’d never done before).  As it’s an uncommon approach to a game jam, this postpartum is as much a referendum on that approach as it is on the game itself.

The Concept:

concept art

The Result:

What Went Right:

  • I learned a new skill!  As many drawbacks as my approach has, there’s the one big benefit: I actually accomplished my goal.  Before this Ludum Dare, it seemed like it would be a nightmare to start developing for mobile devices- learning all the considerations that don’t apply to desktop and web development and getting all the necessary components to cooperate with each other.  Now, making my first real Android game seems like it will be a lot simpler of a task, though much of that is thanks to…
  • The tools.  I’ve been wanting to use OpenFL (a library for developing multiplatform applications using just one codebase in Haxe) for quite some time, but I had problems setting it up before.  Those problems have been mostly resolved, and it worked like a charm.  Installing the Android tools took way longer than I anticipated, but thanks to OpenFL’s capabilities, I was able to develop and test the game in Flash while I waited for the tools to download without having to change huge chunks of the codebase for the Android version. There seemed to be a few things that worked in one platform but not the other, but resolving those issues didn’t take too much time.  I also tried a new IDE, IntelliJ IDEA, because I was tired of Haxe code completion not working in Eclipse’s Eclihx plugin.  Code completion worked much better in IntelliJ, though it appears not to detect files in the same directory as the file in which you’re working (importing classes from those files compiles fine).
  • The control scheme.  I’ve heard horror stories about virtual joysticks on mobile games being the Worst Interface Ever, but the constraints of my idea (a limited camera view that may not necessarily be looking at the player character) prevented me from having the player directly touch objects to move them.  As such, I worked out a two-“joystick” setup that avoids the usual virtual-joystick problem: having to constantly make sure your finger is on the spot of the screen that represents the joystick.  Instead of having a joystick at a fixed point on the screen, my game uses wherever your thumb lands as the center point (that’s what the thumbprints represent in the concept screenshot above; the circles represent where the thumbs have been dragged to), re-centering it every time you touch your thumb to the screen anew.  As a consequence, you don’t have to look at the interface to re-center yourself.  It also has the added benefit of allowing people with different hand shapes to play the game comfortably without having to adjust the UI.

What Went Wrong:

  • The phone’s accelerometer.  See my previous post for details on my problems with that.  It set me back about 24 hours, but I still had a whole compo’s worth of time left to go.
  • Distraction.  I spent Saturday and Sunday working very efficiently and brimming with confidence.  Come Monday, boom- my resolve suddenly disappeared as I debated whether or not I could finish something workbale in time, and figuring out how to implement some important bits.  I ended up spending many hours just trying to de-stress myself by doing things unrelated to Ludum Dare.
  • Collision detection.  Ironically, the big time-sink that became the reason why my game has absolutely zero polish (and no levels of substance) was not one of the many technological experiments I underwent in the making of this game, but rather the inherent limitations of the one tool I was familiar with: the Flixel engine.  I knew going in that I would have to implement circle-to-square and circle-to-circle collision because Flixel does not support those, and I didn’t want to spend valuable time importing and figuring out a full-blown physics engine like Nape.  I implemented those types of collision easily enough.  The problem was that I assumed that circle-to-circular-sector collision, which I also needed, was just a subset of circle-to-circle collision and would also be easy to implement.  I realized too late that the problem was not so trivial, and spent about half of my final day attempting (and failing) to work it out.
  • The aftermath of the jam.  This is the major problem with the approach I tried this LD:

I knew that I was probably going to turn in a less polished product than I usually do, because this time, I wasn’t focused on making the best game possible so much as one that worked under the constraints I set for myself.  As I said previously, I was willing to accept that risk this time around, because my goals were different from what they’ve normally been since I started LD two years ago.  However, now that I have taken that risk, and I have put out an unpolished tech demo, I’m not so sure I want to do it again.  While my idea worked in principle (using the time pressure of the jam as a tool to learn a skill), I made a mistake in choosing Ludum Dare as the venue to do it.

A major purpose of Ludum Dare is to make something you can share with others- both for the joy of being involved in a community, and so others can evaluate your work to help improve your skills.  This game is not something I really feel is shareable- not in its current state, anyway (I felt a little dirty submitting it).  I’m well aware of the maxim “it’s never too early to playtest”, but I feel there are limits to that idea.  This game isn’t just “I didn’t get to include all the features I wanted” unfinished; it’s “I haven’t even completed the core mechanic” unfinished.  Because of this, I actively didn’t want to play and rate anyone else’s games– not only because it would draw unwanted attention to my own game (through the Coolness system), but I feel like if this is what people see of my work, than I have no grounds on which to evaluate others’ work (even though I’m a student of game design who’s been doing game jams for years).

So, will I use this approach to LD again?

Probably not.  I underestimated the level of gratification that comes with trying my best to make the most polished game I can, and I didn’t realize that redefining “success” as something irrelevant to the final product (in this case, the learning experience) takes away all the joy of the 3 weeks after LD.  That said, am I glad to have done it?  Yeah, I can’t really complain about having opened the door to mobile development for myself.  My technique worked as intended, not for gaining a complete understanding of mobile development, but as a way to prove to myself that I can do it without agonizing over it forever.  I’d just rather do this again in a context that has much less of a focus on other people evaluating my work.  Maybe I’ll do it again in a MiniLD- no ratings/rankings, no pressure.

See everyone next LD!

Mobile Games Are HARD!

Posted by (twitter: @Gjarble)
Sunday, December 15th, 2013 9:39 am

So here’s the deal.

During my brainstorming session for this theme, there was one idea I had that was far and away my favorite.  The problem is that it would require me to make a mobile game- and I’ve never made one before.  However, I knew Haxe, I knew Flixel, and I had attempted to set up OpenFL before the start of the compo, so I figured I might be able to set up HaxeFlixel and compile for Android.  I knew from experience that, if I were experimenting with technology, it would probably take me half the competition just to make it work- and it did.  However, I think I’m ready to accept that risk now.  I’ve learned a lot of new things just from making this one game, and I have been enjoying myself.

So I successfully compiled- YAY!  But the mechanic I needed mobile for hasn’t been working out as planned.  I wanted to implement the theme as “you only get one row of pixels to view the gamespace”, so the players would have to see what’s going on by using the phone as a POV display- that is, waving it like this:

But after a lot of research into apps that did this sort of thing and research into the way I was accessing the phone’s accelerometer, I determined that it was impossible to do this with just one row of pixels in a way that the player can tell what’s going on (the above image was accomplished with a long-exposure camera and the Light Writer app, which uses far more screen space than the one pixel-width line I needed to fit the theme).

So I decided to go a different route: instead, you can only view one tile’s worth of gamespace at a time.  I still wanted to control the camera movement here with the accelerometer, but after some testing and more research, it looks like I can’t prevent the screen from rotating during gameplay when holding the phone in the orientation that I’d want the game to be played- at least not through OpenFL.  They purposefully eliminated that feature because iOS apps that used it were failing App Store submissions because of it (sometime later, I might try to write a library that does it for Android games).

But dammit, I started an Android app, and I’m going to finish an Android app.

So, instead of the accelerometer, I’ve settled upon a different feature that only mobile devices have: multitouch.  That one actually seems to work the way I want it to!  Now, time to make the actual gameplay.  I might take this into the Jam so I have more than 9 hours to do all that stuff; I still like my idea and I want to make a good game out of it!

I’M IN!…

Posted by (twitter: @Gjarble)
Saturday, December 14th, 2013 8:53 am

I’m using a tech I’ve never used before (OpenFL), which I know better than to do after two years of LD.

I’ve got a crazy ambitious idea, which I also know better than to do after two years of LD.

I started 4 hours late due to a concert, which means that, aside from sleep, I’ve had almost two hours to work so far, which have mostly been spent on brainstorming and research to see if my idea was even possible.


It’s going to be an interesting 2 days.

I’m In – A Day Late!

Posted by (twitter: @Gjarble)
Saturday, August 24th, 2013 10:25 pm

Hi everyone,

I was busy today, so I haven’t started yet.  I purposely didn’t look at the theme until tonight so I wouldn’t be distracted with ideas.  Even so, I was pulling for this theme (admittedly an anti-underdog if there ever was one)  because I got an awesome idea soon after I saw the theme’s huge winning margin in round 1.  I think I’ll enter the Jam this time so I can still get close to the full 48-hour experience.

Looking at the current field, I already see a bunch of cool ideas that I’m excited to play.  Plus, I confirmed that my idea’s probably unique!  I’m sure that with thousands of entries, my particular usage of the 10 titular seconds has occurred to at least a few other people, but I haven’t seen one such interpretation yet.  Also, it seems like my idea’s low-scope enough to pull off in a reasonable timeframe.  My biggest risk is AI- that’s something I haven’t attempted to do in LD before.

Good luck to everyone!

Interns From Mars! – Postmortem

Posted by (twitter: @Gjarble)
Tuesday, January 15th, 2013 2:51 pm



It looks like my bolstered confidence from this jam was indeed justified. I have submitted to 4 LDs including this one, but for this LD, I set a new personal best in every single category in which I got a rating (except Coolness). Not all of those new records are by a significant amount, though; the reason I’m so happy is not because of the improvements in my strongest categories, but the improvements in my weakest categories- the quality of my work is more consistent across categories without having lost any of my strengths. I still have to refine my methods a good deal, but the changes in my work habits I resolved to make for this LD paid off. This is my first solid evidence that I’m actually getting better at this.

So, why’d I do how I did in each category, and how do I improve?

#76. Innovation – 3.67 (previous best: 3.64, LD21)
I usually do well here, but I was still surprised at my performance this time, because I deliberately constrained my brainstorming.  As I mentioned in my “I’m In” post, I wrote “NO GAME GENRE REFERENCES ALLOWED” in large letters across the top of my brainstorming sheet.  However, I also made sure not to accept an idea unless it was low-scope enough to actually pull off well (I was SERIOUSLY tempted to go with a cooler but much higher-scope idea).  As a result, I adopted a rather generic arcade-style gameplay structure to maintain that low scope, but the primary gameplay mechanic isn’t quite like any game I know of, since it wasn’t designed with any existing game or genre in mind.  While almost certainly something new, it’s still nothing hugely out of the ordinary.  If I want to improve, I’ll have to find ideas in that small overlap between “low-scope” and “attention-grabbingly unique”- quite a difficult task.

#94. Theme – 3.83 (previous best: 3.80, LD21)
I’m also a bit surprised about how this was my highest-rated category. I thought it was a pretty standard implementation of the theme… perhaps people liked how I offered a sympathetic portrayal of the “villain”, but that was just in text outside of the game proper.  Improving here’s not my highest priority, but as long as I don’t keep my idea too much of  stretch from the theme, hopefully it’ll improve hand-in-hand with Innovation.

#174. Fun – 3.25 (previous best: 3.05, LD23)
This is always my highest priority, but also hard to complete satisfactorily within 48 hours. As per my game-design training, the gameplay has a solid “core” (the challenge of picking up humans without dropping them). However, I was aware going in that I would get a few marks down for some gameplay flaws that could easily be fixed given more time (i.e. humans staying out of reach, weird chain-of-humans physics). I intentionally saved these kinds of tweaks for later. In the past, I’ve fixed an emergent flaw as soon as I detected it, but this caused me to neglect other aspects of gameplay, as well as almost all of the graphics and audio, preventing me from working on a more “complete” experience.

#181. Overall – 3.33 (previous best: 3.00, LD23)
I like how this was my biggest non-audiovisual improvement. I think it reflects the fact that this is a more “complete” product than my past entries, as I mentioned previously.  This was the first time I feel like I properly scoped for 48 hours. I do still need to improve on “completeness”, though, and I think that’s the primary way I’ll be able to improve my Overall rating. The graphics and audio, while present to the degree they “need” to be, were still noticeably bare-minimum, and the gameplay still needs some more polish (see “Fun”).

#206. Audio – 2.92 (previous best: 2.18, LD23)
My most-improved category for obvious reasons (for the first time, I have music). I suspect this was brought down by a noob mistake I made and didn’t find out about until well into the rating period: after each round, the game started playing a new instance of the background music from the beginning, but kept playing the previous instance of the music at the same time. I’m going to be a bit more rigorous with my audio testing in the future to make sure nothing like this happens again.

#272. Graphics – 3.17 (previous best: 2.69, LD24)
I’m surprised that my programmer-art got me above the 3.00 threshold. I guess I just have to keep making sure that I don’t include any assets well beyond my drawing capabilities- though I was kind of proud of the way I disguised the collision boxes with the design of the mothership. I think, if I am to improve here, I have to go for a consistent, stylized aesthetic (ideally minimalistic), and find the time to do non-essential things like illustrated instructions, non-default UI graphics, background imagery, and “juicy” visual effects.

#1048. Coolness – 22% (current best: 32%, LD23)
As usual, I struggled to find time to rate other participants’ games, between holiday plans (including a trip to New York for New Year’s Eve), commitments with friends (as students at different colleges, winter break is the only chance we really have to catch up with each other), and various obligations.  I’m graduating in May- hopefully, come LD27, I’ll have more free time.

Humor – N/A (current best: 3.25, LD21)
I included a little humorous story on the game’s ratings page, but I didn’t really intend the game to be all that humorous… just cute/lighthearted fun.

Mood – N/A (current best: 2.53, LD23)
I know I find mood hard to rate for most games (and usually abstain), and I’m betting most other voters do too. Like I said, I was going for a cute/lighthearted aesthetic, but I’m not sure it’s really stylized enough to constitute a “mood”… I guess the voters agreed. Plus, I think some voters use the Mood category only for melancholy or artsy aesthetics… those are the only ones I find easy to rate myself.

Right On Schedule

Posted by (twitter: @Gjarble)
Sunday, December 16th, 2012 3:00 pm


Things have been going surprisingly well!

You can still tell I’m not an artist, but I’ve got the bare-minimum art done (I’d like some clouds, hills, or something else to fill that empty space in the background if there’s time), and the humans behave much more (though still not entirely) according to the laws of physics.  I’m satisfied with all the mechanics, so that just leaves sound/music (and writing instructions- I saved that for last in case there’s any last-minute mechanical changes) and I’m home free!  I might actually have time to add extra polish!  Probably not goats, though, but that’s okay.  Maybe for a post-compo version.

I don’t want to jinx anything, but I think this has been my best LD performance yet.  This is already leagues better polish-wise than I managed with my LD 24 entry (which I took an extra 24 hours to do), I’m going to have art, sound, and MUSIC (a first for me), and I didn’t overscope!  I’m very happy with how this has been coming out.

To the finish line!


Progress Made…

Posted by (twitter: @Gjarble)
Saturday, December 15th, 2012 10:53 pm


I’m always so jealous of the people who know how to art.

Everyone else’s games look so much prettier than mine right now, but then again, that’s because I’ve spent my entire time so far working on mechanics- some of you all might have done art first or interspersed it with mechanics.  I try to reassure myself that I’ve therefore spent more time on gameplay than most other people (and thus my game probably plays better), but is that true?  My logs say I’ve done 5 hours, 17 minutes of actual work.  While that’s a little over half as long as I predicted I’d take to get to this point, the time doesn’t add up.  Almost 28 hours of LD have elapsed so far- subtract 4 for planning, 9 for sleeping, 2 for meals and the like- that’s still about 7 hours, 43 minutes that have vanished into the mystery zone.

Where did all that time go?  I know I get distracted a lot, but I’ve been fairly focused so far- I’d attribute no more than, say, 2 hours to distractions.  Am I really underestimating by that much?

No matter.  Time to get back to work.  I’ve stopped a few mechanics early because, while I’d have a hell of a time trying to narratively justify the physics at this point, it’s already fun/challenging.  I figure polish first, make sense later.  I’m going to do a bit of menus, then go straight to the art, then sound and music. After I’ve done all that, I’ll come back and add in whatever I originally planned that I still have time for (like the people you abduct not being able to pass through the ground once they’re attached to your ship).

Oh, and I think I figured out how to work goats in if I have time. :)

I’m In!

Posted by (twitter: @Gjarble)
Friday, December 14th, 2012 10:32 pm

Hey everyone!  I’m back for my 6th attempted (and hopefully 4th completed) Ludum Dare!  Although I’ve completed a few games in the past, I still really have to work on my polish and work ethic- I haven’t been too good at either of those things in past LDs, and it shows.  After the disaster that was last time, I am now committed to learning from my mistakes and Doing Things Completely Differently.  Here’s how I’m changing up my process from last time:

  • Having my tools set in stone before the compo.  In the past, I’ve been tempted to use an engine I was less familiar with or write more code from scratch because it better suits the idea- this time, I established what I’m going to be using well in advance of the theme announcement – all tools that I’m familiar with and will allow me to prototype quickly.  I’ll be working in Flixel, with Photoshop CS3 for art, Bfxr and Audacity for sound, and GarageBand for music.  These will restrict the kinds of games I can make, but the assurance that I won’t overscope on the core mechanic alone is worth it.
  • Focusing less on an innovative high concept and more on polish.  Of course, I always want my gameplay to be innovative, but my ideas are usually a bit too “let’s put a big ol’ gigantic TWIST on the theme”, forcing me into oddball gameplay structures that don’t lend themselves well to the tools I use.  This time, I’m focusing on wowing people less with the elevator pitch (I’m doing a game about alien abduction- not too unusual) and more with the actual experience.
  • Not making a platformer.  I tend to think too much within preexisting genre conventions.  This time, I wrote at the top of my brainstorming sheet “NO GAME GENRE REFERENCES ALLOWED”.  I thought purely in terms of what kind of villain the player might play, and what primary “verb” the villain will be doing.  I think that it’s paid off – the idea I’ve settled on would probably be best described as an “action game”, which is pretty damn nonspecific (at least compared to things like “shooter”, “beat’em up”, or “platformer”).  This allows me to branch out a bit in terms of game design, and think less inside the box.
  • Planning, planning, planning. I’ll be writing out every little thing I plan to implement, how I plan on implementing it, and how long I plan on taking to implement it (within a fixed time budget of 13 “on-the-clock” hours, not counting meals, sleeping, and such), so I don’t get carried away with designing while I code.  It’s a distraction, and keeping all the info I need in my head has severely slowed me down by forcing me to constantly remind myself what I’m doing.  Of course, if playtesting reveals something interesting (or uninteresting), I’ll change the design accordingly, but I’m not going to improvise while I’m typing out the code.
  • Tossing away my nitpicks and worrying about them later.  So the collision’s a little off.  So the spawn rate of enemy X is a little high.  Who cares?  I’ve got an entire game to finish!  Instead of trying to fix these little things, I’ll put them in a list to fix if I have more time, and move on to more important things, like interesting mechanics, art, and sound.
  • Reserving time to make music.  I don’t care if all I’ve got in the game after Day 1 is Hello World, I will put some music in this game if it kills me.  I have yet to have a game with polished gameplay, art, sound effects, AND music – something that really feels complete instead of just thrown together.  I plan on changing that this weekend.
  • Stretch goal – Progress shots!  I have yet to supply in-progress shots of my game, because I’m too busy rushing to make something barely playable.  I want to participate more in the community, and I want to feel less pressured about the amount of time I have.

Well, I’ve spent long enough writing this (that’s another thing I need to learn not to be so perfectionistic about)- time to get to work!

Coming Into Focus – A Postmortem/Autopsy

Posted by (twitter: @Gjarble)
Tuesday, August 28th, 2012 10:38 pm

Screenshot (no, really):


Bluh. I submitted my game to the Jam, but I’m not sure I can say I “finished” it. It’s a very rudimentary packaging of what I was able to program within the time limit, but it’s not really a coherent “game” without a lot of explanation. Also, I accomplished absolutely none of the goals I outlined in my “I’m in!” post; as usual, I simply didn’t have time. This is my third completed and fifth attempted LD; I should be doing better than this by now!

So, what went wrong? I picked a terrible idea. I don’t think it’s a terrible idea for a game when actually executed to spec, but it IS a terrible idea for a Ludum Dare entry. The kicker is that the primary mistakes I made, I already knew were mistakes. I knew working with a language that was not my primary programming language would slow me down; I knew making a platforming engine from scratch would decimate my scope. The problem was that making an ASCII platformer was critical to my idea at the start – I wanted to impress people by having the link you click on transform into the game, using the Ludum Dare page itself as a play surface and playing off that fact as part of the story.  That required me to jump through all these hoops that slowed me down, and I had rejected all my other ideas because they were either unoriginal or had a very low chance of being fun.

Thankfully, even though I was well aware of many of my mistakes, I did learn some new things from it that’ll help me be more confident and, hopefully, get much more accomplished the next time around:

  • Technological experimentation in a time-constrained game jam is not a good idea.  I’ve read so many things about how the spirit of Ludum Dare is about going out of your comfort zone to create something unique; something you wouldn’t have made or perhaps even thought of otherwise.  That’s all well and good, and I love that aspect of LD, but I feel like that statement has some serious caveats.  Most of the experimentation I’ve done has involved structuring my games in uncommon ways that are not well-supported by existing engines.  The less you can rely on existing infrastructures and codebases to form the backbone of your game, the less you can get accomplished in all the other areas of game design, and the more potential there is for things going very wrong.  I spent about 50% of my time writing an ASCII platforming engine from scratch, and 50% of the remainder working on a Javascript exploit that was basically rejected by the submission form (in order for the game to be played on its own ratings page)- leaving very little time for art, level design, or anything approaching a coherent user experience.  Even though programming was the first game-related discipline I learned and one of my strengths, I think next time, I’m going to scrap any idea where the primary “wow” factor is supposed to be a technological aspect, in favor of experimental gameplay or storytelling methods that are easy to program.
  • Innovation doesn’t have to be in how you interpret the theme.  When brainstorming, I didn’t even stop to consider any ideas where the player character or enemies were the ones doing the evolving, or where the evolution was literal/biological in any way.  As per the aforementioned spirit of Ludum Dare, this was in order to ensure my game was unique- but I think it ended up working against me.  A lot of other people try to think like that, and in the case of this theme (or any theme based on a verb), there’s only so many other things that can evolve.  Sure enough, one of the eariler games submitted to the Compo stated in its description that, like in my own idea, the graphics were the thing that evolved.  In addition, I realized that I was sort of fighting against the theme rather than working with it.  I was categorically rejecting all the ideas that would’ve come naturally because they came naturally.  I still like that common “scrap your first idea because everyone’s going to do that” piece of advice, but in trying to innovate upon what aspect of the game evolves or how it evolves, I lost sight of the fact that there are other ways to innovate.  I have a feeling I would’ve done better had I just done a standard “characters get upgrades as you progress through the game” bit, but done so with unusual characters, in an unusual scenario or genre, or given it a unique stylization or sense of humor.
  • I should be doing FAR more detailed planning on paper.  I spent an embarassingly high amount of time looking at the top item on my to-do list (stuff as broad as, say, “enemies” or “collision detection”), wondering how to execute that particular aspect of the game, then getting distracted, forgetting the plan, and having to think it up all over again.  Here’s another thing I plan on doing next time: during the first 4 hours, I will do no programming, art, or anything else related to the production of the game.  I will simply figure out what idea I’ll be doing, then plan out the whole thing on paper, complete with time estimates and, where I’m not sure about execution, broad-level pseudocode.  I will budget for 13 hours of pure work-time.  In 48 hours, I usually sleep for 18, and since the planning would take 4, that’s about 26 hours of free time.  I cut those 26 hours in half because, having previous experience with self-estimates, I know that they tend to be pretty accurate (possibly even self-fulfilling, due to Parkinson’s law), but that I spend about half my time doing things “off the clock”- that is, real-life stuff that gets in the way: eating, bathroom breaks, distractions/breaks from work, phone calls, other unavoidable social situations, etc.  I say 4 hours for planning because settling on an idea usually takes me 1 hour (I was a bit intimidated when the keynote described it as “the first minute” of the LD experience- it took me a whole 3.5 hours to find an idea I liked this time, due to the flaw in my plan outlined by the previous bullet point), and the remaining 3 hours should be enough to make a very thorough plan that outlines the entire design (both on the user end and the programming end) in one fell swoop, so I can eliminate critical thinking almost entirely from the programming process (I work, like, 10x faster and more distraction-free when I don’t have to think all that much about it).
  • EDIT: I need to stop being such a perfectionist.  Reading Sos’s excellent post-mortem reminded me about this one.  I caught myself several times hacking away at bits of code because they didn’t work in some obscure edge case, or testing, altering the gravitational acceleration by miniscule amounts, and re-testing because the game might’ve been a bit too easy or a bit too hard without those adjustments.  I know from experience that I have a very hard time letting go of little nitpicks like that, but I need to learn to move on and come back to it if I have time (even though, deep down, I know I won’t).  In my most recent (non-LD) project with a deadline, on my to-do list, I kept a list labeled “nitpicks” of all the things that bugged me about the game that I thought would harm the user experience.  When I was done with the rest, I went back and fixed maybe two of them before I had to submit, but it was all the better because I didn’t focus on those right away.  I guess I should start doing that in LD too.  After all, why spend half an hour on fixing minor bugs in the controls when you could do it implementing something more important, like sound?

I guess I’ll end this very long-winded post by saying that, while this Ludum Dare was less pleasant to me than usual because of all my failures, I’m still glad to have done it because of how much it has galvanized me to do the next one so radically differently that I might actually accomplish some polish that time.

[cache: storing page]