Party time! Thanksgiving threw me off a bit, hence the extra week between updates, but there's been some craziness happening in the world of SummerJammers. Let's start by seeing how those goals from last time went:

- Fully implement Wall,Disc, and Goal classes

Goal is coming along nicely, including logic to construct goals out of an arbitrary number of GoalSegments for drawing purposes.

- Build a complete test stage with goals, wall, and bleachers

Nope. Turns out there was a lot of stuff that had to get done first, as today's update will make abundantly clear.

- Fully implement methods to convert on-court position to draw position

Done! Every drawable component has a DrawableParent and a RelativeDrawPosition, so it's super easy for a player to get it's on-court position and then add that vector to the court's actual draw position.

- Implement Draw transforms and logic for 1920x1080 and 1280x800 resolutions (more will be added later, I just want to have two different resolutions for testing purposes while I build that framework)

Done, and for any arbitrary resolution! Everything is first drawn to a virtual resolution that I set with two values in code, and then the SpriteBatch just scales the whole thing based on the target "real" resolution. Depending on the target aspect ratio, there will be either vertical or horizontal "letterboxing," but once I'm done with the Draw stuff this will just look like extra crowd around the court (as opposed to a big black bar). The virtual resolution will probably be 2560x1440, meaning that all assets will be designed with that resolution in mind so that only people running 4k screens will have to deal with upscaled textures. There are a few things I haven't been able to test yet, like position scaling, but the basic functionality is there. Also I need to add logic to balance the letterboxing so it doesn't just clump up on the bottom or right of the screen (the top left corner is the default scaling origin). Here's a screenshot showing the scaling effect from a 1920x1080 virtual resolution to a 800x600 target.

So, What Else Is New?

The past three weeks have seen some pretty radical changes to SummerJammers. Entire chunks of code have been removed or heavily revamped, with the most notable example being the SuperGameComponent and SuperDrawableComponent classes. As I mentioned last time, the SuperGameComponent was my way of enhancing the standard XNA GameComponent class with ways to keep track of "children" that would receive Update calls from their parents, and SuperDrawableComponent added the same type of logic for Draw calls. The problem with my implementation (and I knew it would be a problem eventually) was that SuperDrawableComponent didn't inherit from SuperGameComponent, which is what you should do when you're just expanding an existing class with extra functionality. The reason was that I wanted to inherit some of the event handlers from the XNA.DrawableGameComponent class, which meant I inherited from that instead of SuperGameComponent (and remember, you're not allowed to inherit from two different "branches" of the class tree). However, I realized that the event handlers I was trying to inherit (changes to DrawOrder) were rendered obsolete by the fact that my "children" system uses a SortedSet class that automatically sorts when the "key" (UpdateOrder or DrawOrder) changes. This allowed me to unify my component under a single inheritance column, which is good news.

Of course, now that I've done all of that work, I'm starting to realize that the extra functionality I've built into my SuperComponents could probably just be left to the individual implementing classes, like Player, Character, or Stage. There's a lot of overhead that goes into creating the SuperComponents, and all I really get out of it in return is the ability to say "go Draw your children" instead of "hey, you're a Stage, you specifically have a Court and some Players to draw." This is especially interesting in light of the fact that I removed my ImageComponent class, which was a class that by default would actually draw things to the screen, and moved the literal drawing into the SuperDrawableComponent class (objects that literally draw are tagged with a boolean called "drawsImage"). This got rid of questions like "is a PlayerCharacter a SuperDrawableComponent or an ImageComponent?" and has made the code a lot cleaner and more uniform. But still, it's very possible that, when it comes to my component structure, I may be able to trim some fat.

So aside from the work on the components, I spent some time on the asset management side. I added support for texture atlases, which has dramatically cut down the number of texture loads (which are super slow) and will make it a lot easier to implement animation down the road. I've also started building structures containing things like Courts and Characters - the things you actually see in the game! It was super exciting getting to a point where enough game and draw logic was done that I actually had to start thinking about those things.

But there's still much to do before I start roping in folks to create the assets that will fill up those structures. For starters, there are still a lot Draw issues to manage, such as rotation and relative position for objects built out of chunks, like a Goal built out of GoalSegments. Also, I'd like to play around with using mulitple render targets. This would allow me to draw things that don't change frame-to-frame (like the court and other static images) to an off-screen buffer once and just reuse them instead of redrawing them every frame. It's probably overkill for a game like this, but it's good practice! And don't worry, I'll include logic that only uses extra render targets if your card supports them, so it won't keep you from Jammin' if your hardware doesn't meet the XNA "HiDef" requirements of a DirectX10 card.

So what are the next goals? I have no idea! There's a lot that could get done right now, but it's mostly working with existing features rather than implementing new ones. My instinct is to take another look at the component structure and make a final call on that and then tackle the remaining Draw issues. I'll cut this period to one week, so check back in on December 23, 2013 to see what's new. I'm hopeful that calls for assets will start going out in late January.