Syntaxus Dogmata

An Insane Developer's Journal

Spritely Sprites in Spriteland

The last quandary I’m slated to tackle is the whole cascading effects feature I’ve wanted for VertX.  See this post I made several days ago for details.  Originally, I was ruing the task of getting all of that working in VertX, but now I’m not so sure it’s going to be the chore I was expecting.

What I’m discovering now is that I don’t have much cascading left to do in the hierarchy, really.  My initial thought was to have sprite objects able to contain other sprite objects, but after thinking about it, I’m coming to realize that such a thing would be overkill for what I want to do with sprites.  Instead, I’m leaning toward having sprites contain multiple graphics (Texture2D objects), and manipulating them during the sprites’ Update() and Render() cycles.  That way their locations and transformations can be relative/cascaded or not as the game developer chooses.

So, in the time it’s taken me to get to this cascading effects issue, I’ve removed the Widget class from the hierarchy, added the Frame class, and decided that sprites don’t need to contain other sprites.  These three things together has made cascading effects something of a non-issue.  All I have left to do, really, is create a sprite with multiple textures, and voila!  I’m in business.

Once that’s done, I have a decision to make.  I could proceed to work on the Animation class, which is pretty exciting and a big leap toward making VertX’s a viable game development framework.  I’m tempted, however, by the prospect of working on Tetris again.  I’m in this to make games, after all, not merely to make an XNA-based framework for game development.  Tetris wouldn’t require any animations (that I can foresee right now), so this is an opportunity to actually put my framework work to work and make it work.

Yeah, that sounds more appealing.  I’ll extend VertX as needed with future games that are more sophisticated.

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

Frames Are On!

I finished the introduction of Frames into VertX.  They work great, and the Screen class has been refactored the way I described in my last post.  Screens became so simple, in fact, that I wondered if I hadn’t made a huge mistake and turned it into something of a vacuous class.  But looking at it now that everything’s working, there’s enough functionality there to justify its existence, I think.

As I worked, the thought occurred to me about how adding frames affected things like collision detection and mouse clicks in the future.  VertX doesn’t feature such things right now, but it will fairly soon, and I couldn’t help but wonder if adding frames into the hierarchy wasn’t unwittingly sabotaging such matters.

I figured collision detection wouldn’t be a problem, as long as I made it a rule that sprite collisions would only be detected between sprites in the same frame.  Implementing this rule would make frames quite useful, in fact, as they would separate out the sprites whose collisions I don’t care to detect from those sprites whose mutual interaction I do care about.

Mouse clicks, on the other hand, nearly made me reconsider what I was doing with frames.  Every time the player clicks somewhere on the screen, I have to figure out what it is the player is clicking at.  It’s a form of screen-wide collision detection that transcends all sprite layers — including any frames that happen to overlap at those screen coordinates.

Obviously, this already violates the rule I established two paragraphs up, and I don’t envy the poor bastard (me) who is responsible for writing the algorithm that works through all the frames and sprite layers in order to serve up the sprite that was clicked… if any!  Not only that, but it must do so in a manner that doesn’t severely impact performance for that game cycle.  How would it look if every time the player clicked the mouse, the game froze for an eighth of a second just to figure out what it was they were clicking at?

If you’re waiting for ol’ Syndog to pull a proverbial rabbit out of his hat with some slick mathematical solution coupled with a brilliant coding twist, expect to be waiting a while.  I get the feeling the solution to this problem will require a lot of experimentation and trial & error engineering to pull it off.

But just because my hat is bereft of all lagomorphs in this matter, that doesn’t mean I don’t have a few tricks up my sleeve.

The first is a flag I’ve already implemented the Frame class, labeling it as mouse-sensitive.  If there are no “clickable” sprites in a particular frame, then there’s no reason why the mouse click algorithm should consider that frame at all.  That alone can cut out a huge number of sprites from the process of elimination.

Another idea I had was to make only one frame mouse-sensitive at any given time, which would narrow the field even further, but I think that’s too impractical a limitation to place on the game developer.  When it comes to the organization of their sprites among the screen’s frames, I want them to have as much liberty as possible.  Mouse sensitivity will certainly affect the way they organize their sprites among the frames, but I don’t consider it overly restrictive, as having only one mouse-sensitive frame would be.

One way or another, I’ll work it out.  Who knows?  Maybe I’ll get lucky, and the process won’t be all that intense to begin with, and I’ll find I was concerned over nothing.  Were I a gambling man, that’s not the way I would bet, but stranger things have happened.

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

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.”

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

More about VertX Hierarchy Classes

Okay, I know this is a lot of Syndog Noise™ for one week, but there’s just so much to consider with this Frame refactor that I’m getting a bit overwhelmed.  And since writing it all out helps me organize my thoughts…

All this talk about encapsulating the instantiation of Screen objects in my last post has me second-guessing how this is currently achieved for all hierarchy classes in VertX.  When I first started piecing this beast together, I had a chicken-and-egg issue when it comes to hierarchy class composition of their parent and child objects.  After all, hierarchical classes would be impossible to instantiate if their constructors demanded a parent object and child objects as parameters.  By definition, no hierarchical class object could exist without a full set of preexisting hierarchical class objects to pass.

Catch-22 FTB.

To address this problem, I made it so parent and child objects could be added through accessor methods after construction completed, but before the SetUp() method was called by the engine.  If they hadn’t been added yet, then SetUp() would throw an exception and say it’s Miller time.

I never really liked this solution, to be honest.  It made me squirm in much the way Hanes Her Way do on Hulk Hogan.  Mired as I was in a conundrum of a hundred other dilemmas at the time, however, it was the only way I could see out of that particular issue.

Now I’m considering revising it so a parent object is required in every hierarchy class’s constructor, leaving the instantiation of any child objects to be encapsulated within the class itself, or by descendant classes if it’s abstract.  This is exactly the same as with the Screen class I mentioned in my last post, except this will be true for all classes at every level of the hierarchy.  From where I’m sitting right now, this comes off as a very clean and elegant solution that makes class hierarchy instantiation a breeze outside the API.

Time will tell.

So, before I introduce the Frame class, I’m going to give this solution a whirl.  For those of you who made it this far and managed to follow what I was gibbering about the entire time, I’ll let you know how it works out.  For those of you who didn’t, I’ll still let you know how it works out.  I’m flexible that way.  No need to thank me — your look of bemusement mixed with sheer horror is thanks enough.

Apr 13, 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