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.
No comments:
Post a Comment