Back to the swing of things

Srsly.

Evening, world wide web!

I love vacation.  I think vacation is the best thing ever.  It's even better than deep dish pizza.  And if you know me, you know I love that stuff.

Pic Unrelated.

But as much as I love sleeping in and stuffing my face (Aka vacation and being home) I have to be productive and stick with the rhythm of programming life.  So what have I done?  Nothing special or remarkable, just have kindof/sortof kept the ball rolling.

I created a very basic first build for my Zombie Yoga team, and I've received my very first ever Kinect (Bought refurbished off of amazon b/c I'm lazy and cheap like that) which means I get to start working with David on putting the Kinect to good use in our game!

We are building the game in the Unity game engine, which is a cross-platform development engine (literally, it will create games for mac, PC [perhaps ubuntu, but I'm speaking out of my butt right now] iOS, android and, if you pay big bucks, Xbox arcade, which is what we are currently banking on)

speshul tree for speshul kevin

Unity is, admittedly, really to use in a very very scary way.  For programmers one of the most important things they beat into our stereotypically-socially-awkward and stereotypically-glasses-wearing faces (I don't actually have glasses... yet, no comment on the social aspect of my life) is that all of your variables should be private unless you have a very good reason to make them public.

For those of you who have no idea what I mean by public or private, in code when you declare an instance of an object, or set up the foundation for an object in code, you have the choice to make your variables either accessible to the entire program (public) or to just that object and other objects of the same type (private).

If you make your variables, or the stuff that holds all the information in your object like health, or id number, or rank, etc. public then anyone anywhere who uses your code can suddenly get in and mess with your variables in ways you didn't intend.  If that was still too programmer-y for you, then the simple way of saying it is making a variable public is a very bad thing to do, and can break your code if other people decide to mess with stuff.

However, in Unity where everything (or almost everything) is based on drag-and-drop functionality and someway, somehow, everything has access to everything else, making your variables public is one of the only ways you can access those variables in the normal Unity editor.  The core game logic, such as the asset loading, using, rendering, and the game loops are all taken away from the control of the programmer (at least from what I can tell at this point) so where I would usually be able to pass variables to new objects upon creation (avoiding having to use public variables) in Unity when I drag and drop something into the scene the global set up is taken away from me, the instance pre-exists any commands that I'm used to being able to use during a game, so to rectify the situation I make variables public so that I can tweak their settings in the Unity Editor.

It gives me goosebumps thinking about how everything in Unity can just access everything else.  It's creepy for me as a programmer.  Then again I'm not programming wizard, others may see it differently, but let me use the following metaphor to describe how comfortable I am with Unity: I see unity as a very large and powerful rifle that descended from heaven to my lap during the zombie apocalypse that has one little flaw in it: every so often it fires a bullet that is secretly a tiny boomerang that comes back straight at you.

Aside from the fun I've been having with a full-fledged game editor, I've gotten back to work a little bit on my own stuff. David and I will be re-hauling what small fragment of a 2D engine I have now, but I'm determined to finish off at least one game with what I have (which I now see as an ugly mess of code, but that's what any programmer would see when he revisits a project he didn't properly comment/document)

And in that regard I've made a little bit of progress.

I've got a bunch of different buildings (see blue planet) and spaceship types up, now I just need to tweak, smooth, and slap a HUD onto this baby and see if I can get it on Xbox Live Arcade.  This is my pet project for the winter break, aside from Zombie Yoga.

I have all the necessary skill and knowledge to finish this game, it's just finding the time to put into it, I believe.
It's nothing big, but it'd be one small step for Kevin, one giant leap for... Kevin.  First game to be completed in, what, 5-6 years?!
Hope I didn't just jinx myself.

Cuz' all white whales look alike, right Ahab?  It's allllll about skin color with that dude....

Flowers, anyone?

- Kev

So uh... yeah, quarter's over!

I'm essentially writing to kill time.  I'll be home in a little over 16 hours, flight out of here is 10:30 and I land at 1:00-ish.

So, um, where to start this?  The beginning?  Well, not the entire beginning, I pretty much stopped posting around September... so October?

Wait, no... story time?

Taking four programming classes at one time was probably not the wisest choice ever made.  Taking two of those classes online was also not incredibly intelligent, but for better or worse, I have pulled through, piling other stuff on my plate as well.
But this isn't a blog about me, it's about the games I strive to create.  So what have I gotten done?

Does this answer you question? No?  Hm...

Well, pretty much nothing.  I'm now working on a game project lead by one of the professors here at DePaul, the title of the project is Zombie Yoga, I'll be taking on the role of a programmer and we'll be using the Unity engine as our main framework, so that's really awesome, but it takes away from the time I have for my own project.

Regardless, as the final wound to a close I was able to finally meet up with my equally-or-insanely-more-busy friend David and we have big plans to go back to the base "2D engine" that I started on over the summer and to add oodles and oodles of functionality and features.

We discussed putting in a template zombie plant class.

One of the concepts that we toyed with (read: David thought up) was creating a very dynamic class manager.

How many of you are programmers?  ...right, since my audience is probably zero, that number is probably zero, but on the off chance any of my friends are actually reading this (thanks so much!) you may or may not be familiar with the programming and the funny terms I'm throwing around.

I'll do my best to break this down as simply as possible.  And as somebody said, if you can't explain it simply, you don't understand it well enough.  Hope I understand this stuffz then.
Anyway, in terms of programming dynamic refers to anything that is created at runtime.  That is to say, when the program is building up these "dynamic" objects don't have to exist, they can be created on the fly.  The structure of these objects must exist before hand (in most cases), and their functionality, i.e. what they do needs to be defined, but when the program starts I as the programmer only have the reference to what this thing can do, and then if it's dynamic I can create as many of these objects as I want and tweak their values individually to make them do different things. 

To recap: I can make as many as my computer can handle and mess with them based off of one framework.

That handles the dynamic thingy I was talking about, now what was this about a class manager?

fer' real.

Well the way a program works is that you can easily create as many dynamic objects as you darn well please, as long as your computer has enough space (I'm simplifying the whole thing a bit, bear with me though)

However, when I create these new and dynamic objects, I have a problem.  Since my code is creating these things, I as the programmer don't have direct access to them, per se.  If I create a new object, it puts the memory for this object on the heap, but if I don't keep a reference to this object, or declare a variable to hold onto all of it's information, then, in languages like C++ I absolutely lose the object.  Poof, it's gone, it's still on the heap, taking up space, chillin, probably having a drink or two, or three depending, but there is zero means of me being able to access it again (I CAN go back through the heap and look for it, but that's a pain, not available  in all languages and unreliable at best)

POINT BEING that to keep track of all of these objects I need a container for all of them, most likely a list or deque, but that's also not important.  What's important is each type of object needs to have it's own container, or that's how it works best in games.  Certain objects can be grouped in their own containers, but it's a good idea to have an object manager, which is a class that holds the container of all of a certain type of object, such as tanks.  So I have a tank manager, it knows where all of my tanks are and updates them, but a tank manager can also do special things to all of the tanks, or change their behavior based on certain circumstances, such as let them all know "HEY! THERE'S A BAD GUY OVER HERE!"

Fire the slings and arrows of misfortune!  ...And the flaming harpoon of indifference.

Back to David... why is a dynamic class manager important?  Because Class managers, such as the tank manager, are going to look darn similar to my manager for bullets, or my manager for players in a multiplayer game.  They have the same structure, have the same container but different contents, and will pretty much run the same, but they will have different group behaviors that are specific to tanks or bullets.
Which means that I would have to write almost the exact same manager for each different object I wanted to create, differing only in the group implementation.  Which, as any programmer will tell you, is a pain and is generally really really really really really not cool, bro.

So David's solution was to create a template-ed game manager (A template class means, simply enough, it can take any kind of class if you want, usually it's used to put that class into a container)
That can take any kind of game object we wanted, tanks, bullets, players, chickens, self-aware bacteria, etc.
The template thing is awesome: essentially we say, hey, compiler, we want a manager class that can take any kind of class and manage it! The problem is that the template has the same code for each different kind of class that we put into the template.  So we can have a bullet manager, tank manager, and chicken manager that are literally written for us by the compiler based on our original template.(Though I don't think they are called templates in C#, whatever same concept)
So, we lose our ability to have special group behaviors.

Excuse the language

Well nuts, we can either write a bunch of really similar but kinda different manager classes, or write one manager class, but lose the ability to have those small differences that could make a big impact gameplay wise.
This is where David saves the day.

In our template-ed managers, we create a shell object, a game object that doesn't "technically" exist, and that isn't updated or drawn or etc.  Each of our game objects now contains a special function that actually contains the special behavior that we want our game object manager to have, and each game object we create (not dynamically, but in code, such as the base code for a tank, and the base code for a bullet, and the base code for a chicken, so on and so forth...) can have different versions of this function, which means the managers, even though they all run the same way on the surface (in the template) when they call the unique game object's special function, they get a different group behavior than a game object manager of a different type.  So tanks can be alerted to an enemy, but chickens can be told to run away by their respective managers, even though we only have one template manager class.

I have a feeling I didn't do this concept justice, and probably explained it very poorly, but if you skipped everything else and just got to this, or read all the way through and didn't understand any of it, I'll break it down very, very simply:
David is a genius.
I'm back to working on my own stuff, starting with this new template manager.
I'm so ready to go back home.

-Kevin

p.s. Get your doodle fix.

Plants versus... humans?

This isn't supposed to make sense, fyi