Quarplet

Whew, this game is big   Someday, I’m going to teach myself a lesson about scope creep, and make a small, simple game.

But it will not be this day!

I posted a couple bits of art over at deviantART.  I’ve been drawing a lot!  But I’ve only posted a couple things publicly.  I wouldn’t want to give away very much!  But there’s a baby snail in my game now ^-^

Coding bosses takes forever.  It’s fun, though!

• Map splitting revisited.  Now I hash each layer of each room, so I don’t store identical room layers more than once.  This means, for example, adding empty rooms takes no space.  I added a second background layer behind the collideable layer, which makes my life easier as a map designer, though it’s strictly unnecessary.  What if I use it in only 4 or 5 rooms?  Then it costs me nothing for the rest of the rooms, rather than costing an extra 250,000 tiles like it would have in Snaily 1.  This also means there’s no advantage to laying out the map densely, and I can lay out the map however I want this time, and as big as I want   And the memory usage is tiny.  I also scan for more metadata, so I was able to add…
• Doors!  Hit up or down to enter, and it takes you to its pair with the same ID.  They get scanned when the rooms are split, then stored as room,x,y coordinates in embedded XML.  They work pretty well, I think!  I could add a teleporter hub using about the same system, but I haven’t yet.  Right now doors only function in pairs.  To avoid confusion with the doors in snaily 1, I called these “portals”.  I can do more stuff like this, because of the map splitting.
• Main loop, and timestep sadness!  One problem Snaily 1 had was gameplay that was inconsistent across machines.  A couple bugs never showed up for me, but did at low frame rates due to Flixel’s variable timestep.  I felt kind of bad about that!  I resolved to use Flixel 2.55, which has a fixed timestep.  But it’s just not as smooth!  I think Flash is basically incapable of consistent frame timing, especially re: multiple platforms.  That’s okay, as it’s not TOO bad.  But I took Photonstorm’s advice (not given to me specifically) and cut out the accumulator entirely, and switched back to a variable timestep.  Everything felt much nicer and smoother!  But now I had noticeably inconsistent physics again.  So I rewrote the main loop–the timestep is allowed to vary a bit, but between certain thresholds, frames are split into 2 or more pieces, to keep the timestep RELATIVELY consistent.  If the system slows down past a final threshold, the game simply slows down rather than becoming more choppy.  So I’m hopeful that this gives the most consistent experience across computers, without sacrificing the smoothness I had in Snaily 1.  What I’ve heard back from alpha testers so far makes me optimistic
• Generating asset embeds!  I wrote a couple perl scripts which automatically generate AS3 files containing embed directives for all the files under art/ and sfx/.  The art script makes a list of all PNGs under art/, but then removes any that aren’t in use by the code.  It creates symbols for each that match the filenames.  The result is I save time doing annoying manual input adding hundreds of images to an assets file, and the file size ends up smaller, as I almost surely had unused assets in Snaily 1 editing the file by hand.  The sfx version is similar, but it invokes swfmill on any SWFs in the directory, converting the SWFs to XML to get a list of exported symbols; it includes these in its tests for which sfx are used.  (This is of course because sounds are less latent if you encode them from the IDE rather than embed MP3s directly, but I don’t have the IDE, so I ask xdanond to use the Flash IDE to encode and export the sfx for me when he gets a chance.)  Last, an XML file contains default volumes for each sound effect (if I want to override the global default).  Managing this stuff automatically is a life saver
• Debugging: collision pt. 1!  Not everything works the same way it did in Flixel 2.43.  Some things do, and I was simply unaware at the time.  FlxG.worldDivisions bit me–Flixel decides objects collide when they don’t actually, if this is too low.  PhotonStorm’s explanation indicated this wasn’t a bug, but I don’t think it makes sense to say it’s not.  In any case, rather than rely on a high value for worldDivisions, I changed the design of my code not to use the collision code for the fine granularity checks I needed.  They were too slow, anyway, even with a smaller value!  But I have a class which temporarily sets worldDivisions higher, creates (well, recycles) an invisible “hit box” object, sets its size and position, collides it against a target, then resets worldDivisions to the old value.  It’s useful for checking if something would collide if you changed its size or position, though it’s not terribly fast.
• Debugging: collision pt. 2! Flixel 2.55 keeps track of the last position of objects, and how far they’ve moved.  My old code for Snaily changes the physics often (size and position), whenever you go in or out of your shell, or switch to walking on a wall or ceiling, or when you teleport to a save point.  In the new game, portals add to this, and so do [secret].  But they all mess with the delta!  All sorts of things go wrong with Snaily if I don’t translate the *previous frame’s* coordinates as well.  For example, when Snaily went through a door to another room, the silly snail would pick up all of the items nearby, without touching them!  This took me some digging to find, frustratingly, though it was simple to fix in the end.
• Debugging: collision pt. 3! Tunneling is too expensive to solve in the general case, but easy to solve in individual cases.  Some objects in my game have multiple sets of physics–pea circles can collide with enemies with a size of 26×26, but with terrain they only collide on a single pixel.  This is so Snaily can fire them straight forward without hitting the ground or ceiling!  They also move very, very fast, enough that rewriting the game’s main loop makes them substantially more consistent across different computers.  But not enough.  A simple hack: I put in checks for 5 pixels, drawing a line between the center pixel on the last frame, and the current one, and interpolating 5 different points.  If it collides at any of these, it hits the terrain.  Fast enough, and I get the behavior I want without tunneling.   Hooray!
• Debugging: memory leaks!  Snaily 1 called FlxG.play(), passing in sound effects from an assets file containing a list of embeds.  Apparently if you do this, you leak memory.  A lot.  Crap, how much memory did Snaily use, anyway?  Snaily 2 shows memory usage hovering between 12 and 21MB.  It rises, but then drops back down with no permanent increase, so the gc is working.  (I didn’t know any AS3 when I programmed Snaily, and although I’ve been a programmer all my life, I think I was a bit unaware of what I was doing at the time.)  To make sfx NOT leak, just hold onto a FlxSound and call play() on it.
• Animation!  My copy of Flixel is pretty Flixely, but it has lots of little changes.  Things you wouldn’t get very excited about, like outlines on text, but to me, the little things start to add up.  I’ve been expanding the animation class for a while for different needs.  Instead of just looping the whole thing, you can set a loop point; you can set a next animation to go to when the current one’s finished; you can set up parallel animations and switch between the two keeping the current frame #; and you can set an object to die when its animation is finished.  See, all little things   But they make my life easier.

Of course, this is all driven by the actual game, but that’s not what this blog post is about, so I’ll stop there…

I was working on a new project with someone really talented, and we haven’t officially cancelled it, but he asked if I might be willing to work on a smaller project instead, for now.  So, it’s at least on hold.

I said sure, but I’m waiting for some kind of design to act on it.  So for now, there’s:

• Fire: on hold. It’s definitely promising, though.  It’s fun playing even what we’ve got so far, and the art is amazing.
• RS2: on hold. Paul’s working on the characters and script.  I wrote a basic engine for it, though I could probably go back and incorporate some code I wrote for Fire.  xdanond wrote all the code for RS1 (well, I contributed a couple functions, but that’s all), and he’s kind of excited about having me do the coding for the sequel   I’m planning on working really hard on the boss design, which is my favorite part, really!
• VR: in my head.  I still want to work on this, but I’m reluctant to write the entire story myself.  I love writing, but I’m kind of afraid of failure, and if I want to do it, I have to push myself past that fear and invest a fair amount of time for what may simply not be good enough.  I’ve been working on other things instead (coding), which is more or less playing it safe, since that’s where my talents lie.  Then again, there’s an off-chance xdanond will write VR, depending on what we do.  In any case, VR isn’t supposed to be a very big project, so maybe I should just make it and can it if it’s not good enough.
• S2: playable, but I’ve been working on other projects instead.  I think I made a couple missteps with it.  What works well for me is working within limitations, and by changing them for the sequel, I opened myself up to the paradox of choice and took away the feel of consistency the limits provided.  I think that feel is what made Snaily work despite my lack of art skills, so that’s a pretty bad move on my part.

Okay, so now that Fire’s on hold, I guess it’s time to go back to S2.  I’m not sure I’ve given my subconscious enough time to design additional bits, though.  In any case, I’ll probably drop whatever I’m working on as soon as xdanond is ready for me to work on RS2, because RS1 (Starwish) was really successful, and I think it’ll be a lot of fun working on it.

BTW, I give all my projects names even before I know anything about them, but I’m sure the names are meaningless to most people.  Then again, most people aren’t reading this blog.  (I’m always a bit surprised when someone I don’t know comments!  I expected this blog to be public in theory, but restricted to a dozen or so friends in practice.  I wonder who reads it?)

I’ve been spending a lot of time just working on music, and guitar in particular.  I’m also making a tutorial for Famitracker!  Yay, me!  But if I’m not working on Fire anymore, I think I’d rather do Snaily 2, because I know I can push myself to finish a project on my own, and it’s disheartening when a project gets put on hold.

So, prepare for more crappy programmer art, world!