Keeper of the House

Created with Sketch.

Keeper of the House

I’m thinking that I’ve got a pretty goo handle on C# now. It’s not quite yet enough for me to declare that “My Kung Fu is Strong,” but certianly enough to do what I demand of it. I’m also beginning to think about ways to do other projects in the docket, specifically the incredibly esoteric EP (a project that I very well could code is Blitz, since I’m fuggin Li Mu Bai in that particular Matrix). In any event, I’ve got a fine competentcy in classes. I can summon them, serve them, update them, and most importantly, I can make them talk to each other. Also, when I write things they tend not to crash outright, and that’s miles ahead of where I started. Far less swearing now – the key word there being “less.”
So yesterday after diving into the code I starte putting together one of the most basic enemies to allow me to code collision and so on, and I could not find a decent way to insert them into the code as it was. I made a new class of objects, gave it a few things to do and then could not easily add a way to pull them from nothingness. On a longer term, I’m planning on basically stealing the code out of one of the code samples that came with the C# compiler. In it a string of character is translated into tiles. I’m going to expand that considerably to allow for scrolling, and then spawn ground, enemies, background elements and everthing else through this system. Then I’ll be able to put together whole levels using a text editor. It’ll save me a bunch on time building tools, since my computer came preinstalled with WordPad. Of course, adding these additional functions to the “borrowed” code will require that I have a far deeper understanding of the thing, so I don’t consider it cheating.
Anyway, I haven’t done that yet, but I still need to create the little buggers so I can build the rest of the engine. My easy work around is to create them on the screen through a press of a button (the big green A button in this case). But I couldn’t, since all of my control functions were inside the spawning functions of players and bullets. It’s a situation that, I’ve learned the hard way, needs avoiding.
So, even though I really wanted to make little planes doing little plane stuff, I instead found that I had to rewrite and reorganize not un-small chunkies of code. So the spawn functions were stripped of their controls and a new centralized Control Function was built. After some, let’s say, dumbassery I got it doing a two step.
Along the way, I discovered the bestest thing ever (this week). By creating functions that only call constructors (little commands that make new instances of classes) I can deal with adding only the information that I give a steaming crap about. Let me try that again, from the beginning. Functions, as we know (if not, go back 2 years and read up to here {like anybody reads this}) are little bits of code that can be looked at and treated as little blocks of informations and instructions. So in Thief when I make the dude run, there’s a “Run” function that has all the code that makes him run. I could write that out every time, or I could do it once and label the whole chunk Run(). Later, instead of typing it out again, I just have to put “Run()” and the computer will go find the code I already did. It allows me to make changes in one place and have it go everywhere. The little ( ) at the end let’s me tell it stuff.
Constructors make instances. That sounds very complicated. The way I think about it is to say that the code for Classes are instructions for a robot. So all my Robot Chickens will follow the Chicken Class Code. When I call the constructor code for a Chicken, it makes a new Robot Chicken that will also follow that Chicken code. It’s a cute thing. When you make a new Chicken (or any new instance, chicken or otherwise) you tell it starting information and most of that information is the same every time.
This is where the two meet in the middle. So let’s say that there’s a dozen bits of information for making a new Chicken, silly stuff like animation frame information and stuff like that. The only one we care about is which color the Chicken will be. So instead of writing out the whole thing with a dozen little bits, I can make a function with all of that already there and a variable for the color. Then just do this :


It’s how bullets work now in the Prototype for Paper Zeppelin.

– Oh, up towards the top you’ll notice I mentioned that I try to avoid spreading my control functions all over the place. There’re a couple of reasons for that. The first is that, hypothetically, if I wanted to change something I’d have to find every single instance of the controls being looked at and update them, which is stupid. I know this because it took me 2 days to add gamepad support to The Thief’s Tale. Those are days I’m not getting back.
The other reason is one of speed. You see, a piece of software runs in your computer; CPUs and GPUs and motherboards and a bunch of other technical sounding things. Imagine that the innards of your computer are a city like San Diego. Now imagine that all the little bits are scattered around in their own buildings. So the CPU is City Hall, and the Motherboard is the streets and PetCo Park (or whatever it’s named this week) is your hard drive. Now say that the CPU needs some info from the hard drive, so it sends a message via Bike Messenger.
Since PetCo is reasonably close to City Hall, it’s a pretty short trip and goes pretty fast.
A controller or keyboard or anything else, isn’t even in the same city. It’s not on the same streets even. So say, the CPU wants to look at something at the keyboard. It again sends a Bike Messenger, only this time, he has to pedal his little ass all the way to Los Angeles. That’s kind of slow. Now do that a couple of dozen times per cycle and we see why that’s something to dodge. If you need to do it, just once should be enough.

– Hmm, technical post today. It’s what happens when the Designer also does all the programming then feels the need to explain it. I’ll see if I can’t use even more tortured metaphors in the future.