StepWood Games Development

After another evening of working in an unscheduled fashion, focusing on whatever seemed to be needed most by the game engine, the skeleton of a camera system now exists.  Development on this new system quickly revealed that many tweaks and adjustments are needed in other areas of the game to make it work and still have any hope of following proper engineering practices.  Ideas that once seemed relatively sound are now fraught with gaping holes in logic and elaborate plans to better organize things.  

It may seem like something as simple as where an object lives in your game world or where it shows up on your screen would offer no itchy situations involving what objects actually know that information.  In reality however, it’s one of the most crucial tidbits to get right, and it doesn’t necessarily end up where you may have thought.  The fledgling camera system has shown us that we chose incorrectly in our initial plans and a bit of engineer vs engineer discussion revealed a far more intelligent place to put it.  Included in these changes of course come still more revisions to the badly beaten up collision system.

The idea at its core is a camera that does the translation between world coordinates and screen coordinates.  Between objects that can be seen and a viewport that shows them.  It is actually a bit cleaner and simpler than it sounds, but it’s still a good deal of work to “get it right.”  What started as “we need a camera system” became “do we really?” and then wandered back to “we sure do, except to do it right we need all these other things too.”  Thus far nothing shows up on the screen, but I figure that’s only a day or two off.

After an evening of working together to get through animation system bugs mentioned in a previous post, we’ve made a lot of progress and things are starting to come together nicely.  Our custom SpriteML™ XML format continues to become more powerful as new “operations” are added into the format.  The best part is, they work.  

Imagine a world where you can write an XML file, load a sprite, and with just a couple of lines of code have a fully animated character walking around on your screen.  I’m sure to people “in the industry” this sort of thing is commonplace and entirely non-exciting, but as a guy that has had a desire to code games since he was seven, and a profession that has had nothing to do with games at all his whole life, well, it’s pretty darn cool.

As things get trickier with the XML and features are added, a sprite editor program is beginning to make more and more sense.  Since that would mean a huge side effort that would need to be changed every time we tweak the animation system in the game (an occurrance that is extremely likely to happen a lot at this point) I think now is not a good time to start that project.  Choosing instead to favor the game itself with our development efforts.

At this point I still need to reinvent collision detection  to work properly within the bounds of this cool new system, but I don’t honestly think that will be so bad in the end.  After that it’s back to the map system, but this time with a better sprite system under the hood.  I stalled out waiting on features that now exist.  These are very exciting times indeed.

Lately our project has been evolving heavily as we build out the features of our engine.  The latest system to make its way into the ranks is our young sprite animation system.  This crafty system has managed to break all sorts of things as it offers a wealth of both new features that don’t work yet, and loads of features that haven’t been implemented yet.  For now, several older tests of other systems now fail outright thanks to new ways of handling sprites and new tests to play with animation don’t work yet either.  

I’m confident that the system will grow up to be an impressive one indeed, but for the moment we have definitely fallen into the old standby trap of one step forward and two steps back.  After some discussion and a night or two of coding, we should have enough of the animation system working to continue in other parts of the game.

After much tweaking and poking of the collision detection code, the pipeline code, and some impressive XML files, I can say this weekend’s quest to implement some basic collision test was quite successful indeed.  The new code takes in a couple of sprites and spits back out both whether or not they bumped into each other and if so, how it happened.  It detects first whether or not the sprites overlap on a basic level usually referred to as “Bounding Box.”  That is, do the rectangles that the sprites live in overlap each other at all?  If they don’t, well, then there is no point doing more work.  This test is brutally simple and fast and can almost instantly get you an answer if you don’t overly care about silly things like accuracy or have the amazing opportunity to check on sprites that completely fill their bounding boxes.

Once you know the pictures actually overlap, the next goal is to determine if they actually do.  I know that sounds weird, but a spaceship that lives in a box would have big sections of the box that aren’t full of spaceship, well, unless it was a really blocky looking spaceship I guess.  When a missle enters the bounding box in a section not full of spaceship but counts as a hit anyway, players get annoyed.  In a tricky process you can look deeper at the actual pixels of the spaceship and missle to see if they overlap.  This process takes a good deal of extra work to accomplish and can be a pain to make it go quickly.  That is where the pipeline comes in.

In the XNA content pipeline you have a unique opportunity to pre-calculate things to get them ready for use in your game.  By moving the heavier parts of the pixel level detection down into the pipeline you can take that load out of the game, which naturally makes it run faster.  Add to that careful additional checks and simplified math and logic to optimize what has to be done in realtime and you can end up with a pretty slick little piece of code indeed.