FOTB’09 presentation: 3D Bowling demo
UPDATE Nov 2009 There is a better quality video posted by John from Flash On The Beach. It is available here: http://vimeo.com/7292505.
As I promised during my "3 minutes" in Brighton, I publish all the sources of my presentation. I added some comments in the code and removed the part with the slides.
Here's also the demo and a video of the mini-session. The demo is pretty rudimentary - I made so because I wanted to keep things simple during the presentation. I hope that it will be a solid base for someone who wish to create a full featured bowling game in Flash.
There were a few other implementations of a bowling game in JigLibFlash and Papervision3D. Initially, guys a Blitz Agency published a few interesting experiments with JigLibFlash, including a simple bowling simulation. Devon O. Wolfgang has written a great tutorial about building such a game on Tech Labs - be sure to check it out. I found it only after the presentation and since the tutorial explains a lot of things in details I felt like I was reinventing the wheel here. But hopefully there are still a couple of things I can add.
Thanks to the new plugin API we developped some time ago, setting up a scene with JigLib and an 3D engine has got a bit less complicated. However, tweaking the engine can be a hell. Here's a few things I found out:
1. Simulation speed
When you create the physics engine instance, the default speed of the simulation is 1. This is very slow and unrealistic. It will look much more natural if the speed is increased. Beware however - at higher speeds the collision detection system can be very inaccurate and result in objects running through each other without any collision being detected. I don't think there is a single setting that works fine in every situation, but for this case 9 worked fine for the regular speed simulation, and 2 for the "slow speed". You should always try different settings.
2. Mass
Each rigid body has a mass property. It's easy to forget about it since it has a default value and it never complains if you don't change it. However, setting the masses right is crucial for a realistic simulation. In real world object have different masses, and so they should in a simulation. This is particularly important for a bowling game, where the ball is pretty heavy and the bins are not (I guess... has anyone ever had a bowling pin in his hands?) The trick is that the masses are relative to each other, so the more different objects you have the more you need to tweak the masses to get the results right. Also remember the effect of any forces applied to an object is related to it's mass.
3. Physics material
Each rigid body has a property called material which is an instance of the MaterialProperties class. It has two properties: friction and restitution. I found out that playing with this values has a quite big impact on the simulation. Ex. setting a high value of the restitution results in the object becoming bouncy - I used this for the ball in my older ping-pong example. In the bowling demo I used lower friction on the ball to make it slide more - just as a real bowling ball does.
4. Object rotation
Once a DisplayObject is wrapped into a physics rigid body you can't rely on it's rotationX, rotationY and rotationZ propeties anymore - because they are not being set. The physics engine sets the transformation matrix directly on the DisplayObject, so if you need to check it's rotation you need to extract it from the matrix. Fortunately, there's an easy way to do this:
-
var p:DisplayObject3D = physics.getMesh(pins[i]);
-
var h:Number3D = Matrix3D.matrix2euler(p.transform);
-
// h.x is the rotationX of the object in this case.
5. Object activity
As a result of multiple forces being applied to an object and multiple collisions sometimes the objects are left in a state where the shake a bit endlessly. This can also happen when the objects are initially positioned. Calling the RigidBody.setInactive() will fix that. And you can call more than once.
Important conclusion: tweak, tweak, tweak...
It is generally agreed that hardcoded ("magic") numbers are not a good coding practice. However in 3D animations, and especially with physics the important thing is not the beauty of the code, but the what you see at the end. If you browse the source code from this demo you will notice that I not only hardcoded a lot of values, I even left ugly lines like that:
-
force = (speed == 9) ? 5000 : 3000 * 8 * 4;
In fact this is what I like the most in doing all those demos and experiments - the moment when code stops being just a list of instructions for the machine and becomes an art of making things look good by adding little tweaks here and there. If you tend to write very clean code and use all possible standards and conventions, from time to time make it ugly... you'll see how good it feels :)
I hope that this few tips will help you with your next JigLib project!
Last but not least, I'd like to say thanks to everyone who woke up early to see the Elevator Pitch session. It was a great experience being there and talking to you. The Brighton Dome packed with people can be intimidating and 3 minutes is not much time, so there was no place for mistakes. Fortunately, the FOTB technical crew made it all seamless. Great job guys!
Finally, I would like to give a special thanks to John Davey for inviting me to Flash On The Beach and for making this great conference happen!
Hope to see you next year!
