I've put in a few enemies now: there is a ghost-type enemy, and a mummy/zombie type enemy that both haunt the graveyard. The combat system is awesome and I'm really into the swing of it. I think it will be quite fun!
@p
In VtV I used an AI system similar to the one I'm using now, with a key difference. In VtV there was a distinction between an "AI Instance" and an "AI Pattern". Instances were a collection of variables; i.e., hit points, physics information, associated visuals, and eventually this grew to sort of an ugly structure. Patterns themselves were just a tree-like structure which represented different time-evolving changes to this structure; e.g., there was a pattern for flying from one location to another (this was the most complicated one), another for facing towards the player, another one that let me build up state-machines, etc.
@p
It seemed neccesary to have the Instance structure; just imagine if one pattern is responsible for regenerating HP and another pattern is responsible for making a choice based on total HP. They both need to reference the same variable.
@p
And yet, not every AI pattern cares about every variable! This is even true of for instance physics or visuals information, since some Patterns are responsible for spawning enemies but themselves aren't an enemy. Worse, I had to create sort of an Instance-level variable scope which was nasty to deal with. Even worse, since each Pattern had it's own local state, the AI state was now spread between the flat, shared Instance structure shared by all relevent patterns and the Pattern itself. And this was all in C++, ugh!
@p
In Texas, there is no Instance information (almost; I did something a bit wierd with NPCs that could/should/probably won't get fixed). Instead, as the AI is structured into multiple layers, each layer that needs to reference some kind of shared value just asks for that in it's constructor. So in the above example, both the HP-regenerator and the HP-decider Patterns would ask for a shared "HP" variable that they would then reference. Anything that wanted to make use of these patterns would then have to appropriately supply the reference to the appropriate variable, which is just logical consistance.
@p
This is all very lovely, makes great sense. The Instance and Pattern model only really makes sense if the Patterns are actually just flat, i.e., Instance becomes the parent structure that determines based only on it's own state what AI routines should run, rather than a shared kernel of information between Patterns.
2008-03-16