PZ Like Sunday Morning
The Big List is together for Paper Zeppelin, and at first blush it seems like a lot. I’ve made the mistake before of saying something to the effect of, “No problem. I can get this done in like an hour,” so I’m not going to let the size of the thing seem like it’s not a big deal. There are a lot of things on that list that still need doing, but worse for me there are good number of things that I would need to figure out. To wit, the stuff that goes under the “Classes” section for programming is all pretty basic on a fundamental level. They are all sprites and work the same way within the confines of the structure that I’ve built already. So adding the Ground for example, shouldn’t take to long. Making it work correctly, which also involved a rudimentary collision detection similar to the one employed in TTT is something else altogether. But that’s just logic and math, and is do-able by the stretches of most imaginations.
Less so are the things on that list that I need to figure out still, like the String Import Routine, where I’ll be able to import text into the PZ engine (I think I’ll dub it “The Paper Engine”) so I can build my levels using Excel. Otherwise I’m going to end up hard coding all of the levels, which I would rather not do.
The Game Types bit may also take a while, since A) I only have the one controller for my PC and B) I’ll need to re-write some chunks of code that are already there.
Of course that doesn’t include any of the art or anything, which will always take more time that I think it will.
The thing is, with certain caveats, nothing on this list is too terribly out there. There’s nothing in it like there is on the designs that I’ve written up for The Star Frog EP that would take some kind of extensive programming mojo to be discovered. I can do pretty much everything with what I know, and hopefully will have something up and running and fun to play sooner rather than later, which is always a good thing.
– The plan yesterday was to finish off some stuff and add some options for drawing on the screen. So if we look at the new Big List, the Dive Bombers and their dead versions are finished. Well, more or less. The little bits of code that drive them works, but nothing has been finalized yet in terms of variables. The important thing though is that they work and you can shoot them, and they fall in a big ball of fire and can crash into each other. It’s pretty cool.
-Also, I got rotation to work. It sounds really dumb, but it is important. Basically, there is only 1 function that draws stuff on the screen. So when I want to draw a bunch of things using C#, I tell the system to look at the list of sprites, and run the Draw() function. It works great. However, I realized when figuring out how the bloody ground was going to work, that I also need to keep track of some other variables like the rotation, and the color. However there was a bit of a problem, my master Draw() function didn’t have variables for these things, and none of the Classes (like Dive Bombers, bullets or players) had to track those variables. So I added them…to everything. It could be worse though, since I could have added this way later to my dozen+ things that the Big List says I should.
-Except for color that is. Different things know what color they are supposed to be, but I can’t make it work correctly. Basically, in C# you can draw something and add color to it. In PZ, players will all share the same sprite and animations, but will be colored differently. It’s how they used to do it back in the proverbial day.
Using C# it looks like this : Color.White
…assuming that “white” is what you want the color to be (which is to say, don’t add any color). So I thought that if I added a variable like this :
String tint = “white”
…then I could do this and it could work.
Except that it doesn’t. I built a bit of code that sorta gets around it, but it’s incredibly ugly and crazy limited. It does work well enough though, and there are too many things to do to spend time right now.
-Hmm, got a little technical at the end there.