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-lengthy GameDev.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 Hotel XNA 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 -- a timespan 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), and Havok 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 slight HDR/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 the following 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.