Short story made shorter: I’m putting my XNA Action/RTS Cubegasm on hold. My framework isn’t nearly robust enough to make the kind of game I want to make and, since this is strictly a hobby project, I’d rather not have to put all of the gameplay on hold while I flesh out the necessary backbone in order to get to the “fun stuff.” I didn’t see this as a reason not to release the current code for the project, though. So I’m doing that. You can get the source package: here.
It’s not a very big release. Nor a very done one. It basically doesn’t do anything. It’ll load up a game map with one fortress firing bullets (that never get destroyed) at the player’s five cube-spawning points. That’s about it. How exciting!
Replacing Cubegasm is a game that I can actually play alongside development (also using XNA); it’s called Brain Snack. I’ll post some more information/screenshots when they’re not embarrassingly bad.
I assumed that it would be in poor form to have every single object in need of collision detection on a frame-by-frame basis to have collision tests performed against every object in the scene aside from itself I figured that now would be the time to add some form of spatial partitioning to my XNA engine/library/framework (Rawr).
With that in mind I looked around for some articles on writing an octree component and stumbled upon a really rad demo by Fabio Policarpo. I then adapted that to my codebase, edited the code as I, in my infinite ignorance, saw fit to do, and then added some rudimentary rendering functionality to the octree to provide what I assume will be a much-needed graphical visualization (in the future).
Anyway, it looks like a squishy death array of lasers.
For the record, working on Asplode! was so much easier. Anyone who says that 2D is harder than 3D is a dirty, blasphemous liar. No one says that, though. Because they are smarter than me. Not that I said that either. I think.
Let’s talk about games and, more to the point, the making of games. I’m going to start a weekly column (here!) sometime next week entitled “Mechanics” where I’ll do my gamer/designer thing by choosing a game that I’ve been playing recently and analyzing a certain mechanic or set of mechanics that, I think, are remarkable in some fashion. But that’s next week.
Microsoft did this really rad thing when they released the XNA Game Studio a couple years ago as a means of giving hobby game developers a means of creating games with a toolkit/API specifically designed for hobbyists that were interested in creating games. This isn’t the first time the company has done something like this, as DirectX fills a similar sort of need, but with XNA Microsoft decided to step up their game. So to speak. XNA is best described as the marriage of the higher-level aspects of DirectX, Microsoft’s own C# (a managed language), and the benefits of both the PC platform and the Xbox 360. The end result is a vastly more approachable environment for game development without a lot of the limitations of setups like Blitz Basic and pygame without overloading the less programmaticly inclined wannabe-game developers that may get scared off by the concept of working with C/C++ and DirectX or OpenGL.
With the original release of XNA almost two years old that is all old news; XNA 3.0 is currently in beta and will launch with an Xbox 360 XNA game browser capable of displaying and delivering XNA games made by the hobbyist/independent game developer community to the Xbox 360 owning masses in a Youtube-like fashion. That’s the idea, anyway. When I submitted my first XNA game I apparently crashed the console of the person who was reviewing my submission. I, apparently, failed to package the game correctly or something. Either way, my first game, which I’ll talk more about in a moment, was far from being up to snuff for any sort of widespread public release so the peer reviewer was probably just doing me a favor. The point is that XNA allows game developers to deploy games to the Xbox 360 with an only an absurdly trivial process required to setup the PC/Xbox 360 XNA game compatability. As far as building a copy of the source code for deployment to the Xbox 360? Well, once the XNA Game Studio executable has been installed and setup the only action required by a user is to right-click a project and select “Create Copy of Project for Xbox 360 [or Zune].” The first time I was able to see my game on my 360 it was exciting, to say the least — though, to say the honest answer, the first time I saw my game on my 360 I realized that I didn’t setup a way to deal with the interface without access to a mouse. Nor did I map a button for escaping the program. These realizations are all part of the experience.
That game I made was the first full game I’ve ever made. I called it Asplode! which, along with my current game Cubegasm, make for some very awkward conversations of the “Uh. What was the name?” and “I didn’t catch that” variety, but that’s neither here nor there. Coming from a C/C++ background with absolutely no thought paid to the concept of actually learning C# before utilizing it for a full game yielded some very awkward optimizations when describing my project to new people. Despite the many faults that Asplode! had it was a lot of fun for me to work on and, more to the point, it was the kind of learning project I needed to get my codebase the kickstart it needed for an actual 3D game project.
The lack of familiarity with C# is one of the reasons I’m writing this: with the release of XNA 3.0 due in the next few months, there is one very important thing that any XNA game developer needs to understand: memory management is necessary even within the confines of a managed language. The primary difference between working in a language like C/C++ and C# is that, in C/C++, memory is managed very carefully by the programmers and the task is, more or less, given to a developer whether he/she likes it or not. C#, however, cozies up to new programmers and holds their hands while all sorts of terrible code is written that may not rear its ugly head until the worst possible moment (end of the project). C# has an automatic garbage collector that, as the name implies, cleans up loose objects when they go out of scope/use. On the PC, the garbage collector is generational and can perform different types of collections ranging from gen0 (fastest; performed on simple object types with no finalizers) to gen2 (a full collection that actually halts the execution of a program). This is important to keep in mind for XNA game development for the PC platform but, on the Xbox 360, the garbage collector issues become more pronounced as the 360 GC isn’t generational so when it fires it actually has to pause all of the currently running threads while it does its thing.
This brings me to the impetus for writing this little introduction to a two-year-old system. For Cubegasm, my current action/RTS, I need vastly more complicated methods of handling rendering, updating, and then collision detection (along with a basics physics simulation layer). Now, I’m no good at physics nor am I a prodigy when it comes to the kind of calculus that is saved for a third- or fourth-semester college class but, due to the infancy of XNA as a community there isn’t an abundance of “middleware” that exist for C/C++ applications. When I was interested in integrating a physics solution into my game I heard good things about Bullet and, subsequently, BulletX but when I actually tried it in my project I discovered that it fired off the garbage collector every two seconds or so (down from the two times immediately after initialization that I had my game firing it at). So, as an aspiring game developer that wants to write his/her own program from scratch here’s what I’m going to recommend: think carefully about your game design. Ambitious is great, I encourage it, but no one ever got anywhere by being overly ambitious about a game project that, eventually, disheartened everyone involved with it to the point that it gets cancelled. And, if your target platform is the Xbox 360, then remember that your game isn’t going to be running on the latest greatest PC hardware but, rather, the hardware that is within every Xbox 360. What runs great on the PC is almost certainly going to run much slower on the Xbox 360 due to less powerful hardware, memory restrictions, developer assumptions about the system, and so on.
Now for a list of communities/blogs that will almost certainly prove invaluable:
In the end, remember: if you use XNA then you, despite being the kind of developer that has no publisher backing, money source, or the kind of time/manpower that full studios have, have the ability to develop a game for a goddamn console. Just think about how cool that is.
For the interested, along with the release of Asplode! I packaged up the project source code because I thought that it may prove useful or interesting to someone. It’s not incredibly well-organized or commented but I’m still using some of it for Cubegasm so it can’t be all bad.
What I’m about to say should come as no surprise to anyone who knows me, has talked to me, or reads my articles: my attention-span is lacking and I like being stimulated or challenged as often as possible. Take my obscene love for the Geometry Wars games; Geometry Wars: Retro Evolved 2 (since that’s what I’m playing the most now) is like playing a constant adrenaline rush that is a millisecond-by-millisecond test of a person’s hand-eye coordination and always manages to make players feel like they’re executing Jackie Chan-like maneuvers through the tiniest, most impossible of situations. Getting a good score in Geometry Wars is something that has kept myself and a person from Shacknews playing the game’s three-minute-long Deadline mode in a round-robin fashion since the game’s release in order to see which of us could get the highest score that the other simply does not have the skill to get — for the record, at this point in time it’s me with a score of 29.9M which ranks me, Xbox Live Tag: skmittens, as 241st in the world (my friend is somewhere around 400). Not only is Geometry Wars: Retro Evolved 2 a superb shoot-em-up but the developer, Bizarre Creations, maximized the idea of the High Score metagame that the GW2 formula brought with it through efficient use of the Xbox Live leaderboards which display the top five scores of the player and the people on his friends list in the game mode selection screen. It’s an absolutely genius design mechanic.
My absolute favorite game genre, though, is real-time strategy. I love the entire process of managing an economy, building up a base and an army, and sending out scouting and strike teams to wreck havoc on enemies. And, while playing Madden NFL 2009 every day for a couple of weeks, I found myself thinking more about the different plays that I had in my Detroit Lions playbook, how I was subconsciously figuring out ways to maximize the yardage I acquired on the following play and, in doing so, get the most of any play by taking advantage of what an opponent would think I would be doing given an offensive line-up. After a few games in this mindset I realized that, in a lot of ways, console football games really are a form of short real-time strategy segments with player/route bookends. It was strange how this realization made me not only enjoy the game more (and I already enjoy football and football video games a great deal) but also become a much better player online in the Shacknews Madden league
These two games — yes, Geometry Wars: Retro Evolved 2 and Madden NFL 2008 — got me wondering what kinds of possibilities were open to the RTS genre for more action-oriented strategy games that treated game maps as more of strategic set pieces for players to execute a specific strategy, see how it plays out, and then figure out ways to improve upon it to result in the most efficient execution of a certain “play.” Out of these thoughts was born Cubegasm.
The Basic Idea is this: a player is given five structures and these are placed at one end of a map. The rest of the map is then populated with a bunch of enemies, towers, walls, and strongholds. The only thing the player needs to focus on is clearing a given goal for a map in the shortest time possible while maximizing his/her score through efficient use of his units, quickly dispatching enemy units and structures, and ensuring the survival of the player’s five structures. Each of the five structures will spawn a certain type of unit; the spawning rate will be adjustable by the player in the sense that if, say, Structure A has its spawning rate jacked up then Structures B, C, D, and E will also suffer decreased spawning rates to compensate. The player can balance the spawning rate of his units to fit whatever strategy he plans on employing for a given map. I’m not sure about this but, ideally, I’d like there to be no hard unit cap placed on the player; instead, I will place a score “handicap” on the player when he starts using more than the map’s maximum suggested unit amount.
The five unit types will be consistent from map-to-map; these will be the toolkit of a player’s strategy. Through intelligent use of spawning rates, a player can customize his army to deal with any situation effectively. And, since this is something that bugs me a great deal about most strategy games outside of Supreme Commander, all of the attacks, both ranged and melee, will depend on actual collision detection. If a shell is fired from a ranged unit then the only way it will do damage to anything is if it actually collides with an enemy unit. The ranged unit will have code to handle predictive targeting of any target a player chooses (or automates) to reliably hit a target but, if the ranged unit is maximizing its range and the target is not stationary, it’s very possible for the shell to miss. The last thing I want is to just throw a bunch of random numbers into a mathemetical equation to determine if a unit hits or misses its target. The following units make up the crack squad of cubes in Cubegasm:
And, for an overall discussion of the game, I think that will do it for now. I’m working on the particle engine this week and, if things go accordingly, I should be able to start on implementing the structure logic and at least one of the five units for testing. My goal is to get a prototype level up and running by the end of October but that is, most likely, a pie-in-the-sky time estimate. If the prototype gameplay is entertaining enough for me and some of my friends then I’ll work on a map editor and go for a complete game with the concept. I’ve never really posted about a game design before so, uh, yeah. Feedback would be neat.
Cubegasm seems to be my personal Duke Nukem Forever in terms of the number of development platforms it has made a cute little nest in. The project, which I was originally calling Bipolar (since it was about a gigantic manic-depressive, self-abusing, blob that was a weapon of mass destruction if its happiness levels got too low), started as an XNA project using Torque X; though, I was very unhappy with the state that the 3D aspects of Torque X were in. After that I moved on to trying a number of different engines as I had no interest in writing all of the graphical routines from scratch — these engines included Power Render, Nebula, OGRE, and Torque Game Engine Advanced. Of these engines I chose to use OGRE with Havok as my physics solution as the game design was to make heavy use of physics puzzles. I made a decent amount of progress (with a full development gallery to serve as evidence). After my latest development journal entry, though, I took a look at what little I had to show for the time I spent with OGRE and figured: nahhh.
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.