Still a-going

Not a whole heck of a lot to show off this time around. Some stability issues have been squared away, and I've just about removed the game's dependence on GUI elements being packaged with the application's resources and, instead, it draws them from the same resource archives it draws meshes and level data and whatnot.

This way, there is a single repository for almost everything that's displayed in the game. Currently, the splash image that shows is still embedded in the application repository, as that needs to be called before MOGRE and its resource management system has been instantiated. That is, in fact, the point of the splash logo. To display while these systems are initializing and loading, so the user knows that yes the program is launching. It just takes a few moments to load everything up.

Previously, each game state was able to hook into the overlying WebGUI element to display HTML content. However, each state was responsible for its own callback and input handling, and they loaded their HTML content via hard-coded strings. No longer! Now they load it from the game repositories. The net result of this is that an end user could, if they so chose completely break the in-game menus and HUD.

I kind of like the idea of the game interface being customizable. The behaviors of each element, though, is still under the purview of the program itself, so it's not like people can use it to cheat (though I will be very likely to write a save game editor myself, or at least have the save format something easy to edit -- like XML), just to change how the information is displayed.

As I mentioned before, nothing to particularly show off. The game looks the same so far, which is kind of the point. It just operates better behind-the-scenes.

In other news, I'm tentatively going forward with a modified Gamma World system as far as conflict/task resolution. It satisfies my needs of being easy-to-grasp, scaling upward in relative power without a finite ceiling, and being transparent about its own mechanics.

I feel like I should explain that second point: There's an issue that you run into with a lot of conflict resolution mechanics where arbitrary 'caps' are introduced. If the chance of success or failure is based on a percentage, then obviously those percentages will 'cap out' at 100% or 0%, respectively. I do not plan on having a level cap, and I want whatever mechanical system it uses to be able to steadily increase without capping out or becoming horribly horribly unbalanced.

I do plan on obfuscating the mechanics some, to make the player's interaction with them more 'in theme' with Bimbpocalypse, and to allow me to do away with a couple of elements in Gamma World character creation entirely -- notably a character's Origins.

When creating a Gamma World character, you select two origins (generally at random). These origins are things like 'android', 'rat swarm', 'pyrokinetic', 'ectoplasmic', and represent a fairly wide array of mutations. While I plan on having a couple of these more-or-less represented in the game, they will not be for brand new characters. A new character in Bimbpocalypse will be human, through-and-through. In Gamma World, though, a character's starting origins defines two starting abilities, their primary and secondary ability scores, and two of their trained skills. Doing away with selecting a starting origin leaves the primary and secondary ability scores and trained skills in the air. I plan to have a set of archetypes to encapsulate these. Things like: 'Brute' would have, say, Strength as their primary and Constitution as the secondary ability score. 'Tinkerer' might have Intelligence then Dexterity, and training in the Science skill.

This allows me to give the player some customization in their character's stats, but also lets me change the underlying mechanics without altering the player's interaction with the game interface.