Let’s start at the middle of the story. During what I refer to as The Second Necromancer Saga my laptop burst into flames like the Wicker Man. Since computers get names here at Star Frog only after they have died, that one was named Shiney. Yep, misspelled and everything. Anyway, along the way I created a backup copy for everything on the Shiney hard drive, including, but not limited to – Paper Zeppelin.
Now, usually, when somebody throws in the caveat “but not limited to” they’re just adding that as a bit of fun. You know, kind of a needless rhetorical flourish for, I don’t know, the “lulz” I guess? In this case, something very odd happened. The code base for Paper Zeppelin and a couple of other things that were inside those archives were spliced together.
So in Visual Studio, most projects are kept in these big things called “Solutions,” which is exactly the kind of corporate naming convention that entices me, nay forces me to call my own corporate projects things like Project Prometheus, and The Quicksilver Protocol. Inside these solutions are where your namespaces and classes all live. In the original Paper Zeppelin, I had created a rather large number of test projects, and simply left those in the archive as I went along. After all, what were the odds that any of them would come back to diddle me some untold number of years in the future?
Well, they were often just like, spliced into my main Paper Zeppelin archive. And since many test projects were ported into Paper Zeppelin that means that there is duplicate code and duplicate uses of certain variables.
On top of that, I can say with additional years of coding under my belt that the engine programming for Paper Zeppelin is…fine. It worked. Are there a bunch of parts that make me cringe though. Like, I got it into my head that tracking different Sprite types is best if I just assigned them all a number. So 29 is slanted up ground type. Why in the name of sweet puppy Jesus didn’t I just pass a string along that was like sGround or something like that?
Then, then, Visual Studio updated everything, and XNA no longer exists. Which means that the engine for Paper Zeppelin will not load and due to the above reasons I do not know why. It could be any of them. I don’t know. That’s exciting.
That all means that I basically have to port Paper Zeppelin. I’ve created a new file and am now in the process of moving over the pieces one by one. Along the way, I’m making adjustments to clean up the code where I can and add additional comments. (as a side note – thank you me from before for your prodigious commentary. I did this thing where I would leave notes when I learned something and explained it in the code itself, which is shockingly useful now. Other things, not so much)
But that brings me to my current issue. There was a class called Learning Game and another class called Game1 in the Paper Zeppelin archive, and I didn’t know which one had the code that was actually supposed to be there, after all both of them had the drawing code in it. Well, it turns out that neither of them should be. The Drawing code was actually within the confines of the SpriteManager class. The tip off that something was very, very wrong was that the Sprite Lists (player, enemy, particle, ground, and the unfortunately named sprite) were all local variables within the Sprite Manager itself.
Does it work now? It does not. Stay tuned.