About Ashera

Entries

 
Ludum Dare 17
 
Ludum Dare 16

Ashera's Trophies

The "Why Didn't I Think Of That?" Award
Awarded by SonnyBone
on January 2, 2010

Ashera's Archive

Stixel — Like Flixel but more Flash-y

Posted by
Wednesday, August 18th, 2010 11:05 pm

For this Ludum Dare, I’ll be using the Actionscript library/engine I started writing last Ludum Dare. I’m calling it Stixel for now, since it started as a replacement for Flixel.

Stixel has some physics, including mass/momentum calculations. Its collision detection assumes circles. Structure-wise, it’s more vector-oriented and Flash-like than Flixel, relying on the display list for rendering and nesting. It also supports wrapping maps.

The source zip contains:

  • The current version of Stixel
  • The state machine classes I created last Ludum Dare for managing game states
  • An experimental Asteroids game that shows off some features of Stixel (wrapping, rotation, physics)

Stixel 001.zip

Post-mortem

Posted by
Monday, April 26th, 2010 11:35 pm

This Ludum Dare was far more frustrating than the previous one.

My game idea was somewhat more ambitious than SEEK*TOR, but what really killed my progress was trying to use flixel for something it’s not suited for. I spent most of Friday and Saturday trying to bend and hammer flixel into doing what I wanted it to. I managed to code some work-arounds, but I felt like I was doing twice as much work as I should have been.

The game I wanted to make had you swimming around a world as an aspidochelone, or asp-turtle. You would start out small and eat fish and other sea creatures, slowly growing bigger. There would be ships and sea monsters floating around, which you could ram to make them drop their stuff if you were big enough. Once you got big enough, you could start picking up rocks to build an island on your back. With an island, you could pick up people and have them build a village on your back to help you out. There would be different resources that would encourage your villagers to specialize and give you different bonuses, like faster movement, stronger weapons, faster growth, etc.

The two features that I really had trouble doing in flixel were scaling and rotation (specifically, collision detection while scaled and rotated). Given that I had a turtle swimming around in a top-down view, growing as the game progressed, this made things pretty difficult. Also, I kept needing groups of things to move and rotate together, which FlxGroup isn’t quite set up to do. (FlxGroup is very good for pooling objects so you can re-use them. It’s not so good for moving multiple objects as a big chunk.) A minor annoyance that I kept encountering was the fact that it’s difficult to create an object that’s only for display and doesn’t have all the physics-y stuff attached.

With about 18 hours left, I finally decided to toss out flixel and write my own engine from scratch. That consumed the rest of Saturday and a big chunk of Sunday. Getting movement to work was no problem. Switching over didn’t take me too long either, since I tried to match flixel’s organization as I coded my engine. The real headache was getting collision detection and handling to work. I have variously had islands shoot off behind the turtle when touched, trap the turtle and prevent further movement, and stick to the turtle like glue.

So, I didn’t manage to finish my game. On the other hand, I now have a half-way decent first version of my very own game engine!

Frustrated and crazy

Posted by
Sunday, April 25th, 2010 12:27 am

It’s over, flixel!

I feel like all I’m using from you now is the collision detection and handling (specifically, having objects bounce back when they collide). Considering everything else I have to go through–non-existent rotation handling for groups, piss-poor scaling handling when combined with collision boxes, and all the crap I need to do to so I can test with colored boxes instead of having to draw sprites–I’m putting in more than I’m getting out.

So now I’m writing my own framework for simple physics, with 18 hours to go. We’ll see how far I get.

More progress

Posted by
Saturday, April 24th, 2010 5:39 pm

Now there are enemies, food, and a progress bar for your size.

progress02

I think the next step will be to add the villagers that go on your back. And maybe have the enemies move around.

Progress, of a sort

Posted by
Saturday, April 24th, 2010 11:47 am

I’m way behind. I’ve spent all morning grappling with flixel in an attempt to make a map that wraps around. I feel like every time I try to use flixel, my game idea includes something just far enough outside flixel’s boundaries that I spend twice as much time working around it as I would have doing it without flixel.

For future reference: if you want to set a FlxGroup’s x or y coordinate directly, you have to use FlxGroup.reset(x, y) instead. Otherwise, it sits there like a stupid lump and doesn’t update anything.

What I have now (the turtle does move around, at least):

progress01

Looking forward to this!

Posted by
Thursday, April 22nd, 2010 6:23 pm

Last December was my first Ludum Dare, and it was a blast! So I’m definitely in this time around.

I’ll probably use the same tools I did last time:

  • FlashDevelop + mxmlc compiler. +flixel if I do a game that benefits from it.
  • Audacity and sfxr
  • Acid Music Studio with some free softsynths
  • Paint.NET or GIMP if I don’t do my graphics in code

I think I’ll also check out the IRC channel this time, although that may fall by the wayside as it gets down to the wire…

Post-mortem: SEEK*TOR

Posted by
Monday, December 14th, 2009 7:12 pm

So this was my first Ludum Dare. I did the Global Game Jam back in February, so I had some idea of what to expect, although the GGJ was teams rather than solo. One thing I do regret is not interacting more with the community–IRC, Twitter, etc. I could have used more feedback than I got, instead of relying almost entirely on my husband’s comments.

Friday night I spent brainstorming ideas and thinking over mechanics. Saturday morning I started coding. By late afternoon / early evening, I had the major mechanics implemented, but it wasn’t fun. At that point the turrets were just yellow diamonds (and they were warp portals which your cyan circle teleported between), and the hint circle always disappeared before you could fire again.

Screenshot of older version of SEEK*TOR

Screenshot of older version of SEEK*TOR

The best thing that happened for the game occurred when I sent my Saturday prototype to a friend for feedback. He told me two very important things:

  1. He had the most fun figuring out where the hint circles intersected
  2. He wanted to know why you had to aim and fire to reveal the map instead of just placing light bulbs around the “platforms” (yellow diamonds)

So I made the hints persist but fade over time. That means you can see the hint circle intersections, but the screen doesn’t become overly-cluttered with old hint circles. It also means the aiming mechanic is important, since if you take too long, the previous hint will have faded away. I also changed the theming of the game so that the portals became turrets and you selected a turret to fire from, rather than teleporting between them.

Sunday was mostly a day of polish. The big feature changes were implementing multiple levels, scoring, and flare limits. I also added the start, game over, and between-level screens, made the graphics, (such as they are–hooray for GlowFilter!) composed a background track, and created the sound effects.

In the end, I was successful in terms of having a pretty-much finished game at the end. On the other hand, seeing some of the other entries, I kind of wish I’d done something a little more ambitious…

Things that worked out:

  1. Using abstract glow-y vector graphics instead of trying to draw. (I spent about 20 minutes attempting to draw a single turret before deciding my time was better spent elsewhere.)
  2. The game selects from 4 (hand-crafted) turret layouts and randomizes the enemy and player locations. That turned out to be enough randomization that I didn’t need to make a turret layout generator. In fact, I only just realized that I left the game in debug mode where it always chooses the same turret layout.

Things that didn’t work out:

  1. When I started, I implemented everything in one file just to see if the core mechanic would work. I made such a mess of my code that I spent hours late Saturday night moving code around so I could add levels. Spending hours working on code without actually adding new functionality–even regressing at times–was very hard on my morale.
  2. I spent too long trying to make my git history tidy. I’d keep forgetting to add a file to the commit or not commit for a while and wind up with a gigantic commit that involved 3 features and all the source files. Then I’d try to figure out how to break up or revise the commits. (And how to use vim, since that’s the default git editor…) Given that I never had to revert to a previous version, it was kind of silly of me.

Tools and Libraries Used:

  1. FlashDevelop
  2. TweenLite
  3. git
  4. ACID Music Studio
  5. Free VSTi soft synths: Crystal, LazySnake, and ErsDrums
  6. Audacity
  7. sfxr

Finished my first Ludum Dare!

Posted by
Sunday, December 13th, 2009 7:28 pm

Sweet, I managed to complete my first Ludum Dare! I was thinking of learning Push Button Engine for it, but after going through a couple of tutorials I decided I’d go for straight-up Actionscript instead. PBE has some neat features, but I need more time to get my head around its component-based programming model.

Anyway, SEEK*TOR is a game where you’re trying to locate the enemy by firing search flares from turrets. You have limited flares, and turrets have a limited range, so you need to carefully choose where you aim. It’s in Flash.

SEEK*TOR Voting page

Incidentally, I’m annoyed with Audacity because it added an initial silence to all the mp3 files I encoded with it. So all the sounds come in late. :( Also, I just realized that I forgot to have the background music loop…

[cache: storing page]