StepWood Games Development

Our game has been progressing at a very pleasant clip for some time.  Many tweaks to the engine and additions to the capabilities it has as we struggle through the intense process of building a game from scratch have made their way into the code base.  During this process we’ve been testing things mostly on our PCs since that’s where we are developing.  We still generally compile the code for the XBox 360 just to be sure it builds, but beyond that deplying to the console is something that up until now has been done relatively infrequently.

This weekend was one such deployment.  The results were, well, less than outstanding.  We ran into things that worked so slowly we began to wonder if we were coding to a system that could get out of its own way.  Other things, that ran at a decent speed, did so thanks in part to not working as expected at all.  Overall we were comparing a “decent” laptop to an XBox 360, and the laptop didn’t just win, it destroyed the competition.

I for one picture games like Halo 3 and have mental pictures of a system with unlimited horsepower.  Afterall, how could such a game exist or function on the machine without said machine being very speedy indeed.  As it turns out there are several reasons.  To begin with, Microsoft doesn’t want just anybody coding to the metal of the XBox 360.  Indie developers, as we are now called, get XNA and C# in what is called a “managed code environment.”  They give us access to basically everything anyone would need to write a game, but do a good deal of keeping us out of the finer points of managing our own memory usage.

To those out there that are not coders, this may not mean a whole lot.  In English, they took away the need to care about memory management, but at the extremely high cost of imposing upon us something called a garbage collector to do it for us.  Ignoring the details of how a garbage collector works, the high level explanation is that when we are no longer using something it throws it away for us to free memory for later use.  As it turns out, the garbage collector they gave us is geared around tight management of memory and using as little as possible.  The cost of that decision is that the way it works is very heavy and involves throwing the game into a cocked hat while it’s doing it’s thing.

After literally days of work, we have stolen some of the power of that garbage collector back from the system at the high cost of effectively coding our own memory management.  Instead of letting the garbage collector steal our unused objects away from us, we effectively keep references to them forever.  This pattern prevents the garbage collector from caring about them since to it they are still in use.  It’s a careful balance and it adds a good deal of complexity to our code to use our system instead of theirs, but the improvements created by keeping the garbage collector from running all the time out weigh that nicely.  By the time we are done, with any luck, we will be able to run our 2D adventure game on the same hardware as Halo 3 uses without our game plowing through all the resources of that system.  Who knew we’d be pushing the envelope of horsepower on the XBox 360 with our game?  We sure didn’t.

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.

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.

Another night of coding.  I’m working on a small tool that will decompose images into various color regions.  It’s actually an interesting problem.  I tried two different methods, both of which resulted in “not quite what I wanted”.

One approach was to use a DisjointSetForest to split the image into adjoining regions of similar color using a simple Euclidean distance formula (considering R, G, B to be “coordinates” in 3-space).  While it works pretty well, it generates far too many disjoint areas to be useful given our typical input to the tool.

The other approach was to sepeate the image using Hues (from the HSB color space).  While this did an adequate job, it still generated far too many sub-images to be of use for the problem we are trying to solve.

I ended up with a simple breakdown of the image based on Hue and then an additional pass to recombine various “detail” areas back together assuming their Hues were close enough.  It actually results in a reasonable output from the tool, so I’m happy for tonight.  There is plenty more to do with it (and since we haven’t described WHY we want such a tool, I’ll leave that to your imagination).

And the project advances one small step in the positive direction…

Well, my partner in crime development has managed to inspire me to start writing my impressions of our new project.

Like Dave, I’m not yet willing to disucss the idea too much, but those people that know me well will have heard the idea in various incarnations in the past.  Other than being a vast simplification of my original ideas, it won’t be a big surprise to anyone when it’s announced.

I’ve laid the foundation for screen management, input, audio and started on the graphical viewport layer for “in-game”.  We are still quite a ways from anything to show, but at least some progress has been made.

Of course, like all good things, too much of something causes issues.  In my case, I broke the build.  *sigh*  Tonight that gets fixed and more foundation work is laid before I start into one of the major subsystems of the new game.

Till next time!

After many months of being too busy to do anything, things have settled down a little with our real jobs.  The side effect of this is of course that we started looking at our current projects for things we should be working on instead of doing nothing.  Well, that in turn made us realize that neither of us was feeling especially motivated to work on any of our previous ideas.  It’s a bad place to be thanks to ideas such as wasted work and lost hours, but it’s an excellent place to be for concepts like inspiration and inovation.

Many weeks of discussions and planning and spitballing and brainstorming and that type of thing has landed us with an idea that we like.  Development has finally begun now that the basics are sketched out and we are already making some pretty cool progress.  Until we are farther along it doesn’t make a lot of sense to expound the awesomness of our creativity and how much fun this game is likely to be, but I will say I personally like this idea better than card games.