The first thing I did was mentally design Missle Command. I've seen several different implementations of it, so this is the spec I came up with:
The player "controls" five turrets on the screen. Each turret has a limited supply of ammunition, so it's key to shoot straight. Missles streak downward toward the turrets from random locations at the top of the screen; the player's objective is to shoot them down before they destroy his turrets.
The bullets that the player has act in "dum dum" style; that is, they explode in mid air, and not upon impact with anything. They will explode at the point where the player clicks, so he has to "lead" the missles in order to hit them.
DAY 1: 3/2/98
There is an inherent problem in GP, in that when you assign behaviors
to something, they don't get updated while in flow of control -
altering blocks (if statements, while loops, etc.) Therefore, I'm
going to have to use animators for moving missiles, etc.
Harkening back to the days of 9th grade algebra, I recalled in a moment of brilliance that slope = rise/run ... now my lines are actually straight paths to their targets! WOOHOO!
ahl suggest parameterizing the equations of the lines, but I'll leave that until I get everything else working. I'm really enjoying working on this project; it may be the free reign that it gives me (or it could be the fact that Missile Command is just frickin' cool ..)
Animators are the way to go! I'm using them for pretty much anything -- apparently they spawn multiple threads, which is nice -- I can use all kinds of different flow of control constructs and the like. I still need a way to implement collision detection; I'll probably sleep on it. My current plan is to have a collection or a sequence of some sort to store all active missiles in, and then use GP's collision detection to do the majority of the grunt work for me. It's 1:07am and I just had a Coke. Bad idea.
I'm still not happy with the way the good guy's attacks look. The way the math is done now, the line shoots "faster" when it has to go a greater distance. Maybe ahl's parametrization (sp?) method is the way to go; again, I think I'll have to sleep on it.
I decided to have the user switch between turrets using KeyInteractors (currently "z" for left and "x" for right), because having to click on turrets was just too time consuming. It works nicely, ever since I found out that Java's mod function doesn't work well with negative numbers. One if statement later, everythings swell. I'm still wired. Damn.
DAY 2: 3/3/98
I've decided to make my holder class check for collision detection
between falling missiles and anything. Most of my classes have a
reference to it, so it will make things easier and more encapsulated.
After a two hour (or so) hiatus, I came back to Missile Command with a new theory that I worked out with ahl for drawing the lines such that their speed is constant. It's documented in the xxxxMissile classes, but basically it treats the trajectory and such using basic trigonometry.
I also added a toolish startup menu from which you can select between communists and captialists, as far as political affiliation goes (doesn't do anything except change the color of the turrets, but ahs threatened to beat me if I didn't implement it ... er, or something.)
That's about all I did today.
DAY 3: 3/6/98
I added various little features, such as a game that actually perpetuates itself and one that you can keep playing. Current plans include implementation of scorekeeping system, which I think I'll stick in a panel off to the right side of the game -- I'm also considering adding snazzy graphics, but that'll only happen if I get some spare time.
DAY 4: 3/9/98
Ok, so there's been some down time. I spent awhile figuring out just what the heck I was doing, and realized that I need to change my design a bit. I have the Game object doing way too much; it needs to dellagate much of its duties to the Attacker class. It makes much more sense to do it that way.