So I went back to the drawing board. I started with the basics of the game that I wanted to make and the constraints that I am placing upon myself for this particular project; in this case I want to make an action/real-time strategy which exists in a world populated solely by cubes (and boxes). And, unlike Asplode!, I wanted to make a fully-3D game; I think the gameplay could easily work on a 2D plane and, for the most part, it will work out that way in practice but, visually, I wanted to work in 3D and develop a toolset that I could use in either a 2D or 3D game going forward. Asplode! was my first full completed game -- even though I skimped on the feature set and presentation of it as finishing it coincided with the release of my first commercial game -- and now I want to make a full completed 3D game. Once I had my new design for Cubegasm all set and ready to begin work on I decided to abandon all of the work done with Ogre/Havok and go back to using XNA and, as intimidating as the thought was, just work from the very basic and mundane codebase that I established with Asplode! and go from there.
Looking at the barren, untouched, and innocent Cubegasm codebase I decided that my first course of action should be to establish a camera. I had absolutely no desire to write any camera code as it's something I've struggled with in the past and, although I've always come out of the skirmish victorious, I was never fully satisfied. So I did what any white-blooded American would do and went to the XNA Community Site and found camera tutorial samples, scavenged the corpses of code that were placed in front of me by the Internet and came away with a surprisingly decent camera. I'd give details about the mish-mash of techniques I used to create the 3D viewer but I don't want to bore myself to sleep quite yet. Here is a picture of the camera:
The camera posed very nicely for the picture, as you can tell. I suppose, more to the point, the scene posed very nicely for the camera. Whatever. That textured plane was absolutely horrifying, though, so I went about writing code for a procedurally generated grid which has perty polygons:
Since Cubegasm's namesake is, in fact, a cube then it should follow that my game will have a great deal of, well, cubes. Since I don't want to limit myself to rigidly-similar model dimensions, though, I decided that cubes are good friends with boxes and it would be a crime to not let boxes strut their six-sided stuff. Either way there are going to be a great deal of boxes and cubes that populate any given scene in Cubegasm so I wrote a set of routines for rendering large volumes of cubes and boxes at once; I call this creation a Box Batch. I group a number of box batches into a Material Box Batch which groups all boxes of the same material together and renders them at once. It's not very fancy but neither are cubes or boxes; they're simple primitives with primitive needs. One of their needs, for example, happens to be efficient rendering. I deliver, unto my cubes and boxes, that:
Be kind to the boxes and cubes. They weren't ready to be shown to the world yet but I told them that the world would be kind to them in their aesthetic infancy; I promise that they will, in a matters of weeks, look positively stylized and beam with chic digital fashion that only a certain type of graphical style can bestow upon their limited-detail meshes. Anyway, after the box batch was done I went about adding the various types of game XML structures (map, object, and fort structure) to the XNA content pipeline and that's not the quickest of tasks. So that's where I am right now.
So, remember, Cubegasm! It's an action/real-time strategy game where an army of brave cube warriors save their villages from roving box fortresses and evil box minions from imminent destruction! This game is shipping sometime before 2009. I hope. Or else I'll probably cry a little bit. I leave you with an action shot of Cubegasm development.
