Anyway, here is a shot of the targeting system and a test fireball spell in action:
When a spell is requested (currently only TestFireball is supported, via a hotkey, and enemies can't yet cast it. It also doesn't do anything except spawn an area of flames) the interface enters a targeting mode where a region of a certain size is targeted and tested for LoS against enemies and blocking cells. The interface shows a grid of blue hex overlays for valid locations, and the red X for locations out of LoS. Casting a spell will still work out of LoS, the spell will merely travel until it hits whatever is blocking LoS and explode there. I am hacking on various details of the actual system, but so far it works pretty well.
I also implemented the (relatively minor) fixes I needed to make to allow the player to adjust the game speed. Until now, the clock has been hard-wired at 3 updates per second. That doesn't seem like much, but one logic update represents the time it takes to walk from the center of 1 hex to the center of a neighboring hex; to move 1 unit, in other words. (Assuming no haste/slow effects.) So at 3 updates per sec, this amounts to a fairly decent pace. 2 is slightly slow, 1 is unbearable and very hesitant-feeling. However, it is possible and even comfortable to bump the clock up again, and I can definitely see a use for bumping the clock up during testing phases.
The thing is, in the current working version of the combat state, everything takes turns. The player's units get their turns first (no initiative rolls at the moment) then the enemy gets their turn. Each unit gets a number of movement points to use. The player will not end his turn until he asks to; I do it this way because eventually, when more combat is fleshed out, the direction a unit is facing will be important, and I want to give the player the chance to correct his facing after his turn is done, hence the need for an explicit End Turn command. Anyway, with a whole bunch of units, a single combat turn can take awhile to complete. Expert players or impatient ass-hats can bump the game speed up to soothe their demons of impatience. I could see setting the minimum clock at 4 updates per sec, and I think 6 or 8 is a reasonable maximum.
I have also been experimenting, as I said, with alternative combat modes. Specifically, a combat mode that is more like a rogue-like system. In this combat mode, the player is allowed to go first, and he can move any number of steps up to some maximum, or cast any spell/action. Once he has moved or cast, then execution is taken away from him and each enemy in turn is given a number of combat points equal to the number of combat points spent by the player to move/act. For example, if the player walks 6 hexes, then each enemy will be given 6 movement points in their subsequent turn. In this combat mode too, the camera remains locked on the player.
I am experimenting with how I want to handle the enemy turns. I can either a) make the enemies take turns, spending their full allotment of movement points at once, or b) interleave the enemy turns so that each moves 1 space at a time and these movements are simultaneous. This second alternative feels snappier, but the logistics of it are kind of difficult to figure out.
At any rate, once I get a fully functional version of this combat state, I want to upload a small demo that allows the player to select one state or the other and play it, to see if I can get some player feedback on which combat scheme works the best.
