Now that the kid has been born and we're settling into somewhat of a new routine (albeit one with significantly less sleep involved for all concerned parties) I've found the time and inclination to pull Goblinson Crusoe back out and dust it off. Since the last post about GC, I implemented quite a bit more functionality regarding combat, etc... but the more I worked on it, the less I liked it. The most recent iteration has a very Diablo-ish feel to it. In effect, it has become what I really didn't want it to become: a click fest. Click button A, where button A is any button with a damage ability assigned to it. Click button A until the enemy dies or your mouse/keyboard explodes.

Now, I do love Diablo, and I've been enjoying the hell out of the Diablo 3 beta. But a click-until-stuff-dies-fest is just not what I had envisioned for GC. I'd envisioned more of a tense survival-oriented scenario, where actions needed to be carefully considered in regards to resource balancing, etc... So I want to get GC back on track. To that end, I've recently been experimenting with a turn-based combat system.

I've started on turn-based systems before, and the thing that I always discover time and again is that turn-based done right is significantly harder than a real-time action simulation. I know, I know, that sounds wrong. But it's true. Real-time is easy. So, so easy. But scheduling and orchestrating a turn-based simulation so that is looks sharp, feels smooth and solid, and doesn't annoy and frustrate the player is quite a bit harder for me.

Nevertheless, I've been making some progress. The current prototype hasn't come close to catching up to where the action-RPG version of GC was, but I'm getting a good handle on the scheduling and management of a turn-based scenario.

This new prototype introduces something else new to the GC universe: an experimental hex-based system, rather than the isometric system of before. Since I wanted to emphasize the tactical and strategic elements of survival as a young apprentice goblin wizard in a hostile wilderness, I wanted to introduce a hex grid. To me, hexes are so much better suited to a tactical type of game.

A final switch was the complete removal and extermination of the old hard-wired OpenGL backend, in favor of a new backend based on the Irrlicht engine. Or, at least, the Irrlicht Video Driver system. I don't use any of the 3D scene management stuff. Irrlicht has a fine, easy to use driver abstraction layer, but I've found its 3D scene manager to be sub-par for any practical project I've attempted. I much prefer Ogre. However, since GC is still fundamentally a 2D game, I only needed the driver bits. Now, the application can specify whether to use OpenGL or Direct3D for the backend renderer. This decision was forced upon me by the necessity of getting GC to work on the computers at work, which are quite old Dell boxes with Intel integrated drivers running out-of-the-box XP with no service packs. OpenGL GC worked, but it was slow and crash-prone.

So anyway, there I am. In terms of visual quality and feature set, GC has taken a significant step backward. However, already I am more pleased with the (still very rudimentary) battle system over the click-fest that the previous iteration had become. Stay tuned as I work the bugs out, and gradually re-introduce features, modified to suit the new format.

Some screens, showing the user selecting a path for movement. The red/green markers are placeholder as I try to figure out an icon set that looks and feels more appropriate. Green dots show where you can move given the current number of movement points you have left, red dots are locations out of range for current turn.