Tag Archives: C#

Cubegasm Source Code Release

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.

Octreegasm

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.

XNA Game Studio

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.

Cubegasm and XNA!

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.

Cubegasm’s First Dev Journal Entry

In lieu of actually doing any development tonight I, instead, chose to write a gaming article (still no Metal Gear Story; I’m still thinking about that) and then a particularly-lengthyGameDev .net Daily. Now, since I’ve given up hope of getting work done tonight and have accepted the idea that Battlefield: Bad Company will dominate my nights for the next few days, I’ll write about what I’m actually working on for the moment.

I’ve never worked on a project that had any sort of physics simulation occurring within it before; when I found out that Havok released their SDK that could be used by hobbyists and by any commercial product that retailed for less than $10, though, I retreated from my previous stay at HotelXNA and back into C/C++ Direct3D9 Land. I didn’t want to spend months writing a framework and a rendering engine, though, since I’m currently in the kind of mood where I want to put out a game every two-three months — atimespan which is variable based on game release dates, occasional social interests and obligations, and work schedules. It is a direct result of this mindset which led me to using OGRE. I spent a few days configuring my project, the engine (and all of the modules for it which I planned on using), andHavok in Visual Studio and then got about implementing a basic Havok simulation and rendering aesthetic worked out.

While doing these tests I had envisioned a bright, solid-colored color palette with a very minimalistic lighting scheme for the scene all with a slightHDR/Bloom glow attached. I had the Havok world and the cube objects all set up and working at the time the above screenshots were taken but, in movement, something felt wrong about the way they were interacting with the environment. I looked over all of the environment values that I had set and things looked alright. Then I realized that, when a cube-like entity hit a ground surface with a high restitution value from eighty meters above the surface that the chances of it rotating are, well, almost a certainty. And I wasn’t taking an entity’s orientation quaternion into account for the OGRE cube graphic whatsoever. So, yeah, fail. The right-most image in thefollowing trio shows that OGRE is having some difficulties maintaining high rendering speeds with all of the cube objects which, really, seems not so good. I’m either adding the entities/nodes to the scene in an unoptimized fashion or the debug rendering runtimes are extraordinarily slow. This is something I’m still playing with at the time of writing.

I got back to this codebase about a week and a half after the previous set of images was taken (Metal Gear Solid 4 needed some love and attention) and when I started up my project build I realized I didn’t really like the look things were taking. The aesthetic didn’t really match the one I had envisioned for my game so, this past weekend, I went about remedying that (with the most current image being the far right one):

And, now, I’m just cleaning up the codebase as it exists right now and thinking about what, specifically, I’m going to do for the game. My current idea right now is a sort of Fort Wars single-player game against the AI; each player has a structured composed entirely of cubes and each one is attempting to blow up the other person’s fort first to reveal a large target-like item in the center that, when exposed, must be hit a few times before it explodes and, then, ending the match. My idea is to make differing types of cubes that have a variety of effects once they are hit: some will give positive benefits to the player (increased damage radius, multiple launched projectiles per shot, etc.), some will give negative benefits, and some will simply be explosive that can take out a number of surrounding boxes at once. Whether this what I’ll actually do for the game is, at this point, completely up in the air. I’m going to code some initial mechanics and play around and see which seems like the most fun for me.

That is, of course, once I devote some time to Battlefield: Bad Company.

Asplode! v1.2 Release

For this update, my role in Asplode! was absolutely minimal. While I’m in the middle of a mild crunch for The Political Machine 2008 and then away at Rochester, New York for a Paramore concert, Josh was working asininely hard on version 1.2 of Asplode!. As started, my role in this update was purely peripheral as, in my spare time, I’ve been working on the start for Bipolar and taking some of Josh’s code for his game and turning it into a more generic library that both of us can use in our current and future projects (the library is HardCat Library, obviously). Anyway, major changes:

  • Fixed a bug where the player’s time alive, score multipliers, etc. weren’t getting reset for successive game sessions.
  • Fixed a bug/leak related to game audio.
  • Complete rewrite of the particle engine’s rendering (GPU-driven now).
  • Refactored the enemy code.
  • Now entirely functional on the Xbox 360.
  • Added an option for full screen.
  • High Scores!

Asplode! Installer
Asplode! Source

For some inexplicable reason, the XNA redistributable may still fail to install using the installer, so you may want to manually install it: XNA redistributable.