Sometimes a bit of game development is easy, and you sit there, slightly dumbfounded, because you expected that bit to give you some sort of struggle. Struggle being, if not the default, at least the trend. I mean, there are 352 (!) posts here and the majority of them are not “Well, that was easy.”
In any event, I was able to get controls back online, and now you can fly the zeppelin around the screen again. Now, it wasn’t all easy. The original Paper Zeppelin engine was built using XNA, which was designed by Microsoft, which means that they installed a bunch of stuff to facilitate creating software for the Windows and XBOX platforms. In XNA, one of those things that they had the good nature to add was a suite of functions based on the GamePad object. The default buttons for said GamePad were the same ones that you could find on an XBOX 360 controller, which for our purposes were 2 sticks, a Right Trigger and a Start Button.
Since that’s what I had at the time, I went ahead and used that. It worked great and as I recall I was able to get it all up and running pretty quickly. It took a lot longer to install the control functions in The Thief’s Tale. Now that was a platforming game where the controls were a lot more context dependent, but that’s not the point. In Paper Zeppelin moving a stick which did a thing only took 2 lines total.
Monogame also uses the same controller protocol that XNA used, which means that they too use GamePad. The difference is that Monogame is designed to be portable to other platforms too, so I cannot assume that everybody has a Microsoft compatible controller just laying about. After all, I don’t. So I went and attempted to use the more agnostic JoyStick suite of tools, and those basically just refused to even recognize that anything was even plugged in. It was, annoying – but the solution was obvious. I needed the proper drivers on my Window machine to recognize the alien PS4 controller. After installing those (a program called DS4 of all things) Paper Zeppelin works great using that original GamePad suite. Now, that really isn’t the best practice and I would prefer to have native support for PS controllers in PZ. But then again, I can’t really go out and add full support for every possible permutation for controller setup available on PC, so I’m going to keep the GamePad suite as the only control method for Paper Zeppelin and leave it up to the player’s to make sure that they have the proper drivers installed.
Since that whole process took almost no time I went ahead and ported over the Player Bullet class so when you use the right stick it sprays bullets all over the place. I did discover something unsettling though, but to get there I need to roll back just a bit. The original Paper Zeppelin was written assuming a resolution that was standard for televisions at the time it was created, which had a total corner to corner resolution of 1080. It was a simpler time. But that meant that I could have these gloriously chunky tiles that were 32 pixels across and could neatly stack up 32 of them to cover the entire screen with gaming. That also mean that on the screen at any given moment there were (at most) 1280 tiled things on the screen. Not including player or emergent objects. So when you run the loops to check for collision, that’s what it would be checking against. That’s a lot.
Now, the resolution that the game now wants to be for new, better screens is about double that, which means a few of things. First I’m going to probably need to make adjustments to the levels themselves. The 32×32 tiles are now proportionally much smaller than they were previously. Second, a doubling of the length also means that the total number of tile based objects increases by a factor of 4 – so a full screen would have 6000 things on it. Finally, that means that the collision detection is slowing the engine way down due to how it was designed. It worked before, but before there were a lot few things it was checking since there were fewer things on the screen in the first place.
Which means…*sigh*, I need to update the collision detection. I have a couple of ideas. I could verify that Paper Zeppelin is actually checking collision boxes and not pixel collision. One is very quick and the other looks to see if there is any overlap of an image that isn’t part of the mask color or transparent. The latter is, to put it mildly, a lot less quick.
The other thing I can do is only run collision on objects that are anywhere near each other. In other words, I could do a check before looking for collisions to see if my 2 objects are within, say, 100 pixels of each other. Maybe less. That might be much faster. Another thing I could do is really clean up what exactly I am looking for collision for. Like there is ground that is fill so that there isn’t just a hole in the middle of a hill. Well, I shouldn’t check collision on that. Not really. It’s a lot of checks that would be irrelevant 99.9% of the time. Tests (and hopefully speed) incoming.
While checking for Monogame PS4 connectivity I discovered something interesting / unfortunate. You can, in fact, deploy a Monogame project to a PlayStation platform, which is great. There is actually a complete PS4 SDK (Software Development Kit), but there is a whole process to get it. The process doesn’t seem terribly arduous (Star Frog Games is, after all, an actual development studio) but it’s also not something that I need to really stress about in the interim. Absolute worst case, I would port Paper Zeppelin (again) to a new PS4 solution from the Windows / Steam implementation that I’m currently building. The main thing that I would have to adjust, ironically enough, is the control and GamePad functions.
Finally, let’s go out into the weeds and talk about classes and subclasses and how I do dumb things sometimes.So part of my “charm” is that I will run headlong into things, damn the torpedoes and all of that. Then, once I’ve figured out something that “works” I will advance to the next thing. As far as things go, it’s not my worst trait. Now, if I want to go in after the fact and make changes or updates then that gets trickier since I’ve built on top of a certain assumptions and then needed to continue to work within those confines.
In Paper Zeppelin, one of those assumptions was that classes and subclasses need to have all of the same information in them. So if I have a class that had Thing1, Thing2, and OxfordComma, then my subclasses would also need Thing1, Thing2, and OxfordComma. That’s a concept known as inheritance. In other words, the subclasses have all of the properties of the main class. Now, the sublcass might not need to use all of those main class properties, but they’re there if I want them.
Subclasses can also do something called Override. That’s where you can make the subclass have a different property than the main class. In Paper Zeppelin there is a class of objects called Sprite and a subclass called Ground which are the ground tiles. Those tiles all override the default image, size, position and so on of the main Sprite class, but again the fact that they have those properties at all is because they are a subclass of the main Sprite class.
What they can also do is have their over unique properties. I did not know this when I created the original Sprite class and subclasses. And since I was attempting to keep the total number of class properties small, I wound up using a single field to do a LOT of heavy lifting. That field is called “Misc.”
Misc is an integer. It’s used for things like which player a Fighter enemy is going to target and who a fortress is shooting at. It’s also used for things like tracking if a crasher type is going to burn out, and the HP for players. And the bullet timer for players. And whether or not a player is invincible after a spawn. It was doing all of that by doing a whole bunch of modulo division and, like I said before – if I’m going to build on top of it it’s going to be a nightmare. So moving forward when I port over classes I’m going to update their subclasses so that they have everything a growing subclass needs to be big, strong, and functional.
Next time, I’m going to continue the Design Notes for Dungeon Quest. Same Bat-Time, same Bat-Channel.