Trigonometry hurts.
I remember bawling over my trigonometry homework about 4 years ago. For some reason, the laws of cosine, sine and tangent didn’t stick no matter how hard I crammed them into my skull. There was a time when it comforted me to know that I would probably never need to remember any of that hellish subject matter. Ah, how inexperience makes us naive. It turns out that trig is everywhere in programming, and especially in game design. Easing, trajectories, rebounding angles, physics, and more all derive their characteristics from trig. There are ways to cheat your way out of it, but it ends up limiting your code in such a way that bites you in the end or makes your game design look bland and elementary.
My current game “Space Lasers” utilizes a lot of trig in order to perform its core Laser Beam management algorithms. In my previous games, Flash’s API would generally take care of all the trig related stuff that I needed. Ah, those were the halcyon days. Not so much anymore.
ActionScript 3.0 may know when a collision occurs between a line and an object, but not WHERE that intersection takes place. Therefore, trying to program a laser to understand when it’s hit an interactive element, then bounce off at a different trajectory at that specific impact point has been aggravating and very time consuming.
I’m 90% complete in implementing this feature, but it’s been quite a journey. I’d like to thank Colin Moock, the author Essential ActionScript 3.0, Kieth Peters, the author of Foundation ActionScript 3.0 Animation: Making Things Move. Last but not least, special thanks to my good astrophysics friend Mike for being a handy consultant.
The remaining game engine features are all ‘easy-peasey-lemon-squeezy’ (as John would say). Soon, I’ll be back into creating artwork and sound, a much more familiar and comfortable realm of creativity for me. Until then, it looks like I need to study up on Arctanget in order to get the beam reflection angles correct.