StepWood Games Development

In a world where random is king and seamless is required and visuals need to be spot on, shaders wear the crown.  Our game is no exception to this rule.  We’ll be using the graphics hardware at our disposal as well as we can of course, and that means new things to learn.  We expect them to be able to do everything from making our landscapes seamless to our characters and objects having nice shading to the time of day changing as you play.

Shaders can do all that and so much more it’s almost silly.  If you can think of it and then come up with a way to cram it into HLSL (High Level Shader Language) you can make it happen almost as an aftertought.  Almost.  Thankfully we started looking into this stuff well before it qualified as an afterthought because we realized that how we were doing things in XNA and the services provided by SpriteBatch and the like were somewhat lacking for this new idea.  Which of course meant another round of adjustments to our code base to better support it.  SpriteBatch itself doesn’t play especially nicely with pixel shaders that require frequent texture changes, so however much it pained us to lose some of the nice things it provided, we had to send it packing.

We have a good deal of features in our current shaders after seemingly countless hours of tweaking and adjusting by Alan, but we have grand plans to extend them into new realms in the quest of a beautiful game.  It should be an interesting thing indeed to see how this all comes out.

It’s been a couple weeks since the last post and a lot has happened.  Massive refactoring was done to make things work in a “better” way.  This included the near removal of the concept of a WorldLocation, the addition of several new interfaces and the deep reaching revisions of code to use those interfaces.

WorldLocation became MapLocation and moved between systems within the code about 42 times to finally end up in the MapSystem where it probably belonged all along.  To get around the problems associated with map coordinates versus screen coordinates versus animations moving things on the screen or in the world, etc., the lion share of coordinate space has been moved into generic points and rectangles provided by XNA.  This helped tremendiously in helping to arrange our supporting classes, but admittedly left in its wake an occasional wondering which coordinate space an object lives in when dealing with it.

A nested structure of interfaces was added to make things work in a far more generic way.  We are no longer loading sprites and directly drawing them on the screen, for example.  Now we are taking objects that are ICameraViewable and passing them through a Camera onto an ICameraView.  This is nice because previously we were forced to put things into Sprite that did not belong there, now a GameObject holds those and can do all the things a Sprite used to be able to do, but simultaneously a camera in no way requires GameObjects to draw.  When we got into making maps work, they became ICameraViewable too with an entirely different set of things to keep track of and yet still worked just like they are supposed to.

During all this refactoring and new coding we found ourselves in a better place with a more clear arrangement of our code and with more features than ever before.