Well, maybe not lights, but certainly camera and action.

It's been a good week for SummerJammers. I only put it in two days of work, but I managed to knock out something big each time, and here are the results:

- Camera. The old render system drew things directly to the viewport, which would be a problem if I ever wanted to do things like zoom and pan. The new system is a 2D camera with a 3D position, with the z coordinate (which describes the distance from the things being drawn) used to handle zoom. This means that objects that are closer to the camera (like a popped-up disc) scale up in size so that the scaling doesn't have to be baked into the animations. The camera also, conveniently, automatically handles the letterboxing and related corrections that need to be made. The camera just takes a predefined chunk of "world space," transforms that chunk into "camera space," and then applies the resolution scale matrix to get it to "view space."

-Component framework. I completely removed the whole "trickle down" structure of the components. While it was nice to have a quick way for things to get passed down throughout an item tree, it made it harder to write code for more complex items, which ended up needing their own custom implementations of some of the component features. This eventually led to a lot of cases where there were two different ways to get the same results, which is bad form, so I scrapped the idea of having children managed at the Component level and instead have each game object do its own custom update calls (so instead of checking a generic UpdateableChildren list, a Match will explicitly send calls to its Disc and PlayerAvatars and etc.).

- Hit detection. Done and done. I use axis-aligned bounding boxes, which are rectangular prisms (since I'm using 3D space) with each edge parallel to one of the coordinate axes. Seeing as how the majority of motion in this game is simple translation, this is a perfect fit and the whole thing was crazy easy to do. In the course of about four hours I learned all about hit detection and then designed, implemented, and tested the collision system. It works! As for game-wide hit checking, it's pretty easy since there aren't that many objects that need checking, so I just check the disc against the players, bumpers, and goals and then make sure the players are in their allowed court regions (it's a lot easier to say where an object is allowed to be then where it isn't!). It's probably worth mentioning that XNA has built-in classes for bounding regions but that I am writing my own because I want to learn as much as possible about collision detection.

-Game logic! What I like to call the ons, the methods that tells objects what to do when certain game actions occur. For example, Disc has methods called OnCollideWithPlayerAvatar that resolves a collision and OnThrown that does things like clear the flag saying that it's being held by a player. This is the standard language by which all of the game objects interact with each other, and it's a good practice because it ensures that important attributes of objects aren't changed without permission and without doing all of the things that need to trigger when certain values change.

- Other things. Small things like adding code to relate the world location of an object (which I like to be the center of the object) to the draw location (which is upper-left-corner based) and some stuff that allows for image scaling for non-resolution-related factors, like if the art for a given character is a different size than the character's hitbox.

As of today, there are officially two Giant Bomb Windjammers remakes in the works (the other can be found here). Do I feel bad that somebody got as far in eight hours as I have in.. how many hours ago was November? Not at all! While this is by no means my first time coding, it's definitely my first time doing anything that draws to a screen or has hit detection or is, you know, a game. It's been slow going, but it's just because I've been learning a lot as I go and I don't move on until I fully understand what I'm doing. That is, of course, until I get down the line a bit, realize I didn't know what I was doing and go back and fix things (I'm looking at you GameComponent). The good news is that I'm out of the woods with regards to new stuff. All the rendering, collision, and file structure work is largely in place, which means that from here on out I'm doing stuff I already know how to do, which in turn means faster progress. Unless, of course, I keep falling down into computer science rabbit holes and spend half the day reading about red-black trees and culling methods.

But in a practical sense, this means there are now two projects which will potentially need contributors, so I'm going to put off the call for peeps until at least next week's update. Both projects seem to be in roughly the same place, so the big difference seems to be that this one is using XNA/Monogame and that one is in Unity, and also that I've never done anything like this before (but it's coming along nicely!). I have no interest in merging projects since the whole point of this for me (other than ending up with a bitchin' game) is to learn how to make a game from start to finish, so SummerJammers is here to stay. If you're looking to contribute code, however, definitely give the other project a look, as it's open source and all up on GitHub. Aside from network stuff down the line, I'll probably be handling all of the code myself, but need teams for art and sound asset creation.

So that's it for now. I'm off to clean up some code and add some more input logic. Next week I'll definitely be asking for contributors, so check in if that sounds like fun.