…and Boom Goes the Dynamite
Rockets works now. First though let’s back things up just a moment and let’s review a conversation that I recently had with my computer.
“Alright computer, I have explosions and rockets. Everything looks okay jah?”
“Cool. So let’s run this thing and…where are the rockets?”
“I made them. Didn’t you see them?”
“Fine you rotten thing. I made the rocket exist for a really long time. Now I can see them. Where are the explosions?”
“I made those too. I think you are going blind.”
“Dammit, no. I would see a bloody explosion.”
“You’d think so wouldn’t ya?”
“Okay. Let’s do this. Let’s make an explosion every time the rocket is updated.”
“Are you sure?”
“Yes, I’m sure. Do it you bastard…you crashed.”
“Too many explosions.”
Eventually the conversation boiled down to this:
“Okie dokie then. You run the code on line 50 and line 52. But line 51 you skipped. Why is that?”
“Line 51 is hard.”
“On line 51 I’m supposed to make an explosion, and I don’t want to.”
“Well why the feck not?”
“Cause explosions are hard. I don’t wanna.”
“When does Spongebob come on? I love that show.”
Turns out that the computer (that stupid, hateful, wonderful thing) was doing everything I told it to do, but it was happening all so fast that it didn’t ever draw any of it. Which leads me to the odd conclusion that everything on the screen isn’t drawn every cycle like I thought it was. Odds are the C# is using some kind of internal clock to keep track of when to draw things. This is different than my Blitz Basic solution that checked to see how long it had been since the last time to decide to update again. I’ll have to keep that in mind.
Right, so now explosions and the rockets that bear them into the world work. It’s pretty awesome really. Bullets and rockets and explosions and planes and a zeppelin. For the first time today I played through the test level I built, dodging bullets and rockets and shooting and I found myself having a pleasant time. The fundamentals of play are at least fun in Paper Zeppelin.
A couple of things come up though. First of all, I think that I want wreckage. When I shoot down anything it turns into a ball of flame and falls to the ground. When it hits it simply disappears. Considering that I shot whatever it was, watched it fall, watched it hit other things and then hit the ground, there seems to be a lack of coherence in the experience. My brain expects there to be something left over. Preferably something that also has flames on it and smokes like a nicotine addled chimney. Hypothetically, I could create a single Class of broken things and give them different pictures when I create them.
Going back to my Chicken example from way back, I can give the Chicken any kind of variables. I can make tall ones or short ones and red ones or yellow ones. Heck, I can even combine the variables and make short red chickens. The point is that no matter what the variables are, the basic code that makes my robot chickens run is the same. They all follow the same rules.
So, with a crashed enemy, all I need to do is hand the wreck a different picture.
“What’s that? A Fighter just crashed? Okay then, make a Wreck and have it hold this picture of a crashed Fighter Plane. Great!”
It’s more or less how Crashing enemies work. I make a crasher and based on the type of enemy I give it different variables.
In any event, next up is creating the Rocket Launcher. I’m thinking that there should be some way for the Rocket Launcher to let a player know that it is planning to shoot. I could just create an animation that lines up exactly with the firing sequence, although that would make a damn big picture. The other alternative would be to use the misc field to somehow update the frame being drawn. Then I could slow down the animation to match. This would be preferable, but like what I found out before, the drawing happens when C# thinks that it should. So I very well may run into something stupid along the way.