Game Geek Speak

How about a little self indulgence? After the amount of hair I lost wrangling with Flex, I deserve it!

I admit it: this is butt ugly. It’s just plain old Flex. I didn’t add any styling at all. Who has time for that?! And the screenshot is tiny (better ones will be bigger, promise).

Anyway, what you see is the new map dialog, where you enter some parameters for your new map. To the right you see the edit bar, a tile set, etc. This is laid out like the Lila Dreams editor, but the code is only slightly based on stuff I did previously (handling user prefs, finding asset directory, etc). It won’t actually make a new map yet, but I just need to hook that up to the UI.

Let me summarize: five hours of trying to figure out why Flex didn’t like my custom components and associated .as files. Finally I just decided to inline all the code, to hell with keeping it separate. I have always thought Flex is very tedious to use. It’s a love/hate relationship. Maybe in seventeen thousand years, after I have used it a little bit, I will feel more on the love side. Today… not so much.

On the positive side, it is coming together pretty fast despite these kinds of frustrations. There’s a chance I can achieve my goal! More updates to come.

Addendum:
http://www.adobe.com/cfusion/communityengine/index.cfm?event=showdetails&productId=2&postId=7142

*Screams*

Well, at least now I know that you can’t subclass Canvas and expect it to behave like when you subclass UIComponent if you are trying to add a child Sprite to it. What I mean is, if you create a custom component that subclasses Canvas, it will throw an exception when you try to addChild() a Sprite. But if you subclass UIComponent, it will let you addChild() a Sprite.

*Slaps self silly, then gets back to work*

I’ve been on an epic quest to figure out how to best structure my game loop. The game loop is the one place where all your game’s logic should be updated. It’s the control center.

I’ve used delta time before, and that works fine in many cases. It’s where you measure the time since last game tick (aka frame) and tell all your objects how much time has passed so they can scale their responses accordingly. This is simple, and it works for very simple physics models. The trouble starts when you’re using a complex physics simulation to control objects.

I’m using Box2d, and for a physics sim, you want every update to use the same delta time. Fluctuations can cause the simulation to get all wigged out and blow up. Lucky for me, on the game I’m working on (not announced yet), I’m mostly only using Box2d for collision detection. There are no stacks of boxes or whatever, so there’s not a lot of simulating happening, and that makes it more tolerant to variable tick durations. Still not ideal, because it can cause weird collision glitches, like tunneling.

My view camera, though, tends to be very sensitive to update time fluctuations, and if the player moves more one frame than in the last, he jitters. It’s very annoying, and makes the whole game look jerky and twitchy, even at respectable framerates.

So my quest has been to find a game loop that can smooth all this out.

One thing I did was enforce a constant framerate. This allows the rendering to happen at a steady rate (like 30 fps) by sleeping for a few milliseconds if it’s rendering faster than your desired framerate. You basically measure if the last frame took more or less time than what you want, add (sleep your timer) or subtract (don’t sleep) that time from the current frame, and that evens them out.

So I had the physics decoupled from the rendering, but even with the steady framerate, the physics was updating at varying speeds to keep a steady 60 updates per second. So, for each frame (at 30 fps) the physics would typically update twice. But sometimes the interval since the last update would be more than that, so it would update 3 times, or maybe only once. Again, this causes jittery movement and makes the game feel really terrible.

So I’ve decided to just frame lock the physics and rendering. That means when there’s a frame rendered, there’s a corresponding physics update. As long as you have the CPU to stay at or above the minimum frames per second, the game will look nice and smooth.

This is great. Mostly. The problem happens when the computer can’t keep up with your desired framerate. Since things are on a fixed time step, the whole game slows down. Slow motion is only fun if you mean for it to happen! But I haven’t found a better solution, and I’m on a tight deadline. This’ll have to do for now.

Some linky goodness:
http://www.8bitrocket.com/newsdisplay.aspx?newspage=10248
http://gafferongames.wordpress.com/game-physics/fix-your-timestep/

I stumbled across this totally accidentally today while searching to find out if it’s possible to subclass Rectangle (I don’t think it is, but I never found a definitive answer):

AS3 Manual

Where was this thing back when I was learning my way around ActionScript?! It seems to be a really good tutorial, and it’s kinda huge. I guess if I RTFM, I might have known this site existed, but Adobe could do a lot better to tell noobs about things like this. (I won’t start on my Adobe rant, ugh.)

It’s a good reference when you need examples, so even if you’re a hardened veteran, it can be useful for remembering usage or parameters, and so on. Good stuff.