RFC: Hooks for a combat engine

I have been not-so-secretly working on a Drupal 6 implementation of my original Game module, with a slightly different approach to things but without all the hooplah, design, or scaffolding. I'm starting with the smallest playable component, the combat engine, and working outwards from there. Having just finished a turn-by-turn, page-load-by-page-load, game-state-saving version of the combat engine which supports 1v1, 2v1, 2v2, etc., I'm starting to branch out into a few other areas, but wanted to jot down my notes on adding an API to the combat engine. Your comments are appreciated.

What I am looking for:

• Suggestions regarding hook naming and implementation (drupal_alter vs. module_*, etc.).
• Use case scenarios, whether they work or not with the proposed implementation.

What I am not looking for:

• Commentary on the combat rules themselves. They're "finished". End of discussion.

Here are the combat rules that we'll be adding hooks too:

 1) At the beginning of a round, each player rolls a d20 for initiative.
    The highest initiative roll goes first; if tied, everyone re-rolls.

 2) In order of initiative, each player attacks with all their creatures.

 3) Attacking creature targets opposing creature and chooses an attack.

 4) Roll a d20 for this attack, add any relevant modifiers (from the
    creature's own natural abilities, equipment, local modifiers, etc.),
    and compare the final result to the opposing creature's armor or
    defense (as dictated by the chosen attack).

      * If a natural 20 was rolled (sans modifiers) on the attack roll, the
        attack is considered a critical hit: the attack automatically hits.

 5) If the attack matches or exceeds the opposing armor or defense, the
    attack is considered a hit, and the attack's damage is subtracted from
    the opposing creature's hit points.

      * If a natural 20 was rolled (sans modifiers) on the attack roll, the
        attack is considered a critical hit: the attack deals double damage.

 6) Repeat until only one player remains.

And here are the hooks I've jotted down. All hooks receive the entire game/battle state to work with (probably by reference, similar to the nodeapi for certain operations). Hooks, by desire, can mess around with any part of the game.

• game_battle_init: Right after the battle has been declared; the battle state has just been initialized, parties have been loaded and stored, and things are about to commence. Question: should this be _init or _start? Why?
• game_battle_round_start: Before initiative has been determined.
• game_battle_turn_init: After initiative has been determined, before turn start.
• game_battle_turn_start: Before any mob has started their attack phase.
• game_battle_attack_start: The attacking mob has been selected. This would be the primary place for modules to hook in some AI - having a computer player know which target mob to attack, with which attack, and yadda yadda yadda.
• game_battle_attack_rolled($result_op): $result_op would contain one of "success", "miss", "critical success" or "critical miss". Allows modules to react to successful or missed rolls (like a "fate module" that adds in giggle-worthy descriptions of utter failures, etc.).
• game_battle_attack_damage: The attack is successful and the initial damage has been determined. Allows modules to modify that damage output (perhaps a "dodge" roll can halve the damage, or the environment can increase it, etc.).
• game_battle_mob_condition($condition): $condition would contain stuff like "active", "destroyed", "invisible", "confused", etc. Allows a module to listen for those conditions, or even set them (via another hook, etc.)
• game_battle_party_destroyed: Fires when a party is destroyed completed.
• game_battle_turn_end, game_battle_round_end, game_battle_end: I'm not entirely too sure about these, but they would largely be the counterparts to the _start versions above. Garbage collection, duration checks, etc.

That's all fine and dandy, but how would you use them? Here are some examples. Your particular ideas, and their application toward this API, would be most ideal, as they allow me to see what you WANT to do, along with what you CAN, and CAN'T, do.

• Arenas: An arena plugin would sit on battle_start, adding descriptive messages about the battleground the player's are fighting in. It could also modify the game state based on the characters (an "underwater" arena could deal 10 starting damage to fire-based creatures, etc.)
• Flaming Weapon: A flaming weapon plugin could set a weapon on fire, and listen for battle_attack_damage, adding 5 damage to any and all attacks by an enflamed implement. Similarly, an addon could add a new "Dodge" trait which would allow mobs to dodge a successful attack, dealing only half damage.
• Charges: Some attacks are so powerful that they can only be used 2 or 3 times. A charges plugin would hook_form_alter() as necessary to prevent a player from choosing a depleted attack, and would sit on battle_turn_end to remove charges whenever a particular attack could be used. Certain capabilities could recharge an attack, and the plugin could listen on most any other hook to do that.
• Poison: If a weapon can poison a character for 3 turns, then this addon would listen on battle_attack_rolled('success') to add a duration to the current mob's state. During battle_turn_start, it'd check for the poison state, and deplete the mob's hit points if it was poisoned. On battle_turn_end, it would reduce the remaining duration, allowing the poison to eventually expire.
• Frozen: If a frozen ray hits a mob, not only is the mob encased in ice preventing his attacks, but he takes 10 shivering damage a turn. A Frozen plugin would process cold damage on battle_turn_start, as well as removing the frozen critter from the active list of attacking mobs.

This is all napkin design whilst I was babysitting. Rip me apart.