Animation Systems

We were originally thinking about using a combination of custom-made physics and box2D for Carrier.

More recently, we've switched over to using animation states for our physics.  What that means is that there are timelines of different states that a rope can be in.  Based on what velocity I pass in with the rope, I can scrub along this timeline.  This is a system that's very similar to what fighting games use, and for good reason: physics are imprecise.

I don't know if I'm the only person that gets annoyed when games stick physics in that aren't constrained based on the systems they're part of.  I've seen people bypass puzzles with no idea of what they were supposed to learn, get caught on objects, etc...  Physics are useful, but like any tool, they shouldn't be used haphazardly.

The idea behind us using fake physics is, to quote our product owner, make physics "work for the player."  If the player does something correctly, the system shouldn't have the option to mess them up.  At least in this game, we want physics to predictable and relatively easy to use.

I'll be doing another post soon to go into more detail about how the system works once I get some additional work done on it, so stay tuned for that.

Carrier Basis

Carrier is a 2D mobile game I'm experimenting with in my GDD2 class as part of a member of a larger team.  It's a fairly straightforward arcade game where players swing cars and rubble around with a helicopter to destroy a city.

We're using Flash to develop the game, and I'm going to be working with physics and other engine design: I've started off by playing around with rope physics.  Eventually I'll be handling object collision and interaction as well.

This blog will detail that role.  I'll mostly be talking about the engine development.  For longer more technical posts, I'll be cross-posting to my primary blog at latinforimagination.