Ludum Dare 31
December 5th-8th, 2014

Gulliver – Quick Postmortem

Posted by (twitter: @ddrkirbyisq)
April 24th, 2012 6:27 am

Side note: I’ve just noticed that apparently we’ve gotten rid of the “Community” category?  I guess it was kind of a hard thing to rate anyways, so I don’t really mind.

Link to rate/play:
http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=7285

 

Alright, it’s been a couple of…days? (my mind is still having trouble readjusting to the day-to-day cycle)  So, let’s start off with a quick recap of what went right, what went wrong, what could have been better, what I’d do differently, …

 

What went well

Doing a warm-up entry
Wow, I am so glad I had time to do TwinkleShooter as my warmup game the week before LD.  I learned a lot, and definitely saved myself a lot of time and stress by familiarizing myself with Flixel and AS3 and all of the weird little quirks and details that you need to know about.  I also got in the groove of riffing on a prominent theme/motif with my entry in One Hour Compo this past week, so that prepared me for the music too.  Speaking of which…

Music
No real surprise here, to be honest, since I’m really used to producing things quickly from all of my OHC practice.  While I would have liked to be able to spend some more time on the music, being able to bang out the entire soundtrack in roughly 3.5 hours and have it be so cohesive and catchy was definitely one of the high points of LD.  One of my main goals this time around was to make a game where I could show off my musical abilities, since One of a Kind wasn’t really particularly amenable to that.  I’ll be writing more about thoughts I had while composing in a separate post.  Btw, soundtrack download is here.

Making a Flash Game
I knew from last time that browser games are just so much easier to distribute and have others rate and play, so clearly that was the way to go here, and I didn’t regret it one bit.  C# was clearly not easily portable, judging from what happened with One of a Kind (it “works” on linux and osx, but the linux one requires weird dependencies and doesn’t work on 64-bit, and the osx download is HUUUUGE), and although I could have always done C++/SDL, that would require way too much boilerplate, and still not as easy as an in-browser game.  There’s also unity and html5, but Flash seems to make the most sense for what I want to do.

The Idea
It wasn’t an AMAZING idea, but I liked it, and it came along pretty quickly after the theme was announced.  I settled on the idea of a free-roaming space shooter game with that miniaturization mechanic, and that was good for multiple reasons, including:
-Multiple areas meant I could make 3 or 4 different level themes (remember my goal of showing off music)
-Since it’s a space shooter, I can get away with little animation
-Similarly, level design can be tile based
-The easy respawn idea didn’t come up until later, but that was a boon too because it meant that even if I made my game a little too hard, it wouldn’t be that much more frustrating.
One of the other advantages of making this kind of game was…

Not making a puzzle game
Now, I certainly don’t have anything against puzzle games or anything, but good gosh, last time around when I did One of a Kind I remember being extremely frustrated because I had no idea how to make good puzzles (or whether they were even possible) with my mechanic.  This time around things were much more straightforward, and as a result I never got “stuck”, except for coding issues.  Which brings us to…

 

What went…not so well

Framework issues
This definitely gave me some anxiety at points.  Flixel is great and I don’t regret using it, but…both Flixel itself and Flixel Power Tools definitely have some kinks.  Some of it is probably just my inexperience, but other things aren’t.  For example, the weird framerate jerkiness bug that’s solved by changing one of the condition tests in the Flixel source (thankfully I found that one while making TwinkleShooter).  I also wanted to do this cool zoomin transition effect, but I ended up figuring out that zooming out is basically impossible in Flixel without bending over backwards and/or killing performance, so I had to kill that.  In addition collision detection gave me all sorts of woes…I definitely spent way too long trying to figure out why you could glitch the ship through walls.  The unshrinking logic for checking whether you’re allowed to unshrink or not was also a pain and a mess.  And I would have liked to use FlxWeapon, but I don’t like its interface.  Of course, either FlxVelocity has a bug or I’m not using it properly (maybe i’m missing a radian/degree conversion somewhere), so when I tried to do shooting logic myself it still didn’t work until I rolled my own cos/sin calculations.  Which, you know, wasn’t hard, but it felt frustrating when the framework didn’t pull through, you know?

Level editing
This was something that was giving me all sorts of worries early on.  I had never used DAME before and had decided to go with that as my map editor (I’d heard it referenced before and knew you could use it for entities as well as map tiles), but understanding how to get it all working and exporting automagically to Flixel source was kind of daunting.  In addition, the editor is noticeably slow when working with large maps, -slightly- buggy, and generally just seems to be inconvenient for doing the large-scale maps that I was doing.  I feel like it’d be fine for small 32×32 levels, but my maps were like 200×200, maybe even bigger than that.  I half contemplated looking for another editor mid-LD, but eventually decided to stick with it.  In the end I actually got pretty used to it and it wasn’t that bad (huge wave of hope washed over me at that point), but that was definitely one of the more nerve-wrecking parts of this LD.

Biting off a little too much
I wasn’t really thinking super-pragmatically when I was considering my idea, to be honest.  I ended up pulling it off, and I’m definitely happy with the result, but it really, really came down to the line–I was still fixing bugs as the submission deadline loomed over me, and I had only finished programming the final boss about half an hour or an hour before that.  So I was really quite crunched for time–and that’s with only sleeping like 10 or so hours through the whole thing, I think! (granted I did take a break to go social dancing and rest my brain)  But yes, doing something with multiple levels, enemy types, non-procedurally-generated levels, upgrades, etc. may have been a bit too ambitious for an LD entry.  If I had chosen something smaller or simpler I might have been able to make it a little more cohesive and polished.  Still, it mostly worked out.  It’s just…I was in the danger zone, so to speak.  I also didn’t have quite enough time for playtesting.  Luckily my easy respawn alleviated that issue, but I’ve already received the common complaint that the ship could be a little smaller (in terms of both graphic and hitbox), which is something I could have  easily adjusted had I known that change needed to be made.

Art style
Now here’s an interesting one that I didn’t realize until pretty late in the game–maybe even after I submitted.  Quite early on I was faced with the decision of game resolution and zoom factor, and I ended up choosing 800×600 with NO zooming–but upscaled sprites to make pixeling easier (most of the sprites are upscaled 4x).  My logic was that upscaling the sprites but leaving the resolution unchanged would allow for smoother sprite movement, and probably a more visually pleasing effect.  What I didn’t realize is that it actually looks kind of sloppy, because you lose the whole pixely feel if your movement isn’t the same as your pixel sizes.  Plus, when you use rotations and smooth movement of pixely upscaled sprites, it just looks like some bad flash movie/game.  so yeah, maybe it would have worked out a lot better if I had chosen my resolution and zoom differently.  Maybe a 640×480 game with 2x zoom, for instance.
On the plus side, I was mostly happy with the art I managed to make, despite the fact that the resolution made everything look a little sloppy.  The bird and bee animations, for example, surprised me at how well they worked, since I’ve hardly ever drawn animations before.

 

What I’d like to do differently

This probably isn’t my last LD, so in the next one, I’ll probably aim to:

-Take on something of smaller scope
-Not rely on the use of any tools I’m not familiar with beforehand (DAME)
-Use a more pixely art style

I might also try FlashPunk instead of Flixel or something, but who knows…I think Flixel is pretty good, but maybe FlashPunk would suit my fancy more and the only way to know is to actually try it out and see the differences.

 

Alright, so that’s my portmortem report.  I’ll be following up with more detailed recountings and explanations of the development process soon…

Tags:


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]