I am back in the Flex/Flash world and working on more games. This time around I have had the opportunity to work with a 2D physics engine in ActionScript 3. Our current choice is the Fisix engine which like the last technology I worked in, is very much in development. Just for context, I have never worked with such an engine and this is my first exposure to this type of modeling.
My first impression is that physics in games is a lot of fun. Experimenting with ideas about structures and interactions is a blast. Unfortunately, if you do not already know the principles behind these engines discovering how to properly model something can be a bit of a chore, especially in a system like Fisix which has inadequate documentation. I am now at the point where I know enough to be dangerous and have found a couple of quick tricks that other users of the engine might find helpful.
The engine has a tendency to allow quickly moving objects to penetrate surfaces, which is not desirable. There are three things that I found that you can do to try to limit this behavior. The first is the most straightforward. You can specify the collision detection mode via an enumeration defined in the DetectionModes class. Setting this to a non-default value can give you better results. I went all the way up to RAYCAST and with only a few objects moving at any given time the performance was fine. The documentation says this detection mode prevents tunneling, but I beg to differ. I had to find a few other workarounds to limit its likelihood.
The second solution I found is to increase the width of the colliding surfaces. In my instance I was freely able to increase the width on one, but not both. It was sufficient though. Instances of penetration dropped dramatically. However, I know that for some applications this just won’t be possible, and there is a third option.
The last option I found is the most risky and should be used with the most discretion. It has to do with the number of instances the collisions are solved each frame in the engine. You modify this property via the setIterations method of any FisixObject. The real gotcha with this is that the iterations value of each FisixObject multiplies the number of iterations its parent must perform. If you aren’t careful you can end up with FisixOjects performing hundreds of solutions every frame and that is no good.
After working on this project for a time I am excited about the possibilities this type of modeling brings to the flash world. The interactivity and realism you can get from the physics interactions is just fun and games can always use more of that.
-Casey
