Next steps

Over the past week, our team was able to playtest movement and collisions for Carrier.  We came out of it with a better perspective on how, among other things, movement and physics ought to work. 

Our initial plan was to calculate acceleration and speed based on the proximity of the user's finger to the helicopter.  The user could move with precision when necessary, and move quickly if they needed to get away from something, or build up speed in order to throw an object.

In practice, what we found was that people always used the max acceleration (finger on the corner of the screen).  We also got a lot of feedback from those same testers complaining about both the speed of the helicopter and the speed of the acceleration.

What seemed to be happening was that users expected the helicopter to almost disregard acceleration.  I had expected them to mostly tap close to the helicopter and maintain a small speed with small accelerations, similar to how a rocketship might navigate through space with thrusters.  With that in mind, if we slow down the maximum speed and raise acceleration, that may result in a better control scheme.

Additionally, since users are disregarding anything but the maximum amount of acceleration, our team has decided to move to a fixed acceleration, rather than one based on distance.  This should lend itself more to predictable movement, and allow people to tap closer to the helicopter and use less motion to control it.

Our second playtest is in two weeks, where we'll test the revised physics out to see if there's been any improvement.

Collision Detection and How Rectangles Mess Everything Up

We're moving close to the stage where we'll have actual gameplay, by our playtest date we'll have enemies and more interesting object interactions.  Objects can destroy each other, and soon they'll have health and masses to determine how much damage they do when hurtled into other blunt objects.

One thing I've been thinking about is collision detection.  Flash has a couple of different methods for dealing with this, and we're going with standard bounding box collision.  Which is great, if all of your objects are rectangular, but ours aren't.  So there are a couple of solutions we can pursue.

1. We can get our artist to draw everything in a rectangle.  Which could be a valid solution, I've worked on games on the past, including Eyes Open, where we pretty much did this.  With Carrier though, we have really large objects, including buildings, and it just seems a little too short-sighted.

2. We can come up with another method for doing collision detection that will give our artist some flexibility, which is what I'm going to try and do, hopefully before Tuesday.  Objects have their own isColliding method, which means that depending on the game object, we can swap out different collision methods, and still just return true and false whenever we check collisions.  For complex objects, I plan on inserting multiple rectangles into the parent clip and then looping through them to handle collisions.

This is a good example of why it's handy to abstract methods out to individual classes.  If we had hard coded our original collision detection instead of letting objects handle it, it would be a serious pain to try and recode this. But because all the game objects are capable of making their own decisions, and just default back to the parent when they don't have anything to say, and because the engine constantly asks them if they want to make their own decisions instead of either requiring them to, or defaulting to the parent itself, we can do interesting overrides like this.