Syntaxus Dogmata

An Insane Developer's Journal

On To Frames!

All right, so it took more effort than I thought, but after much weeping, wailing and gnashing of teeth (and I don’t mean in a good way), I achieved what I set out to do in my last post.  No longer is the SetUp() method having to check for valid objects among the parent and children along the class hierarchy.  It required a few default objects to be made, which I hadn’t anticipated, but there you have it.  This also bought me the liberty to review the code already in place, and make a few minor adjustments.  Mostly it was eliminating code that I’d written under pretenses that ended up not working out in the end, and I neglected to go back and remove it.

So now, on to frames!

You’re gonna want to slap me around after I spent all that time fussing over sealing the Screen class a couple posts back, but I’m reconsidering the conclusion I reached.

If you’ll recall, I decided against it in order to keep screen creation simple.  If the Screen class isn’t extensible, that means all the custom, game-specific objects that compose a screen (sprites mainly) would have to be instantiated and added to the screen by the outside world, making that code more complex than it needs to be just to set up a screen.  I delight in simplicity, and the mechanism of choice by which I achieve it is through encapsulation.  That means the Screen class will need to be extensible, and I still stand by that.

So no, I’m not contemplating a sealed Screen class in the future (not that I’ll confess to, anyway), but I am thinking of abstracting the Update() and Render() methods from its descendant classes.

This wouldn’t make sense if the Screen dealt with all manner of sprites, all bouncing around the screen higglety-pigglety.  How else would the screen manage the various drawing effects and parameters of all those sprites?  The way XNA employs the SpriteBatch ensures any standard algorithm set in stone would be implausible.

But now the screen isn’t dealing with all those sprites.  With the introduction of the Frame class, sprites are now effectively abstracted from the Screen class.  Instead, screens deal exclusively with frames — a far simpler notion — leaving the frames themselves to deal with all those pesky sprites.  All it would take is for the Screen class to store its frames in a standard collection, and then call their execution methods successive to the order they were added.

In short, I’m making a compromise here between the two extremes of letting the game programmer go nuts overriding the fundamental operation of screens, and shutting them out of all customization completely with a single keyword.  Screens will execute the same across the board, but will remain extensible for the purposes of composition setup.

In the words of Gurney Halleck, “Behold, as a wild ass in the desert, go I forth to my work.”

Advertisements

Apr 14, 2010 Posted by | VertX™, Video Games | , , | Leave a comment

Widgets, Frames and Screens — Oh My!

Lots of activity this week.

I decided to follow through with my plans to remove the Widget class from VertX. As of now, widgets are no more, and sprites are directly interacting with their screens. Unsurprisingly, the transition went smoothly.

One quandary down, two to go!

Next, I’m pushing ahead with the “Window” class I mentioned yesterday. I’m actually calling it a “Frame” class, and I’ve decided I’m going to start out by using the GraphicsDevice.Viewport technique I was speculating about yesterday. It won’t do everything I wanted, but at least it’ll be a very simple way to start out, and it’s a chance to learn about an interesting XNA feature.

Where I’m floundering is what the imposition of the Frame class implies. Much of its functionality will be extracted from the current Screen class, which up until now has been a customizable abstract class. Now that I’m looking at how much functionality frames will replace in the Screen class, I’m starting to think that not only should Screen not be abstract, but possibly a sealed class that treats all of its frames identically. This shifts all the “smart code” from the screen to its frames — a distribution of complexity I see as a good thing. I delight in useful simplicity, after all.

The problem with making Screen a sealed class is that it forces a level of complexity every time you make a new screen. By making Screen abstract, I’m able to encapsulate that complexity in the Screen class’s descendants. That way, it requires only a single “new” statement to transition from one screen to another, rather than constructing all the Frames required, and adding them to the screen one by one from outside the Screen class. If I rob myself of that encapsulation, it shifts the complexity from within the Screen class to exposing it to the rest of the framework — not a good thing!

Come to think of it, the “smart code distribution” perk I mentioned will be spread among the frames in any event. It won’t matter if Screen is a sealed class or not.

That settles it. I think it’s too high a price to pay just to keep things stable the closer you get to the VertXEngine in the class hierarchy. The screens should encapsulate all of their own setup code, which means keeping the Screen base class abstract. See? I knew this dev journal was good for something.

Hey, shut up. I wasn’t talking to you!

Apr 13, 2010 Posted by | VertX™, Video Games | , | Leave a comment