Bullet Catcher

Created with Sketch.

Bullet Catcher

I’m now back into C# and the hidden mysteries within. I’m discovering that using a class based language requires some advanced thinking before really siting down and getting to work. The issue is the way the different classes are structured controls how they talk to each other. I seem to have discovered this the hard way.
Things overall, are going very well. I’m learning the basic syntax of C# although I am finding it a little odd. Say for example, where in Odin’s Crusty Beard is my fuggin “OR” conditional? I missing it obviously, because coding language couldn’t be that stupid. It can’t, can it?
I’m clearly on a tangent. Anyway, on structuring the code I tried a couple of different ways to organize how the Player Bullet Class will function. The first way was to think about it hierarchically. So thinking that Bullets come from the Player Sprite, they should be a sub-class of the Player Sprite. Turns out that was a stupid idea, because the code updates things based on a list. So when I add a new object (like a Bullet, or an Enemy) it adds it to the something I called the Sprite List. It’s very similar to the Object Code that I built for Thief, but deep in the guts of the C# language. In any event, when I made the Bullets a subclass of the Player Sprite, it had no easy way to talk add any of those things to the list, because that list exists somewhere else.
Long story short, putting the bullet creation that far away from my Sprite Manager Class (where the List lives) made it very difficult to have it do anything useful.
So I reasoned, “Alright then, everything gets to start and end at the Sprite Manager, since it’s the official Keeper of the List.” So I reconfigured the code so that it could keep track of which way the player was facing, float that variable up into the air where it could be caught and bullets created. That, after a fashion, worked pretty well actually. Not initially of course as you’ll notice from 3 posts ago, but I got it working yesterday. It’s something that will come in handy later, since at least one of the mini projects in The Star Frog EP will create bullets that way. I threw it out though, since it has nothing to do with what I’m currently into – Paper Zeppelin.
When coded right, yes, I can float a value from a sub class and have other functions and classes do stuff with it. However, for my purposes here, I really need to create bullets based on vectors using the right stick. Yes, I know that right stick firing shooters are de riguer, but here it actually works in both context and mechanically.
To get that working, I just had the Sprite Manager have a peek at the sticks, figure out direction, and round off the vectors. So say, the stick is pointing up and to the right. That has a value of Y being less than 0 and of X being more than zero. Or in codish:


RightStick.X > 0

So I rounded those off like this :

if (RightStick.Y

bulletDirection.Y = -bulletSpeed

if (RightStick.X > 0)
bulletDirection.X = bulletSpeed

That way, press a little or press a lot, the bullets all go the same speed in one of 8 cardinal directions. Then I make a bullet, add it to the List and booya, it dances like a drunk with neither pride nor rhythm. Which is to say, in a very entertaining way.

So, what have we learned here today? Well, I figured out how to create and update objects that just do their own little thing. I can use this to make enemies next. The difference will be in how they are created, either randomly (which I hate with a fury – being a design control freak) or by data tables (which I am very fond of). Then I be able to get collision detection working, which is the last piece of the game engine Triforce (Controls, AI, Collision Detection , which correspond to Courage, Power and Wisdom respectively).
Before any of that though, I need to figure out what enemies I need, how they act and how I’m going to going to generate them. So unlike Thief, I need a Design Document. I may even post it online – *gasp*!
Stuff inbound.