There, I said it. I probably just lost a bunch of potential traffic, but hey, at least I am honest. I've faced some real challenges in coding one of my upcoming top-secret games. Actually, the code part is easy. It's the math and physics involved that make me crazy. Last night I came close to looking up my Grade 12 Calculus teacher and asking for assistance. Then at around 12:30am I stumbled upon a great tutorial by Senocular, and it really saved me.
I'm sure you've seen Flash games where a missile gets launched into the air, and it flies a nice smooth arc back to earth. Many of these games are two-dimensional, meaning there is no depth to the scenario. My project involves the launching of various objects into the air, but in a three-dimensional world. When an object in the game is fired "into the screen" it should shrink if you want it to look believable, and it should grow if it gets fired outwards, toward the player's face.
The trouble lies in calculating the proper motion of an object at varying depths. A ball that appears to be traveling fast at close range will appear slow when viewed from a great distance. The trick, as I have learned, is to first realize what the real problem is. You have a three-dimensional scenario that needs to be displayed on a 2-dimensional screen.
In games, information such as speed and direction are stored in digital containers known as variables. A ball that is thrown across the screen is said to have a vx (x speed) and a vy (y speed). In the real world there is a third dimension, depth. Depth is an object's position on the z-axis. When making the necessary conversion from 3D to 2D, it becomes apparent that these 3 dimensions must be made to interrelate. For example, an object up close always appears faster than an object viewed from a great distance. This means that when the z value is large, the vx and vy values must be made smaller. Coding this up is not as simple as plugging a bunch of values into the Pythagorian Theorem. It is messier.
The big trick is to create virtual x, y and z values. Huh? You keep track of an object's position along the three real-world axis: x, y and z. When you convert this real-world scenario to 2D, the z value doesn't really do much except scale the size of the object, and scale the size of the x and y values. When an object is far away it has a large z value, and therefore the object needs to be scaled down to a small size. If the ball is travelling from left to right, it's speed must be scaled down in accordance with it's depth, or distance (or z value, to be technical).
If you have read this far and are not daunted in the slightest, I would highly recommend anything written by Keith Peters. Have a look at his amazing book on the left. He discusses in depth how to make things move with actionscript. Easy enough for beginners, but certainly not boring for experienced coders. He even has a second book, Advanced Actionscript 3.0 Animation which picks up where the first one ends.This blog is not going to get technical very often. The inner workings of 3D programming is really fascinating, and it has been a lot of fun to learn. Creating this next game of mine has made me feel somewhat like a mad scientist (except I'm not in a creepy underground lab with bats and spiderwebs, I'm usually sitting at Starbucks!).
